From the trivia-I-happen-to-know drawer. Classic CA-1 (at least used to) use an unblocked RECFM=F data base so that records could be managed in the same way. So tape volser 123456 would be the 123,456th record in the data base. Made for a gigantic data base, but processing was very quick without having to manage an elaborate direct access method.
That empties the drawer. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Woodger Sent: Thursday, January 05, 2017 5:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: IEC141I 013-A8: how to read VS data sets? Yet in modern times the S for F has its uses. If a C/C++ program is going to use a "seek" for a file, if the file is F/FB, then the file will be read from the start to satisfy the seek (because there may be those embedded short blocks), but if the file is FS/FBS (guarantee, by the person who put the S in the RECFM, to not have embedded short blocks) then the seek is able to calculate the position of he block containing the sought record, and then only have to read within the block. I'm sure all C/C++ programmers who want to use seek on z/OS know that, since it is documented. Yeah. Right. (at risk of starting war) people who want to code seek to save a bit of thinking are exactly the ones who read the manuals. What this means is "if you are using seek in a C/C++ program to access fixed-length records, ensure RECFM=FS/FBS. If you haven't done that, do it, and compare the resource usage. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN