|
|
APPC Subsystem on MPE XL Node Manager's Guide: HP 3000 MPE/iX Computer Systems > Chapter 5 Managing the APPC SubsystemManaging APPC Sessions |
|
This section discusses the APPCCONTROL STATUS and APPCCONTROL SESSIONS commands. You issue the APPCCONTROL STATUS command to check the status of the APPC subsystem during run time. You use the APPCCONTROL SESSIONS command to control the number of active APPC sessions. At subsystem startup, the number and characteristics of active sessions are determined by the parameters in the APPC configuration file. However, once the APPC subsystem is active, you can use the APPCCONTROL SESSIONS command to change session limits and session characteristics so that they no longer match the configuration parameters. The APPCCONTROL STATUS command is used to get the current status of the APPC subsystem. The description of the APPCCONTROL STATUS command in Chapter 2 “Interactive Control Operator Commands” contains an item-by-item description of the display. This section uses several examples to illustrate the use of the APPCCONTROL STATUS command. In the following example, the APPCCONTROL STATUS command is issued with no parameters, so information is displayed for all configured session types and all active TPs. The display shows two configured session types: one independent and one dependent. The independent session type, INDSESS1, has no active sessions. The dependent session type, DEPSESS1, has two active sessions. Each active session is being used by a separate instance of the same TP. The TPIDs are different, indicating two different TP processes, but the Program File Name and TP Name are the same for both processes.
In the following example, the APPCCONTROL STATUS command is issued with the parameter STYPE=INDSESS2, so information is displayed for only one session type. Session type INDSESS2 is an independent session type with two active sessions. The identical TPIDs show that both sessions are being used by one instance of the same TP; that is, one instance of the TP is conducting two conversations simultaneously, over two APPC sessions.
The APPC subsystem supports up to 256 active APPC sessions. By issuing the APPCCONTROL SESSIONS command, you can vary the number of active sessions and reapportion active sessions among different session types. The following APPCCONTROL STATUS display shows the status of an example APPC session type at subsystem startup. This session type will be used in the rest of the examples in this section to illustrate the effects of the APPCCONTROL SESSIONS command.
In the example above, independent session type INDSESS1 has four queued session requests. That means four TP processes have called the MCAllocate or MCGetAllocate intrinsic, specifying INDSESS1 in the SessionType parameter. The session requests were queued to wait for available active sessions. No sessions of type INDSESS1 are active, because the configured number of automatically activated sessions is 0, and no one has issued the APPCCONTROL SESSIONS command to activate more sessions. After the APPCCONTROL SESSIONS command is issued to activate more sessions, the Current session limit in the APPCCONTROL STATUS display will be equal to the Number of Active Sessions. To activate sessions of type INDSESS1, you issue the APPCCONTROL SESSIONS command to raise the session limit for that session type:
When you issue the APPCCONTROL SESSIONS command to raise the session limit to 5, five sessions of the specified session type are activated. The maximum session limit configured through NMMGR is still 8, so you cannot raise the session limit beyond 8 with the APPCCONTROL SESSIONS command. Under Session Limits in the APPCCONTROL STATUS display, the Maximum value is the configured value. The Current value is the new session limit after you issue the APPCCONTROL SESSIONS command. After you raise the session limit, the following messages are logged as sessions are activated:
The LU acting as primary LU activates the session. Sessions can be activated by either the local or the remote LU. The following APPCCONTROL STATUS display reflects the status of session type INDSESS1 after the APPCCONTROL SESSIONS command has been issued to raise the session limit to 5.
The number of active sessions for INDSESS1 is now 5. This is the current session limit, which differs from the configured session limit. The configured session limit for INDSESS1 will always be 8, unless you modify the configuration file and restart the APPC subsystem. The four session requests that were queued have been given sessions, so the Number of Queued Session Requests is now 0. One session is active but idle; it is not being used for a conversation, so its TP ID field is blank. If two more TP processes request sessions, the first TP process will be given the idle session (the one with no TP ID listed), and the second session request will be queued to wait for an available session. The following APPCCONTROL STATUS display reflects the status of session type INDSESS1 after two more TP processes call MCAllocate or MCGetAllocate to request sessions. Five sessions are still active, and one session request is now queued. The session that was idle is now being used by the TP process with TP ID 1258.
If three conversations are deallocated, three sessions will become available for conversations. One session will be given to the TP with the queued session request, and the other two available sessions will remain active but idle. The following APPCCONTROL STATUS display reflects the status of session type INDSESS1 after three conversations are deallocated. The TP ID associated with Session ID 28 changes from 5413 to 2215; the session remains active, but a different TP is using it. The TP ID field for each of the idle sessions is blank.
To terminate sessions, you issue the APPCCONTROL SESSIONS command to reduce the session limit for a session type. The following command reduces the number of active sessions of type INDSESS1 from 5 to 2.
Idle sessions are terminated first. Since two sessions of type INDSESS1 are idle, these sessions are terminated immediately. Another session will be terminated as soon as the conversation using it is deallocated. The following messages are logged as sessions are terminated:
The following APPCCONTROL STATUS display reflects the status of session type INDSESS1 after the APPCCONTROL SESSIONS command is issued to reduce the session limit from 5 to 2. The Number of Active Sessions is 3, not 2, because the APPC subsystem is waiting for a conversation to be deallocated before terminating another session.
To terminate all sessions of type INDSESS1, you issue the APPCCONTROL SESSIONS command to reduce the session limit to 0:
This command terminates all active sessions of type INDSESS1. Sessions are terminated with a shutdown type of QUIESCE, meaning that all conversations on the affected sessions are allowed to end before the sessions are terminated. A message is logged for each session that is terminated. An APPC session can be terminated from the remote side. When the remote system terminates a session, the APPC subsystem attempts to reestablish it. The following is an example of the logging messages you would see if this occurred:
|
|