Despite two decades of serious IT experience (I apologize, world), I have not been involved in Y2K remediation. Hey, isn't the Internet where it's at? de Jager says we have Y2K licked anyway, right?

I'm wondering whether the anonymously posting GI geeks on our NG could give us a discreet but detailed heads-up on remediation efforts they're involved in. OK, DGIs too (really).

Here are the rules:

It has to be projects you've actually worked on.

You've got to give details (platforms, when begun, budgets if known, problems encountered, use of testing plans and test results, do you consider the systems currently Y2K compliant or ready, has your company claimed them to be such ... and the like.

Embedded systems as well as software welcome.

Also, please don't extrapolate to other orgs.

Sounds like I'm requesting a thesis, but heck, two sentences will do if you're busy. You know, like, remediating Y2K stuff.

I know we have threads which include some of this as we go, but I would personally and sincerely appreciate posts that are current as of TODAY. There won't be any statistical or evidential conclusions to be drawn since I assume almost all reports will be anonymous, but we can use our nose.

-- BigDog (BigDog@duffer.com), February 11, 1999

Answers

Personally remediated old Oracle PRO*C application in a couple of weeks. Database and app currently running with 4-digit years. Tested data end-to-end, but CPU it is on (VAX) was not rolled over . Remediation was done only due to lengthy time required for GUI replacement (risk reduction fall-back plan). Our data providers already submit 4-digit years.

Writing a new GUI replacement (using modern Y2K compliant Oracle tools) for the old PRO*C app. Should be done this summer. Already partially in use.

Have seen evidence of Y2K remediation elsewhere in our Oracle shop (personnaly tested, informally), but the database itself is still running with 2-digit years. We have a new server (configured with 4- digit years), but its deployment date is not set. Already more than a year late...

-- Anonymous99 (Anonymous99@anonymous.com), February 11, 1999.

I just got back from a technical support visit yesterday. I was integrating a new system that had been pushed through development without much testing. When I got there I found out that the y2k exercise that was supposed to happen this month was cancelled because not enough of the players were able to participate. It is a good thing, as the systems I was installing are very buggy and definitely not ready for prime time. The situation is too complex to elaborate on without giving out sensitive information, but suffice to say my pessimism is not waning.

-- a (a@a.a), February 11, 1999.

BigDog: I tried doing this on a similar thread a while ago and had a grand total of one answer, which was not even very forthcoming. So congratulations to you for getting what you have.

Anonymous99: Since you are using the ORACLE RDBMS you may find their white paper and Y2K pages of interest, assuming you have not already seen this stuff. The url is http://www.oracle.com/year2000/

Two things that I found good to know were:

The ORACLE pre-compiler products are supposedly compliant since there are no pre-defined date data manipulation routines - the developer's 3GL code that calls the server-side PL/SQL engine, if not done properly, can cause problems, so compliance is really dependant on the developer (as usual).

Also, since you mentioned traditional ORACLE tools, be aware that in SQL*PLUS, the use of DATE variables created using the ACCEPT command are stored as char strings, so once again it is up to the developer to ensure that the format is something like DD-MON-YYYY.

-- Rob Michaels (sonofdust@net.com), February 11, 1999.

I hate thinking about or telling this story. It turned me from 30 to 90 years old in about 6 months.

I got a friend to get me a job in a fortune 100 joint because it was far closer to my house. I thought I was hired as a systems analyst, but as it turns out, I was actually hired because of my experience with a fairly obscure programming toolset (Cognos' PowerHouse suite).

The task: take all the enterprise data (EVERYTHING except payroll) off an MRP solution running on an HP 3000 and push it into another (Y2KOK) ERP/MRP solution running on an AS/400 utilizing DB2.

Timeframe: 9 months. Nine months to learn both applications to the designers/programmer's/DBA's level, then write ~60 programs to extract the data and test the loads, get balances in sync. Got source code for the new app? Nope. Didn't pay for it. Can I call some people? Nope. They know less than you, and it's too expensive, anyway. When are we going to hire an RPG programmer to slam the data into DB2? As soon as we find one who'll settle for working for peanuts. (By the way, I'm the ONLY person working on this: Analyst, programmer and tester - feel my pain yet?) Amount of data? About 80 gig. Revenue? About 100 million/year.

Finally hire RPG programmer, comes from insurance field, doesn't know the difference between a sales order and a purchase order. No concept of ERP/MRP, that is. Very nice, and sharp, but no help to me.

Work all day Saturdays extracting and loading files. 6-year old daughter pretty unhappy about this. Oh, did I mention that the legacy app allowed 18(X) for part #, new one only 15(X), and that purchase order # was 18(X) on legacy, 6 numeric on new system? Can you hear me scream? Nobody can hear you scream.....

Amazingly, I got nearly all of the programming done before I escaped the company. The A/R, A/P, GL, inventory, sales orders, etc. figures balanced pretty well...(oh - on the legacy system, moving-target balances [A/R, A/P, inventory, etc] were a stored value, which is normal, and godly- rather than calculated via FIFO on the new system. What a nightmare to get the transactions to fall right and balances accurately calc'ed......

That was 5 months ago, and I don't know how well the final conversion went. The only reason I write this is I'll never get over the shock of the way my manager viewed the conversion - like it was as simple as loading a spreadsheet from Excel into Access or something.

I could go on but it's too painful. The Horror, the horror. Mind you, I'd never heard of either application: my qualification was knowing a programming language. And ERPs are NOT homogenous in their behavior, believe me.

Now I'm doing insurance.

(ID hint: I can't resist feeding/analyzing trolls.)

-- guess (gone@blank.allofasudden), February 11, 1999.

Hi BigDog. I'll repost this from another thread:

Hi Mike, I think the collateral damage is going to be far and wide. We're in the "middle" af a large Y2K convert. About 300 COBOL and ASSEMBLY programs on mainframe, also only about 25 PC/LAN based programs, but large and complex. Doing ALL from scratch, using Web-based tech. This system used dates so often, for all kinds of computations, we figured it would be easier to sit down, look at the data and resulting products, and just re-do it. We started this late 1996. A few interesting results. We figure it will take another 2 years to give the customer EVERYTHING they have in the existing system. We will be ready for their production, summer 2000, but their products; books, CD-ROMs, and Web site will be missing some very interesting information that was in the 1999 info. Also, since this is the majority of work for our mainframe, We'll also be moving systems that don't have a Y2K problem to the "new technology", so we can dump the old hardware. <:)=

PS - Congrats on your NERC report a few days ago. Did you see the NERC report on Gary North's site (maybe from euy2k) about 44% average done and tested?

-- Sysman (y2kboard@yahoo.com), February 11, 1999.