Old broken COBOL programs from the 70s and 80s

So I guess it was around 1998-1999 I started hearing all this stuff
about how the old COBOL programs needed to be Y2k-upgraded, because
they were only able to handle two-digit dates instead of 4-digit
dates.

All of a sudden all these old COBOL programmers got new jobs to fix
their old broken code.

I assume (perhaps incorrectly) that COBOL programs are primarily for
business applications, unlike FORTRAN for science and math, and BASIC
for basic programming.

Will people please comment on these old broken COBOL programs from the
1970s and 1980s which needed to be upgraded.

Why were companies still using such ancient code in 1999?
What kind of hardware would even still be heavily used at that time
which would support old COBOL code?

In article <b1c5d257-8c79-43a8-a8d0-e986530039ac@d19g2000prm.googlegroups.com>,
x01001x <xemail@softhome.net> wrote:
>So I guess it was around 1998-1999 I started hearing all this stuff
>about how the old COBOL programs needed to be Y2k-upgraded, because
>they were only able to handle two-digit dates instead of 4-digit
>dates.
>
>All of a sudden all these old COBOL programmers got new jobs to fix
>their old broken code.
>
>I assume (perhaps incorrectly) that COBOL programs are primarily for
>business applications, unlike FORTRAN for science and math, and BASIC
>for basic programming.

I assume that you have not done sufficient research on any of these
languages to have yielded expansion of their acronymic names.

>
>Will people please comment on these old broken COBOL programs from the
>1970s and 1980s which needed to be upgraded.

They ran. They produced output. They did so in a fashion which their
owning/using companies thought was needed to a point where their design
flaws needed to be remedied. A lot of them seem to be running still.

>
>Why were companies still using such ancient code in 1999?

I barely know why *I* do anytthing, let alone 'companies'... but the usual
motive given for a corporation's choice of action is something called
'profit'.

>What kind of hardware would even still be heavily used at that time
>which would support old COBOL code?

Hardware age need not be a factor in what code it supports; consider the
workings of a 1401 emulator.

Will you be getting paid for this article or is it merely homework?

"x01001x" <xemail@softhome.net> wrote in message
news:b1c5d257-8c79-43a8-a8d0-e986530039ac@d19g2000prm.googlegroups.com...
> So I guess it was around 1998-1999 I started hearing all this stuff
> about how the old COBOL programs needed to be Y2k-upgraded, because
> they were only able to handle two-digit dates instead of 4-digit
> dates....
> [moved]
> Will people please comment on these old broken COBOL programs from the
> 1970s and 1980s which needed to be upgraded.

For the record, it wasn't just programs written using COBOL which had to be
upgraded. Many, many, many applications written in using many, many
different languages had been written assuming "YYMMDD" would be always be
sufficent to compare two dates or add two years to one.

To answer your next question, "CC" was not routinely included in dates
because it consumed memory, both primary (chips) and secondary (disk).
Memory was a lot more expensive then.

> I assume (perhaps incorrectly) that COBOL programs are primarily for
> business applications, unlike FORTRAN for science and math, and BASIC
> for basic programming.

I'll take issue with your limitation on the BASIC language, but the COBOL
and FORTRAN generalizations are not unreasonable. After all, "COBOL" is an
acronym for COmmon Business Oriented Language., and "FORTRAN" for FORmula
TRANslation.

("BASIC" is allegedly an acronym for Beginners All-Purpose Symbolic
Instruction Code, but most historians now agree that "BASIC as an acronym"
rather than as a meaningful word unto itself came well after the fact).

Lastly on choice of language: It's not the paintbrush, it's the artist.

> Why were companies still using such ancient code in 1999?

It worked. And as DD pointed out, much of it still does.

Of course, well-written software should have a long useful life; which
should tell you something vis-a-vis my opinion on today's quality versus the
quality we put into our products then. Today there is so much
short-sightedness caused by demand for short-term profit that the investment
in really good software is simply not made. (There will be an expansion on
this topic when (if?) I get around to writing that book).

--
Michael C. Mattias
Tal Systems Inc.
Racine WI
mmattias@talsystems.com

> >I assume (perhaps incorrectly) that COBOL programs are primarily for
> >business applications, unlike FORTRAN for science and math, and BASIC
> >for basic programming.

No it is not perhaps incorrectly. You are plainly incorrect.


> Will you be getting paid for this article or is it merely homework?

This is research.

In article <bddfad21-3e50-4fd7-9e49-959342708ee9@z6g2000pre.googlegroups.com>,
x01001x <xemail@softhome.net> wrote:
>
>> >I assume (perhaps incorrectly) that COBOL programs are primarily for
>> >business applications, unlike FORTRAN for science and math, and BASIC
>> >for basic programming.
>
>No it is not perhaps incorrectly. You are plainly incorrect.

Ummmmm... you *do* realise that you've responded with 'you are plainly
incorrect' to your own words, don't you?

>> Will you be getting paid for this article or is it merely homework?
>
>This is research.

Research can be done for articles, research can be done for homework...
will you be getting paid for it or is it for school?

DD

In article <OXZfk.17988$Ri.5145@flpi146.ffdc.sbc.com>,
Michael Mattias <mmattias@talsystems.com> wrote:

[snip]

>Of course, well-written software should have a long useful life; which
>should tell you something vis-a-vis my opinion on today's quality versus the
>quality we put into our products then. Today there is so much
>short-sightedness caused by demand for short-term profit that the investment
>in really good software is simply not made.

