Bracket protocol for IMS output

The output bracket and send/receive protocol used by IMS and the number of output messages sent per bracket are dependent on a variety of factors.

The output bracket and send/receive protocol used by IMS and the number of output messages sent per bracket depend upon one or more of the following:
  • The IMS message type
  • Whether the message is to be MFS paged
  • Whether the other half session supports the SCHEDULER model
  • The output component specified during IMS system definition
  • The bracket and ATTACH protocol associated with the originating input transaction

Within IMS, the protocols used for nonlast chains (pages) of MFS-paged output and the last (MFS-paged) or only chain of response mode, conversation mode, test mode, or command replies are predefined regardless of whether the originating input transaction and resulting output replies are synchronous (ATTACH) or asynchronous (SCHEDULER). This is also true for output resulting from input sent with ATTACH EB and for asynchronous output that must be sent ATTACH because the other half session lacks SCHEDULER support.

CD is used for all nonlast chains of MFS demand-paged messages, the last (MFS-paged) or only chain of test mode, and nonlast conversational mode messages. CD allows the paging operation or synchronous event between IMS and the other half session to continue.

EB ensures that the end of the synchronous event occurs by placing the session in reset state for the last (MFS-paged) or only chain of response mode replies, last conversational mode replies, and command replies. This is also true for replies resulting from input sent with ATTACH EB and for asynchronous output that must be sent ATTACH because the other half session lacks SCHEDULER support. All nonlast chains (pages) of MFS-autopaged messages are sent without either CD or EB.

Using ATTACH SCHEDULER, your installation must define to IMS the protocols to be used for the last (MFS-paged) or only chain of other asynchronous output. IMS allows you to specify single or multiple messages for each component defined for a session and whether IMS should send more than one asynchronous message before indicating change-direction or end-bracket. The possible component definitions are:
SINGLE1
Asynchronous output for this component is sent one message per bracket. Each message begins a bracket (if necessary) and always ends a bracket.
SINGLE2
Asynchronous output for this component is sent one message at a time with the VTAM® begin-bracket (if necessary) and change-direction indicators to allow the receiving subsystem to optionally send its communication traffic.
MULT1
All asynchronous messages for a given LTERM are sent before the bracket is ended. Traffic is sent BB (if necessary), message1, message2,...messageN, EB. EB occurs after the last message for the LTERM is acknowledged and dequeued.
MULT2
All asynchronous messages for a given LTERM are sent before change-direction is sent. Traffic is sent BB (if necessary), message1, message2...messageN, CD. CD occurs after the last message for the LTERM is acknowledged and dequeued.
Consider the definition (on the IMS system definition TERMINAL macro statement or an ETO logon descriptor), and use of protocols for ISC components to be used for transmission of asynchronous messages. This is particularly true in an IMS-to-IMS environment, because most messages between the two subsystems are asynchronous. Incorrectly defining or using these ISC protocols can:
  • Require extra transmissions to occur in order to acquire the flow or to end the bracket
  • Cause unnecessary bracket contention error recovery operations
  • Produce output protocols unacceptable to the receiving subsystem.
A further explanation follows:
SINGLE1
Use of SINGLE1 results in EB on each message and might cause bracket contention if the other subsystem has data to send.

EB on each message can cause process errors within the other subsystem if the transaction must reply synchronously within the initiating bracket. An error of this type can occur in the receiving subsystem when a SINGLE1 component is used to send response mode, conversation, or test mode messages, or IMS commands from one IMS subsystem to another.

SINGLE2 or MULT2
Change-direction sent on messages from a component defined as SINGLE2 might result in unnecessary transmissions to end the bracket when either no output is available or no reply is available within the other subsystem.
MULT1 or MULT2
Messages sent on components defined as MULT1 OR MULT2 indicate change-direction or end-bracket only after the last message on a queue has been dequeued. Therefore, extra transmissions might result if the other subsystem must signal for the flow to return synchronous replies.

For components defined as MULT1 and MULT2, IMS suppresses the queue rotation that normally occurs between output messages. This suppression allows all messages from a queue selected for output to be sent before IMS initiates output on other queues. Selection of the next queue with available output occurs when the previous queue has emptied or when input changes the active output queue. The queues are not rotated if an LUSTATUS - queue empty or another input that indicates change-direction occurs for the same queue.

The following tables summarize the bracket and send/receive indicators that are acceptable for IMS output messages.

