Don't make a date with A0 for the Year 2000

Click here for Forsythe Solutions sponsor message

Don’t make a date with A0 for the Year 2000

Avoiding database transformation with two-character year solution
has hidden costs

By Roy Brown

Sidebar: Why AO is OK with us

All Year 2000 solutions require that January 1 of Year 2000 be represented as greater than December 31, 1999. One shortcut for HP 3000s is the A0 solution, so identified because it substitutes A0 for the year digits of 00, and thus permits sorts to occur correctly. This stop-gap solution bears some examination, a look at its pros and cons while preparing to upgrade HP 3000 applications.

Pro: Dates stored in X(6) can stay X(6) instead of expanding to X(8). There is no need to revise existing database definitions, rewrite existing dates in them, or redefine dates in program working storage.

But as far as I am concerned, that’s it.

Con: About everything else you can think of.

If your dates are 9(6), you’re down the tubes anyway, as you now need the X(6) format. Even if you are already X(6), 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 from YY to A0 and vice versa. And every time your software references a date, it will have to bear in mind which state it is in, YY or A0. Of course, if you ever need the CC century digits, it’s up to X(8), or find a new home for the CC element.

Watch what you pass these A0 dates to. Expect a few ‘Illegal ASCII digits’ if anything was blithely expecting numerics.

You are going to have to pick the A0 apart into CCYY every time you need the CC or the YY separate. Which is, like, everywhere. Then you are going to have to put the A0 back together from CC and YY every time you need to update the database. Which is, like, often.

Got any dates embedded in keys? Dates indexed by Year, Period, Week? Fun for the application, but do-able, just. Whether they would be such fun for a user, in Query, is another matter. Query has an Edit mask for A0 dates, but that’s all. Some HP 3000 utilities are going to handle A0 dates. Not including QUIZ, according to a letter from Cognos, though I now hear it’s included in 8.19. But don’t count on any Posix applications understanding them.

Got any ‘dummy’ dates, like 000000, 999999 and suchlike? I guess ZZ9999 will cover the latter, but you have to find them all. [Ed. note: we hear the latest version of Adager is adept at finding these dates.]

So why follow the A0 path? I can see the logic for MM 3000 users [Ed. note: MM II uses A0MMDD to resolve the Year 2000 issue, but new owner eXegeSys is considering a switch downline], where a database rebuild takes a wet weekend and a half. Who knows what those cunning users have customized in there? But even there, I reckon it won’t pay off in the long term. The database rebuild is the easy bit. Adager and other tools of that ilk will all do it for you.

The application portion is the harder bit. Now, both ‘CCYY’ and ‘A0’ solutions can stick with six-digit dates in VPlus and go for the implied century. Of course, you’ll need to run all your working storage dates in A0 mode.

Who’s doing more work?

Ask yourself if the harder work is for the ‘A0’ developer, or the ‘CCYY’ developer? CCYY developers have to rejig their databases, their files and the copy library definitions. Maybe they even need a specialist conversion program. This seems to be one up to the A0 developers. But this investment keeps the CCYY developers’ databases ‘open.’ You have to compare this work with all the access rejigging you will ever need when you read the A0 developers’ databases with anything from outside the application.

Both have to convert dates coming from VPlus, one adding CC, one making YY into A0. Call that even.

But the A0 developers have to convert going back to screens. (Unless HP made VPlus handle it. They didn’t, did they?) Almost any of the data reformatting already in use covers it for the CCYY developers. One up for them.

The story is similar for all other external outputs and inputs. MOVE CORR WS DATE to OUT-DATE works just as well for CCYYMMDD to MM/DD/YY as for YYMMDD to MM/DD/YY. Conversion is needed if you only used MOVE, or if you have to add a CC. But every such date for the A0 developers needs a conversion. So evens at worst for the CCYY developers, and maybe one up again.

CCYY developers need to make all their internal working storage dates CCYYMMDD. But in COBOL, it’s all Data Division. Once done (and if you call a POP’A’CC’IN routine when you should), there’s not much more needed.

A0 developers can avoid the Data Division changes, but have a lot more YY’TO’A0 and A0’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, A0 or YY.

CCYY developers have the CC right there all the time. A0 developers need another call if they require this. I think CCYY developers win out on the short-term effort, even with the database conversion required. They also win in the longer-term.

We’re CCYY guys who elected to do it all properly here. Mind you, we still have to talk to, and maybe even update, the ‘A0’ databases of MM 3000 rather a lot – from our CCYYMMDD-using code. There’s no justice in the world!

We ‘out-think’ those databases with some skunkworks stuff, a layer below the application, but it works great. It shows MM/DD/YY on the screen, CCYYMMDD in the program, CCYYMMDD on our LCLDB, A0MMDD on MM’s IOSDB. And back again, as necessary.

I hope it’s not too late for you to switch.

Roy Brown, a 20-year HP 3000 user, is Technical Director at Affirm Ltd., a UK-based ISV developing manufacturing solutions for the HP 3000 community.

