Well...BSAM just reads and writes blocks. QSAM involves all kinds of buffering, which would need to be 64 bitted. Also one has to question how much use this all is. In z/OS 64 bit storage is just a sort of data cache really. Programs that use it have to be specially written, it's not a (more or less) transparent thing like in Windows (just recompile with the 64 bit option!) Probably whether MM handles a particular file type is a relevant issue in how likely it might sometime be 64 bit capable.
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. -----Ursprüngliche Nachricht----- Von: IBM Mainframe Assembler List [mailto:[email protected]] Im Auftrag von Bill Fairchild Gesendet: Donnerstag, 13. September 2012 17:28 An: [email protected] Betreff: Re: Data spaces vs hiperspaces Extended data sets all have an extra 32-byte "suffix" added to the end of the data field and 32 is added silently to the user-specified block size. The suffix has info in it that is used, inter alia, to guarantee that blocks received over telecommunication lines for mirroring purposes that may not be sent or received in the same sequence that the user wrote them will be destaged in the correct time sequence at the secondary volume's end. I believe this technology was spawned by XRC. If you're using BSAM, you could just as easily add 32 to the blocksize and manage the "suffix" at the end of the buffer yourself. There's no need for the access method to do only these two new extra things for you. Either there are other reasons for supporting only extended data sets or else it's more of IBM's way of gently migrating all their customers to their newer, later, greater, and more profitable technology. And if they have supported it in BSAM, I expect QSAM will be happening pretty soon. 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 Paul Gilmartin Sent: Thursday, September 13, 2012 9:40 AM To: [email protected] Subject: Re: Data spaces vs hiperspaces On Sep 13, 2012, at 08:12, Bill Fairchild wrote: > Try Googling for a simple sample program using EXCP. I'm sure there must be > several on the CBT tape. I think you would have to use EXCP rather than BSAM > since BSAM apparently only supports 64-bit buffer addresses for extended data > sets, and your data set may not be extended. > Sheesh! They couldn't make an old-style data set a special case of an extended data set, and/of then couldn't treat a below-the-bar buffer as a special case of a 64-bit-addressable buffer? Conway's Law. Sigh. What does an extended data set use in place of CCHHR? -- gil