Ahhhhhhh, for the Oldene Dayse... when quality could be put into a product
such as *ten* products do not have, today!

(you were much more patient with this person than I, Mr Mattias... but
maybe you were caught on a good day; I have little serious time for
someone who cannot find on their own that COBOL is an acronym for Common
Obstacles Beyond Our Limitations)

(oh... and you might want to take a look at
http://www.bitsavers.org/pdf/dartmouth/BASIC_Oct64.pdf , manual page 2,
complete sentence 2 (the last sentence in the paragraph))

DD

<docdwarf@panix.com> wrote in message news:g5q0hr$shi$1@reader1.panix.com...
> (oh... and you might want to take a look at
> http://www.bitsavers.org/pdf/dartmouth/BASIC_Oct64.pdf , manual page 2,

Thanks for the link. Some of those old manuals can be fun to look thur.

I see they do have the "acronym" usage in there. That contrasts which what I
recall about "Basic" vs. "BASIC" but 1964 was really a long time ago and I'm
not terribly surprised there may have been some erosion.

MCM

On Thu, 17 Jul 2008 23:26:26 -0700 (PDT), x01001x <xemail@softhome.net> wrote:

>So I guess it was around 1998-1999 I started hearing all this stuff
>about how the old COBOL programs needed to be Y2k-upgraded, because
>they were only able to handle two-digit dates instead of 4-digit
>dates.
>
>All of a sudden all these old COBOL programmers got new jobs to fix
>their old broken code.

It made entertaining press -- the image of old prgrammers with canes and shaking hands,
stumbling out of retiremenet to fix THEIR mistakes. In reality, Y2K workers came from all
ages, programming cultures and nationalities. A significant percentage were Indian.

>What kind of hardware would even still be heavily used at that time
>which would support old COBOL code?

You don't mean hardware; you mean operating system platform. The answer nearly all of them
-- mainframe, Unix and Windows.

To better understand Y2K remediation, look up 'windowing technique,' which was used for
half or more of the fixes.

In article <ga51849ep6mhrop5e9v9m1i5o4d13p5dkd@4ax.com>,
Robert <no@e.mail> wrote:
>On Thu, 17 Jul 2008 23:26:26 -0700 (PDT), x01001x <xemail@softhome.net> wrote:

[snip]

>>All of a sudden all these old COBOL programmers got new jobs to fix
>>their old broken code.
>
>It made entertaining press -- the image of old prgrammers with canes and
>shaking hands,
>stumbling out of retiremenet to fix THEIR mistakes. In reality, Y2K
>workers came from all
>ages, programming cultures and nationalities. A significant percentage
>were Indian.

Schools sprang up overnight to teach such things... 'Six weeks ago I
couldn't spell COBOL an' today I code it!'

DD

"Michael Mattias" <mmattias@talsystems.com> wrote in message
news:OXZfk.17988$Ri.5145@flpi146.ffdc.sbc.com...
> "x01001x" <xemail@softhome.net> wrote in message
> news:b1c5d257-8c79-43a8-a8d0-e986530039ac@d19g2000prm.googlegroups.com...
<snipped good responses I have no issue with>

> Of course, well-written software should have a long useful life; which
> should tell you something vis-a-vis my opinion on today's quality versus
> the quality we put into our products then. Today there is so much
> short-sightedness caused by demand for short-term profit that the
> investment in really good software is simply not made. (There will be an
> expansion on this topic when (if?) I get around to writing that book).
>

I don't think the quality of today's programming is any worse than it was in
the last century, Michael.

Today, it's a different environment. Many of the things we "took as read"
and had drilled into us are not relevant in an OO component based approach.
If a component has been tested and is known to work, why you would you
retest it every time it is reused? You are more interested in testing to
make sure it plugs into the new application OK (its interfaces...) rather
than testing every method it contains again, for example. Because things are
not necessarily done the way they were does not, of itself, mean the quality
is inferior.

Whether you use iteration and interaction to evolve a program, or use a
formal specification and the stages of the Waterfall to ensure it's quality,
it still has to perform in production. The criticism that we didn't consider
Y2K back in the 70s is a valid one, even if it isn't entirely fair.

As to your final point regarding investment, look at the millions of dollars
that were paid by industry to purchase mainframes which didn't have a
fraction of the power today's laptops have, followed by more millions
maintaining infrastructure and specialists, to obtain applications that were
just as shaky then as they are now, or just as robust then as they are now.
Software quality does not depend entirely on investment. If you have crap
programmers and pay above the market for them you will still get poor
applications. If you underinvest in hardware you will get systems that don't
perform as well as they could.

Strong, robust applications have been around for decades and so have flaky
ones. I haven't seen anything to make me believe that what is being
developed today will be any more or less robust than what was developed in
the past. In fact, the general levels of knowledge today are better than
they were in the last century so we might hope that things would actually
improve.

People are more computer literate, languages are easier than they were (once
you get over the ingrained procedural approach that most COBOL people have)
and hardware is MUCH cheaper so it doesn't require the levels of investment
that it once did, and, consequently, "computer programming" is more
widespread. (Kids are teaching themselves scripting and programming in
modern languages, simply downloading the tools for free off the Internet. It
is a major growth "hobby"...)

As long as computers need people to program them (and that may not be for as
long as many here believe) there will always be questions about quality.
Human Beings are notoriously fallible, as well as being excellent.

As you point out, it is the artist, not the paintbrush

Pete.
--
"I used to write COBOL...now I can do anything."