Processing flow and requirements

The following diagram shows the processing flow:

Figure G-2: Client-to-TRS-to-mainframe processing flow

The following steps describe the sequence shown in Figure G-2 and highlight the requirements:

  1. If TRS has started, the client opens a LAN connection to a designated DirectConnect for z/OS Option server and logs in. This message may appear:

    Server name not found in interface file
    

    If so, make sure that:

  2. When it receives the client login information, the DirectConnect for z/OS Option checks security:

  3. When the client application needs to invoke an RPC or language request on the mainframe, the client sends a request to TRS over the logged-in LAN connection.

  4. TRS receives the request and performs a table look-up to find the mainframe session and Server Option transaction ID to use. The RPC and connection must be in the table. If security is enabled, the client must be authorized to use the RPC and connection to the mainframe. If the table look-up and security check are successful, the line is up, and the session is active, TRS allocates a conversation with the named transaction.

    If a failure occurs during this process, SNA Services writes one of the following error messages to both the TRS log and the client:

  5. TRS sends the client External Data Representation (XDR) information to the mainframe.

  6. TRS sends the client RPC parameters to the mainframe, and then waits for a reply from the transaction.

  7. On the mainframe, the transaction processor initiates the named transaction, and the transaction issues the Server Option Gateway-Library calls. These calls read the client XDR information and RPC parameters. The transaction also performs associated processing, such as issuing static SQL DB2 UDB requests or reading VSAM or other database data.

  8. The transaction issues Gateway-Library calls that send results back to the client. These calls perform required data conversions, generate the TDS reply data stream, and send out reply data.

  9. TRS receives the TDS reply packet and forwards it to the client, which continues until the Server Option transaction issues a TDSNDDON call.

    If a failure occurs during this process, the LAN SNA software writes an error message to the DirectConnect for z/OS Option server log. It also writes this error message to the client:

    Unexpected EOF from Adaptive Server Enterprise

    (The mainframe is acting as a ASE.) If in use, the Gateway-Library tracing functions also record errors in this process.

  10. When the request is complete, the transaction exits and the conversation terminates. A long-running transaction (also called a user-defined transaction) can remain active through multiple requests before the conversation ends. If a long-running transaction terminates before it should, determine whether appropriate client support is set up. For example:

For more information on identifying problems, see “Common problems and suggested solutions”.