Not that I am fully informed, but I have been doing I/O at the BSAM, EXCP and STARTIO level for 35+ years, so I's say I was experienced.
Starting with QSAM and F/FB/FBS format. For RECFM=FB or FBS the block size must be an even multiple of the LRECL. If you are off by a byte, you will get an error. For RECFM=F, BLKSIZE must equal LRECL. When reading a RECFM=FBS data set, a short block signals EOF. There may be additional data after it, but a block that is not the full BLKSIZE is EOF. Technically, you don't need an EOF marker on DASD. If you are reading it from a tape device, then the next block must be a Tape Mark (TM). This most often is a problem when someone writes multiple times to a DISP=MOD data set as RECFM=FB and someone else over-rides the RECFM with RECFM=FBS when they go to read it. They do it because someplace they read that RECFM=FBS is more efficient than RECFM=FB. While that may have been true at some point in the past, it isn't any more, at least it isn't really measurable. QSAM and V/VB/VBS format requires a well formed block. The BDW must equal the total of the RDW's +4. The +4 is for the BDW. You mess that up and QSAM will throw an error. As long as the BDW is equal to or less than the BLKSIZE, QSAM will be happy. BSAM needs to follow the same rules as QSAM, especially on writing, so that someone using QSAM can read what the person using BSAM wrote. Needless to say, you have far more opportunities to mess things up with BSAM because you point at a block and tell BSAM to write it. If you format the block badly, BSAM isn't going to tell you about it, it will just write the block. That is especially true for RECFM=V/VB/VBS, although if you try to write longer than the BLKSIZE, it will give you an error. I can't remember, but BSAM may, and I stress may, check the block length is a multiple of the LRECL. I tend to include that sanity check in my own code, so I haven't seen it in BSAM in years. Hope this helps. Best of the season to you all. Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: cblaic...@syncsort.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of J O Skip Robinson Sent: Monday, December 22, 2014 5:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: BDW length vs. Physical Length In the absence of a truly informed response, I'll take a stab. I learned that a (QSAM) I/O request specifying a block size less than the actual size-of-block results in an abend/RC that describes the error. OTOH if the size-of-block is lower than requested, the operation is successful; it's up to the program to manage the shorter-than-expected data. I've never dealt with BSAM, which may behave differently. There also may be a difference between FB and VB. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, December 22, 2014 8:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: BDW length vs. Physical Length For RECFM=V(B)(S), what happens if the physical length of a block exceeds the length in the BDW? o Bytes in the physical block beyond the length in the BDW are ignored? (A writer on another list tells me I can rely on this.) o The access method reports an error? I prefer to follow the rules. Suppose the programmer reads blocks with BSAM and performs strict error checking? Suppose the programmer reads a VBS file on a non-z system and performs strict error checking? (SMP/E copies IEBCOPY relative files to UNIX files and relies on the BDWs to reconstitute the VBS data set.) -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ________________________________ ATTENTION: ----- The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
