The term partial record or incomplete record applies to both z/OS NFS server text and binary modes whenever processing data blocks in RPC WRITE operations for the legacy path.

For text mode, the z/OS NFS server finds and extracts a record from the byte data stream sent by a client by checking sequentially for end-of-line (EOL) delimiters. The scope of a record being defined as a text partial record is limited to an RPC WRITE size of a data block.

An RPC WRITE data block usually contains several text records. If the last or the only record in the first RPC WRITE data block (starting at offset=0 of the byte data stream) has no tail with EOL then it is a text partial record. The second sequential RPC WRITE data block (with the byte data stream offset = size of the first RPC WRITE data block) contains the tail of the partial record from the first RPC WRITE data block, and so on for further RPC WRITEs.

RPC WRITEs may come to the z/OS NFS server out-of-sequence, so there can be a lost RPC WRITE data block within the byte data stream and thus RPC WRITE data blocks cannot be chained together one-by-one by the z/OS NFS server. If an RPC WRITE data block is not the first one (offset not equal to 0) and the previous sequential RPC WRITE data block is lost, then the first record in this RPC WRITE data block may be incomplete as it has no beginning, just some tail bytes before EOL (or only EOL).

The z/OS NFS server treats a lost or absent RPC WRITE data block as containing a partial record by default.

For binary mode, there is no need to look for records or EOL in the byte data stream, but a lost or absent RPC WRITE data block leads to the same partial record problem (a very long record of the data stream size has data holes somewhere inside).

For both text and binary modes the z/OS NFS server counts the number of bytes of data stream arrived from a client and waits for a new RPC WRITE data block from the client for a specified writetimeout. After this writetimeout expiration, the z/OS NFS server flushes the record_structured cached data (raw data for binary mode) to disk, and closes/deallocates the data set. The z/OS NFS server fills in the "holes" caused by lost RPC WRITE data blocks with zeroes during data flushing. So if an RPC WRITE data block is truly lost (never retransmitted) to the z/OS NFS server, a closed data set will contain zeroes for that data portion that contains holes. The zeroes in a closed data set may be put by the z/OS NFS server at the end of a data set if the last record (referenced by the last data stream byte) is a partial record.

Also, data flushing may be initiated by the z/OS NFS server on RPC WRITE and COMMIT operations without the data set being closed or deallocated.

To indicate the cases of lost RPC WRITE data blocks or partial records, APAR OA16182 introduced special GFSA824W and GFSA825W messages that are issued to the console/log data sets after original writetimeout(n) expiration before data set closure/deallocation.