z/OS Communications Server: SNA Diagnosis Vol 1, Techniques and Procedures
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Index of resource activation flows

z/OS Communications Server: SNA Diagnosis Vol 1, Techniques and Procedures
GC27-3667-00

Table 1 lists the resource activation flows that are illustrated here.

Table 1. Index of resource activation flows
Flow Page
Activating a CDRM  
CDRM with COLD response, activating Figure 15
CDRM with ERP response, activating Figure 14
CDRM with a virtual route-based transmission group, activating Figure 16
Activating a cross-network SSCP-SSCP session  
Back-to-back gateway NCPs request sessions Figure 17
Gateway VTAM® requests session Figure 18
Non-gateway VTAM requests session Figure 19
Activating an NCP major node  
Channel-attached communication controller, activating Figure 1
Link-attached communication controller, activating Figure 2
Activating resources controlled by a host or NCP major node  
Link: Activating a link Figure 3
Link station: Activating a cross-subarea link station Figure 5
Logical unit (LU): Activating a logical unit Figure 12
Application program: Activating an application program and processing an OPEN ACB request Figure 13
Physical unit (PU): Activating a physical unit type 2.0 Figure 7
Physical unit (PU): Activating a physical unit type 2.0 with load required Figure 8
Physical unit (PU): Moving a dynamically added physical unit Figure 10
Physical unit (PU): Moving a SYSGENed physical unit Figure 9
SSCP takeover of peripheral node logical units (LUs) Figure 11
Switched connection, establishing Figure 6
Switched link with takeover, activating Figure 4
Figure 1. Activating a channel-attached communication controller
Diagram of activating a channel-attached communication controller.
  1. Includes NCP dynamic path definition capability indicator.
  2. Flows only for dynamic path definition. SETCV and IST929I flow for each dynamic path definition member specified.
Figure 2. Activating a link-attached communication controller
Diagram of activating a link-attached communication controller.
  1. Flows only for dynamic path definition. SETCV and IST929I flow for each dynamic path definition member specified.
Figure 3. Activating a link (ACTLINK)
Diagram that shows the flow of requests and responses between the SSCP and physical units to activate a link.
Figure 4. Activating a switched link with takeover
Diagram of activating a switched link with takeover.
  1. SETCV does not flow for NCPs that support peripheral nodes.
Figure 5. Activating a cross-subarea link station
Diagram of activating a cross-subarea link station.
Figure 6. Establishing a switched connection
Diagram of establishing a switched connection.

To establish a switched connection, the SSCP sends an Activate Link request to indicate that the link is active. An Activate Connect In request is sent to enable the communication controller to answer incoming calls. (Instead of Activate Connect In, Dial could be sent to initiate an outbound call.) When a call comes in, the communication controller sends an exchange identification (XID) and the physical unit responds with its ID (station address). The communication controller sends a Request Contact (Offhook) request to the SSCP. The SSCP sends a Set Control Vector request containing address and pacing information to the communication controller. The standard activation sequence then occurs.

Figure 7. Activating a physical unit type 2.0
Diagram of activating a physical unit type 2.0.
  1. An XID, instead of an SNRM, will flow to a switched line.
  2. Additional RUs flow if the physical unit must be loaded. These RUs are shown in Figure 8.
Figure 8. Activating a physical unit type 2.0 with load required
Diagram of activating a physical unit type 2.0 with load required.
  1. This figure shows only the RUs that flow when a type 2 physical unit requires loading. For the RUs that flow before and after those in this figure, see Figure 7.
  2. NS_IPL_TEXT and the response might repeat.

For type 2.0 physical units that require loading before they can be activated, the request for load is indicated in the ACTPU response. (During the activation, the physical unit might request loading with an NS_LDREQD RU.)

The SSCP formats the load request into a network services (NS) RU to initiate the load. The management services subcomponent of the SSCP then sends the embedded request to the physical unit load program of the Downstream Load Utility.

If the physical unit load program is not available, it sends a negative response to the SSCP's Deliver RU. The SSCP then sends an NS_IPL_ABORT RU to the physical unit for deactivation processing. (If the load was requested with an NS_LDREQD RU, the physical unit is not deactivated; in fact, it might try the load request again.)

If the physical unit load program is available, as in Figure 8, it sends a positive response to the SSCP's Deliver RU. When the load program is complete, it sends a Forward RU, containing an NS_LOADSTAT RU, to relay the status of the load operation.

Figure 9. Moving a SYSGENed physical unit
Diagram of moving a SYSGENed physical unit.
  1. RNAA flow is as normal. RNAA does not flow for MODIFY DR, TYPE=MOVE, ACT=NO.
Figure 10. Moving a dynamically added physical unit
Diagram of moving a dynamically added physical unit.
  1. RNAA flow is as normal. RNAA does not flow for MODIFY DR, TYPE=MOVE, ACT=NO.
Figure 11. SSCP takeover of peripheral node logical units
Diagram of SSCP takeover of peripheral node logical units.
Note: The following conditions are assumed for this example:
  1. The physical units being taken over are defined with ANS=CONTINUE, specifying that any LU-LU sessions that are active at SSCP-failure time will continue.
  2. There are some LU-LU sessions active at failure time under the physical unit being taken over.
  3. Independent logical unit only (possible multiple RUs).
  4. Dependent logical unit only.

Figure 12. Activating a logical unit
Diagram of activating a logical unit.
Figure 13. Activating an application program and processing an OPEN ACB request
Diagram of activating an application program and processing an OPEN ACB request.
  1. These do not flow for OPEN ACB processing.
  2. PUNS cannot send a response to the OPEN ACB request until LUS receives an ACTLU request for the application program. Therefore, PUNS issues CPWAIT and waits for LUS to post it. After LUS has received the ACTLU, it posts PUNS, which then sends a response to the OPEN ACB request.

For the close ACB flow, see Figure 16.

Figure 14. Activating CDRM with ERP response
Diagram of activating CDRM with ERP response.

Figure 15. Activating CDRM with COLD response
Diagram of activating CDRM with COLD response.
Figure 16. Activating a CDRM with a virtual-route-based transmission group
Diagram of activating a CDRM with a virtual-route-based transmission group.
  1. If the transmission group is an intermediate routing transmission group (NN–NN), the topology database update (TDU) will be built and broadcast. If the host is a migration data host, the topology database update (TDU) will be built and sent to its server.
Figure 17. Back-to-back gateway NCP request sessions
Diagram of back-to-back gateway NCP request sessions.
Figure 18. Gateway VTAM requests session
Diagram of gateway VTAM requests session.
Figure 19. Non-gateway VTAM requests session
Diagram of non-gateway VTAM requests session.
Parent topic: Resource activation flows

Go to the previous page Go to the next page

Notices | Terms of use | Support | Contact z/OS | zFavorites



Copyright IBM Corporation 1990, 2014