Re: Numeric DATE Fields vs DATE fieldtype

[ConnectY2K@xxxxxxx]

In a message dated 97-06-11 04:52:43 EDT, you write:

<< From:        BobCozzi@ibm.net (Bob Cozzi)
 Sender:        mcsnet!midrange.com!midrange-l-owner@Mcs.Net
 Reply-to:      MIDRANGE-L@midrange.com
 To:    MIDRANGE-L@midrange.com ('MIDRANGE-L@midrange.com')
 
 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 >>

SOUNDS  reasonable - how does that fit to most Y2K tools.  Not just
Bypass2000 that you mentioned.  


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *