Network Director Dispatching

Originally published: Fall 1999

Making calls to Technical Support probably ranks pretty low on your "Things I love to do" list. Understanding this, we reviewed calls to our own Tech support department, and found that many of the calls inevitably lead to the topic of Network Director dispatching. We hope that the following discussion on understanding, viewing and controlling dispatching helps to answer any questions that you might have in this area.

Background

The Network Director operates as a single Operating System task within a VSE, VM, or OS390 operating system. However, it needs to operate in a "multi-tasking" environment in order to satisfy its throughput requirements. The multi-tasking environment allows the Network Director to manage a large number of tasks seemingly at the same time. As you might guess, doing this without relying on the Operating System's built-in multi-tasking structure presents a bit of a challenge (or shall we say "opportunity"). Some of the tools that allow the Network Director to do this include the Dispatcher, Dispatchable Functions (DFBs), and the Network Director's architecture itself.

The Dispatcher

The Dispatcher provides logic that manages the multiple tasks existing under the Network Director's control (a task within the Network Director is referred to as a Dispatchable Function or "DFB").

Here's how the Dispatcher works: First, it scans through each logical task(DFB), which are arranged in a priority order on the "DFB Chain" (anchored on the PDA). If a task is ready to be processed, the Dispatcher passes control of the task to the "ready DFB" within the Network Director's address space, partition, or virtual machine. When the DFB accomplishes its goal, it turns control of the task back over to the Dispatcher (at an appropriate time). If there are no DFBs ready for dispatch, the Dispatcher enters an operating system WAIT until something wakes it up.

All about DFBs

Each DFB (Dispatchable Function, also called a "task") within the Network Director can make full use of the asynchronous facilities of the operating system functions. This permits the individual Dispatchable Function to relinquish control to the Dispatcher (TNDDISP), which can then pass control to a different Network Director task (DFB) while waiting for the requested function to complete.

Need a comparison? A DFB is roughly analogous to an OS TCB, CICS TCA, or individual VMBLOK. A set of macros permit the individual programs within the Network Director's nucleus to pass control amongst the various Network Director functions without issuing a "synchronous"request that might suspend the Dispatcher.

The individual DFB (see the figure below, right) contains all of the key information that the Network Director needs for evaluating the DFB's readiness and giving control to the appropriate portion of the Network Director's nucleus when the DFB is ready for dispatch. The Network Director uses a "ECB Posting" methodology, where the ECB exists in the DFB or is pointed at by the DFB, to determine when a request-such as Disk I/O or VTAM session requests-has completed. The unique registers associated with the DFB are also anchored in the DFB. This permits the Dispatcher to return control to a specific location within the Network Director's nucleus, providing it an exact mapping of how we logically reached a specific point within the nucleus

The process of swapping the register save areas from CSECT to CSECT within the Network Director's nucleus is called "dispatching". This specific architectural characteristic gives the Network Director a responsive, high-throughput operational mode.

Displaying the DFB Chain

You can view your system's active DFBs by issuing a DISPLAY DFBS command from Network Administration; this will produce a DFB chain similar to the following:

0249R DISPLAY DFBS
0262G DFB OPER is in ECB wait at 02A8 in OPER priority 200
0262G DFB MNTR is in Timed wait at 0104 in MNTR priority 180
0262G DFB INPUT 02 is in ECB wait at 2024 in VTAM priority 150
0262G DFB INPUT 01 is in ECB wait at 2024 in VTAM priority 150
0262G DFB PO is in ECB wait at 2024 in VTAM priority 140
0262G DFB SEL is dispatching at 1836 in REPT priority 100
0262G DFB MAINT is in Timed wait at 01AA in MAINT priority 20
0262G DFB NTWK is in Timed wait at 0140 in NTWK priority 10
0262G DFB TIMER is in ECB wait at 0176 in TIMEOUT priority 0

Controlling the DFBs in your shop

The DFB Cycle figure (see "The Dispatcher") shows the generic names for most of the DFBs in your system. During periods of high activity, the Network Director will "attach" a high volume of SEL DFBs to manage the work associated with the individual devices on your network.

The GLOBALS ACTIVE-MAXIMUM value determines how far the Dispatcher will look in the DFB chain to dispatch something. This gives you effective control over the amount of system resources consumed by the Network Director at start up (initialization) and during extremely stressful periods.

Considering the Network Director's Architecture

This basic Network Director architecture also provides valuable information if you are considering changing the Network Director's performance group (MVS systems), if you are establishing its partition priority (VSE), or even if you are just trying to understand how it handles so many devices in a single GCS machine (VM).

We hope that this discussion lends some understanding to how the Network Director dispatches tasks. If you still have questions concerning this issue, please do not hesitate to call us.