7 Aug
2008
7 Aug
'08
9:02 a.m.
From http://www.sacbee.com/111/story/1132588.html
concerning the
California budget crisis:
The state payroll system is based on the COBOL, or Common Business
Oriented Language, programming language - a code first introduced in
1959 and popularized in the 1960s and 1970s.
"COBOL programmers are hard to come by these days," said Fred Forrer,
the Sacramento-based CEO of MGT of America, a public-sector
consulting firm. "It's certainly not a language that is taught.
Oftentimes, you have to rely on retired annuitants to come back and
help maintain the system until you're able to find a replacement."
What does California's DMV use?
Cheers,
Chuck
7 Aug
7 Aug
11:14 a.m.
From
http://www.sacbee.com/111/story/1132588.html concerning the
California budget
crisis:
The state payroll system is based on the COBOL, or Common Business
Oriented Language, programming language - a code first introduced in
1959 and popularized in the 1960s and 1970s.
"COBOL programmers are hard to come by these days," said Fred Forrer,
the Sacramento-based CEO of MGT of America, a public-sector
consulting firm. "It's certainly not a language that is taught.
Oftentimes, you have to rely on retired annuitants to come back and
help maintain the system until you're able to find a replacement."
11:19 a.m.
Chuck Guzis wrote:
"COBOL programmers are hard to come by these
days," said Fred Forrer,
the Sacramento-based CEO of MGT of America, a public-sector
consulting firm. "It's certainly not a language that is taught.
Oftentimes, you have to rely on retired annuitants to come back and
help maintain the system until you're able to find a replacement."
It's not at all hard to find COBOL programmers, and they are NOT all
retired. Offer a decent salary, and you'll get them. What the state is
specifically trying to do, though is to cut everyone's salaries, so how
likely is it that they'll offer a good salary to a COBOL programmer.
The real story is that it's a bunch of political posturing.
1:47 p.m.
On 7 Aug 2008 at 11:19, Eric Smith wrote:
It's not at all hard to find COBOL programmers,
and they are NOT all
retired. Offer a decent salary, and you'll get them. What the state is
specifically trying to do, though is to cut everyone's salaries, so how
likely is it that they'll offer a good salary to a COBOL programmer.
The real story is that it's a bunch of political posturing.
Oh, you cynic! I'll come to the defense of the bean-counters by
saying that knowing how to write a program in COBOL and being fluent
in COBOL are very different things, just as learning to read Russian
is one thing and writing like Pushkin is quite another.
COBOL is a huge language for its time. I recall that the early
releases of COBOL for S/360 were not complete implementations. I
have an IBM document somewhere in my files that states that indexed-
sequential file access wasn't implemented in the compiler. The
compile would accept the statements and check them for syntax, but no
code was generated. Instead, one had to call a bunch of assembly-
language routines (ENTER LINKAGE) to the work.
Add to the problems of California's COBOL is the likelihood that most
of this code is probably pretty crufty by now, with all manner of
ugly modifications shoehorned in. I also suspect also that the
application source code is quite large.
Finding enough fluent COBOL programmers who would be willing to
tackle the job might well be more than just a lame excuse for doing
nothing. ISTR that California got burned a couple of times trying to
convert its antiquated DMV applications to something a bit more
modern.
Does anyone know if California's running this COBOL code under
emulation? I remember a customer who was seeking to get rid of his
7080's and run his COBOL on something more modern. The problem was
that it wasn't just COBOL code at that point--there were plenty of
binary patches in the code, along with large stretches of uncommented
7080 autocoder. The customer ended up buying a S/370 configuration
and running it in 7080 emulation mode. Unraveling and rewriting the
code looked to be too much of a black hole.
Cheers,
Chuck
6:40 p.m.
Eric Smith wrote:
Chuck Guzis wrote:
Just prior to y2k they were paying large bonuses to get C programmers to
learn COBOL so the 100s of millions of lines of code could be checked and
patched. Large companies were desperate. I'm sure a lot of these folks
were canned after 2000 when all the Y2K nonsense finally ended but I'm sure
they aren't all retired. And they should still be around if someone
offered them enough money. I haven't written any code since 2001, because
any contract would have required me to travel which I couldn't do any more.
But it was great while it lasted.
Mark (Who is retired but still too busy to get everything done.)
"COBOL programmers are hard to come by these
days," said Fred Forrer,
the Sacramento-based CEO of MGT of America, a public-sector consulting
firm. "It's certainly not a language that is taught. Oftentimes, you
have to rely on retired annuitants to come back and help maintain the
system until you're able to find a replacement."
It's not at all hard to find COBOL programmers, and they are NOT all
retired. Offer a decent salary, and you'll get them. What the state is
specifically trying to do, though is to cut everyone's salaries, so how
likely is it that they'll offer a good salary to a COBOL programmer.
The real story is that it's a bunch of political posturing.
8 Aug
8 Aug
7:15 p.m.
madodel wrote:
Eric Smith wrote:
My little brother was one of those y2k guys. He made a fair pocket
full of cash fixing code, from about '97 to 2002.
He also says, at 49 years old, that he'll dig ditches at minimum wage
before he goes back to COBOL.
Just saying.
Doc
Chuck Guzis wrote:
Just prior to y2k they were paying large bonuses to get C programmers to
learn COBOL so the 100s of millions of lines of code could be checked
and patched. Large companies were desperate. I'm sure a lot of these
folks were canned after 2000 when all the Y2K nonsense finally ended but
I'm sure they aren't all retired. And they should still be around if
someone offered them enough money. I haven't written any code since
2001, because any contract would have required me to travel which I
couldn't do any more. But it was great while it lasted.
10:31 p.m.
On 8 Aug 2008 at 21:15, Doc Shipley wrote:
He also says, at 49 years old, that he'll dig
ditches at minimum wage
before he goes back to COBOL.
Hmmm, goes back to what Eric said about Ada. COBOL imposes its own
rigor. And remembering all of the variants on the some of the verbs
(e.g. INSPECT) is enough to give you a headache. But other aspects
are pretty cool.
I could understand a C programmer having issues with COBOL.
Cheers,
Chuck
11:11 p.m.
2008/8/9 Chuck Guzis <cclist at sydex.com>:
On 8 Aug 2008 at 21:15, Doc Shipley wrote:
Meh. You just have to see the sport in making it do what it wasn't designed to.
.tsooJ
He also says, at 49 years old, that he'll
dig ditches at minimum wage
before he goes back to COBOL.
Hmmm, goes back to what Eric said about Ada. COBOL imposes its own
rigor. And remembering all of the variants on the some of the verbs
(e.g. INSPECT) is enough to give you a headache. But other aspects
are pretty cool.
I could understand a C programmer having issues with COBOL. 
9 Aug
9 Aug
8:55 a.m.
Chuck Guzis wrote:
On 8 Aug 2008 at 21:15, Doc Shipley wrote:
I actually don't mind COBOL that much (or ADA), but I have to admit much
of COBOL's imposed rigor is artificial.
Peace... Sridhar
He also says, at 49 years old, that he'll
dig ditches at minimum wage
before he goes back to COBOL.
Hmmm, goes back to what Eric said about Ada. COBOL imposes its own
rigor. And remembering all of the variants on the some of the verbs
(e.g. INSPECT) is enough to give you a headache. But other aspects
are pretty cool.
I could understand a C programmer having issues with COBOL.
10:29 a.m.
On 9 Aug 2008 at 11:55, Sridhar Ayengar wrote:
I actually don't mind COBOL that much (or ADA),
but I have to admit much
of COBOL's imposed rigor is artificial.
True. On the other hand, how long did it take C to get the
equivalent of MOVE CORRESPONDING or open subroutines? Bad COBOL is
just as awful as bad C as bad assembly as bad Ada...
Aside from PL/I, there aren't many other languages that allow for
regulating the results of computation by means of PICTURE clauses, or
is pretty much explicitly decimal. A very few out there allow for
specification of rounded vs. truncated arithmetic on a statement by
statement basis.
But yeah, COBOL can be a royal pain to write well.
Cheers,
Chuck
9:58 a.m.
Chuck Guzis wrote:
On 8 Aug 2008 at 21:15, Doc Shipley wrote:
Oh, he's not/wasn't a C programmer.
He's just like me, a mechanic fallen in with a bad crowd. :)
Doc
He also says, at 49 years old, that he'll
dig ditches at minimum wage
before he goes back to COBOL.
Hmmm, goes back to what Eric said about Ada. COBOL imposes its own
rigor. And remembering all of the variants on the some of the verbs
(e.g. INSPECT) is enough to give you a headache. But other aspects
are pretty cool.
I could understand a C programmer having issues with COBOL. 
11 Aug
11 Aug
8:29 a.m.
madodel wrote:
Just prior to y2k they were paying large bonuses to get C programmers
to learn COBOL so the 100s of millions of lines of code could be
checked and patched. Large companies were desperate. I'm sure a lot
of these folks were canned after 2000 when all the Y2K nonsense
finally ended but I'm sure they aren't all retired.
Sounds like what they really needed were rewrites, or perhaps
(automated) language translators; say from Cobol to Java. (I say Java
because the mindset of most corps out there is to hire the junior guys
since they see programmers as cogs and would want a cheap source of
labor, and since Java seems to be the Visual Basic of today, not so much
in language complexity but rather in terms of the pool of available kids
fresh out of college - as sad as that concept is... sigh...)
Of course there'd be a lot of manual labor involved in bringing things
up to standards as computer translated code is usually fuglier than the
original.
9:01 a.m.
On 11 Aug 2008 at 11:29, Ray Arachelian wrote:
Of course there'd be a lot of manual labor
involved in bringing things
up to standards as computer translated code is usually fuglier than the
original.
In particular, COBOL translated to Java would be very very fugly
indeed--the languages are miles apart in terms of language-specific
features (e.g. Does Java have subroutines that can be both open (i.e.
fall through) and closed (i.e. as the object of a PERFORM--or worse,
as part of a PERFORM...THRU)?). You'd have an easier time
translating RPG to Java. I shudder to think of what trying to work
on the result would look like--or even guaranteeing that it's
computationaly equivalent.
How about automated translation of GPSS/360 to SNOBOL? Or PL/I to
Prolog?
Has anyone had good results with automated translation of any
programming language to any very different one? To me, the results
of automated translation mostly look like Babelfish output and
require one to spend as much time cleaning up the output as they
would have spent rewriting it from scratch. Both require a detailed
understanding of what the code does.
Cheers,
Chuck
12:03 p.m.
Ray Arachelian wrote:
Sounds like what they really needed were rewrites,
Contrary to anything you may have seen in the press, it is FAR less
expensive to simply hire experienced COBOL programmers to maintain it
than to rewrite it. There are plenty of COBOL programmers out there;
they definitely have NOT all retired. But you're going to have to pay
good salaries, which is what the state is trying to avoid.
or perhaps (automated) language translators; say from
Cobol to Java.
If you do an automated translation, the result will just be COBOL that's
written in Java. You won't be able to find *anyone* that's good at
maintaining that mess.
Eric
3:26 p.m.
or perhaps
(automated) language translators; say from Cobol to Java.
If you do an automated translation, the result will just be COBOL that's
written in Java. You won't be able to find *anyone* that's good at
maintaining that mess.
Eric
12 Aug
12 Aug
8:15 a.m.
Steve Robertson wrote:
I have a friend that is working for a company Web-enabling a COBOL
application for the DOD. This is a mission critical application that
consists of thousands of data input screens and literally millions of
lines of code. It was determined that the only semi-reasonable method of
porting the application would be to use an automated tool.
The tool interprets the COBOL and spits out the mostly equivalent JAVA
code. I am told most of the code will not compile / run without serious
modification. So a developer, conversant in both COBOL and JAVA, has to
modify the already FUBAR code. The result is a multimillion dollar
hodge-podge of code that is absolutely unmaintainable!
My friend had been working on this project for the last 7 years and
expects to retire long before it is complete.
I would've just written web primitives for COBOL, if they don't already
exist.
Peace... Sridhar
or perhaps (automated) language translators; say from
Cobol to Java.
If you do an automated translation, the result will just be COBOL that's
written in Java. You won't be able to find *anyone* that's good at
maintaining that mess.
Eric 
8:44 a.m.
>>>> "Sridhar" == Sridhar Ayengar
<ploopster at gmail.com> writes:
Sridhar> Steve Robertson wrote:
> I have a friend that is working for a company
Web-enabling a
> COBOL application for the DOD. This is a mission critical
> application that consists of thousands of data input screens and
> literally millions of lines of code. It was determined that the
> only semi-reasonable method of porting the application would be to
> use an automated tool.
> ...
Sridhar> I would've just written web primitives for COBOL, if they
Sridhar> don't already exist.
That would be the right answer. But if the customer insists on doing
it the wrong way, and that customer has an infinite budget because
it's our taxes paying for it, the result is programmers doing
wrongheaded work for several generations.
paul
8:58 a.m.
On 12 Aug 2008 at 11:15, Sridhar Ayengar wrote:
I would've just written web primitives for COBOL,
if they don't already
exist.
If the original application were written for a terminal, I would
seriously consider running it as-is inside of an environment that
provided a web-based terminal interface. Sometimes, tweaking the
most innocuous bit of old code can lead to catastrophic results
later.
Often, what clouds the picture on projects like thse is the
tantalizing promise of adding new features to old code--and one of
the "features" inevitably turns out to be a can of cockroaches.
Cheers,
Chuck
5976
days inactive
5981
days old
17 comments
10 participants
participants (10)
-
cclist＠sydex.com -
doc＠mdrconsult.com -
eric＠brouhaha.com -
jvdg＠sparcpark.net -
madodel＠ptdprolog.net -
nico＠farumdata.dk -
Paul_Koning＠Dell.com -
ploopster＠gmail.com -
ray＠arachelian.com -
steerex＠ccvn.com