Reply processing patterns for Single connector — persistent and nonpersistent

Upon server adapter completion, any application response/reply data is written to a server adapter output data container ADAPTER.OUTPUT.

Once the server adapter has completed processing and the Adapter service activity has ended normally, a BTS completion event is fired and control is returned to the Navigation Manager (DFHMAMGR).

The Navigation Manager performs the following reply processing steps:
  1. Performs a check on the server adapter activity completion status by issuing the BTS CHECK ACTIVITY command:
    EXEC CICS CHECK ACTIVITY (ADC-NAV-ACTIVITY)
                  COMPSTATUS (CICS-COMPSTATUS)
                      ABCODE (CICS-ABCODE)
                   ABPROGRAM (CICS-ABPROGRAM) 
                        MODE (CICS-MODE) 
                  SUSPSTATUS (CICS-SUSPSTATUS) 
                       RESP (CICS-RESP) 
                      RESP2 (CICS-RESP2) 
    END-EXEC. 
  2. Reads the state information from process container ADAPTER.PROCESS.
  3. Reads the appropriate server adapter status information from either container ADAPTER.STATUS or COMMAND.STATUS depending upon server adapter type run.
  4. Reads the server adapter output container, if normal completion, ADAPTER.OUTPUT.
  5. Writes the root activity output data container containing the application response/reply data. The output container name is ADAPTER.OUTPUT.
  6. Writes adapter completion status and state information to process container ADAPTER.PROCESS.
  7. Optionally issues MQPUT if the BTS process was executed in asynchronous mode and the client application interface was WebSphere® MQ-CICS bridge. Otherwise, the Navigation Manager (DFHMAMGR) issues an EXEC CICS® RETURN ENDACTIVITY command returning control to the DPL stub program (DFHMADPL) and completing the process.
Figure 1. Navigation Manager program reply processing — single connector type
The diagram illustrates the reply processing performed by the Navigation Manager (DFHMAMGR) program for an Adapter service of the single connector type.

Once the Navigation Manager (DFHMAMGR) has completed processing and the BTS process has ended normally, a BTS completion event is fired and control is returned to the DPL stub program (DFHMADPL).

The DPL stub performs the following processing steps:
  1. Performs a check on the process completion status by issuing the BTS CHECK ACQPROCESS command.
  2. Reads the adapter state information from process container ADAPTER.PROCESS
  3. Reads the Navigation Manager (DFHMAMGR) output data container ADAPTER.OUTPUT.
  4. Builds XML or fixed format reply message to include the header structure (DFHMAH) and any output data container application response/reply data.

    The DPL stub program (DFHMADPL) might call a user-defined program to convert the COBOL fixed format outbound application reply structure to XML application reply tag data. The application program name is determined by the Adapter service.

    The DPL stub program will then call the CICS Service Flow Runtime COBOL to XML Converter program (DFHMAXMO) to convert the COBOL fixed format header structure (DFHMAH) to XML header tag data to format the XML reply message.

    See XML request and response processing and XML message formats for non-passthrough for further information regarding XML message processing.

    The Navigation Manager program (DFHMAMGR) also performs XML reply message processing as described above when the Adapter service is run in asynchronous mode and the client application interface was WebSphere MQ-CICS bridge.
  5. Moves outbound reply message to DFHCOMMAREA and issues an EXEC CICS RETURN command returning control to the service requestor.
Figure 2. DPL stub program reply processing — single connector type
The diagram illustrates the reply processing performed by the DPL Stub (DFHMADPL) program for an Adapter service of the single connector type