And a physical record, otherwise known as a block is the type of record to which I was referring. The count field, the C of CKD, that has zeros for both the key and the data lengths is what signals an empty block, er, physical record.
I would be very surprised if CMS ever wrote such a record in either file system. That would destroy the formatting of the remainder of the track because Write CKD is a formatting write. Regards, Richard Schuh > -----Original Message----- > From: CMSTSO Pipelines Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin > Sent: Wednesday, April 02, 2008 3:56 PM > To: CMS-PIPELINES@VM.MARIST.EDU > Subject: Re: Writing an empty file to set RecFM and LRecL > > On Apr 2, 2008, at 16:04, Schuh, Richard wrote: > > Historically in the O/S360-z/OS line of systems, a zero > length record > > on disk has indicated End-of-File for either PS or PO organizations. > > In the > > PDS, each member is a PS file, so there are potentially many zero > > length records in a PDS. OS Simulation knows how to handle > them, but, > > as noted, CMS does not like them. > > > Sigh. A couple specious arguments. First, remember that > hardware types say "record" where software types say "block". > > o So we're really talking about an empty block. > - for RECFM=V, an empty record has at least an RDW, so only a block > containing no records can have zero length. > - For RECFM=F, an empty block either contains zero records, or > LRECL=0. May we agree to disregard the latter case? > In either case, a file can be unambiguously terminated by > an empty block, which must contain no records. > > o Does CMS, either in SFS or MDFS, terminate files with any sort of > End-of-File, or does it rely on pointers in the directory? > > o When last I looked (some decades ago) CMS didn't separate MACLIB > members with any sort of End-of-File. Rather, it used a specific > data pattern in a record. (I think this engendered a problem of > unintended detection of End-of-Member). > > -- gil >
