If you have CA Disk, there is a utility in the systems guide that lets you 
update the DSCB directly.  There also is still probably one in the CBT 
collection that runs as a TSO command.  Make sure to try it on test data first, 
and keep the access limited to systems people who need to use it.

Bob Longabaugh
CA Technologies 
Storage Management

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf 
Of Joel C. Ewing
Sent: Tuesday, March 01, 2016 11:09 AM
To: [email protected]
Subject: Re: rexx and tso alllocate

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to