On 14 May 2009 17:05:53 -0700, in bit.listserv.ibm-main you wrote: >I have been a bit of experimenting with z/OS QSAM files from a Cobol program >and I find that the manuals don't exactly agree with my results. The manuals >seem to imply that if you use the BLOCK CONTAINS clause (whether 0 or >something else) then the file has a RECFM of either VB or FB. And if you >don't >include it then it's either V or B.
While blocked input files may be read successfully if neither the block size nor BLOCK 0 is specified provided record descriptions match, lack of BLOCK CONTAINS causes the default blocksize on output to be ONE record. I believe I submitted a SHARE requirement back in the 1990's to have a compile option that the default be BLOCK 0. Either is a perfectly valid default according to the COBOL standard. BLOCK would be the default consistent with VSAM handling. The whole issue is a sore point with me and possibly others. Incidentally be careful to specify BLKSIZE=0 on the DD statements of output files from sorts that sort or copy VSAM files. Unless things have changed from 1998, SYNCSORT defaulted to one record per block. Coding RECFM=FB or RECFM=VB also might have forced the output to be blocked. Subtle gotchas lurk. I know having been bitten. > >However, I have been able to read and write to a RECFM=VB file with a Cobol >program that does not have the BLOCK CONTAINS clause. Additionally, I can >read a RECFM=V file with a Cobol program that *does* have a BLOCK >CONTAINS clause. I also can read and write files where BLOCK CONTAINS is >specified (non-zero) but does not match the actual block size of the file. It >just does not appear to matter. > >It seems to me that the RECFM and BLKSIZE information that is specified on >the DD or in the catalog overrides whatever you tell Cobol anyway, so it >seems to not matter what you tell Cobol. > >Basically (and I know this is something so small that you'd wonder why I even >care) I can't see any reason to ever specify the BLOCK CONTAINS clause. If >the file is already cataloged I definitely don't need it. And even if I want >to >create a new VB or FB file I can just put the RECFM option on the DD. > >One thing I haven't checked is if tapes will cause me any problems. But our >applications all backup to disk files instead of tape, so I'm not really >concerned. > >If you do wonder why I care, it's this... We are migrating from VSE to z/OS, >and at the same time we are going to convert most of our existing ESDS files >to regular sequential files. I see no reason to add "BLOCK CONTAINS 0" to all >of our FD's if it has no affect (our VSAM FD's do not (generally!) specify the >BLOCK CONTAINS clause, because it has no meaning to VSAM). (Yes, I do >know we need to remove the AS- prefix from the ASSIGN clause of the >SELECT statement.) > >Thanks! >Frank > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
