Numeric DATE Fields vs DATE fieldtype

So here's my observations:

If you have RPGIII or earlier applications, and a planning on keeping them, 
I think a 9-position packed decimal field with zero decimal positions is 
adequate.

I guess I like the 9-position packed field for two basic reasons:
(1) The system doesn't have to go through the process of packing/unpacking 
the data. Hence it could perform better.
(2) If we figure out this cryogenic thing, we can avoid the next conversion 
(apologies to Neal Palmer. <g>)

I think 8-digit numeric (packed, zoned or otherwise) are just as good, but 
8-digit packed does require a little extra "so what" processing. So packed 
or zoned doesn't seem to matter here.

The other issue is that of null date values. Many systems use 000000 or 
999999 as a kind of "No date entered" flag. Native AS/400 date fields 
currently do not handle this idiosyncrasy. By the time it is implemented, 
it will be too late for year-2000 conversions, and most likely won't be 
available on Version 3 releases. This will be a feature not used in legacy 
systems.

A lot of people (not a majority mind you, but a few) have gone nuts with 
relationship model and used 3, 2-digit fields. This provides many options 
for date formatting. Ironically, these kinds of systems may be the easiest 
to convert. If you think about it, you only really need to expand the year 
component of a date to at least 4 digits. Hence that 2-digit year can grow 
to 4 digits, and most of the other code  probably won't need to be changed.

If you currently use the L data type in RPGIII or RPGIV, then you're 
already okay. If not, and you want to move to the L data type, then you 
could consider a strategy like the following:

Convert the application to RPG IV--leave the date fields as is--that is 
don't convert the your numeric fields to native date fields yet--and run 
parallel for a period. Make sure everything works. Next, convert the 
numeric fields to native date fields and replace your now converted RPGIII 
date-handling code with native AS/400 RPG IV date operation codes.

For NEW applications, I would suggest using RPG IV and native date data 
types. However it is VERY easy to move between numeric fields that pretend 
to be dates, and native date fields, in RPG IV--it's call the MOVE opcode.

As for the performance issue with DATE fields, I agree that IBM needs to do 
it better. Fixing it with new hardware is no solution because that simply 
means the performance could be even better if they had implemented it 
differently. I guess I'm from the school where DASD is cheap, but CPU speed 
is never good enough.

As for t


Bob Cozzi
Bob@rpgdev.net
http://www.rpgdev.net


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the Midrange System Mailing List!  To submit a new message,   *
* send your mail to "MIDRANGE-L@midrange.com".  To unsubscribe from     *
* this list send email to MAJORDOMO@midrange.com and specify            *
* 'unsubscribe MIDRANGE-L' in the body of your message.  Questions      *
* should be directed to the list owner / operator: david@midrange.com   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *