On Thu, 4 Oct 2012 07:09:02 -0400, Thomas H Puddicombe wrote: >Then again ... > >Why would a rational programmer cause an "empty" record to be written in >the first place? To give the programmer writing the code to process the >data a little something extra to do? To make sure the testers are doing >their job? What? > I truly hope that was whimsical. Records with zero data length (count=4 in the RDW) have long been supported by QSAM for Classic data sets (But not ab ovo; someone in the interim must have submitted a requirement that IBM found valid.)
FILEDATA=RECORD was created (again, not ab ovo) to make processing of UNIX (USS) files more compatible with Classic data sets. Making the behavior of QSAM for records with zero data length differ from Classic to USS does not lighten the burden of the testers; it increases it. And, finally, the designer must take into account that not all programmers are "rational", and some of the others even work for paying customers such as those who required the QSAM change so long ago. >From: Paul Gilmartin >Date: 10/03/2012 05:35 PM > >In: > >Title: z/OS V1R13 DFSMS Using Data Sets >Document Number: SC26-7410-11 > >2.1.2.2.1 Record Processing for UNIX Files > >I read: > > Each record prefix is mapped by the IGGRPFX macro. It is the following >four bytes: > > Offset Length Symbol Description > 0 1 RPFX00 Reserved. > 1 3 RPFXLLL Length of record that follows this >prefix. > > ... If any record in the file consists of zero bytes (that is, the >length field in > the record prefix contains zero) or if any record is longer than the >length > of the buffer, it results in an error return code for GET. > >Sigh. Morons. Why did they do that!? It's like being back in old OS/360 >which specified the minimum count field in an RDW as 5. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
