Is there a COBOL Doctor is the house?

[TRexx]

Because I admitted to taking a COBOL class in college, I am now my group's de facto COBOL expert. Most of it is pretty simple but I ran into a weird problem today.

Many of our COBOL programs were compiled using the old OS/VS COBOL compiler, (Not sure how old it is. The date displayed is  March 17 1911.)  The rule is that when we touch a program we have to recompile it using COBOL-II.  Most things are upward compatible but when the compiler sees this:

IF I IS GREATER THEN 5
   MOVE 'YES' TO SOME-FIELD
   GO SOME-LABEL.

it generates this message: "A literal or an expression was expected following a relational operator, but "THEN" was found.  The "IF"  statement was discarded."    

That makes sense.  It seems clear to me that the author meant "IF I IS GREATER THAN 5".  But why doesn't the older compiler complain about this?  How is that statement being executed?     

 

[Carrie Cobol]

As much as I prefer to distance myself from any knowledge of Cobol, I'll take a shot at this.  (Because if I don't, I'll never demonstrate any IT knowledge!)

The older compiler probably assumed the programmer meant this, so executed it thusly:

IF I IS GREATER THEN
   5
   MOVE 'YES' TO SOME-FIELD
   GO SOME-LABEL.

I assume it thought "I GREATER THAN" ... zero? Even modern versions of Cobol allow you to do things like "IF X THEN" but typically that only works if you define X to be a boolean or enumerated value with something like this:

01  X-FLAG   PIC X.
    88   X     VALUE "Y".
    88   Y     VALUE "N".

I'm not sure what it thought of "5" being a statement all by itself.  Maybe it quietly ignored it.

[Richardk]

I'll second that assumption as 'possible' though I'm not a COBOL person.

It seems that it would be easy enough to test if you have both compilers.

[The Gorn]

HA HA HA HA HA HA HA HA

Lame. Assignment operator forbidden!!!!!!!!

 

I'm not making fun of anyone here who knows COBOL.

I dabbled in it in a "Computer Science Explorers" Boy Scouts branch in high school. It was sponsored by NCR and sessions were held at their Sugar Camp training facility in Dayton (now a sea of upscale condos. ) Like FORTRAN it's pukey stuff.

[TRexx]

I'll second that assumption as 'possible' though I'm not a COBOL person.

It seems that it would be easy enough to test if you have both compilers.

[rant]
The problem is that this particular program is buried inside a job stream that no one understands, and no one knows how to run, especially on our alleged "test" system.  That includes the guy who has been running these jobs every day for 20 years.

So my plan was to just write a little program that I can test.  Writing it was no problem, but I can't use our whiz-bang EZ compiler tool (written in 1988) until the program is registered in our alleged source control system, which no one understands.  The person who was in charge of it was rightsized last year and if there ever was any documentation, she burned it on her way out.           

After another treasure hunt I found the compiler and ran my test.  It assumes the programmer meant

"IF I IS GREATER THAN 5".   

BTW the "new" COBOL-II compiler we are using is vintage 1992 and no longer supported. 
[/rant]

[Origisaurus]

IF I IS GREATER THEN 5
   MOVE 'YES' TO SOME-FIELD
   GO SOME-LABEL.

it generates this message: "A literal or an expression was expected following a relational operator, but "THEN" was found.  The "IF"  statement was discarded."    

Umm, yeah.  If an earlier compiler accepted this, it generated some code, and that's what the app has been doing.  It doesn't matter what you think it's supposed to do, it's about what it actually does (hopefully consistently).

This has nothing to do with COBOLski per se.

As we read many times in IBM documentation of the 1960's, "in other cases, results will be unpredictable".

In many cases, it's best to ask what this module is expected to do and then code it from scratch.

===

BTW, I consider myself a master of COBOL, and one of the very few COBOL coders who have actually created COBOL programs from scratch, not by cloning some existing code.  I may be obsolete, but I'm  still damned good.

[TRexx]

In many cases, it's best to ask what this module is expected to do and then code it from scratch.

[rant]
If only I could.  The biggest problem I run into is that there are major pieces of our app that no one knows what they do or what they are supposed to do.  It is highly likely that this particular program serves no purpose.   But I work with a handful of incredibly overpaid individuals (the guy who runs* our nightly production makes about $115,000/year plus bonus). There is no way they will admit to management that we might be able to simplify things and turn 7 hours of daily processing into 2 or 3.
[/rant]

BTW, I consider myself a master of COBOL, and one of the very few COBOL coders who have actually created COBOL programs from scratch, not by cloning some existing code.  I may be obsolete, but I'm  still damned good.

I'm certainly no COBOL expert but I can recognize crap code when I see it.  This stuff would make you sick. The guy who wrote much of it didn't believe in comments. If he had to modify an existing program the first thing he did was delete any existing comments.  He also didn't believe in copy books.  My current task is to update 15 programs he wrote that all read the same file but he coded the record layouts differently in each one. I suggested that since we have to open up each program anyway, now would be a good time to have a common record layout.  Of course that was rejected. Our manager is afraid that something might break and since no one knows what the programs do, fixing a problem is virtually impossible.  Just identifying the programs than have to be changed was a two week project.   

