Passing the conversation to another conversational program

A conversational program can pass the conversation to another conversational program in by performing a deferred switch or a immediate switch.

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

Restrictions on passing the conversation

These are restrictions that apply to passing the conversation to another conversational program:

  • When an immediate program switch occurs and the MPP receives an XE status code, the program attempts to insert the SPA to an alternate express PCB. Remove the EXPRESS=YES option from the PCB or define and use another PCB that is not express. This restriction prevents the second transaction from continuing the conversation if the first transaction abends after inserting the SPA.

    The person at the terminal can issue the /SET CONV XX command, where XX is the program that is to be scheduled in order to process the next step of the conversation.

  • APPC or OTMA protected transactions do not allow immediate program or deferred program switches. If either of these switches occur, the MPP receives an X6 status code.

Defining the SPA size

Define the SPA size with the TRANSACT macro. An option to capture truncated data is also defined with the TRANSACT macro. The format is:
TRANSACT SPA=(size,STRUNC|RTRUNC)

The default is to support truncated data (STRUNC). When a conversation is initially started, and on each program switch, the truncated data option is checked and set or reset as specified. When the truncated data option is set, it remains set for the life of the conversation, or until a program switch occurs to a transaction that specifies that the option be reset.

For example, assume you have three transactions defined as follows:

  • TRANA SPA=100
  • TRANB SPA=050
  • TRANC SPA=150

For TRANC to receive the truncated data (which is the second 50 bytes from TRANA that TRANB does not receive) from TRANA, one of the following sets of specifications can be used:

  • TRANA - STRUNC or none, TRANB - STRUNC or none, TRANC - STRUNC or none
  • TRANA - RTRUNC, TRANB - STRUNC, TRANC - STRUNC or none

Conversational processing and MSC

If your installation has two or more IMS TM systems, and they are linked to each other through MSC, a program in one system can process a conversation that originated in another system.

  • If a conversational program in system A issues an ISRT call that references a response alternate PCB in system B, system B does the necessary verification. This is because the destination is implicit in the input system. The verification that system B does includes determining whether the logical terminal that is represented by the response alternate PCB is assigned to the same physical terminal as the logical terminal that sent the input message. If it is not, system B (the originating system) terminates the conversation abnormally without issuing a status code to the application program.
  • Suppose program A processes a conversation that originates from a terminal in system B. Program A passes the conversation to another conversational program by changing the transaction code in the SPA. If the transaction code that program A supplies is invalid, system B (the originating system) terminates the conversation abnormally without returning a status code to the application program.

Ending the conversation

To end the conversation, a program blanks out the transaction code in the SPA and returns it to IMS TM by issuing an ISRT call and referencing the I/O PCB and the SPA. This terminates the conversation as soon as the terminal has received the response.

The program can also end the conversation by placing a nonconversational transaction code in the transaction field of the SPA and returning the SPA to IMS. This causes the conversation to remain active until the person at the terminal has entered the next message. The transaction code will be inserted from the SPA into the first segment of the input message. IMS TM then routes this message from the terminal to the MPP or BMP that processes the transaction code that was specified in the SPA.

In addition to being ended by the program, a conversation can be ended by the person at the originating terminal, the master terminal operator, and IMS.

  • The person at the originating terminal can end the conversation by issuing one of several commands:
    /EXIT
    The person at the terminal can enter the /EXIT command by itself, or the /EXIT command followed by the conversational identification number assigned by the IMS TM system.
    /HOLD
    The /HOLD command stops the conversation temporarily to allow the person at the terminal to enter other transactions while IMS TM holds the conversation. When IMS TM responds to the /HOLD command, it supplies an identifier that the person at the terminal can later use to reactivate the conversation. The /RELEASE command followed by this identifier reactivates the conversation.
  • /START LINE. The master terminal operator can end the conversation by entering a /START LINE command (without specifying a PTERM) or /START NODE command for the terminal in the conversation or a /START USER command for a signed-off dynamic user in conversation.
  • IMS TM ends a conversation if, after the program successfully issues a GU call or an ISRT call to return the SPA, the program does not send a response to the terminal. In this situation, IMS TM sends the message DFS2171I NO RESPONSE, CONVERSATION TERMINATED to the terminal. IMS TM then terminates the conversation and performs commit point processing for the application program.