Coordinating troubleshooting efforts  Process flow during attention sequences

Appendix C: Troubleshooting

Processing flow and requirements

The following diagram shows the processing flow:

Figure C-1: Client-to-TRS-to-mainframe processing flow

The following steps describe the sequence shown above and highlight the requirements:

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

    Server name not found in interface file
    

    If so, make sure that:

  2. On receiving the client login information, the DirectConnect for z/OS Option checks security as follows:

  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 lookup to find the mainframe session and the 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 lookup 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 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 datastream, 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 an “Unexpected EOF from Adaptive Server Enterprise” error message to the client. (The mainframe is acting as a Adaptive Server Enterprise.) Gateway-Library tracing functions, if in use, 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”.





Copyright © 2005. Sybase Inc. All rights reserved. Process flow during attention sequences

View this book as PDF