z/OS Network File System Guide and Reference
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


How the file size value is generated

z/OS Network File System Guide and Reference
SC23-6883-00

When a file is first accessed (for example with ls -l or dir), usually the entire file is read to determine its size, except for recfm(f) or recfm(fbs) where the binary size can be computed without reading the file. If the file is a system-managed PS, VSAM, or PDSE member, both binary and text file sizes are stored on DASD, so that subsequent file size requests do not require the file to be read.

Binary file size can be quickly generated by using recfm(f) or recfm(fbs) to specify a fixed-length record format for the MVS data set. With this format type, the server pads the last logical record with binary zeros in binary mode processing, because MVS always expects complete logical records. If the application tolerates these zeros, using recfm(f) or recfm(fbs) allows the binary size to be computed quickly because the number of bytes can be computed from the number of blocks, which is stored by MVS.

If you need the exact file size and are using binary mode processing, map it to a variable-format, sequential data set on DASD so that the NFS does not need to pad a partially filled last MVS logical record to a record boundary.

For reading small files or the beginning of files, the read-for-size might not add any processing time. As the file is being read for size, the beginning of the file is stored in the buffers set aside by the maxrdforszleft site attribute, until the buffers are full. When the application reads the beginning of the file, this read is fast because it reads directly from the buffer.

MVS stores the number of blocks (rather than the number of bytes) in an MVS file. For most files, therefore, without reading the entire file, the NFS can only give an estimate of the number of bytes in the file, not the exact number of bytes in the file. Even when the server could get the exact byte count without reading the file, the file size could change depending on the file's processing attributes.

For example, selecting text mode processing introduces end-of-line terminators such as lf, crlf, or \n into the file, thus changing the perceived size of the file. As another example, suppose you select text mode processing with blank stripping enabled on a fixed-length record format file. That causes the server to remove trailing blanks from each record, again changing the perceived size of the file. In these examples, when you first request a file, the server must read the entire file to determine its exact size in bytes.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014