IMS Conversational Applications

Conversational applications are those applications that have to save data (context) between terminal interactions.

There are three ways of doing this:

1. Write it to a terminal screen field that has the PROT, NODISP and MDT on. However there are two drawbacks to this approach. One is that the amount of data saved has to be small. Another is that a user can always press the clear key and erase the terminal buffer. This approach is useful if the data is small and it does not matter much to start all over again if the data is lost.

2. Another way is to write the data to a database. This approach while imposing no restrictions on the amount of data or it’s safety, does have the drawback that a data base has to be defined exclusively for this, along with associated necessary programming efforts.

3. The third approach is to use an IMS facility called a SPA or a scratch pad area. For IMS to supply this area, the transaction has to be defined as conversational. Every terminal that initiates this program is provided its own scratch pad area. When the output message is saved, the SPA is saved too. When the next message is retrieved, so is the SPA. This allows a single copy of a conversational program to work with more than one terminal.

You can think of a SPA as another type of message. However in addition to the LL and ZZ prefixes, it has another half word prefix CI. The CI field is maintained by IMS although you need to provide for it in your application, just like the LL and ZZ fields.

DCL  01  SPA_IO_AREA,
      02  SPA_LL  FIXED_BINARY(31),
      02  SPA_ZZ  FIXED_BINARY(15),
      02  SPA_CI  FIXED_BINARY(15),
      02  SPA_TRANSACTION_CODE CHAR(8),
      02  SPA_USER_DATA  CHAR(nn);

Note that for conversational programs the transaction code does not appear in the first message of a conversational program

The first GU call that a conversational program makes against the I/O PCB in a conversation, fetches a new SPA with the transaction code set. You get the input message by issuing a GN against the I/O PCB after the preceding GU for the SPA.

You save the SPA using an ISRT call against the I/O PCB, before you ISRT the output message. You must not change the transaction code in the SPA while the conversation is in progress. You set this field to spaces when you issue the last ISRT for the SPA to tell IMS that the conversation is ending.

Another point to note for conversational transactions is that it is better to make all data base changes in the last iteration. If you do them in earlier iterations, the changes are committed while issuing a GU against the I/O PCB for the next input message. This may lead to inconsistent updates if the program abends later in the conversation.

To fetch the SPA:

CALL PLITDLI ( C-3,
               C_GU,
               IO_PCB_PTR,
               SPA_IO_AREA);

To save the SPA:

CALL PLITDLI ( C-3,
               C_ISRT,
               IO_PCB_PTR,
               SPA_IO_AREA);

Passing the Conversation to another Conversational Program:

A conversational program can pass the conversation to another conversational program in two ways:

A deferred switch:

The program can respond to the terminal but cause the next input from the terminal to go to another conversational program by:

1. Issuing an ISRT call against the I/O PCB to respond to the terminal.

2. Placing the transaction code for the new conversational program in the SPA

3. Issuing an ISRT call referencing the I/O PCB and the SPA to return the SPA to IMS TM

IMS TM then routes the next input message from the terminal to the program associated with the transaction code that was specified in the SPA. Other conversational programs can continue to make program switches by changing the transaction code in the SPA.

An immediate switch:

The program can pass the conversation directly to another conversational program by issuing an ISRT call against the alternate PCB that has its destination set to the other conversational program.

The first ISRT call must send the SPA to the other program, but the program passing control can issue subsequent ISRT calls to send a message to the new program. If the program does this, in addition to routing the SPA to the other conversational program, IMS TM updates the SPA as if the program had returned the SPA to IMS. If the program does an immediate switch, the program cannot also return the SPA to IMS TM or respond to the original terminal.

If you have any doubts or queries related to this chapter, get them clarified from our Mainframe experts on IBMMainframer Community!