Copyright 1998, The 3000 NewsWire. All rights reserved.



		Click here for Forsythe Solutions sponsor message
		Don’t make a date with A0 for the Year 2000 Avoiding database transformation with two-character year solution has hidden costs By Roy Brown Sidebar: Why AO is OK with us All Year 2000 solutions require that January 1 of Year 2000 be represented as greater than December 31, 1999. One shortcut for HP 3000s is the A0 solution, so identified because it substitutes A0 for the year digits of 00, and thus permits sorts to occur correctly. This stop-gap solution bears some examination, a look at its pros and cons while preparing to upgrade HP 3000 applications. Pro: Dates stored in X(6) can stay X(6) instead of expanding to X(8). There is no need to revise existing database definitions, rewrite existing dates in them, or redefine dates in program working storage. But as far as I am concerned, that’s it. Con: About everything else you can think of. If your dates are 9(6), you’re down the tubes anyway, as you now need the X(6) format. Even if you are already X(6), 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 from YY to A0 and vice versa. And every time your software references a date, it will have to bear in mind which state it is in, YY or A0. Of course, if you ever need the CC century digits, it’s up to X(8), or find a new home for the CC element. Watch what you pass these A0 dates to. Expect a few ‘Illegal ASCII digits’ if anything was blithely expecting numerics. You are going to have to pick the A0 apart into CCYY every time you need the CC or the YY separate. Which is, like, everywhere. Then you are going to have to put the A0 back together from CC and YY every time you need to update the database. Which is, like, often. Got any dates embedded in keys? Dates indexed by Year, Period, Week? Fun for the application, but do-able, just. Whether they would be such fun for a user, in Query, is another matter. Query has an Edit mask for A0 dates, but that’s all. Some HP 3000 utilities are going to handle A0 dates. Not including QUIZ, according to a letter from Cognos, though I now hear it’s included in 8.19. But don’t count on any Posix applications understanding them. Got any ‘dummy’ dates, like 000000, 999999 and suchlike? I guess ZZ9999 will cover the latter, but you have to find them all. [Ed. note: we hear the latest version of Adager is adept at finding these dates.] So why follow the A0 path? I can see the logic for MM 3000 users [Ed. note: MM II uses A0MMDD to resolve the Year 2000 issue, but new owner eXegeSys is considering a switch downline], where a database rebuild takes a wet weekend and a half. Who knows what those cunning users have customized in there? But even there, I reckon it won’t pay off in the long term. The database rebuild is the easy bit. Adager and other tools of that ilk will all do it for you. The application portion is the harder bit. Now, both ‘CCYY’ and ‘A0’ solutions can stick with six-digit dates in VPlus and go for the implied century. Of course, you’ll need to run all your working storage dates in A0 mode. Who’s doing more work? Ask yourself if the harder work is for the ‘A0’ developer, or the ‘CCYY’ developer? CCYY developers have to rejig their databases, their files and the copy library definitions. Maybe they even need a specialist conversion program. This seems to be one up to the A0 developers. But this investment keeps the CCYY developers’ databases ‘open.’ You have to compare this work with all the access rejigging you will ever need when you read the A0 developers’ databases with anything from outside the application. Both have to convert dates coming from VPlus, one adding CC, one making YY into A0. Call that even. But the A0 developers have to convert going back to screens. (Unless HP made VPlus handle it. They didn’t, did they?) Almost any of the data reformatting already in use covers it for the CCYY developers. One up for them. The story is similar for all other external outputs and inputs. MOVE CORR WS DATE to OUT-DATE works just as well for CCYYMMDD to MM/DD/YY as for YYMMDD to MM/DD/YY. Conversion is needed if you only used MOVE, or if you have to add a CC. But every such date for the A0 developers needs a conversion. So evens at worst for the CCYY developers, and maybe one up again. CCYY developers need to make all their internal working storage dates CCYYMMDD. But in COBOL, it’s all Data Division. Once done (and if you call a POP’A’CC’IN routine when you should), there’s not much more needed. A0 developers can avoid the Data Division changes, but have a lot more YY’TO’A0 and A0’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, A0 or YY. CCYY developers have the CC right there all the time. A0 developers need another call if they require this. I think CCYY developers win out on the short-term effort, even with the database conversion required. They also win in the longer-term. We’re CCYY guys who elected to do it all properly here. Mind you, we still have to talk to, and maybe even update, the ‘A0’ databases of MM 3000 rather a lot – from our CCYYMMDD-using code. There’s no justice in the world! We ‘out-think’ those databases with some skunkworks stuff, a layer below the application, but it works great. It shows MM/DD/YY on the screen, CCYYMMDD in the program, CCYYMMDD on our LCLDB, A0MMDD on MM’s IOSDB. And back again, as necessary. I hope it’s not too late for you to switch. Roy Brown, a 20-year HP 3000 user, is Technical Director at Affirm Ltd., a UK-based ISV developing manufacturing solutions for the HP 3000 community.

		Copyright 1998, The 3000 NewsWire. All rights reserved.