Post by Test
The original design was that only 0-9999 would be enough (only positive
integers). Unfortunately this was not enough (after 10 years). It would much
better if I could fit a higher number. What I need to maintain compatibility, ie
if str gets " 15" it mean number 15. A hex number could otherwise suffice if not
A quick solution would have a numbering systems where 0..9998,9999, AAAA,AAAB...
etc. where "AAAA" is 10000 and "AAAb" 10001 and so on.
Another oen could be using a hex number say "1000" is 4096 decimal.
This would make life a lot easier and provide backward comptibility: older
systems can continue providing 0...9999 but newer systems would be able to also
utilize higher numbers while haveing 0...9999 if the number is within oldstyle
range. When when the main program sees anything other than space of a digit it
assumes that a newer version want to give a number larger than 9999.
Not wanting to reinvent the wheel are there C source code examples to this
As an aside, a similar thing happened in many mainframe data
processing shops in the US in the early/mid eighties.
Many shops that stored addresses stored the ZIP code (postal code) as
a five character field, with five numeric digits in it. IOW, a Cobol
"PIC 99999 USAGE DISPLAY" field. The introduction of the extended
scheme ("ZIP Plus 4" - that's the 12345-6787 you see at the end of
many computer generated addresses - rarely is that written on hand
addressed envelopes) suddenly gave people *nine* digits to store.
The hack, repeated in hundreds of shops, was to redefine (create a
union) of the original (display) field and a *packed* (BCD) ZIP+4
field, and use the fact that no valid packed field would also be a
valid display field (and vice-versa, at least in EBCDIC) to
05 ZIP-CODE PIC 9(5) USAGE DISPLAY.
05 ZIP-PLUS-FOUR REDEFINES ZIP-CODE PIC 9(9) USAGE COMP-3. (="BCD")
IF ZIP-CODE IS NUMERIC
...use 5 digit ZIP Code
IF ZIP-PLUS-FOUR IS NUMERIC
...use 9 digit ZIP+4
That let them handle both formats, without getting all the files
converted, plus allowed them to update the fields without
re-arraigning the record layouts to accommodate a bigger field.
It would be a trivial thing to do something similar, and distinguish
between the two cases based on the "old" form being valid or not. A
simple solution would be to store a "z" in the first position, and
then a 24-bit binary number in the other three. That get's you some
16.7 million additional values. A bit more complex, you could code
the new numbers as a 24 bit binary plus another number from
0..(255-11) (there being 11 valid character in the first position of
an "old" style number, for a total for 4.1 billion new numbers.
Now whether or not this is a good idea is a completely different