On 03/01/2016 09:06 AM, Mike Schwab wrote: > The LRECL should be at least the MAXIMUM record length. Additional > space would be filler or trimmed by the actual length on a variable > record. > > On Tue, Mar 1, 2016 at 8:49 AM, Tim Brown <[email protected]> wrote: >> Yes to "So if you write X records and determine you need a different lrecl?" >> >> I will try your suggestions: An IF Statement with a different ALLOC >> statement with REUSE or MOD might do it. Or you may need to FREE and ALLOC >> as needed. >> >> Tim One point which I'm not sure was made clear: the attributes describing the DASD file in the VTOC are only set at OPEN-for-OUTPUT time, so changing the DCB after records have been written but before the CLOSE may affect current program behavior but those changes won't be reflected in the VTOC attributes for the file. Subsequent allocation of the file without specifying LRECL will default at OPEN time to the LRECL at the original OPEN.
A subsequent allocation of the file can specify a compatible desired LRECL and an OPEN for INPUT will use that LRECL to override the attributes from the VTOC on DASD, but again the values in the VTOC won't be affected. To change the VTOC attributes after the original CLOSE, you must use a subsequent FREE and ALLOC specifying the desired LRECL and DISP(MOD) (to retain existing records) and then OPEN the file for output and CLOSE the file. As others have mentioned, if you set attributes this way to values that are incompatible with some of the physical blocks already in the file, you will no longer be able to read those blocks successfully (and for a PDS file the attributes are for the entire PDS, so any file attribute change while writing one PDS member must be compatible with every member in the PDS). The only reasons I can think of why you might want to reduce a VB LRECL to the minimum for actual records is (1) to make clearer from the file definition itself whether the file would be compatible with some other program or process that has a documented upper limit for LRECL; (2)to make clearer from the file definition itself what minimum LRECL would be required if you wished to convert the file to RECFM=FB without any wasted space, or (3)possibly to aid a program wanting to use LRECL to dynamically pre-allocate storage before actually reading the records for manipulating a large number of records in memory without grossly over-allocating. More commonly one would not define a VB file with an LRECL greater than actually needed unless the application using it was designed to potentially generate records of that length. In that case it is wiser to retain the designed LRECL even if current records are shorter, to make it clear that all downstream programs need to be able to handle that max LRECL. Except in the unlikely event that a poorly written program is internally using many max length moves to manipulate variable-length records, or erroneously padding records written into a VB file with useless trailing bytes, there is zero extra overhead in reading a RECFM=VB file whose LRECL is larger than actually needed by current data. -- 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
