In article <01BD362B.B12AAEA0@apatel>, Ashvin Patel
<[log in to unmask]> writes
>Year 2K solution - 6 alpha Numeric Dates (AAMMDD - A00101 - 01/01/2000)
Comments
>& Issues
>
>Currently, I am involved in a Y2K project which has adopted a date format of
>AAMMDD. i.e. January 1st of 2000, stored in the data base as A00101.
(developed
>by James Overman of HP).  I would like to hear pros and cons or a list of
>cautions, problems and issues from anyone who has taken this approach.  Any
>comments from HP - MM3000 group will be greatly appreciated.
>
>My comments so far are:
>1.      Support from existing 3rd party software vendors?
>Robelle Consulting LTD. - SUPRTOOL (Version 4.0) - is already supporting this
>format as AAMMDD. (Thank you Robelle).
>COGNOS - POWERHOUSE, this format will be supported in 8.19 release (8.19
version
>will be in field test in March 1998 @ COGNOS).
>VESOFT - STREAMX - VESOFT, has acknowledged this request for change.  No date
>announced as to when it will be released.
>To commence our integrated testing of the software, we need to wait. (Not too
>bad though).
>2.      Future 3rd party vendors?
>Client-server development? Using ODBC/SE or any other 3rd party software, will
>it recognize date format AAMMDD?
>3.      Complexity?
>Add hoc reports, using Query will be difficult for non IS users to recognize
>year as A0.
>Programs must be aware where the dates are stored into the repository that is
>internal or external, simple move won't work.
>
>Thanks in advance for your comments.
>
>
>Ashvin Patel

Given that the fundamental requirement that 01/01/2000 be represented as
greater than 31/12/1999 must be met by all Y2K solutions, then for the
A0 solution specifically:

Pro: Dates stored in X(6) can stay X(6) instead of expanding to X(8).

     No need to revise existing database definitions, rewrite
     existing dates in them, or redefine dates in program working
     storage.

     Er. That's it.

Con: About everything else you can think of. See below.


If your dates are 9(6), you're down the tubes anyway, as you now need
the X(6) format.

You might think you won't need to change any X(6) dates in working
storage in your programs. And maybe you won't.
But you are going to have to call a routine on them to go YY -> AA and
vice versa. And, everytime your software references a date, it will have
to bear in mind which state it is in, YY or AA.
Of course, if you ever need the CC, it's up to X(8), or find a new home
for the CC bit.


Watch what you pass these AA dates to. Expect a lot of 'Illegal ASCII
digits' if anything was blithely expecting numerics.

You are going to have to pick the AA apart into CCYY everytime you need
the CC or the YY separate. Which is, like, everywhere.

You are going to have to put the AA back together from CC and YY
everytime you need to update the database. Which is, like, often.

Got any dates embedded in keys? Date indexed by Year, Period, Week?
Fun for the app, but doable. Whether they would be such fun for a user,
in Query, is another matter. Query has an Edit mask for AA dates, but
that's it, as far as I know.
(But maybe I'm out of date. I have a letter from Cognos, saying they
have no plans to handle AA dates. So maybe they made some since they
wrote it....)

Got any 'dummy' dates, like 000000, 999999 and suchlike? I guess ZZ9999
will cover the latter, but you have to find them all...


But why are you doing this? I can just about see the logic for MM3000,
where a database rebuild takes a wet weekend and a half, and who knows
what those crazy^h^h^h^hunning users have customised in there, but even
there, I reckon it won't pay off in the long term.

The database rebuild is the easy bit. Adager (hi, Alfredo!) and other
tools of that ilk will all do it for you, IIRC.

The app bit is the harder bit. I presume you're sticking with 6 digit
dates in VPLUS, and going for the implied century?  You've probably got
a routine to do it. You'll need to run all your working storage dates in
AA mode of course.....


So, who's doing more work? The 'AA' guy, or the 'CCYY' guy?
-----------------------------------------------------------

The CCYY guy has to rejig his databases and files, and their copy
library definitions. Maybe even have a specialist conversion program.
Seems to be one up to the AA guy. But this investment keeps the CCYY
guy's DBs 'open'. You have to compare this work with all the access
rejigging you will *ever* need when you read the AA guy's DB with
*anything* from outside the app.

Both have to convert dates coming from VPLUS, one adding CC, one making
YY into AA. Call it evens.

But the AA guy has to convert going back to screen. (Unless they made
VPLUS handle it. They didn't, did they?) MOVE CORR, unchanged from pre-
Y2K, covers it for the CCYY guy. One up, if you used MOVE CORR. Still
evens if you didn't.

Same for any other external I's and O's. MOVE CORR WS-DATE to OUT-DATE
works as well for CCYYMMDD to MM/DD/YY as for YYMMDD to MM/DD/YY. But
every such date for AA needs a conversion first.

The CCYY guy has to make all his internal working storage dates
CCYYMMDD. But it's all Data Division. Once done (and if you call your
POP'A'CC'IN routine when you should), there's not much more needed.

The AA guy can avoid the Data Division changes, but has a lot more
YY'TO'AA and AA'TO'YY calls to position correctly in the Procedure
Division, and the constant worry of whether the date you are using is in
the mode you think it is, AA or YY.

And the CCYY guy has the CC right there all the time. The AA guy needs
another call if he requires this.

I think the CCYY guy wins out on the short-term effort, even with the DB
conversion required, let alone in the longer-term.



Anyway, we're CCYY guys who elected to do it all 'properly' here. But we
still have to talk to, even maybe update, these goddamn 'A0' databases
of MM3000 rather a lot. From our CCYYMMDD-using code. There's no justice
in the world!
So we 'thunk' em. Skunkworks stuff, a layer below the app, but it works
a treat. DD/MM/YY on the screen, CCYYMMDD in the program, CCYYMMDD on
our LCLDB, AAMMDD on MM's IOSDB. Amd back again, as necessary.

Actually, it's probably an easier way of doing AA than the one outlined
above :-)

Hoping it's not too late for you to switch.....

--
Roy Brown               Phone : (01684) 291710     Fax : (01684) 291712
Affirm Ltd              Email : [log in to unmask]
The Great Barn, Mill St 'Have nothing on your systems that you do not
TEWKESBURY GL20 5SB (UK) know to be useful, or believe to be beautiful.'