This chapter discusses the IMS online environment, online application programs, backup, and recovery. It covers the following topics:
IMS Online Environment
Application Programs
Backup and Recovery
Database Recovery Control
IMS Online Environment

The IMS/ESA product is made up of two major components-IMS DB and IMS TM. IMS dB supports the creation and maintenance of the database and processes database calls. IMS TM is a data communication system that supports online transaction processing for IMS dB This section discusses the components of the IMS online environment, the facilities available, and the types of programs that can be used.

There are major differences between batch processing and online processing. When you initiate a program in batch mode, a region in memory, sometimes called an address space, is assigned to it. The region will be loaded with the application program itself and the IMS modules it needs for execution. The batch application program will process independently of other jobs being run in the system. The batch application program begins with the first JCL statement, executes serially through the job, and (assuming it is coded properly and all systems are functioning correctly) completes successfully. It needs no intervention from a user or another program.

In the online environment, an application program can be started and stopped intermittently. It can be launched by a user or by another program. You don't have to submit JCL to initiate it. Instead, you can enter a transaction code from a remote terminal. When IMS receives the message with the correct transaction code, it will initiate the application program for you. In fact, any user with the proper authorization can initiate an online application program. Users can use the program in interactive mode from their terminals. These capabilities, and others, make online programs indispensable for most business computing environments.
Application Programming Environments
IMS supports five application processing environments that provide a wide range of processing options:
+
dB/DC (database/data communications)
+
Database Control (DBCTL)
+
Data Communications Control (DCCTL)
+

dB batch
+
TM batch

dB/DC
In previous chapters we have discussed IMS databases and use of the DL/I command language in writing batch application programs. These application programs use the services of DL/I only. The IMS dB/DC environment provides a full implementation of DL/I and the data communications interface to allow online processing.

There are a number of differences between batch and online applications.

With online applications:
+
Many users can access information in the databases simultaneously.
+
The application can communicate with users at terminals and with other applications.
+
Users can invoke the application from terminals.
+
Users get the results of the application processing immediately.
+
The database can be updated immediately.


Database Control

The DBCTL environment allows a transaction management subsystem other than IMS TM to have online access to DL/I databases and data entry databases (DEDBs). This means users of the Customer Information Control System (CICS) transaction manager, for example, can use DBCTL to access DL/I databases.

DC Control

DCCTL lets you use IMS TM to access non-IMS databases, such as DATABASE 2 (DB2*). DCCTL uses the IMS External Subsystem (ESS) Attach Facility to access other databases. When using DCCTL, you must define the subsystems that DCCTL can access in an IMS.PROCLIB member. DCCTL provides access to the following subsystems: online change
+
MFS
+
MSC
+
DBRC
+
device support
+
IMS commands


Online Configuration

The IMS online processing environment consists of a central control region and a number of designated address spaces within the MVS environment. Figure 3-1 shows the configuration of the online processing environment.

Each box in Figure 3-1 represents an address space in an MVS environment. The online operating environment is controlled through the following specialized processing regions:
+
control region (CTL)
+
message processing regions (MPRs)
+
batch message processing regions (BMPs)
+
DL/I separate address space (DL/I SAS)
+
Database Recovery Control (DBRC)


These regions provide the following functions:

Control Region: The CTL region is the address space that holds the control program that runs continuously in the dB/DC environment. It is responsible for a number of online functions. It holds the IMS control program, which services all communications DL/I calls. It is responsible for Fast Path databases that are accessed by an online program and for Fast Path I/O. It performs all IMS command processing. The control region also:
+
supervises processing for message queues
+
supervises communication traffic for all connected terminals
+
is responsible for restart and recovery information
+
is responsible for the operation of the system log


DL/I Separate Address Space: The DL/I SAS controls full-function databases accessed by an online program. It handles full-function database physical I/O for programs. It also is responsible for full-function program isolation (PI) locking.

Database Recovery Control: DBRC extends the capabilities of utilities for database recovery to allow easier recovery of full-function databases, Fast Path DEDBs, and databases accessed through CICS. DBRC has three levels of control:

+
log control
+
recovery control
+
share control


See "Database Recovery Control" for more information. Address spaces that contain application programs are referred to as dependent regions. Each of the regions discussed below is a dependent region.

Message Processing Region: The MPR loads the application program and holds it to wait for messages. The control program controls scheduling of processing in the MPR. Output can be to a terminal or to another program.

Batch Message Processing Region: The BMP region contains application programs for processing against databases in a batch processing operation. The BMP has access to non-IMS DL/I databases such as flat files, as well as to IMS databases and online IMS message queues. Scheduling is done by OS/VS messaging.

Online Resource Allocation

Most examples of online programming discussed in this chapter deal with the dB/DC environment. Because most dB/DC systems handle a number of application programs and respond to messages originating from a variety of sources, IMS must have a broad-ranging control of resources. When you define the IMS system for dB/DC, you must provide IMS with certain information about the application programs and databases that IMS will be processing and about the communications resources that IMS will use.

Defining Application Resources

To use the resources available to application programs, you must define those resources to IMS for use with the application. This section discusses the resources available and how to define them to IMS.

Databases
To access databases through MPPs or BMPs, you must first define each database to IMS by entering a DATABASE macro that lists the DBD name of the database. The following DATABASE macro accesses a database whose DBD name is COLLEGE:

DATABASE COLLEGE
APPLCTN Macro

