Operating a basic IMS network involves:
As in many areas of IMS, the tasks involved in operating an IMS system have evolved over time. Historically, these tasks were performed by a person (called the master terminal operator) sitting at a master terminal (an important, required device that is defined to IMS as part of the system definition process). Some IMS systems are still operated in this manner. Most IMS customers are automating their operations by documenting their operational procedures and writing automation application programs to implement those procedures. These automation application programs can interact with IMS in the following ways:
"The Master Terminal" describes the tasks performed by the master terminal operator (MTO), which are still applicable today even though these tasks might be automated. As IMSs are joined together into sharing groups (sharing databases, resources, or message queues), system management becomes more complex. Prior to IMS Version 8, the IMS systems in sharing groups had to be managed individually. IMS Version 8 introduced system management enhancements so that a single IMS or multiple IMS systems could be monitored and managed from a single point of control. With IMS Version 8 or later, you can issue commands and receive responses from one, many, or all of the IMSs in the group from this single point of control. For more information about these enhancements, see Chapter 28, "IMSplexes," on page 495. The Master TerminalThe task of the master terminal operator (MTO) is to monitor and manage an individual IMS. The master terminal operator (MTO) has the following responsibilities:
Table 12-4 shows the activities usually performed by the MTO and the commands usually reserved for the MTO's use.
The MTO interacts with IMS through the master terminal. The master terminal is the key control point for IMS online operations. When the IMS system is defined, the master terminal must be included, and consists of two components:
All messages are routed to both the primary and secondary master terminals. Special MFS support is used for the master terminal. The following sections of this chapter discuss the tasks of monitoring and managing an individual IMS using the MTO:
The Primary MasterTraditionally, the primary master was a 3270 display terminal of 1920 characters (24 lines by 80 columns). A sample traditional IMS master terminal is shown in Figure 12-6. Figure 12-6. Sample Traditional Master Terminal Screen03/04/04 14:49:48 IMSC DFS249 14:43:46 NO INPUT MESSAGE CREATED DFS994I COLD START COMPLETED DFS0653I PROCECTED CONVERSATION PROCESSING WITH RRS/MVS ENABLED DFS2360I 14:29:28 XCF GROUP JOINED SUCCESSFULLY. -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - PASSWORD: - The display screen of the master terminal is divided into four areas. They are the: Message area
Display area
Warning message area
User input area
Program function key 11 or PA2 requests the next output message, and program function key 12 requests the Copy function if it is a remote terminal. The Secondary MasterTraditionally, the secondary master was a 3270 printer terminal; however, the use of a 3270 printer terminal has been phased out in many sites, who instead define the secondary master as spooled devices to IMS, in effect writing the messages to physical data sets. By writing the messages to physical data sets, the secondary master can be used as an online log of events within IMS. To accomplish this, add the definitions in Figure 12-7 into the IMS stage 1 system definition. Add these definitions after the COMM macro and before any VTAM terminal definitions. Figure 12-7. Sample JCL for the Secondary Master Spool* LINEGRP DDNAME=(SPL1, SPL2), UNITYPE=SPOOL LINE BUFSIZE=1420 TERMINAL FEAT=AUTOSCH NAME (SEC,SECONDARY) To complete the system definitions, code SPL1 and SPL2 DD statements in the IMS control region JCL. The data sets should be allocated with the following DCB information: DCB=(RECFM=VB,LRECL=1404,BLKSIZE=1414) Using the z/OS System Console as the Master TerminalIMS always has a communications path with the z/OS system console[2] and uses the write-to-operator (WTO) and write-to-operator-with-reply (WTOR) facilities for this purpose. Whenever the IMS control region is active, there is an outstanding message requesting reply on the z/OS system console that can be used to enter commands for the control region. All functions available to the IMS master terminal are available to the system console. The system console and master terminal can be used concurrently to control the system. Usually, however, the systemconsole's primary purpose is as a backup to the master terminal. The system console is defined as IMS line number one by default.
MCS/EMCS Console SupportYou can also communicate with IMS using the z/OS MCS/EMCS (multiple console support/extended multiple console support). Any z/OS console can issue a command directly to IMS, using either a command recognition character (CRC) as defined at IMS startup, or using the 4-character IMS ID to be able to issue commands. An MCS/EMCS console has the option of using RACF or exit routines for command security. For further details, see Chapter 21, "IMS Security," on page 361. Operating the Network with APPC/IMSAPPC/IMS supports IMS commands for network operation, but the LU 6.2 device handles normal operations such as session startup, transaction initiation, and error handling that does not require master terminal operator (MTO) intervention. Initiating a Session with IMSA session can be initiated by a logical unit, by the VTAM network operator, by the IMS MTO, automatically by VTAM, or by IMS itself. After a logical unit connects to IMS, it remains connected until one of the following actions occurs:
After the physical connection between the controller and VTAM is established, an LU-to-LU session is initiated. The LU that is requesting the session informs VTAM that it wants to communicate with IMS. VTAM notifies IMS of the request through the VTAM Logon exit routine. IMS indicates that it will accept the request, and VTAM then logically connects the LU to IMS. A session is required before communication between the LU and IMS can be accomplished. To open a session, all nodes in the communication path (IMS, NCP, line, and station) must be in active status. After a session is established, VTAM directs all data between the logical unit and IMS. IMS also supports SNA communication links in an Extended Recovery Facility (XRF) complex. Related Reading: For information on establishing sessions in an XRF environment, see:
|