On Thu, Aug 24, 2017 at 9:03 AM, Paul Gilmartin < 0000000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Thu, 24 Aug 2017 08:09:18 -0500, Elardus Engelbrecht wrote: > > >Paul Gilmartin wrote: > > > >>>> ... RECFM=FB. ... > >>Why is that still a thing in the 21st Century? > > > >Backward compatibility all the way back to Julius Ceasar and Nero ... ;-D > > > >What would you like to have in place of FB? > > > It could be done, with extreme backward compatibility. Consider that for > a UNIX > file if the application OPENs it for INPUT with RECFM=FB, the access method > (it was briefly called "XSAM") pads each record to LRECL with blanks and > removes > the NL character; for RECFM=VB, it converts each NL to a synthesized RDW. > For > OUTPUT, the operations are reversed (but trailing spaces are not removed). > (Except for Binder which pigheadly overrides JCL DD attributes and does its > own stupid thing.) > > Decades ago, before OMVS was envisioned, I was maintaining/enhancing the > runtime library for a FOSS Pascal system and wished the access method > would do something similar for Classic data sets. It would have saved me > considerable support code and a Pascal application could have seen > everything as RECFM=V. > > Such support for Classic data sets still merits an RFE, IMHO. Even better > than > mere backward compatibility. > That would be interesting to have. Let [BQ]SAM compare the RECFM in the DSCB (or tape label) versus the program (or JCL). If the DCB or JCL says RECFM=V & the DSCB says RECFM=F, then create a VB record from the FB record and vice versa. If this were really wanted, then I would bet that someone could use the GPSAM program from the CBT to create something. > > -- gil > > -- If you look around the poker table & don't see an obvious sucker, it's you. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
