Operating an IMS Network

Operating a basic IMS network involves:

• Establishing a communication session between a logical unit and IMS

• Sending data between a logical unit and IMS

• Terminating the session between a logical unit and IMS

• Restarting the session after a failure

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:

• By interrogating the messages sent that IMS sends to the master terminal and then issuing appropriate IMS commands to react to those messages

• By monitoring IMS's operational status and issuing IMS commands to react to that status

"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 Terminal

The task of the master terminal operator (MTO) is to monitor and manage an individual IMS.

The master terminal operator (MTO) has the following responsibilities:

• Running IMS

  The MTO starts and shuts down dependent regions and manages the system log.

• Knowledge of the ongoing status of the IMS subsystem

  The MTO continuously monitors processing and detects any error situations.

• Control over contents of the system and network

  The MTO can control the network, connect other IMS systems, and perform other prearranged tasks.

• Privileged commands

  In addition to routine work, the MTO responds to error conditions, changes the scheduling algorithm, alters passwords, and reconfigures the system as necessary.

Table 12-4 shows the activities usually performed by the MTO and the commands usually reserved for the MTO's use.

Table 12-4. Master Terminal Operator Activities and Associated IMS Commands

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 :

• Primary master

• Secondary master

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 Master"

• "The Secondary Master" on page 193

• "Using the z/OS System Console as the Master Terminal" on page 193

• "MCS/EMCS Console Support" on page 194

The Primary Master

Traditionally, 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 Screen

03/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

The message area is for IMS command output (except /DISPLAY and /RDISPLAY ), message switch output that uses a message output descriptor name beginning with DFSMO (see "MFS Control Blocks" on page 305), and IMS system messages.

Display area

The display area is for /DISPLAY and /RDISPLAY command output.

Warning message area

The warning message area is for the following warning messages:

• MASTER LINES WAITING

• MASTER WAITING

• DISPLAY LINES WAITING

• USER MESSAGE WAITING

To display these messages or lines, press PA1. An IMS password can also be entered in this area after the "PASSWORD" literal.

User input area

The user input area is for operator input.

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 Master

Traditionally, 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 Terminal

IMS 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.

^[2] System console: The main operating system display station, usually equipped with a keyboard and display screen, that is used by an operator to control and communicate with a system.

MCS/EMCS Console Support

You 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/IMS

APPC/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 IMS

A 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:

• The logical unit itself requests disconnection.

• The IMS MTO requests disconnection.

• Another VTAM application program requests connection to the terminal.

• IMS, VTAM, NCP, the logical unit, or the entire network is stopped .

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:

• IMS Version 9: Customization Guide

• IMS Version 9: Administration Guide: System