|
|
|
|
This section explains some SNA information that you need to consider when writing SNAP-IX LU0 applications.
This guide does not attempt to explain SNA concepts in detail. If you need specific information about SNA message flows, refer to the documentation listed in Related Publications, and to the documentation for the host application for which you are designing your SNAP-IX LU0 application.
During initialization of the LU session, the host sends a BIND message to SNAP-IX that contains information such as RU sizes to be used by the LU session.
The LU0 API makes its own checks on the BIND parameters. The BIND must conform to the specification in BIND checking; if it does not, LU0 rejects it and fails the session initialization.
If the BIND passes the checks above, and the application has used the asynchronous version of lu0_init, the API then returns the BIND to the LU0 application using the callback function. It is the responsibility of the application to check that the parameters specified on the BIND are suitable. The application has the following options:
Accept the BIND as it is, by simply returning from the callback function.
Reject the BIND by issuing an asynchronous lu0_term from within the callback function.
If the application uses the synchronous version of lu0_init, it cannot check the BIND parameters. The LU0 API does its own BIND checking but does not pass the BIND to the application.
The LU0 API does not provide a mechanism for the application to negotiate BIND parameters.
SNA sense codes may be returned to an LU0 application in the following cases:
If the session cannot be initialized:
If the LU0 application cannot connect to the local LU, SNAP-IX returns an LU0-specific sense code. The possible values of this sense code are listed in LU0-Specific Sense Codes.
If the session cannot be established, SNAP-IX returns the sense code that was supplied by the host.
If the session fails after initialization.
If the application specifies in the lu0_init function call that data is to be sent RQD (definite response required), the host provides a sense code when responding to data sent by the application.
When the application issues an lu0_read call to read data from the host that was sent RQD (definite response required), LU0 sends a positive response to the host for this data. There is no mechanism for sending negative responses to the host.
LU0 uses a number of standard SNA sense codes, and also some LU0-specific sense code values. When returning a sense code, it also writes details of the error to the SNAP-IX error log file; check this file for more information on a specific error.
To determine the meaning of a sense code returned by LU0, first refer to IBM's Systems Network Architecture: Formats. The sense codes are listed in numerical order by category.
If the returned value is not listed in Systems Network Architecture: Formats, it is an LU0-specific value. Refer to LU0-Specific Sense Codes for more details.
Pacing is handled by the LU0 interface.
If pacing is being used on data sent from the LU0 application to the host (this is determined by the BIND), an lu0_write function may take some time to complete. This is because SNAP-IX has to wait for pacing responses from the host before it can send more data.
If pacing is being used on data sent from the host to the LU0 application, SNAP-IX sends a pacing response when the application issues lu0_read to read data from the host. This means that, if data is queued in LU0 because the host is sending data faster than the application is reading it, SNAP-IX withholds pacing responses to apply back-pressure to the host application.
If an LU0 application is used to transfer large quantities of data without requiring a response, either to the host or from the host (for example, a file transfer application), then the host configuration should specify that pacing is used in that direction; this is to ensure that the node receiving the data is not flooded with data and does not run out of data storage.
Chaining of RUs is handled by the LU0 interface.
The lu0_read function always returns a complete chain of data to the application.
If the data supplied to the lu0_write function is larger than the maximum RU size specified on the BIND, the LU0 interface divides the data into a chain of RUs. If the BIND specifies an unlimited RU size (indicated by a value of zero), LU0 uses an RU size of 4096 bytes for sending data to the host.
|
|
|
 |
|