Re: Alpha in Numbers running out (was no subject)

From Al Macintyre

Running out of numbers is a familiar topic for programmers - recent Y2K - 
social security numbers next - telephone area codes also a recent memory - my 
favorite "running out of numbers" story is the federal reserve unable to 
generate government bonds for a week

I may earn some flames for this, but it is possible to put alpha characters 
in a numeric field if you recompile all programs that access that field to 
disregard decimal data errors ... not something that I reccommend, because 
then you miss out on discoveries of other problems & depending on what other 
tools you use to access the data that is defined numeric, you are basically 
saying "we cannot access this data base information with these tools because 
we sabotaged the data base."

Eons ago in programming before S/36 there was some IBM limitation on how long 
a numeric field could be, so I basically defined two numeric fields & all 
access to them were by logically concatenating them together in all programs. 
 

It was Ok when the data could be treated like alpha reference, but it was a 
bitch to handle the math that carried digits over the threshhold.

If you do not want to change your data base, you might add a new file 
containing the digits in front of your new number, then all programs that 
access your client number would assemble the number you use as say 10,2 S 
from your existing 7 & 3 more pasted in front from some other file.

I believe that fixing the data base would be less trouble than the 
programming, unless you are dealing with packaged software, or infinity of 
other programs accessing the same file.  You either need to make the field 
larger, or redefine it as an alpha character field, depending on what that 
would do to your overall applications.

I believe the process is (& no doubt other people can refine this)

Say goodbye (temporarily) to all your logicals over this physical
Copy the old source file to some safety reference
Copy the file & all its data as is to some other library for safety
Recompile the file source creating empty physical same layout except your 
client field has been enlarged
Copy the data from the old file into the new file & so long as the field 
names are the same, IBM will populate everything correctly, except that your 
7 digit field has become 10 digit field properly populated
Recompile all the logicals that are over this file
Recompile all the programs that access this file
Study screen layouts that display the file ... you may need to move some 
stuff around to make room for the larger field
Study reports that output the file ... you may need to make some adjustments.

There is another thread on locating queries that happen to access the file - 
they also may need adjustment.

A million different clients is an impressively sized business - perhaps my 
guidance is inappropriate.  My current employer has less than a thousand, 
although when I worked in punched card programming we had a 10 digit customer 
account field and it was not big enough, because the first 5 digits was the 
postal zip code, with non-existant zips used for our international clients, 
so retail outlets in high density population cities could easily have more 
than 100,000 customers in the same zip code.

>  From:    GRIFFIC@aisl.uk.com (GRIFFITHS, Clive)

>  some time this year we will need to do some work to extend the range of 
> our client numbers available.
>  
>  The current field is defined as 7,0 S (zoned decimal). Do you know of a way
>  to use hex/alpha characters so that we don't need to make any database
>  changes?

I loved

>  From:    timm@as400ftp.com (Tim McCarthy)

>  Use negative numbers.  

This is really cute & a whole lot easier for most end users to understand 
than hex.

You need to carefully review how negative numbers are printed in reports that 
go outside the company ... personnel at vendors & customers might not 
understand what you are doing, neglect to include the negative number when 
bills are paid, so you have to be careful not to post stuff to the opposite 
absolute value account number.

Hex has a disadvantage that if you have a variety of keyboards, intended for 
AS/400 vs. for PCs, there is no standard way for your users to enter hex.  
There is also the issue of printers able to handle the full collection ... 
you would have to research what the capabilities are of all your printers, 
and enforce some hex-compatibiliies in the aquisition of all future 
additional output devices.  I suspect that hex might also cause some 
difficulties when transmitting data between operating systems, like AS/400 to 
PC.

Al Macintyre  ©¿©
http://www.cen-elec.com MIS Manager Programmer & Computer Janitor
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---