Standard IMS application programs

Standard IMS application programs use the existing IMS call interface.

Application programs that use the IMS standard API can take advantage of the LU 6.2 protocols. Standard IMS application programs use a DL/I GU call to trigger a sync point and to get the incoming transaction. These standard IMS application programs also use DL/I ISRT calls to generate output messages to the same or different terminals, which can be LU 6.2 terminals. (A non-message-driven BMP is considered a standard IMS application program when it does not use the explicit API.) The identical program can work correctly for both LU 6.2 and non-LU 6.2 terminal types. IMS generates the appropriate calls to APPC/MVS™ services.

IMS provides the following services for standard IMS application programs:
  • Receives incoming transaction from an LU 6.2 application program
  • Calls the Input Message Routing exit routine
  • Schedules transactions into local and remote IMS dependent regions
  • Provides necessary transaction recoverability
  • Provides necessary transaction rollback and retry
  • Provides integration of IMS-controlled conversation flows with database updates during sync point for all APPC Sync_Level options (NONE, CONFIRM, SYNCPT)
  • Provides all needed LU 6.2 calls to APPC/MVS services
  • Sends either synchronous or asynchronous output to an LU 6.2 application program
  • Keeps asynchronous output on IMS message queue until successful transmission
  • Allocates new LU 6.2 conversations for messages inserted to alternate PCBs using the DL/I ISRT call

Existing application programs that are sensitive to a terminal's hardware characteristics, such as cursor position or MFS format names, might need to be changed to communicate with LU 6.2 application programs.

Restrictions:
  1. If a LU 6.2 synchronous conversation implicit transaction initializes other transactions (program-to-program switch), an express PCB can not be used to do the ISRT. An express PBC causes race conditions to occur and the output may randomly return to the inputting terminal on a new asynchronous conversation with TPNAME DFSASYNC. The original conversation may not be deallocated.
  2. If a transaction initializes more than one child transaction, which in turn may initialize other transactions, and one of the child transactions provides the response, the result is unpredictable.

    Depending on the execution sequence of these transactions the LU can receive a DFS2082 message with the response sent to the default TP name DFSASYNC or the LU receives the response and no DFS2082 message is issued.