The dB/DC environment processes two kinds of online application programs: MPPs (see "Message Processing Programs" on page 3-18) and BMPs (see "Batch Message Processing Programs" on page 3-18). The main difference between the two is that IMS processes an MPP dynamically when it receives a message with an MPP as a destination. IMS processes a BMP when it is scheduled by a system operator. BMPs are typically used to process messages that are held in a message queue for that purpose. You must define MPPs or BMPs to IMS in the APPLCTN system definition macros during system definition. Here is an example of an APPLCTN system definition macro for an MPP:

APPLCTN PSB=PROGRAM1
Here is an example of an APPLCTN system definition macro for a BMP:
APPLCTN PSB=BMPPGM2,PGMTYPE=BATCH
Transaction Codes


Messages are associated with application programs through the use of transaction codes. You can assign more than one transaction code to an application program, but you can assign each application code to only one application. Transaction codes are defined through a TRANSACT macro, which follows the APPLCTN macro for the program it is assign to. You define a transaction code as a unique combination of one to eight characters. IMS creates a message queue for each transaction code. As messages are generated for the transaction code, messages are stored in the appropriate message queue pending processing. Here is an example of a TRANSACT macro for transaction code TRANS1:

TRANSACT CODE=TRANS1

Defining Communications Resources

In using the dB/DC environment, you must also define communications resources such as communications lines and terminals to IMS. When you define these resources to IMS, you are creating a communications network that IMS will use in routing messages to and from terminals and the central processor. Control of the hardware is managed by a type of subsystem called a teleprocessing access method. An example of a TP access method is Virtual Telecommunications Access Method (VTAM). The three major types of hardware defined to IMS are communications lines, physical terminals, and logical terminals.

Communications Lines
There are two major types of communications lines: switched and non-switched. With switched lines, users dial a number to gain access to the network. Switched lines allow the attachment of only one remote terminal at a time. With non-switched lines, terminals are connected directly to a dedicated line. Non-switched lines can be contention lines or polled lines. Contention lines allow only one contention-type terminal on the line at a time. Polled lines allow one or more terminals to use the line at a time. You must use a LINE macro to assign one or more remote terminals to a communications line and the LINEGRP macro to create line groups of lines that connect terminals of a similar type. Use separate line groups to group terminals with the same communication mode, polling technique, or transmission code.

Physical Terminals
Physical terminals are connected to a communications line and defined to IMS. Each terminal device in a line group is assigned a numeric identifier or address called a PTERM. A major distinction of terminal attachments is whether they are local or remote. Local refers to attachments made through a channel; remote attachments are made through a communications control unit. Because remote terminals are connected through one or more levels of communications control units, you must use a CTLUNIT macro to define the control unit to IMS when configuring the network.

Logical Terminals
Although the physical terminal is defined to the system, IMS uses logical terminal (LTERM) names to communicate with the terminals connected to the system. An LTERM name can be assigned to a physical terminal and later moved to a different physical terminal. You can associate many LTERM names with a single physical terminal to allow multiple users of the same terminal. When you define a TERMINAL macro, you can follow it with one or more NAME macros that list the LTERM names associated with that terminal.

In IMS online processing, LTERM names are used as message destinations in much the same way that transaction codes are used. IMS creates a message queue for each LTERM name. Messages addressed to that LTERM are held in the LTERM message queue. LTERM messages can be sent by MPPs, BMPs, or another logical terminal. The use of message queues allows the application program to be independent of the time of transmission or arrival of messages.

An application program interacts with a logical terminal in much the same way it does with a database. A GU call, for instance, retrieves a message segment from a queue, and an ISRT call inserts a message segment into a queue.

Here is an example of IMS data communications macros defining the line groups, lines, control units, physical terminals, and logical terminals on a network:
LINEGRP DDNAME=LINEDD,UNITTYPE=3270
LINE ADDR=L03
CTLUNIT ADDR=CT4,MODEL=1
TERMINAL ADDR=65
NAME LTERM5
TERMINAL ADDR=66
NAME LTERM11
NAME LTERM15
NAME LTERM22

Message Types
Units of communication that flow between terminals and the host computer in an online environment are referred to as messages. Most of our discussion of online processing revolves around the format and processing of messages. In IMS online processing there are three message types, based on their destination:
+
transaction code messages
+
logical terminal messages
+

IMS terminal commands


Transaction Code Messages

Transaction code messages are used to communicate with application programs. Transaction code messages can originate from a terminal or from another program. Transaction codes are used to link transactions to the program that will execute them. A transaction can be assigned to only one program, but a single program can be assigned many types of transactions. The code is recognized by the system and is used to route the message to the transaction's message queue for processing by the application program.

Logical Terminal Messages

During IMS TM system definition, physical terminals are assigned logical names. A physical terminal can have more than one logical name, and a logical name can be changed, removed, or assigned to another physical terminal. The logical terminal name plays a similar role to the transaction code. The logical terminal name is used by the system to place the message in the right message queue for further processing. Logical terminal name messages are those messages addressed to a logical terminal. They can be sent by the host processing unit or by another terminal.
v IMS Terminal Commands

Certain commands are reserved for specified IMS operating functions. They are used for operations such as starting, stopping, restarting, controlling, or changing IMS online. They are also used to run IMS utilities. Most of these commands are used by the master terminal operator (MTO) only. Their format is a slash followed by the command. The command /STOP, for example, prevents new IMS transactions from scheduling.

Message Segments
Although messages are transmitted as a single unit, they can be divided into one or more message segments. MPP and BMP programs actually retrieve messages one segment at a time, in much the same way that database records are retrieved one segment at a time. Input and output messages have segments reserved for IMS control information. Figure 3-2 shows the structure of a message segment.

Full article...