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. -- Joel C. Ewing, Bentonville, AR [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
