Speaking of YAHOO news, found this dated Feb. 10. Any comments from my fellow programmers out there? <:)= Digits Corp Reveals an Automated Solution...


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

Answers

I am a 51 year-old programmer/analyst and am currently working on Y2K fixes in the aerospace industry. I have been coding for 31 years on all types of machinery, starting with IBM 1401 autocoder, burroughs assembler, and Univac 1004 plug-boards with 4K of main memory.

I have been lurking in this forum for several months, but have not really felt qualified to contribute to many of the technical questions presented here, or have found that someone else had already provided a satisfactory answer.

Regarding this question: The code that I am working on right now was originally written in IBM 1401 autocoder in the early 60's. When ANSI 74 Cobol became the industry standard, the company passed its code through a Cobol converter. In the ensuing 25 years since this conversion, 8 different sets of programmers have revised/modified these sytems, all using "spahgetti coding techniques", that is, all branching is done with GOTO label, which is a nightmare to follow even with good documentation. There is hardly any reliable documentation in this system, and we are talking about code that is listed as "critical" for a Fortune 50 company.

The company decided three years ago to use windowing as a code fix, as opposed to date expansion (which, in my opinion, was the wrong way to go). They also decided to put two people on this particular system - me and 30 year-old guy who knows his stuff.

After one year of intense effort, we are in the process of testing using aged data, and passing that data through several cycles of identified "critical dates" in 1999, 2000 and 2001. All this is an extremely tedious and exacting process.

Now, somebody pops aou of the woodwork and says that they can duplicate our effort with NO program modifications required???

Excuse me, but if that could have done, this company would have been all over it. In addition to that, form what I know about systems and application programming, this "super program" would by nature be extremely haphazard in identifying date fields.

No, to be completely accurate (and Y2K fixes require that you be very precise and all-inclusive) you have no option but to fix the code.

I don't have all the answers, but these kinds of announcements make me very nervous. Does this guy know Koskinem personally?

To me, this sounds like a guy that we should help - let's start by helping him get the contract to fix the IRS system.

Mike.

-- Michael H. Cumbie (Mikecumbie@aol.com), February 13, 1999.

Hi, Mike. I'm a 47 year old vet, got my first job as 2nd shift 360/30 operator while still in hi-school. We had 1401 emulator on that machine, and a few autocoder apps, but never got involved. I agree, windowing isn't the way to go. Doesn't work in many cases, and IMHO will cause some wacky problems. My feelings also about this product, just more smoke and mirrors. Too many "games" can be played with dates, and I've seen many. Thanks for your comment, and keep iy up! We need all the help we can get here!!!

Come on folks, I know there's a bunch of pros out there. What do you think about this "solution"? <:)=

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

I can imagine a solution like this for a given mainframe (say an IBM 3083 to take a FAA example), if the solution is essentially a modification to the operating system. It wouldn't be perfect, but thats the only way not to touch the App source code. However, I can't imagine how you would apply this across multiple operating systems & versions/multiple systems. I'll bet this guy has something that sortof works for ONE system.

-- RD. ->H (drherr@erols.com), February 14, 1999.

That "Digits Corp" story about a product that "automatically locates a program's potential date problems at the machine code level" may be a real claim by a real company, but it looks to me more like a complete hoax.

So called "machine code", whether the phrase refers to machine language, or assembler language, could not distinguish a date from any other number! The idea that it could is farce one of the story.

Farce two is that every execution of arithmetic instructions, as well as compare instructions, would need to be "trapped" to let the date checker check them, and that would increase the CPU overhead of applications by amounts that would, in most cases, greatly exceed the computer's capacity.

I would be delighted to be wrong about this, but ......

Jerry

-- Jerry B (skeptic76@erols.com), February 14, 1999.

Thanks for the input folks. Even if this is some sort of hardware/OS thing, there's too many things an application can do with a date, once it gets it from the OS. I remember one large system I worked on for about 7 years total, 500+ programs, LOADED with the following date logic:

Make YYMMDD format, so it sorts nice

Convert each part to binary

"pack" the whole result in 2 bytes

Wonder how this quick fix would handle this... <:)=

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

Speaking of credibility, this "Dr." couldn't have "invented the Seawolf reactor control" program - because there wasn't one. The earlier reactor's were strictly manual controlled by the reactor operator. Rickover never trusted any program or controller, even the simple steam generator water level control valves had manual backups, and were not used in "automatic" mode. reactor trips and alarms were checked weekly, but were not "programs" at all - just simple electro-mechanical circuits and relays.

If he was speaking about the first (liquid metal) Seawolf reactor, the "Doctor" could have written code to simulate the reactor performance, but that was system was designed and built in mid-fifties to early sixties (and there were no shipboard computers then! None, not even air intercept computers worked reliably on huge aircraft carrier and cruiser installations!). The Seawolf liquid metal reactor was unreliable and unrepairable, and was scrapped in favor of simple light-water technology.

(I was nuclear repair superintendent and decommissioning nuclear planning officer for Seawolf in mid-80's. You will need to determine whether my description, or the unknown doctor's credidentials are more reliable, then make up your mind whether to trust his program. Or at least trust your company to the writer who is describing this program.)

-- Robert A. Cook, P.E. (Kennesaw, GA) (cook.r@csaatl.com), February 14, 1999.

Thanks Robert. Looks good on his resume though! <:)=

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

Just thought of another problem with date processing that has reared it's ugly head, and this one may cause more errors and consternation than windowing....

I've discovered arithmetic expressions that subtract one date from another and take a process control branch depending on the answer.

Since most dates are stored in MM/DD/YY format, arithmetic expressions that subtract one date from another have either convert the gregorian date to a julian date (whoel number), or reverse the gregorian date to CC/YY/MM/DD in order to arrive at the correct answer.

Try subtracting 02141999 from 02142000 and you'll see what I mean (this expression does not return the correct number of days that elapsed).

My concern is that this used to work in the 20th century, but the same routines will NOT work when computing elapsed days, whether or not you use windowing or date expansion.

If my fellow pros can confirm this, it would make me feel better.

Maybe this is something you young'uns have run across when dealing with legacy code?

Thanks to all for the other great comments, and thank you, sysman for bringing it up.

Mike.

-- Michael H. Cumbie (Mikecumbie@aol.com), February 14, 1999.

Thanks for your input Mike. A few points though. In your example, wouldn't the result be the same using 1998 and 1999? Also, the mainframe OS does offer a day of year counter from 001 to 365, or 366. Still a good point. Lots to think about with this issue, and at least you're thinking! <:)=

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

Sysman,

I Apologize for the previous post that contains the flawed logic problem. Staying up too late reading these threads and not paying enough attention to what I say. I know it doesn't help to post info that is not credible - I have already seen enough of that here and other places.

That is not the first mistake I have made and it won't be the last.

Mike

-- Michael H. Cumbie (Mikecumbie@aol.com), February 16, 1999.

Yeah Mike, but I've found that the more mistakes you make, the faster you can make new ones. Hmmm. That's doesn't sound right. What about: the more you practice, the faster you can make mistakes? The more you make mistakes, the easier the mistakes are to make? ....the more efficient at making mistakes you are? ....the more productive your mistakes are?

Something's not right here.....

-- Robert A. Cook, P.E. (Kennesaw, GA) (cook.r@csaatl.com), February 16, 1999.

No problem Mike. Being a programmer, I see flawed logic every day! Like I said, at least you're THINKING about the problem. <:)=

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