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: [email protected]


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 
[email protected] 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 [email protected] with the message: INFO IBM-MAIN

Reply via email to