On Feb 23, 2011, at 13:25, Robert A. Rosenberg wrote: > At 15:18 -0700 on 02/21/2011, Paul Gilmartin wrote about Re: SYSADATA > file quirk: > >> Simply, the check should be coded in OPEN, and any attempt >> to modify the attributes of a nonempty existing data set should ABEND. > > IMO - Only if this is being done in an downward incompatible way. > > IOW: Increasing the BLKSIZE is OK. So is increasing the LRECL (but > only for a V not a F dataset). The idea is if the new settings allow > members stored with the old settings to still be read, then there is > no real problem. Reducing either BLKSIZE or LRECL should trigger the > ABEND since it would cause read problems for members who can now > exceed the new maximum LRECL or BLKSIZE lengths.
Of course, if a DCB has hard-coded LRECL (frequently done) or BLKSIZE (what a bad idea!), increasing either can cause existing programs to fail. I'd have little problem with either your proposal, or a simple fiat that the data set must be copied to change attributes. (Can IEBCOPY deal with a change in LRECL? How about IEBGENER?) And John M. reports that a CA product can enforce the restriction. Apparently they see this as a feature sufficiently useful that they can charge money for it. IMO, the most frequent intentional use of the facility to change attributes is to recover from the situation where a programmer has unintentionally changed them. -- gil
