VSAM reads/updates records in CONTROLINTERVALs (CIs) but I/O's whole
CIs, not just the records. If the records are fixed length, the CIs will
contain two 3-byte RDFs (Record Definition Fields) followed by a 4-byte
CIDF (CI Definition Field). If they are variable length, the CIs will
contain an RDF for each VL record, finally followed by a CIDF. If there
is a combination of FL and VL records in a CI (where the FL records are
sequences of two or more adjacent same RECSZ records within the CI),
each sequence of same RECSIZE FL records will be associated with two
RDFs (the first indicates the length of each FL record, the second
indicates the number of FL records) and each VL record will be
associated with a single RDF. The CIDF is in the last 4 bytes of the CI
and the 3-byte RDFs are stored in reverse order from the byte before the
CIDF (e.g. if the CIDF is at offset 4092, the 1st RDF is at offset 4089,
the 2nd RDF is at offset 4086 etc.)
So, if there is a VSAM problem after increasing the RECSZ, dump the CIs
and check the record length stored in the RDF: if they don't match, try
REPRO'ing the original VSAM dset to a flat file and then REPRO'ing the
flat file to the new VSAM dset. Else it is probably a programming error:
check the application program's ACB/RPLs/etc. (or whatever the error
message indicates needs fixing).
Has the reloaded VSAM dset with its changed RECSZ ever worked anywhere?
What size records are shown in an IDCAMS "PRINT <...> COUNT(5)" of it?
Joel C. Ewing wrote:
On 06/27/2014 07:53 AM, Elardus Engelbrecht wrote:
Joel C. Ewing wrote:
VSAM KSDS data sets are always variable length by definition. Setting "average record
length" = "maximum record length" indicates an intent to write same length records
and that information is used for space calculations, but each record still has its own length
value, is structurally variable length, and records of any length up to the maximum record length
are allowed by VSAM. So if you just re-defined the file with higher maximum and average record
length and copied the old records to a new file using something like REPRO, or some other utility
with no explicit record size redefinition, the old records would be exactly preserved including the
original record length of 200, just like you were using the utility to copy from one RECFM=VB file
to another VB file defined with a larger record size. There are utilities that will expand and
pad the records on copy, but you have to use appropriate control cards to explicitly request that
be done.
Thanks for this refreshing overview, much appreciated. Mind you, it was some
time ago (I was force-feeded that work when I was a junior!) I wrote programs
handling those VSAM KSDS datasets. So my memory is indeed hazy about that.
What would you suggest to the OP what should he/she do with the excess 50
characters?
Groete / Greetings
Elardus Engelbrecht
If the extra 50 characters is an extension of the last field in the old
record and is only needed in rare cases, then I would be strongly
tempted as a more elegant solution to make that last field and the
entire record variable length to improve I/O efficiency (ditto if the
old record ends with a repeated field, and the increased length is just
an increase in the number of allowed repetitions). If your data really
is variable length, why not put KSDS variable records to good use to
minimize bytes transferred and stored. But, if the field and records
are currently treated everywhere (except VSAM) as fixed length, then
this is probably the more difficult programming change and that decision
would have to be influenced by programming resources available -- and I
have known programmers who just had an unwarranted aversion toward
variable-length records.
If the extra 50 characters represent new fields that will eventually all
become populated as records are updated, then you either have to somehow
supply default values for missing fields internally in programs that
access the records, or add a 50-byte extension with the appropriate new
field defaults to all records. Since you have to modify all programs
that access the longer records anyway, you could go either way here, but
it mght take less coding changes to just extend all records in the data
set with appropriate defaults for the new fields so programs didn't have
to handle short records or missing fields as a special case. We already
know from the OP that the data set size is such that it is practical to
copy and extend all records at the same time.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
