Re: BLOCK CONTAINS
- From: "Charles Hottel" <chottel@xxxxxxxxxxxxx>
- Date: Thu, 14 May 2009 22:23:17 -0400
"Frank Swarbrick" <Frank.Swarbrick@xxxxxxxxxxxxxx> wrote in message
news:4A0C5CAB.6F0F.0085.0@xxxxxxxxxxxxxxxxx
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.
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
--
Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation
Lakewood, CO USA
P: 303-235-1403
F: 303-235-2075
Record format is specified by the RECORD CONTAINS clause which is optional.
If omitted the compiler can examine the layouts of the record or records
defined and determine if it is F or V. You could have one fixed length
record , multiple fixed length records of the same length, or multiple
records of different lengths which would mean V. There is also a way to
define record format U.
Blocksize is specified by the BLOCK CONTAINS clause and it may be specified
as zero which means that the DCB does not require any specific blocksize and
in fact the blocksize may then be overridden by JCL or file label (DSCB). If
the blocksize contains a value other than zero then it will not be
overridden. I believe if you omit the BLOCK CONTAINS clause the DCB in the
program will initially be zero. The specification of blocksize in no way
determines the record format.
Here is a slightly edited summary from:
http://www.mail-archive.com/ibm-main@xxxxxxxxxxx/msg82786.html which
describes the DCB merge process:
"It is not mandatory to code DCB parameters in JCL while creating new QSAM
or BSAM dataset. The properties as per the COBOL code in INPUT-OUTPUT
and FILE sections. If the values are coded in JCL and they conflict with
COBOL code then the program fails."
To understand what is happening here one needs to be conscious of the order
in which OPEN constructs the DCB information from the various sources
available. This is not a COBOL issue but an Open Processing one.
There are three source for DCB information, Program, JCL, and File Label,
and the Open Merge process uses the three sources in that order.
This means that anything hard coded in the program cannot be changed in JCL
for instance. This led to the practice of coding BLOCK CONTAINS 0 so that
BLKSIZE on the JCL would be accepted by OPEN.
The general concept produced a trend whereby if data sets were being read,
then DCB information was omitted from JCL so that the File Label would
provide any missing items for OPEN. Conversely if the data set were being
written, then DCB information tended to be included in the DD statement.
In either case, if the DCB were incomplete at this point then an S013
occurs.)
SMS is not really an issue here as the above remains substantially true,
although SMS does allow the short cut of providing DCB information via
DATACLAS thus allowing its omission from the DD statement.
If for some reason there is a conflict of DCB information subsequent to open
being successful, i.e. incorrect JCL parameters accepted in preference to
correct File Label attributes, then an S001 is likely.
The key in all of this is OPEN. If a data set is created via a DD statement
definition and the file is not opened, as would be the case with IEFBR14,
then the DCB information may well be incomplete in the File Label, and may
well produce an S001.
I hope this is of some assistance.
.
- Follow-Ups:
- Re: BLOCK CONTAINS
- From: Frank Swarbrick
- Re: BLOCK CONTAINS
- From: Clark F Morris
- Re: BLOCK CONTAINS
- References:
- BLOCK CONTAINS
- From: Frank Swarbrick
- BLOCK CONTAINS
- Prev by Date: Re: BLOCK CONTAINS
- Next by Date: Re: BLOCK CONTAINS
- Previous by thread: Re: BLOCK CONTAINS
- Next by thread: Re: BLOCK CONTAINS
- Index(es):
Relevant Pages
|
