|
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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.