I also found a real bug in the compiler today -- one of those error messages that says "you shouldn't get this. Please report it to IBM Support".  But I can't do that because we are running the 1992 version of COBOL-II.
<sigh>

Do Forever
  Say "I get paid by the hour"
End

[Origisaurus]

I'm certainly no COBOL expert but I can recognize crap code when I see it. 

Yes, the kaka just jumps out at you, regardless of the syntax.

What you have here is not a COBOL problem, but a jack-wagon problem.  Sorry about that. 

Do Forever
  Say "I get paid by the hour"
End

"Howdy, Ms. bank teller, here's my paycheck".

[I D Shukhov]

TRexx, what industry is this?  How can anything get done this way?

[Richardk]

Well it had to be one or the other and I have to agree with Carrie when she wondered about "5" being a statement. I guess that should have been a clue that it was "THAN" and not "THEN" but the other assumption seemed just as good.

I don't know TRexx, I didn't think COBOL was that hard to learn so I'm perplexed why the team can't figure it out.

Your nightly production guys have a good thing going. How can they be paid so much since I'm assuming that the programmers are not easily topping that salary? And certainly 'inefficiency' keeps them employed.

[TRexx]

TRexx, what industry is this? 

Financial services.  Some very serious investments are made based on the numbers we crunch.

How can anything get done this way?

Remember, this is the same industry that wrote $500,000 mortgages for folks making minimum wage.  The prevailing attitude seems to be "Don't think about any problem until it smacks you right between the eyes.  And then only do the bare minimum to stop the immediate pain."

[Carrie Cobol]

The jack-wagon issue is actually very common in all industries that have critical systems.  Once the system is heavily depended on, they can't afford to take chances it might break.  They consciously allow the development teams to only touch the bare minimum needed to fix bugs in the short term.  They can't afford to ever refactor it.  The longer this goes on, the more brittle the system gets, the more they're afraid to touch it.  Add in corporate RIF's and other idiocy, and... well, you know. 

This is partly why I finally left the dispatching job.  I'd had a bellyful of working on and supporting 30 year old software.  Wait, it would be more than 40 years old now.  Almost as old as I am!  The last project really got to me:  a 40 year old system written in Macro (VMS assembly), brittle as the day is long, barely supported by non-technical staff who think the thing is a spiteful godlike black box, and we added a very fancy new enhancement to it:  automatic vehicle location.  (Which I mentioned here before.  Sweet feature if put on new software.  Trying to tack it onto a super-brittle neolithic system?  Scares me spitless.)

[expat]

...
IF I IS GREATER THEN 5
   MOVE 'YES' TO SOME-FIELD
   GO SOME-LABEL.

it generates this message: "A literal or an expression was expected following a relational operator, but "THEN" was found.  The "IF"  statement was discarded."    

That makes sense.  It seems clear to me that the author meant "IF I IS GREATER THAN 5".  But why doesn't the older compiler complain about this?  How is that statement being executed?   

I seem to recall that for old compilers the real statement was
IF I GREATER 5
(etc)
and you could actually write that and it would compile. The "IS" and "THAN" are just padding allowed (but not required) so that humans can read it. So some compilers tolerantly allowed all kinds of human errors in there, as long as the real compiler keywords were present.

[Walter Mitty]

I am one of many programmers who undervalued COBOL during my career. 

At the peak of my game, features like recursion, separately compiled modules,  etc. etc. seemed to be so basic (no pun intended) to me that any language that lacked them seemed hopelessly crippled.

I wasn't until much later that I began to appreciate the genius behind COBOL, and the reason why it gained so many loyal users.  I could say something like that about FORTRAN, BASIC,  C,  SQL, or any number of languages.  In fact, it's useful to take a long list of languages, including some you aren't proficient in,  and ask the same set of questions, including but not limited to the following:

What innovation did it put forth?  Why did it catch on?  And, on the other hand,  why didn't it become the universal language?

[Carrie Cobol]

I think most people remember the earliest versions of IBM Cobol.  Later versions that ran on OpenVMS supported recursion and pointers.  You could also set up variable-length arrays.  Searching an array in Cobol was three lines of code, (one statement).  But it's really hard to overcome the obstacles that people remember.

(I actually did implement a recursion in Cobol in my first job out of college for practical reasons.  I was reluctant, thinking that recursion wasn't much more than a party trick.  But I tried over and over again to implement the solution with iteration and it just would NOT work.   The only problem I ran into with recursion was that it needed some sort of entry vector.  Hard to describe that better.  It could call itself recursively but if you did that, you couldn't call the program the first time to get the ball rolling.  It was some hitch with the way they implemented the Procedure division, I think.  I ended up making a little stub entry vector in Vax Basic that called the Cobol routine.  It worked quite beautifully and I was thrilled.)