z/OS Communications Server: SNA Programmer's LU 6.2 Guide
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Data delivery considerations

z/OS Communications Server: SNA Programmer's LU 6.2 Guide
SC27-3669-00

As VTAM® specifies the application supplied buffer list, VTAM passes responsibility to the application for ownership of the storage. This ownership responsibility entails either ultimately freeing the storage or passing the storage (along with ownership) to another process. If the original requester of the storage specified a free routine at storage allocation time, that original requester is entitled to the return of storage without modification. Therefore, the receiving application should consider this storage as read-only storage, and should not modify the contents. Note that the storage allocation source is unknown to the receiver. Therefore, the application cannot safely make assumptions as to whether a storage return is to be performed, and consequently whether the read-only requirement exists.

It is possible that applications, if written as a cooperative set of processes, could determine that it is acceptable to modify the data if the original application does not require the original data returned unmodified. The caution here is that applications written in this manner must be able to guarantee that the original requester of the storage is one of the cooperative applications. If it is possible that the originating conversation partner can be on another node, VTAM is the requester of the storage. In this case the cooperative set of applications cannot meet the guarantee that the allocator of the storage be one of the cooperative applications.

Storage passed to the application on an HPDT receive could be copied by VTAM. Data that is not copied is most likely in the same storage as it was when VTAM first obtained the data. Therefore, the contiguous size of storage is based on how the data was obtained by VTAM. If the source was a same-host application, the contiguous size is based on the smaller of sending application buffer size and MAXRU size for the session. If the source was a DLC, the size of each contiguous piece could be based on the amount received from the network based on any number of segmentation schemes. Different arrival rates of the data segments can very likely result in the various segments being received into different CSM buffers. Data can be segmented into different sizes based on these factors. Regardless of the source, VTAM passes the data to the application in as large a contiguous piece as possible without moving the data.

If the storage passed to the application is copied, VTAM obtains a new CSM buffer in order to copy the data. The size of the CSM storage may vary.

If CSM storage is constrained when VTAM attempts to obtain new storage, it is possible that a request for CSM storage could be made that cannot be satisfied. In this case, a return indication is passed by way of the RPL (RCPRI,RCSEC of X'0070',X'0000') to indicate that CSM storage was unavailable. If this situation occurs, the application can take several possible actions.
  • Reissue the APPCCMD several times as a temporary retry recovery action.
  • Issue a non-HPDT receive so that the data can be copied into application private storage.
  • Explicitly deallocate the conversation using APPCCMD services.

Note VTAM gives this return indication only if no storage can be obtained. If some amount of storage can be obtained, this storage is passed to the application with no error return code. This treatment allows VTAM to continue to move data through the system, even when constraint conditions exist. For FILL=LL processing, this method results in a partial LL being received. For FILL=BUFF processing, this method could result in an amount of data being passed to application that is less than the receive buffer size 1.

1 Because the application specifies a buffer list rather than an actual receive buffer, the receive buffer size is specified by the application by way of parameter.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014