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:
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:
The client interfaces file is set up correctly.
The client Sybase path variable (SYBASE) is defined correctly.
The DirectConnect for z/OS Option server is specified in the DSQUERY variable.
When it receives the client login information, the DirectConnect for z/OS Option checks security:
If security is enabled, the DirectConnect for z/OS Option ensures that the client is authorized. If the client is not authorized, this error appears:
Security Violation: Login denied (no login entry)
If the client is authorized or security is disabled, the DirectConnect for z/OS Option acknowledges the login.
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.
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:
Security Violation: Access to RPC ‘xxxx’ denied.
The client is not authorized or is not listed correctly.
Request Rejected: No host connections are available.
Connections to the mainframe are unavailable.
Request Rejected: Remote procedure ‘xxxx’ not found.
The RPC name was entered incorrectly or the name is not in the lookup table.
TRS sends the client External Data Representation (XDR) information to the mainframe.
TRS sends the client RPC parameters to the mainframe, and then waits for a reply from the transaction.
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.
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.
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.
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:
The client may be set up to disconnect after invoking the transaction and before the transaction ends.
ASE logs out after sending a client request and, therefore, does not support long-running transactions.
For more information on identifying problems, see “Common problems and suggested solutions”.
