Re: BDW length vs. Physical Length
On Thu, 25 Dec 2014 22:29:07 +, Blaicher, Christopher Y. wrote: BSAM gets the length of the block to write from the DCB BLKSIZE at the time of the WRITE. As long as the DCB BLKSIZE is equal to or less than the max BLKSIZE all is OK. BSAM will build the CCHHRKDD from the various values it keeps and the DD comes from the BLKSIZE. I guess you could always leave the BLKSIZE in the DCB, but you are supposed to set the BLKSIZE to the BDW size. I have not done much with BSAM in years, mostly EXCP and STARTIO, so myknowledge of what BSAM checks and validates is vague at best. IIRC, for RECFM=V(B)(S) I never modified DCBBLKSI. I, likewise, and my Assembler skill has atrophied in the decades. For RECFM=FB, a short block is fine as long as it is a multiple of LRECL. As for finding end of file, it is recognized by the EOF marker or end of the last extent, if blocks so fill a track that the system can't fit an EOF marker on it. I remember that to write a short FB block I modified DCBBLKSI, and if I neglected to restore the earlier value before CLOSE Bad Things happened. IIRC, for RECFM=V(B)(S) I never modified DCBBLKSI. Now for Mr. Altmark's comment. Yes, using BSAM, MVS can write all RECFM=VB blocks BLKSIZE in length, but I would not guarantee that everybody will accept them as valid. Also, you would be wasting a lot of space on tracks if you do that. Bottom line - Write well-formed blocks and follow the rules as outlined in the various DFSMS manuals. I'd welcome a specific citation. On 2014-12-22, at 10:13, Alan Altmark wrote: ... MVS has no problem with short records in a block for VB[S] files. Padding the last record doesn't hurt because MVS writes ECKD records that are BLKSIZE in length, but you must not modify the RDW to include the pad bytes. Or, for RECFM=V(B)S you may use Null Segments for padding. Two respectable experts disagree. I remember that for RECFM=V(B)(S) I merely put the desired length in the BDW. I don't yet know which: o Does BSAM write BDW bytes? o Does BSAM always WRITE DCBBLKSI bytes and QSAM ignore the excess on GET? My experience (above) seems to support this. o Does Postel's Principle pertain? Certainly for RECFM=V, always writing BLKSIZE bytes would be wasteful for a ragged file (a preponderance of short records). It's a pity that QSAM doesn't routinely exploit track balances. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BDW length vs. Physical Length
At 10:49 -0600 on 12/27/2014, Paul Gilmartin wrote about Re: BDW length vs. Physical Length: It's a pity that QSAM doesn't routinely exploit track balances. I agree. It is a waste of track space when the access method refuses to write short blocks just to keep all but the last block as BLKSIZ long. I think that VB(S) is might actually make use of the gas at the end of a track and output a short block/segment to fit. It seems to be a trade-off between I/O efficiency/processing and use of the space on a track. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BDW length vs. Physical Length
Equally, it could be argued that the FBA DASD used to emulate ECDKD is in most cases not really 'spinning' DASD at all; but Christopher Blaicher was unassailably right when he said that emulated ECKD devices are what z/OS DASD controllers.see. If one finds it amusing to do so, the reductionist game of describing underlying reality can be played over and over again, down to the quantum-electrodynamic level; but what must be programmed for, in a z/OS environment, is a notional. ECKD device John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BDW length vs. Physical Length
In b6c1eb4364c30e47950e0f68ef65f467a3561...@proditmailbox1.us.syncsort.com, on 12/25/2014 at 10:29 PM, Blaicher, Christopher Y. cblaic...@syncsort.com said: A Count field with key and data lengths of zero is an EOF marker. The key length is irrelevant; any record with a zero data length is will give a unit exception with read, although normal z/OS applications don't write EOF markers with keys. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BDW length vs. Physical Length
In CAE1XxDE1FGTt0Xg9Aea1tDFUHiJhz8CsYh7WHCXe0t2TZqG=7...@mail.gmail.com, on 12/26/2014 at 05:25 AM, John Gilmore jwgli...@gmail.com said: Equally, it could be argued that the FBA DASD used to emulate ECDKD (sic) is in most cases not really 'spinning' DASD at all; AFAIK that is not true yet, although solid state drives are certainly moving up rapidly. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BDW length vs. Physical Length
My implicit qualification to z/Architecture contexts should have been explicit, Elsewhere rotating DASD continues in significant use. It is, however, all but irrelevant to the current discussion John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BDW length vs. Physical Length
On Wed, 24 Dec 2014 19:18:44 -0500 Robert A. Rosenberg hal9...@panix.com wrote: :At 22:59 + on 12/23/2014, Blaicher, Christopher Y. wrote about :Re: BDW length vs. Physical Length: :I can't remember, but BSAM may, and I stress may, check the block :length is a multiple of the LRECL. :This would only be applicable to FB. I doubt that it checks. The only thing I would expect it to check (which the I/O driver is really checking) that the block is less than the amount specified to read. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BDW length vs. Physical Length
I have to question the accuracy of Mr. Altmark's comment. First let's take the last question from Paul Gilmartin. ECKD, which is what all modern DASD is, stands for Extended Count Key Data. The 'Extended' refers to the channel commands you can issue, not the devices capabilities. All blocks written to a ECKD device consist of a Count field, an optional Key field and a Data field. The Count field is 8 bytes long and has a format of CCHHRKDD. (Extended format volume count fields are formatted slightly differently, but for basics, this will do.) CC = the Cylinder number. HH = the head number. K = Key length. DD = Data length. If the key length is zero, there is no key field. A Count field with key and data lengths of zero is an EOF marker. BSAM gets the length of the block to write from the DCB BLKSIZE at the time of the WRITE. As long as the DCB BLKSIZE is equal to or less than the max BLKSIZE all is OK. BSAM will build the CCHHRKDD from the various values it keeps and the DD comes from the BLKSIZE. I guess you could always leave the BLKSIZE in the DCB, but you are supposed to set the BLKSIZE to the BDW size. I have not done much with BSAM in years, mostly EXCP and STARTIO, so my knowledge of what BSAM checks and validates is vague at best. What I can tell you is that any time you don't follow the rules, I.E. write a block longer than the BDW, someone is going to complain. Be it BSAM, QSAM or someone using EXCP and doing extensive sanity checking, or that has been my experience. For RECFM=FB, a short block is fine as long as it is a multiple of LRECL. As for finding end of file, it is recognized by the EOF marker or end of the last extent, if blocks so fill a track that the system can't fit an EOF marker on it. Now for Mr. Altmark's comment. Yes, using BSAM, MVS can write all RECFM=VB blocks BLKSIZE in length, but I would not guarantee that everybody will accept them as valid. Also, you would be wasting a lot of space on tracks if you do that. Bottom line - Write well-formed blocks and follow the rules as outlined in the various DFSMS manuals. 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 On 2014-12-22, at 10:13, Alan Altmark wrote: ... MVS has no problem with short records in a block for VB[S] files. Padding the last record doesn't hurt because MVS writes ECKD records that are BLKSIZE in length, but you must not modify the RDW to include the pad bytes. ... which raises lotsa questions. Is this BLKSIZE in the DCB, BLKSIZE in the JFCB, or other? What goes in the CKD COUNT field? For EKCD RECFM=FB, how does the access method recognize a short block that may occur at the end of the data set (or even in the interior). Does ECKD prohibit DISP=MOD for RECFM=FB? Etc. -- 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
Re: BDW length vs. Physical Length
cblaic...@syncsort.com (Blaicher, Christopher Y.) writes: ECKD, which is what all modern DASD is, stands for Extended Count Key Data. The 'Extended' refers to the channel commands you can issue, not the devices capabilities. All blocks written to a ECKD device consist of a Count field, an optional Key field and a Data field. The Count field is 8 bytes long and has a format of CCHHRKDD. (Extended format volume count fields are formatted slightly differently, but for basics, this will do.) all modern disk is fixed-block, there hasn't been any real CKD DASD manufactured for decades ... it is all emulated on industry fixed-block disks. ECKD started out when MVS couldn't support FBA ... and they wanted to retrofit 3380 3mbyte/sec disks to 1683033 1.5mbyte/sec channels ... getting CALYPSO to work was something of horror story past posts mentioning FBA, CKD, multi-track seek, etc http://www.garlic.com/~lynn/submain.html#dasd past posts specifically mentioning CALYPSO http://www.garlic.com/~lynn/2004o.html#7 Integer types for 128-bit addressing http://www.garlic.com/~lynn/2007e.html#40 FBA rant http://www.garlic.com/~lynn/2007f.html#0 FBA rant http://www.garlic.com/~lynn/2008q.html#40 TOPS-10 http://www.garlic.com/~lynn/2009k.html#44 Z/VM support for FBA devices was Re: z/OS support of HMC's 3270 emulation? http://www.garlic.com/~lynn/2009p.html#11 Secret Service plans IT reboot http://www.garlic.com/~lynn/2010e.html#36 What was old is new again (water chilled) http://www.garlic.com/~lynn/2010h.html#30 45 years of Mainframe http://www.garlic.com/~lynn/2010n.html#14 Mainframe Slang terms http://www.garlic.com/~lynn/2011e.html#35 junking CKD; was Social Security Confronts IT Obsolescence http://www.garlic.com/~lynn/2012j.html#12 Can anybody give me a clear idea about Cloud Computing in MAINFRAME ? http://www.garlic.com/~lynn/2012o.html#64 Random thoughts: Low power, High performance -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BDW length vs. Physical Length
Lynn, Of course you are correct as far as the physical disk is concerned, but z/OS only talks to ECKD controllers which emulate ECKD on FBA devices. The discussion was on how BSAM and other I/O routines read and write data on DASD. 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 Anne Lynn Wheeler Sent: Thursday, December 25, 2014 8:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: BDW length vs. Physical Length cblaic...@syncsort.com (Blaicher, Christopher Y.) writes: ECKD, which is what all modern DASD is, stands for Extended Count Key Data. The 'Extended' refers to the channel commands you can issue, not the devices capabilities. All blocks written to a ECKD device consist of a Count field, an optional Key field and a Data field. The Count field is 8 bytes long and has a format of CCHHRKDD. (Extended format volume count fields are formatted slightly differently, but for basics, this will do.) all modern disk is fixed-block, there hasn't been any real CKD DASD manufactured for decades ... it is all emulated on industry fixed-block disks. ECKD started out when MVS couldn't support FBA ... and they wanted to retrofit 3380 3mbyte/sec disks to 1683033 1.5mbyte/sec channels ... getting CALYPSO to work was something of horror story past posts mentioning FBA, CKD, multi-track seek, etc http://www.garlic.com/~lynn/submain.html#dasd past posts specifically mentioning CALYPSO http://www.garlic.com/~lynn/2004o.html#7 Integer types for 128-bit addressing http://www.garlic.com/~lynn/2007e.html#40 FBA rant http://www.garlic.com/~lynn/2007f.html#0 FBA rant http://www.garlic.com/~lynn/2008q.html#40 TOPS-10 http://www.garlic.com/~lynn/2009k.html#44 Z/VM support for FBA devices was Re: z/OS support of HMC's 3270 emulation? http://www.garlic.com/~lynn/2009p.html#11 Secret Service plans IT reboot http://www.garlic.com/~lynn/2010e.html#36 What was old is new again (water chilled) http://www.garlic.com/~lynn/2010h.html#30 45 years of Mainframe http://www.garlic.com/~lynn/2010n.html#14 Mainframe Slang terms http://www.garlic.com/~lynn/2011e.html#35 junking CKD; was Social Security Confronts IT Obsolescence http://www.garlic.com/~lynn/2012j.html#12 Can anybody give me a clear idea about Cloud Computing in MAINFRAME ? http://www.garlic.com/~lynn/2012o.html#64 Random thoughts: Low power, High performance -- virtualization experience starting Jan1968, online at home since Mar1970 -- 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
Re: BDW length vs. Physical Length
On 2014-12-23, at 15:59, Blaicher, Christopher Y. wrote: 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. Reading Data Sets 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. I had asked a related question on IBMVM, citing: http://www-01.ibm.com/support/knowledgecenter/api/content/nl/en-us/SSLTBW_2.1.0/com.ibm.zos.v2r1.idad400/d4361.htm Null Segments z/OS DFSMS Using Data Sets SC23-6855-00 I could find no affirmative statement in op. cit. either affirming or forbidding that the physical block may be longer than the count in the BDW, and Alan Altmark followed up: On 2014-12-22, at 10:13, Alan Altmark wrote: ... MVS has no problem with short records in a block for VB[S] files. Padding the last record doesn't hurt because MVS writes ECKD records that are BLKSIZE in length, but you must not modify the RDW to include the pad bytes. ... which raises lotsa questions. Is this BLKSIZE in the DCB, BLKSIZE in the JFCB, or other? What goes in the CKD COUNT field? For EKCD RECFM=FB, how does the access method recognize a short block that may occur at the end of the data set (or even in the interior). Does ECKD prohibit DISP=MOD for RECFM=FB? Etc. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BDW length vs. Physical Length
At 22:59 + on 12/23/2014, Blaicher, Christopher Y. wrote about Re: BDW length vs. Physical Length: I can't remember, but BSAM may, and I stress may, check the block length is a multiple of the LRECL. This would only be applicable to FB. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BDW length vs. Physical Length
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
Re: BDW length vs. Physical Length
I should have mentioned, See Chapter 20 of DFSMS Using Data Sets 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 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
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
