Re: Numeric DATE Fields vs DATE field type

I would vote for a normal conversion  & Post  date data type- L. due to the
added logic that will have to be considered and corrected.

 Just introducing RPG IV is a low risk. As for planning the  placement of
the  expense should be carefully  done so FASB accounting rules allows it
to be viewed as other than Y2K and it put to the bottom line of the balance
sheet  over a few years.

At 03:22 AM 6/10/97 +0000, you wrote:
>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
>


Glenn
___________________________________________________
Glenn Ericson,          Phoenix Consulting                      
P O Box 701164   East Elmhurst NY 11370-3164 USA                            
Ph. 718 898 9805         Fx. 718 446 1150
AS/400 & Year 2000- - Solutions  © 1997copyright,  all rights reserved
____________________________________________________


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