In the tables the VTAM indicators are represented by the following abbreviations:
INB
Indicates that synchronous or asynchronous output occurs within the same bracket as the previous input
BETB
Indicates that IMS initiates output while in a between-brackets state
BB
Begin-bracket
EB
End-bracket
CD
Change-direction (allowed on last- or only-in-chain)
N
No bracket or send/receive indicators
Table 1. VTAM bracket and send/receive indicators sent with output message using ATTACH SCHEDULER
Message type sent using attach scheduler SINGLE1 msg.init INB BETB SINGLE2 msg.init INB BETB MULT1/21 msg.init INB BETB
MFS demand-paged output:First SNA chain (ATTACH SCHEDULER)2 EBBB/EB EBBB/EB EBBB/EB
MFS demand-paged output:Nonlast page      
MFS demand-paged output:Last page if OLP3 CD CD CD
MFS demand-paged output:Last page without OLP (See appropriate message type)      
MFS autopaged output: First page NBB NBB NBB
MFS autopaged output: Nonfirst, nonlast page N N N
MFS autopaged output: Last page (See appropriate message type)      
Response mode output (Including Fast Path) EB EB EB
Nonlast conversational output message CD CD CD
Last conversational output message EB EB EB
Message switch output EBBB/EB CDBB/CD NBB
Command output: /FOR, /DIS, /RDIS EBBB/EB CDBB/CD NBB
Command output: /TEST4 CD CD CD
Other Command output EB EB EB
Test mode output4 CD CD CD
None of the above message types - asynchronous EBBB/EB CDBB/CD NBB
Notes:
  1. LUSTATUS - queue empty is used at the end of a queue to send EB for MULT1 and CD for MULT2. EB is sent when an ERP backout has reset the DFC and ATTACH states to between-brackets and no component 1 (COMPT1) is defined during IMS system definition. Also, the BB indicator in the BETB column occurs only for the first message or MFS page that must initiate an output bracket asynchronously.
  2. Although IMS is between-brackets after having sent stand-alone ATTACH SCHEDULER for response mode, Fast Path, or conversational demand-paged output, IMS does not accept input until the preceding output is successfully transmitted and dequeued using the appropriate paging requests.
  3. MFS operator logical paging (OLP) is in effect if the MOD specifies PAGE=YES and autopaged output is not indicated in the MFS system control area (SCA).
  4. Applies to test echo mode only. Not applicable to /TEST MFS.
Table 2. VTAM bracket and send/receive indicators sent with output message using ATTACH (no SCHEDULER)
Message type sent using ATTACH (no SCHEDULER) SINGLE1 msg.init INB BETB SINGLE2 msg.init INB BETB MULT1/21 msg.init INB BETB
MFS demand-paged output: First SNA chain (ATTACH) CD CD CD
MFS demand-paged output: Nonlast page, last page if OLP3 CD CD CD
MFS demand-paged output: Last page without OLP (See appropriate message type)      
MFS autopaged output: First page N N N
MFS autopaged output: Nonfirst, nonlast page N N N
MFS autopaged output: Last page (See appropriate message type)      
Response mode output (including Fast Path)5 EB EB EB
Nonlast conversational message CD CD CD
Last conversational message EB EB EB
Nonresponse, nonconversational output (No SCHEDULER model defined for other half session) EB BB/EB EB BB/EB EB BB/EB
ATTACH SYSMSG BB/EB BB/CD BB
Command output      
Command output: /TEST4 CD CD CD
Other command output (except /FOR, /DIS, and /RDIS)6 EB EB EB
Test mode output4 CD CD CD
Notes:
  1. LUSTATUS - queue empty is used at the end of a queue to send EB for MULT1 and CD for MULT2. EB is sent when an ERP backout has reset the DFC and ATTACH states to between-brackets and no component 1 (COMPT1) is defined during IMS system definition. Also, the BB indicator in the BETB column occurs only for the first message or MFS page that must initiate an output bracket asynchronously.
  2. Although IMS is between-brackets after having sent stand-alone ATTACH SCHEDULER for response mode, Fast Path, or conversational demand-paged output, IMS does not accept input until the preceding output is successfully transmitted and dequeued using the appropriate paging requests.
  3. MFS operator logical paging (OLP) is in effect if the MOD specifies PAGE=YES and autopaged output is not indicated in the MFS system control area (SCA).
  4. Applies to test echo mode only. Not applicable to /TEST MFS.
  5. Response mode operation always occurs for input transactions that are directly attached.
  6. See LUSTATUS protocol for more information on /DISPLAY, /RDISPLAY, and /FORMAT command output.
Table 3. VTAM bracket and send/receive indicators sent with other output message types
Other output message types SINGLE1 msg.init INB BETB SINGLE2 msg.init INB BETB MULT1/21 msg.init INB BETB
VTAM command/indicator2      
FMH7 (ERP) messages: During conversation CD CD CD
FMH7 (ERP) messages: During test mode CD CD CD
FMH7 (ERP) messages: Other3 EB BB/EB CD BB/CD Note 4
QSTATUS (QMODEL) Note 5 Note 5 Note 5
Notes:
  1. LUSTATUS - queue empty is used at the end of a queue to send EB for MULT1 and CD for MULT2. EB is sent when an ERP backout has reset the DFC and ATTACH states to between-brackets and no component 1 (COMPT1) is defined during IMS system definition. Also, the BB indicator in the BETB column occurs only for the first message or MFS page that must initiate an output bracket asynchronously.
  2. BIS is sent without CD or EB. CHASE is always sent CD.
  3. An FMH7 requests the protocol associated with the resulting between-brackets reset state of the last committed input component after backout of the DFC and ATTACH states due to the ERP operation.
  4. FMH7 is sent with EB for MULT1, CD for MULT2.
  5. CD/RQE1 is sent on a QSTATUS that results from an invalid cursor in an MFS DPM demand-page request for output. CD/RQE2 or EB/RQD2 is sent on QSTATUS, which results from the receipt of QPURGE during demand-paged output. CD/RQE2 is sent: 1) when in IMS conversation or test mode or 2) when the input is sent with ATTACH SCHEDULER and the associated output component was SINGLE2 or MULT2. All other cases result in EB/RQD2.