Controlling the amount of data received

The buffer length parameter (APC82XBL) in the XBUFLST-receive vector specifies how much data VTAM® should accumulate before completing a receive when the receive is operating in FILL=BUFF mode. When operating in FILL=LL mode, the buffer length parameter is ignored. It is possible for a FILL=BUFF mode receive to complete with less data than the APC82XBL value and data remaining enqueued for the conversation.

The receive completion criteria uses the buffer length indicated in the XBUFLST-receive vector the same as it would on the AREALEN parameter when in FILL=BUFF mode and XBUFLST is not specified. That criteria is one of the following items:

VTAM has internally accumulated the buffer length amount of data.
A PS Header is received.
A non-data indication is received as follows:
- A SEND indication is received.
- A CONFIRM indication is received.
- A DEALLOCATE indication is received.
- An ERROR has been detected.

Once the above receive completion criteria is met, the amount of data received could vary as follows:

The data amount received is greater than or equal to the buffer length value.
This situation occurs if the application-supplied buffer list area is large enough to reference the entire amount of data.
The data amount received is less than the buffer length value.
This situation occurs if:
- The application buffer list is not large enough to reference the entire amount of data.
  In this case the buffer list area is filled.
- VTAM encountered a resource constraint that prevented it from delivering all of the data.
  In this case the buffer list area may or may not be filled.
- One of the non-data events that is indicated in the WHATRCV field occurred.
  In this case the buffer list area may or may not be filled. The WHATRCV field will be appropriately set.

If the application received less than buffer length, it must check the WHATRCV field for a non-data event. If a non-data event is not indicated, that means that more data is being held by VTAM. The application then should issue a new receive for the remainder of the data. A non-data event could have occurred, but it will not be indicated in the WHATRCV field until all enqueued data is received. If the application wants to immediately receive any data remainder, the buffer length parameter used on the subsequent receive should be reduced to reflect the difference of the previous buffer length value and the previous amount received. This ensures that the posting criteria is met in the event that a non-data event has not occurred. Note that the APPCCMD TESTSTAT macro can be used to determine the data amount enqueued for the conversation.