

Systems Network Architecture Considerations (SNA) › Receiving Data
Receiving Data
RECEIVE_AND_WAIT DATA
LENGTH
FILL
WHAT_RECEIVED
RESOURCE
RETURN_CODE
To read data sent from another LU, your program must issue some form of read request (#TREQ READ, GET, PUTGET, or WRITREAD). CA IDMS/DC buffers all input received from a logical unit. Your program can issue multiple read statements until all of the data in the buffer has been transferred to your program.
Parameters Applying to Incoming Data
The following parameters apply to incoming data:
- The INAREA parameter specifies the location of the input data stream.
- The INLEN parameter specifies the actual length of the input data stream.
- The MAXIN parameter specifies the maximum length of data your program can receive. CA IDMS/DC never truncates data; if the length of the input data stream exceeds the MAXIN parameter in your READ statement, CA IDMS/DC will buffer the data so that it will be available for your next read request.
- The LOCATE parameter requests CA IDMS/DC to allocate a buffer the exact size of the input data stream. Register 1 contains the address of the buffer that will contain the input data. The INLEN parameter can be used to indicate the actual amount of data received. The LOCATE parameter and the INAREA and MAXIN parameters are mutually exclusive.
If all of the input has been transferred from the data buffer to your program on completion of a read request, the data-complete-flag (UIODC) will be set on. In general, you should always continue issuing read requests until the change-direction (UIOCD) or last (UIOLST) flag has been set.
LU6.2 Conversations
For LU6.2 conversations, CA IDMS/DC can receive only one type of input with each request. For example, if CA IDMS/DC receives input that contains data, a change of direction indicator, and a confirm request, you must issue two read requests in order to get all the information you need:
- First read request—Reads the data. The data (UIODAT) and data-complete (UIODTC) flags in the UIOCB are set on to indicate that all of the data has been received and given to your program (assuming the buffer was large enough to hold all of the data). If the input buffer is not large enough to hold all of the data, CA IDMS/DC will buffer the data so that it will be available to your next read request.
- Second read request—Processes the change of direction and confirmation requests by setting on the change-direction (UIOCD) and confirmation-requested (UIOCFM) flags in the UIOCB.
LU6.2 data is always passed in LU6.2 logical records, made up of a header and the user data. The header consists of a 2-byte length field and a 2-byte generalized data stream ID (GDS ID).
LU6.2 Mapped Conversations
During LU6.2 mapped conversations, CA IDMS/DC removes the header from the logical record (OPTNS=LL).
LU6.2 Unmapped Conversations
During LU6.2 unmapped (basic) conversations, a read request can specify the following options:
- LL specifies that CA IDMS/DC will pass one LU6.2 logical record, without removing the header.
- NOCHASM requests CA IDMS/DC to pass single chain elements (RUs) to your task one at a time, regardless of logical record, without assembling the chain into a buffer area. The last (or only) chain element is indicated by the UIODTC flag.
- Not specifying either option requests CA IDMS/DC to read an input data stream of the length specified by the MAXIN operand, regardless of whether an entire logical record is sent. The read is complete when the amount of data specified by MAXIN has been read, or when the end-of-chain has been indicated.
Non-LU6.2 Conversations
For non-LU6.2 conversations, the following considerations apply:
- All currently available data and read information is passed to your program in one read, unless the buffer is not large enough to hold all of the data.
- A read request can specify either OPTNS=NOCHASM or leave this parameter unspecified:
- Specifying OPTNS=NOCHASM indicates that an inbound chain is passed to your task a single chain element (RU) at a time, without assembling the chain into a buffer. The last (or only) chain element is indicated by the UIODTC flag.
- Not specifying this option requests a read of a single buffer of the length specified in MAXIN. All SNA chains are assembled into a single buffer; the read is completed when either the specified length of data or the RU marked as the end of the chain is received. The data-complete (UIODTC) flag is set when the end of the chain is received.
- Your program can indicate how function management headers (FMH) are handled on input by specifying INFMHY or INFMHN:
- INFMHY indicates that function management headers are passed to your task along with the input data stream. The UIOFMH flag in the UIOCB is set on to indicate the presence of an FMH in the data stream.
- INFMHN requests CA IDMS/DC to remove any incoming FMH from the input data stream before the data is passed to your task.
Copyright © 2014 CA.
All rights reserved.
 
|
|