I agree with Paul regarding the absurdity he mentioned.
Here's another scheme you might want to consider. Let's call the set of logical records currently at the beginning of the data set the Restricted Access Set. Presumably, the remaining records comprise the Unrestricted Access Set. You could create two files: File One contains the Restricted Access Set records. File Two contains the Unrestricted Access Set records. All file I/O can be done with QSAM without needing to perform any type of record location calculations and the corresponding positioning operations. You can make the Block Size anything that makes you happy; let Data Management do all of the blocking and unblocking and deal with all of the device idiosyncrasies. The two files could even reside on very different types of devices and possibly different file systems. Both sets could be read as a logical single entity by concatenating the two files. The Unrestricted Set could be read (and written if so desired) by simply OPENing that file. The same thing goes for the Restricted Set. The concatenation could be done in JCL and/or Dynamic Allocation. If you do not intend to Extend either set, the two files could be members of a PDS, and you can access the members using QSAM. If you DO intend to extend either set (where the containing file is a PDS), then DISP=MOD (or OPEN EXTEND) against a PDS member is disallowed by Data Management. In this case you would need to create a "new" member by copying the "old" member data to the "new" member, and then (without having CLOSEd the "new" member) add the new logical records. After CLOSEing the "new" member you would need to delete the "old" member and rename the "new" member, giving it the "old" member name. In this kind of scenario a PDSE would be better since it never needs to be compressed. Clearly, the two separate files approach is the simplest. Bob
