> -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin > Sent: Tuesday, October 30, 2007 9:10 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: z/OS 1.9 Features summary >
<snip> > Indeed, but too little too late. The OS (not utilities) simply > should _never_ change the attributes of an existing nonempty > data set. (Possible exceptions: increasing BLKSIZE, and for > RECFM=V increasing LRECL.) If need be, the programmer can > allocate a new data set and copy. The only time I've used the > facility is to recover the mess when someone has misused it. > And then I generally wind up with a PDS containing one member > with RECFM=F among others with RECFM=V. The OS (not whatever > utility) should prevented that happening. > > -- gil I'll go futher than that. The entire concept of LRECL, BLKSIZE, and RECFM is archaic and should be eliminated. If a program wants to read a dataset, let it specify what it thinks the LRECL and RECFM should be. If the system can accomodate that, then so be it - let the system (access method) read the physical data and present it in the format that the program wants. The only cavaet is if there is a record which cannot be processed properly if "reformatted" into the LRECL that the program says that it can accept. As an example, suppose I write a program which expects LRECL=80, RECFM=F. If the actual file only has records which are 80 bytes long or less, then the access method should just "pad out" the record in my buffer using some pad character. The pad character could be specified by the program, or have a specified system default (such as blank or x'00'). If my program expects RECFM=V and the file is RECFM=F, then give the program the entire 80 byte record from the file with an appropriate LLBB file prepended. I have never truly understood RECFM=U. Why is that superior to RECFM=V with an appropriate LLBB? Have I been doing too much UNIX/Linux work lately and been corrupted? -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
