Re: Question: How will the Year 2000 bug impact your work?
Posted in 1996
Topics: Stored Procedures & SPL
Ray Porter <lrp@email.adp.unc.edu> wrote: >Kim Schludecker wrote: >> >> Terry Pennington wrote: >> > >> > James Buss wrote: >> > > >> > > > >It has long been prophesied that the end of the world is going to occur in >> > > > >1999, and therefore renders the question moot. :-)=) >> > > >> > > > Excellent point, Jeff. >> > > > I can change my date fields back to two digit centuries again! :) >> > > >> > > Of course, I don't see what the big deal is about typing 19 in front of >> > > all my dates. >> > > >> > > Jim. >> > It's not that YOU have to type the '19' in front of dates, it's the >> > users that whine about it. Two more characters per date and the next >> > thing you know there's no time to gather 'round the water cooler and >> > chat about the kiddies and kitties. >> > >> > But, I'm just a cynical crumudgeon who can't spell as you can see from >> > this sentence. :)>. (new symbol for smiling while sporting beard) (and >> > very small nose) (and no hair, which fits) >> > >> > Terry Pennington >> >> Didn't I learn at Progress school that you can set the century to start >> at 1980 and end at 2079 or some such thing? Thereby eliminating four >> digit years? > >Maybe, but that won't help everyone. Our database is the >alumni/development >database at UNC and we legitmately have dates spanning the period from >about 1725 to the present (and continuing into the future) so there have >always >been places in our system where our users have had to enter the century >along >with dates. Fortunately for us, our dates have always been stored as 8 >digits >so we haven't had to make any file changes. The only thing we had to do >was >make room on screens and reports to display/enter the additional data. >I would >estimate it probably took us (2 full-time and 1 half-time programmers) >less than >a month all together to complete the necessary changes (and that was >while continuing >normal maintenance and some new development). It's going to be more of >a problem >for those who have to restructure files because they've stored dates as >6 digits. > >Still, overall, I think this problem has been far overblown by the media >and >alarmists in our own profession. It is a problem that has to be >addressed. >Fixing it is going to be tedious and more or less time consuming but not >particularly difficult. In fact, it probably won't take all that much >time >if people will quit worrying about it and just do it. It's just another >maintenance task and one that we have over 3 years to complete. > >BTW, the application that we just fixed consists of over 400 mainframe >batch >programs (Cobol II), a similar number of mainframe online programs and >screens, >a fairly major DSS client/server system, large IDMS and Sybase databases >and >numerous sub-systems and desktop apps. Three of us got it all converted >in >a month (note that the only file changes we had to make were to flat >file extracts from the database, all dates were already stored with >century). > >-- >================================================ >Ray Porter >Applications Analyst Programmer >Administrative Information Services, UNC-CH >Phone: 966-5878 >email: lrp@email.adp.unc.edu > dragon@email.unc.edu >Home Page: http://www.adp.unc.edu/~lrp/ You don't think it's a problem? Check the going rate for *experienced* mainframe COBOL contract programmers. That's a REAL measure of the problem. It will be even worse in Europe with the billing changes needed for a common currency coinciding with Y2K. Whatever you may think it's the mainframes that run the systems that support your interactions with government and the corporate world - so maybe YOU should worry as well. Andy