fyi: gerry boyd zum y2k-problem

[dietz@koma.free.de (Karl Dietz)]

hallo,

zur info. die mail stammt aus der liste ACCMAIL.

viele gruesse. karl


===beginn der weitergeleiteten nachricht=================

Date:    Sun, 21 Feb 1999 20:03:02 -0800
From:    "Gerald E. Boyd" <gboyd@netcom.com>
Subject: Re: Y2K nonsense

At 05:54 PM 2/20/1999 -5, HOWARD KARTEN wrote the following:

[...]
>phenomenon the reporter failed to notice.  In a second
>story about "how it all came to be", the reporter badly
>garbled some information he'd been given.  (Interested
>parties:  go back and read that stuff; pay particular
>attention to the nonsense the reporter writes about the
>"picture clause" in Cobol!)

Pathetic is the word to describe this. When I read the article, I
thought this was written by a high school journalism major, not a major
US magazine writer.

>The bottom line is, don't pay too much attention to the
>nonsense you hear in the media.  If you want more accurate
>information, find a programmer (preferably an older
>programmer who worked on mainframes years ago) and ask that
>person.

Ok, here is from the old-timer, especially IBM OS/360/370, MVS, MVS/XA,
MVS/ESA and OS/390 operating systems from IBM 1620's to new IBM CMOS
mainframes.

Once upon a time when computers meant mainframes and only a few thousand
people in the world worked with them, the Y2K "bug" was born. Probably
the most significant date was in 1964 when the IBM System 360 was
released. At the time computers and storage were expensive. Large
mainframe
installations were in the range $10-20 million each and computations
cost about $0.035 per 100,000. Computers and computing were expensive.
Computing charges were billed back to the originating department. There
was no such thing as a CIO or that computers should be taken for
granted or
that their costs should not be charged. Hence a program had to be
inexpensive
to run or the originating department would scream at the programmers for
costing them money.

The original OS/360 TIME macro instruction (the assembler language
macro that gets the time value from the computer system clock)
returned, in register 1, the date in packed decimal format:  00YYDDDF
where YY was the year as 2 digits, DDD was the Julian day number
(1-365) and F is the sign byte '1111' . So any date routine by any
computer program or computer language would only return a 2 digit year.
If you wanted 4 digit years, they would have to have been coded in the
computer program. The mainframe sure wasn't going to give it to you!

NOTE: The time macro since about 1980 or so with MVS, MVS/XA, MVS/ESA,
and OS/390 now returns data in the form 0CYYDDDF where C is a digit
representing the century. In the years 1900 through 1999, the macro will
return a value of C=0. In the years 2000 through 2099, the macro will
return a value of C=1.  YY is the last two digits of the year.  DDD is
the Julian day of the year (1-365) and F is a 4-bit sign character
'1111' that allows the data to be unpacked and printed.

The shortcutting of storing dates came about by most COBOL programmers
saving dates in the MMDDYY or DDMMYY instead of DDMMYYYY or MMDDYYY. We
were all saving 2 bytes per record. If you had a 10,000 employee
database and one file for each employee, you saved 20,000 bytes.
Computing was expensive. Small tightly-coded programs that ran quickly
were the rule. You had to cram as much code as possible into a program
but it had to be compact and quick running. You could not afford to run
large programs -- it was too expensive.

Mainframes had no more than 2Mb real memory. Virtual memory was unknown.
Large programs were limited to 1500K in size lest you bog down and hog
up CPU cycles.
Programs larger than 1500K had to be run in off-peak hours, not during
the business hours. We all learned good programming techniques such as
overlays so that we could squeeze a 2200K program in less than 1500K.

The first mainframe I worked on, an IBM 1620 only had 64K memory!!

The problem with PCs is everyone is now blinded to the reality of how
tightly-coded programs are in the mainframe world. Large mainframes
today still only run about 2Mb real memory and up to 64Mb virtual
memory. However, most have multiple CPUs -- 6 to 8 and verrrrrry efficient
operating systems to support multi-user and multi-programming
environments.
Tight code and quickly running programs is still the rule in the
mainframe world.
10,000 users and 350+ plus programs running simultaneously doesn't even
cause
the mainframe to slowdown.

The main Y2K problem in the business world is locating all the COBOL
source code, going through it to see if there is a date calculation, and
then revising the code for a four-character year. Programs that only
print dates or don't use them in calculations are not being updated
first but held for later updating. You then have to run the programs and
databases on a second or test sytem to simulate dates greater than 2000
and perform many performance tests. We are talking about tremendous
amounts of code throughout the world and tremendous resources being
used. You can't shutdown your day-to-day operations until one whole
database and all the associated programs that go with it are throughly
tested. You then have a production turnover at some off-peak hour, 2-4AM
usually, and roll out the new system.

Companies with many systems and programs have millions of lines of code
and thousands of programs to go through. This is not a simple task.
Where I worked we had gone through about 85% of our code by July 1998.
Full-scale testing will be done for the whole year of 1999 running
duplicate systems. It was cheaper for us to buy another small mainframe
computer ($4 million) and additional DASD to duplicate and run parallel
systems than try to disrupt day-to-day operations involving a customer
database of 1.3 million.

Our biggest problem involved old 360-assembler language programs that
were coded and linked to our COBOL code. Many of the original sources
have been lost and some of the routines were coded in the 60s and 70s.
Also, most newer programmers don't even know 360-assembler so some of us
"old" dogs got the reward of re-writing the code. You take a dump of the
code and go back and try to re-create the 360-assembler language. This
then will be re-written in "new" assembler language. Talk about
difficult. I'm glad I retired.

I'll say it again, Y2K is a programming problem. Mainframes have not
had a date problem since 1980 because their date routines are DDMMYYYY.
However,
the millions of line of COBOL code running do have a problem because so
many of us early programmers only carried the date as DDMMYY. We did
this because we had to have tightly-coded programs running in mimimal
memory quickly.

Heck, my PC today has more capability than the first $12 million IBM
360 I worked on. The big exception is that the Windoze 98 operating
system sucks and no way can be considered a multi-user
multi-programming OS. It's a pathetic excuse for an OS. And don't
bother mentioning Windoze NT which is another loser. The only OSs for
PCs that even comes close is Linux and OS/2.




--
Gerry Boyd -- gboyd@netcom.com


## CrossPoint v3.11 ##