Therm-O-Link wrote:

> On Tue, 24 Mar 1998 16:41:51 -0800,
> [log in to unmask]
> writes:
>
> >We are using Maestro to do our date calculations in JCLs.
> >As part of year 2000 project we would like to change the date format from
> YYMMDD
> >to AAMMDD where AA represents (A0 = 2000 , A1=2001 ,...).
>
> This thing just won't die, will it?  As pointed out by others who are
> far more respected (and respectable) than me, the idea of using AAMMDD
> as a solution to the Year 2000 problem is an excrutiatingly bad one.
> Actually, if the average business hasn't started Year 2000 remediation
> by now, it's already too late.
>
> So, why don't you tell us *your* reasons for using this arcane AAMMDD
> date format?
>

You shouldn't be so quick to label a particular company's methodology as
being a bad idea unless you know more details. Arcane? Doesn't it really
depend on the site, their data and their programs?

I can tell you why WE are implementing this 'arcane' method as you put
it.

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% date field saturation.
It would take many many hours of programming and testing to modify this
code to expand to a ccyymmdd format.

We have 300Gb of databases with lots and lots of date fields. Utilizing
the power of our 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 ccyymmdd 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-nummeric. Due to this format of our data, when using the aammdd
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 aammdd format is the easiest, quickest and
most reliable method for handling our particular Y2K challenge.

Maybe the site you chastized for having a 'bad' methodology and using an
'arcane' data format has very valid reasons for doing their conversion
that way.

Try not to be so quick in judging others methods.
--
****************************************
**                                    **
**  Chad Gilles                       **
**  Sr. Software Analyst              **
** ---------------------------------- **
**  American United Life              **
**  One American Sq.                  **
**  Indianapolis, IN 46206-0368       **
** ---------------------------------- **
**  Ph.  317-263-1423                 **
**  Fx.  317-263-1956                 **
**  EM.  [log in to unmask]           **
** ---------------------------------- **
**                                    **
**    _/_/_/  _/                  _/  **
**   _/      _/                  _/   **
**  _/      _/_/_/  _/      _/_/_/    **
** _/      _/  _/  _/_/    _/  _/     **
**_/_/_/  _/  _/  _/  _/  _/_/_/      **
**                                    **
****************************************