According to slide 4 of z/OS SAM extended format and compression (a 12-slide slide show at http://publib.boulder.ibm.com/infocenter/ieduasst/stgv1r0/index.jsp?topic=/com.ibm.iea.zos/zos/1.0/DFSMS/V1R0-SAM-Extended-Format-100808/player.html), the suffix contains the length of the user data, the relative block number, and three bytes used to detect control unit padding.
According to z/OS DFSMS Using Data Sets, control unit padding occurs when the block is written during one of the following four situations: when the processor loses electrical power while writing a block. when an operator issues the CANCEL command. during a timeout. during an ABEND when PURGE=QUIESCE was not specified on the active ESTAE macro. When read back in, if control unit padding is detected then an I/O error is signaled. Bill Fairchild Programmer Rocket Software 408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA t: +1.617.614.4503 * e: [email protected] * w: www.rocketsoftware.com -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of David Stokes Sent: Thursday, September 13, 2012 1:10 PM To: [email protected] Subject: Re: Data spaces vs hiperspaces The 32 bytes is a Media Manager thing, which is a level below the access method, it's nothing to do with 64 bit or not. AFAICT there's a count for record number in a file, I don't see any connection with data transfer since there's no time dependency here, also a network protocol can add all kinds of metadata, no need to save it in the physical file. Do you have any reference for this? Also user block lengths are simulated in extended files. (One of the more interesting items I've discovered in this area btw is the Berger/Bruni RedPaper on MIDAW). Anyway, there's no point I can see in adding it yourself since either MM does it for the datasets it handles or it would be assumed to be just part of the user record.
