|
Running SSCTL starts MSO. This program becomes the main task of the region (normally SSCTL runs as the "job-step task", in OS/390 terms). This task spawns many other OS/390 tasks, often called subtasks because they are children of the main task. The two main categories of tasks in MSO are the control tasks and the user tasks. Control tasks help MSO to perform its job of managing the users. User tasks are the ones where each FOCUS user has their own copy of FOCUS. |
In this section: |
The following is a schematic of the MSO address space.
SSCTL is the task that manages the overall execution of the MSO region. When the MSO server starts up, it reads the configuration file (FOCMSO) to determine what options are requested for this execution, such as security, usage accounting (SMF records), fast loading of modules, console options, how many FOCUS tasks to start initially, the maximum number of users to allow, and so on. It also reads the name of the VTAM applid assigned, and if specified, opens the VTAM ACB to allow logons. SSCTL then attaches all of the control tasks and user tasks. When the message
(MSO13023) ALL INITIAL SERVERS STARTED
appears, initialization is complete, and logons can be processed.
During normal operation, SSCTL handles users logging on and off. Requests may come either via the VTAM logon exit or from the SSGET control task (for CICS and TSO). Work given to SSCTL is queued in the order received and executed sequentially. Because of this, most requests are broken into many parts, each of which can be speedily dispatched while SSCTL moves on the next work item.
The goal is to make sure SSCTL is never waiting for a unit of work to complete on behalf of a user. When the first portion of a request completes, it schedules the next part to SSCTL, and so on. Thus a logon from a CICS user to a FOCUS task may take either one or two steps: first, the logon request from SSGET is received. If a FOCUS task is already loaded and available, the user is assigned to that task, and it is woken up to begin execution for the user. If a ready task is not available, one is started. SSCTL then goes on to service someone else. When the FOCUS task started is ready to accept the logon request, it sends a queue element to SSCTL, who then completes the process, and the user's FOCUS session goes live.
VTAM users log on to MSO by first driving the VTAM logon exit established for the VTAM ACB opened when MSO came up. This logon exit operates asynchronously in the SSCTL task; it queues a message to the synchronous part of SSCTL to report that a logon request has been received. The VTAM logon request passes certain information to MSO, which determines what MSO will do next. If the terminal logging on supports the "queryable" attribute, MSO will issue a "query" to the terminal. This is simply a VTAM operation that returns additional data about a terminal and its capabilities (screen size, support for color, and so on). If user data was passed in the logon, it is analyzed for an MSO "fastpath" logon. The user data can contain the userid and password of the user logging on, thus allowing MSO to bypass the standard MSO logon screen and go straight into FOCUS. If there is no user data, then MSO next puts up its logon screen to solicit the users' userid and password.
All VTAM operations discussed so far occur as asynchronous exits running within the SSCTL task. Once a user has finished the logon process and is assigned to a FOCUS subtask, however, the FOCUS task takes over the VTAM conversation and begins to converse with the terminal using synchronous communications. SSCTL is no longer needed for the traffic of user screens being passed back and forth, since the FOCUS task is speaking directly to VTAM.
SSCTL is posted whenever any FOCUS task ends. SSCTL makes sure that all resources belonging to that user are cleaned up, such as allocations, memory, communications thread, and so on. After detaching the old FOCUS task, SSCTL may start a new task so that it will be initialized and ready when the next logon request is made.
SSOPER is another MSO control task. Its function is to process commands (MODIFY or STOP, usually abbreviated F or P) from the MVS operator's console. Even though SSOPER is a subtask of SSCTL, it runs at a higher priority than SSCTL does within the MSO region. This is done to ensure that no matter how busy SSCTL becomes, MSO will always respond to operator commands or queries.
SSCON is the control task where the MSO Console runs. This subtask accepts connections via VTAM, from multiple terminals and allows authorized users to view and/or control the operation of the MSO region. A complete description of this process is provided in The MSO Console. SSCON runs at a priority below SSOPER but still higher than SSCTL, again so that control and query operations will take precedence.
SSGET is the subtask responsible for receiving messages from TSO and CICS users. MSO uses an inter-address space communications protocol to send messages from TSO and CICS regions to SSGET in the MSO region. The protocol uses an OS/390 subsystem to accomplish this communication. When a user sends their first message to MSO, SSGET queues it to SSCTL as a logon request, as discussed above. Messages coming in for users already logged on are given directly to the FOCUS task that was assigned to this user by posting the ECB that the task is waiting on.
SSPUT is a companion subtask to SSGET, and is used to send data from MSO to a connected TSO or CICS user. SSPUT waits for a message from any of the FOCUS tasks, as well as from SSCTL, and sends them out to the associated user. Most messages consist primarily of the screen contents to be displayed on the users' TSO or CICS terminal. After a user ends his FOCUS session, whether by typing the FIN command or any other means, a final message is sent to let the user's address space know that the conversation with MSO has ended. This allows the MSO program running on the user side to know that it should terminate and return the user to TSO or CICS.
SSTIME is the control task that handles MRM (the MSO Resource Manager). It wakes up at a preset interval to perform analysis of the FOCUS subtasks running within the MSO address space. This feature is described in detail in the MSO Resource Manager. When MRM is not active, SSTIME continues to wake up periodically to prevent the region from being terminated with an S522 abend due to inactivity.
Each copy of FOCUS runs in a separate subtask dedicated to a particular user. The task does not start up by attaching FOCUS; instead, a program named SSFOC is attached to begin the user subtask. When FOCUS runs in MSO there is a terminal user entering screens, from which it accepts commands and writes screens out in return. SSFOC is responsible for providing the "smoke and mirrors" by which FOCUS is fooled. When FOCUS thinks it is issuing a TPUT to a TSO screen, SSFOC is the one that intercepts the request and routes it either to SSPUT (for CICS and TSO) or to VTAM.
SSFOC also handles file allocations. All FOCUS users need certain ddnames to be allocated. MASTER, FOCEXEC, FOCSORT, and OFFLINE are several examples of standard ddnames used in a FOCUS session. However, in MSO, users need their own personal allocation for some of these files. FOCSORT, for example, is a work file that two or more users cannot share; each must have their own. Since MVS shares allocations between all subtasks in an address space, SSFOC provides FOCUS with a mechanism called "ddname translation" to ensure that each task uses a unique ddname with MVS. When a particular FOCUS allocates a ddname, SSFOC first creates a translated name. The new name has the same two leading characters, a 3-digit "uniqueness" value, and a 3-digit "task number" value. Thus FOCSORT might be translated into FO001002 for one user, and FO003007 for another.
Whenever FOCUS references a ddname, the translated name is substituted instead. MSO handles the issue of shared allocations by dividing ddnames into two groups: global ddnames and local ddnames. Local ddnames are those for which SSFOC provides the translations. Global ddnames are those that are shared between all of the FOCUS tasks. The global ddname table is built by reading the MSO server startup JCL at initialization; all of the JCL-allocated files go into the global table. Additionally, if files are allocated or freed via either of the console services (SSCON or SSOPER), then that global table is updated as needed. Certain ddnames which we know should never be shared are automatically excluded from the global table, names such as OFFLINE, FOCSORT, HOLD, HOLDMAST, ADMDECK, FOCSML, FOCSTACK, SAVE and STDOUT.
Since OS/390 knows the FOCUS ddnames under different ddnames than the user does, this can sometimes be confusing when trying to reconcile what a given ddname represents. The relationship between a translated ddname and the ddname known to the user are shown in several places. One is via the MSO Console. In the DU display, use of either the WHOHAS command, or the prefix command W, brings an authorized user into a display showing the private allocations of the selected user(s), with the ddname known to the user shown on the left side of the screen, and the actual MVS ddname on the right. The other place where this relationship is easy to see is in an IBISNAP (the IBI Snapshot Facility) formatted dump printout, where the entire local ddname table is printed for the user. This is especially useful after a file-related abend such as an SB37, since the MVS-generated message has the translated ddname. Just look in the IBISNAP to see the corresponding ddname by which the user knows it.
User tasks also are responsible for other parts of the MSO system, such as establishing security and writing SMF records. Security is validated prior to allowing a user to connect to the subtask. Deletion of the security environment will occur whether the task terminates normally or abnormally. The same holds true for SMF records; the logon record is created before the user receives control, and the logoff record is created from normal or abnormal termination. A flag is set when a logon record is created; this flag ensures that the logoff record will be created later when the task terminates.
MSO frees user-allocated files in three separate steps. The first is during normal termination within FOCUS itself. Second, any ddnames remaining after normal or abnormal termination are cleaned up, which is performed while the users' security environment is still active. Finally, the SSCTL task will look for any that may have been difficult to free (such as a file which had been left open for update), and will free them after the SSFOC subtask has been detached and is totally ended. This takes place under the server's security environment.
I/O is not directly reported as there is no way to correlate an I/O to a particular subtask in any way useful to MSO. The same holds true for SRB time, which is why MSO records only TCB time. MVS keeps CPU time on a per-task basis, which MSO uses to report CPU time.
Several other components of the MSO Server are worth looking into in greater detail, and are covered in the following sections.
| Information Builders |