How to handle IBM IMS AOI user exits under OPS/MVS?

Products

• OPS/MVS Event Management & Automation

Issue/Introduction

The OPS/MVS IMS Automated Operator Interface (AOI) makes uses of exits to communicate with IMS IOF regions. 

 

 

Environment

 

Cause

IMS Automated Operator Interface (AOI) allows users to use automation to read and react to IMS messages and commands destined for the MTO or IMS log. This interface can alter messages and/or send copies of commands or messages to alternate destinations. An exit point was provided so that users can write programs that can perform these functions automatically.

Resolution

When IBM released IMS R5.1, they introduced a second AOI exit called DFSAOE00, or Type 2. This exit is an improvement over the original AOI exit DFSAOUE0, or Type 1. With this Type 2 exit, users can now write their own exits that work in both Transaction Management and database-only environments. To enable this new type of exit to work in both environments, the IMS development team set a new exit point, retaining the old one for backward compliance.

The Type 2 exit is processed first, if it exists, and controls whether or not the Type 1 exit is called. If a Type 2 exit does not exist, the Type 1 exit, by default, receives control. If you implement Type 2 exit processing and you want to process Type 1 exits, you must force the Type 2 processing to override the default.

This presents a unique challenge for automation applications. The IMS Operations Facility (IOF) in OPS/MVS needs to be aware of both types of user exits. When a user implements both Type 1 and Type 2 exits, IOF must be made aware of the decisions made by the Type 2 exit. IOF honors the user's Type 2 exit if the Type 2 exit is set to pass control to the Type 1 exit.

The most complicated scenario would be when a user implements both types of user exits and AOI is processing IMS multi-segment messages:

1. The first segment of a multi-segment IMS message is generated.
2. IOF captures this first segment and performs its automation.
3. IOF passes control to the user Type 2 exit.
4. The user Type 2 exit decides to have the old Type 1 exit do the processing.
5. IOF captures the same segment on the Type 1 exit processing but must ignore any automation to avoid duplicating Step 2.
6. IOF passes control to the user Type 1 exit.
7. All other secondary segments of the message proceed from Step 5 through Step 7, except that IOF performs automation on all the secondary segments through the Type 1 exit process.

Note that after Step 4, IMS bypasses any Type 2 exit processing for the remaining segments of the message.

A variation of this process is when the Type 2 exit retains control in Step 4:

1. The first segment of a multi-segment IMS message is generated.
2. IOF captures the segment and performs its automation.
3. IOF passes control to the user Type 2 exit
4. The user Type 2 exit decides by default not to pass any segments to the Type 1 exit.
5. IOF captures and automates all the other secondary segments through the Type 2 process and passes control the user Type 2 exit.

The IOF facility of OPS/MVS was enhanced extensively to accommodate these two types of user exits. The enhancements were implemented to require a minimum amount of user effort and to retain the automation functionality of the feature.

 

Additional Information

Additional Information:

For more information see the product documentation section titled:  Install the IMS Operations Facility