Posted by Bob A on May 07, 2013 at 12:14:47:
In Reply to: Re: Any ideas on these issues? posted by Barbara Brazil on May 07, 2013 at 10:26:09:
BB:
my two choices in the first post boil down to:
a) break the "big" identifier into the original size and the "suffix", which I'd put at the end of the record... then the key would be key.current + key.suffix this idea occurred to me because in most places this data element is only passed on, so 90+% of the programs don't care if this identifier is split into two pieces, cause they don't even refer to it
b) increase the size of the identifier, change the file to extended key, put the identifier at the end of its own reference file, and at the end of each file that refers to it (where it's not a key)... making its original location as "future expansion"
with the info in this post my decision is (easily) made
it's now 16 bytes.... so, I can easily put it some place at the end and free up the first 16 bytes leaving everything else as is in its own file
I'm a little upset with myself that I wasn't aware of this fact about how the record header is changed by the delete logic... oh well.....
Thanx
Bob "A"
P.S. to put it in perspective.... IBM had a minicomputer (1130) about 50 years ago... it had both RPG and FORTRAN... however, the two languages wrote the file headers with the delete byte in two different offsets... so.... you couldn't share "Business" data (RPG) with "Scientific" data (FORTRAN) unless you wrote assembly language routines that were linked to the main code to do the I/O...
Each file can be a maximum of 1MB in length Uploaded files will be purged from the server on a regular basis.