Why A0 is OK with us


By Chad Gilles

Labeling a company’s A0 methodology as a bad idea really depends on the site, their data and their programs. I can explain why we are implementing this method. Due to the nature of our data, we cannot use a windowing technique.

We have 1.5 million lines of code that have a 10 percent date field saturation. It would take many, many hours of programming and testing to modify this code to expand to a CCYY format.

We have 300Gb of databases with lots and lots of date fields. Utilizing the power of our HP 3000 997/500s and based on our benchmarks of Adager’s date conversion routines, it would take us several days of processing just to convert the data to a CCYY format. We are a 24x7 shop and cannot be down for two hours, much less several days.

All of the date fields in our databases are in YYMMDD format defined as alpha-numeric. Due to this format of our data, when using the A0 format, we won’t be required to change anything, except our input and output routines. We are writing callable routines that can be inserted for all input/output areas of the code. This is a much simpler task of programming for our site than the expansion method.

I feel that our usage of the A0 format is the easiest, quickest and most reliable method for handling our particular Y2K challenge.

Chad Gilles is Senior Software Analyst for American United Life in Indianapolis.


Copyright 1998 The 3000 NewsWire. All rights reserved