Re: Update primary filre

[Barbara Morris <bmorris@xxxxxxxxxx>]

M. Lazarus wrote:
>   That means that it's more difficult to generate the limits file and 
> the key lengths need to be hardcoded in the program(s) using it.
>
>   Is there any technical barrier to implementing it "properly"?

I agree that it's unfortunate that the key lengths have to be hardcoded.

I don't know whether there's any technical barrier to allowing an 
externally-described limits file.  But I don't know how useful it would 
be either.

About generating the limits file, wouldn't that be a different program 
that _could_ use an externally-described file?

An externally-described limits file would have to have a double set of 
fields, one for the from-keyfields and one for the two-keyfields.

I think it would be easier to use two externally-described data 
structures with just the keys from the controlled file.

Flimits  o    f   100  disk
D keyDs       e ds           extname(myfile:*key)
D limitsRec     ds           qualified
D   from                     likeds(keyDs)
D   to                       likeds(keyDs)

   ... setup limitsRec.from and limitsRec.to
   write limits limitsRec;
   ...

Using the program-described limits file with the externally-described 
keys has the downside that the record length has to be hardcoded in 2+ 
places (the program generating the limits file and the program(s) using 
the limits file).

Using an externally-described limits file would require keeping the two 
externally-described files in sync, with the limits file having two 
copies of each key field in the controlled file (with a different name 
for at least one of each pair of field).  That seems to me to be much 
harder than keeping the record lengths in sync.

To help ensure the record lengths are in sync, you could add this to the 
program that generates the limits file:

    if %size(limitsRec) <> 100);
        issue an error that all the programs using the limits file
        need to be updated
    endif;