When a user invokes the ISPF end-user interface, the InfoManager component is in control of the terminal session. The InfoManager provides presentation services that deliver a multiwindow environment to the end user. To display a CICSPlex® SM view in a window, the user must specify a context for the request. The context is the name of either a CMAS or a CICSplex from which information is desired.
The InfoManager uses the CAS and two of its components, the LUManager and the DataManager, to establish a communication path from the TSO session to the CMAS that will handle the request. The LUManager provides a generalized communication facility between any two points in communication with a CAS. The DataManager passes data between tasks running in the TSO session and in the CMAS and schedules the running of programs that support request processing. The CAS determines which CMAS is to service requests for a given context. Instances of the DataManager are then established in the TSO address space where the InfoManager is running and in the target CMAS; the two are logically connected via the LUManager. An LUManager session must be a single point-to-point connection. This means that there must be a direct link between any two CASs where such a session is to be established. For full connectivity, there must be a direct link from each CAS to every other CAS.
Figure 3 shows a sample CAS network.
When a particular CICSPlex SM view is requested, a program is run that supplies data to populate the view. This program is called a selector. A selector runs in a CMAS under an OS TCB that was created as part of the DataManager instance. Note that there may be multiple instances of the DataManager and multiple OS TCBs under which selectors are run, since one is created for each user window that is requesting services. A selector returns records of data to the DataManager, each of which represents a single row in the resulting view. If, for example, a CICS®RGN view is run with a context that results in data for three CICS regions, the selector returns three records of data to the DataManager. The selector is rerun whenever a refresh of the data in the view is requested.
Because a CMAS is a special CICS/ESA address space running the CICSPlex SM application, the selector must invoke services running under the TCB of the CICS/ESA AP domain. A structure exists within a CMAS to cause the dynamic pairing of the OS task under which the selector runs with a CICS task that can invoke other CICSPlex SM routines that must run within the CMAS. WAIT/POST logic is used, together with shared data areas, to direct the invocation of services and the exchange of results between the OS and CICS tasks.
Once a view has been invoked and a selector has supplied the initial data, the user can request an action to be performed against the data. Each action causes a program to run in the CMAS to service the request. This program is called a back-end program. A back-end program is invoked to process an action against a single instance of a resource (such as a transaction in a CICS system). If the user requested that an action be applied to multiple resources, the back-end program is invoked multiple times, once for each resource.
For simple actions, the back-end program processes the action and returns a response indicating the result. For actions that require either more information or confirmation from the user, the back-end program uses a service of the DataManager to run a program called a front-end within the TSO address space. The front-end program presents an ISPF panel to the user and waits for a response. The ISPF panel takes over the screen and all InfoManager windows are temporarily overlaid. The front-end program performs some validation of the data entered and passes it to the back-end program by way of the DataManager. When processing of the ISPF panel is complete, the InfoManager windows are redisplayed.
Figure 4 illustrates CICSPlex SM end-user interface processing.
[[ Contents Previous Page | Next Page Index ]]