Need arbitrator: END-IFs and EVALUATE... 7

[JFett]

This question is open to everyone, and I would appreciate your responses on these.

1) Can someone tell me what their professional opinion of (and their installation's standards/guidelines on) the use of explicit scope terminators like END-IF/ENDIF? I use them because they're clear and (as their title says) they explicitly terminate the scope of a sequence of code. It makes nested IF's much easier to follow for me. My impression of them is that they MUST'VE been useful to others, since they were added to COBOL in its later variants.

My teammates at work hate them and I'm being run into the ground on it. They'd rather use periods, indentations, and NEXT SENTENCEs as indicators. They're mostly older programmers who are pretty set in their ways/opinions. (To add to their intractability, we don't get along that well.)

2) For another example (and one I'd like your input on as well): I tried to suggest using an EVALUATE statement for a segment of code where they had to consider each digit of a string, and they shot me down, even though it would've reduced the code by a third or more. They preferred using a nested IF structure, but unindented in a "Case-like" format. For example:


IF condition a
statement
ELSE
If condition b
statement
ELSE
IF condition c
statement

(etc)...

On the other hand, here's how EVALUATE would look

EVALUATE variable
WHEN condition a
statement
WHEN condition b
statement
WHEN condition c
statement

(etc)...


To me, it makes for cleaner, more understandable code...but they argue that their way is better. When I suggested the use of EVALUATE (which they weren't familiar with), I got shot down. To me, it seems that everyone else is hell-bent on maintaining THEIR preferences, regardless of what may actually be better or may follow more standard practice elsewhere.

Maybe I'm the crazy one. I'd appreciate you guys letting me know.

 

[ceh4702]

I was in a program the other day that uses
Perform
abc
xyz
depending on a123

There are only one or two programs on our system that are written that way.

If you do not like my post feel free to point out your opinion or my errors.

 

[Crox]

that is probably an other programming language because a PERFORM ... DEPENDING ON does nog exist in COBOL. A GOTO ... DEPENDING ON exists. A lot of people don't like it but it can be very efficient in certain situations.

 

[WMK]

Just to repeat an earlier warning,

Please do NOT mix "Next Sentence" and End-IF. The '85 ANSI Standard (and the '02 Standard) make it "non-conforming" to code:

If A = "A"
Next Sentence
Else
Perform ABC
End-IF

However, IBM, Micro Focus (and probably others) allow this as an extension.

Understanding the DIFFERENCE between "CONTINUE" and "Next Sentence" is an important thing for all programmers using explicit scope terminators to do.

Bill Klein

 

[Crox]

The trouble with all this kind of talk is that people forget that COBOL is not the language you are thinking in. (at least I hope so!!!) It is just a way to implement a solution which - I hope - you made in your own language, for example by using Jackson Structured Programming techniques.

When your COBOL compiler creates instructions based on your source, it generates all kinds of 'unstructured' assembler whith jumps and so on. Do you bother?

When you have a Jackson designed solution, you should not bother about what code does the job. Somethimes it can be very relaxed to simulate stop-and-resume points in your COBOL program by using a GOTO ... DEPENDING ON. Nothing wrong with that. This happens for example when a main-program is changed into a called module, just using some transformation rules. A precompiler can do that job for you but if you don't have one, you do those things by hand the easiest way, not a complete source-redesign with no advantage at all.

I think it is completely wrong when any programmers thinking is delimited by the programming language. It should not.

It would be nice if those typical implementation aspects like described by Jackson would be part of the compiler options. Compiler builders like IBM, MicroFocus, CA, etc. should introduce such elements into their compilers. But... true structured programming is almost not supported in any language .... pitty. If you want to use a good Jackson precompiler, you have to make one yourself.

Regards,

Crox

 

[ceh4702]

You are probably right it probably was GO TO DEPENDING ON. I will have to look at that program more closely when I come across it again.

Sorry about that.

On using the IF statements, I try not to write programs with too many IF and ELSE statements strung together. I find it very hard to follow end even harder to edit. I think there are normally better ways to structure a program to make it understandable.

Divide and Conquer.

I have never used Continue and probably never will. We are going to stop using COBOL in a year or so, so we will not be purchasing a new Compiler when we switch over to our new system. The new system is a package and uses ENVISION as a programming language, and a UNIDATA Database System.

We usually try to use the NEXT SENTENCE Extension to avoid compound conditions with negative conditions. That is the traditional style of programming we use or have used in the past. I have written a program or two with no GO TO statements in it, but it just confused people to see my use of the PERFORM command. So I just went with the flow and tried to use their normal programming style with GO TO. However, Some programs just work better with some perform statements.

You just have to use the standard employed wherever you are working. PERFORM can be just as confusing as the GO TO.

If you do not like my post feel free to point out your opinion or my errors.

 

[JFett]

Thanks for all the additional input, guys.

Actually, I have a new wrinkle for everyone. I'm being forced to re-write code I'd done previously with END-IFs because everyone pressured my supervisor to change the standard back to periods-only (previously I'd been "allowed" to use END-IFs in nested IF statements). Now, I'm running into this error/warning:

33XXX IGYPS2112-E The "IF" statement did not have a matching scope terminator. A scope terminator was assumed on line 34XXX. The execution results may not be correct.

I thought that previously, the compiler could understand/interpret the code based on indentations and verb/command placement. Does anyone know if the latest versions of COBOL now require END-IFs for nested conditionals? Is there any other way to handle nested logic to avoid this, other than breaking things into a dozen different mini-paragraph/procedures (which I am loathe to do because of bad readability)?

Using some vague "psuedocode", here's one quick example (probably not the best, but the quickest I could toss out)


MAIN
Perform Procedure A until item-number-changes

PROCEDURE A
IF item-record-type is Z
IF item-prefix = '11'
activate flag-1
ELSE
SEARCH table
when item-type is found activate flag-2
MOVE fields to save
DELETE record
IF output-status not successful
display errors
ABORT
IF flag-1 or flag-2 activated
PERFORM Procedure B
PERFORM Procedure Read-Next-Item-Record.


Try to read it the way the compiler would...you're entirely dependent upon picking up the indentation/verb-usage clues to determine the appropriate breaks. Can someone think of a better way to code this (without scope terminators) to avoid the confusion that would cause that error message? For clarity, here's that same Procedure with the appropriate scope-terminators.


PROCEDURE A
IF item-record-type is Z
IF item-prefix = '11'
activate flag-1
ELSE
SEARCH table
when item-type is found activate flag-2
END-IF
MOVE fields to save
DELETE record
IF output-status not successful
display errors
ABORT
END-IF
IF flag-1 or flag-2 activated
PERFORM Procedure B
END-IF
PERFORM Procedure Read-Next-Item-Record
END-IF.


Just figured I'd ask for for some advice...it's amazing how one has to contort just to avoid something that's designed to help in this very situation. THANKS!

 

[PHV]

Something like this ?
IF item-record-type NOT = Z
GO Read-Next-Label
.
IF item-prefix = '11'
activate flag-1
ELSE
SEARCH table
when item-type is found activate flag-2
.
MOVE fields to save.
DELETE record.
IF output-status not successful
display errors
ABORT
.
IF flag-1 or flag-2 activated
PERFORM Procedure-B THRU Procedure-B-End
.
Read-Next-Label.
PERFORM Procedure Read-Next-Item-Record.

Hope This Helps, PH.
Want to get great answers to your Tek-Tips questions? Have a look at FAQ219-2884 or FAQ181-2886

 

[kkitt]

this is what you paragragh looks like now and will be executed like

PROCEDURE A
IF item-record-type is Z
    IF item-prefix = '11'
        activate flag-1
    ELSE
        SEARCH table
            when item-type is found activate flag-2
        MOVE fields to save
        DELETE record
        IF output-status not successful
           display errors
           ABORT
           IF flag-1 or flag-2 activated
              PERFORM Procedure B
              PERFORM Procedure Read-Next-Item-Record.

Notice that without the scope terminators that all the code gets lumped under the search, when in reality you would like it to be after either the 'Prefix = '11' or the search.

sorry to say that the only way around this would be to create a couple of procedure to handle them kind of like:

PROCEDURE A
IF item-record-type is Z
    IF item-prefix = '11'
        activate flag-1
        [b] perform New-A1[/b]
    ELSE
        SEARCH table
            when item-type is found activate flag-2
        [b]perform New-A1.[/b]

  [B]New-A1[/b]
        MOVE fields to save
        DELETE record
        IF output-status not successful
           display errors
           ABORT
        IF flag-1 or flag-2 activated
           PERFORM Procedure B.

        PERFORM Procedure Read-Next-Item-Record.

Is the read only done if the 'Item-Record-Code is Z'?

 

[TonHu]

... I'm being forced to re-write code I'd done previously with END-IFs because ...

Just 1 possible advise left: Please get a decent Job, at a different company.
Sigh.

HTH
TonHu

 

[Glenn9999]

<quote>"I'm being forced to re-write code I'd done previously with END-IFs because everyone pressured my supervisor to change the standard back to periods-only (previously I'd been "allowed" to use END-IFs in nested IF statements).</quote>

A good warning sign that you're going to be in for nothing but headaches. I concur with the previous poster, assuming you can do it.

<quote>I thought that previously, the compiler could understand/interpret the code based on indentations and verb/command placement.</quote>

Nope. To the compiler all it is seeing is a stream of cards. As long as you follow the real-estate rules, the compiler is happy.

<quote>Does anyone know if the latest versions of COBOL now require END-IFs for nested conditionals?</quote>

The compiler is basically putting this error out because the assumption is that there can only be one IF statement terminated by a period. You are encountering the exact reason why using periods-only is a foolish deprecated programming practice.

<quote>Is there any other way to handle nested logic to avoid this, other than breaking things into a dozen different mini-paragraph/procedures (which I am loathe to do because of bad readability)?</quote>

No.

 

[WMK]

Just to clarify, NO COBOL compiler understands "indentation" - except A-/B-margin differences.

A "conditional statement" (IF, Search AT END, ADD ON SIZE) etc - withOUT a scope terminator (END-whatever) is ONLY allowed in certain places (notably within an IF ELSE construct.

You MUST either use scope terminators - or NOT nest concitional statements.

P.S. From the "IGY" message, I can tell you are at an IBM shop. If you would like some IBM references to WHY you SHOULD use scope terminators (to show your boss), I would be happy to send them to you.

Bill Klein

 

[Glenn9999]

http://www.naspa.com/PDF/99/T9901012.pdf

Another good read on the topic.

 

[JFett]

From WMK:
P.S. From the "IGY" message, I can tell you are at an IBM shop. If you would like some IBM references to WHY you SHOULD use scope terminators (to show your boss), I would be happy to send them to you.

Oh, would you please! I'd GREATLY appreciate that!

TonHu and Glenn9999: Unfortunately, I'm not able to find a different place at the moment. Just a move to a different team within my workplace would probably help, which is possible...but I'm in a very unusual situation (due to outside influences) that prevents this for the time being. So unfortunately I'm stuck here for the indeterminate future, unless another job becomes available. :-(

THANKS again to everyone for all your encouragement and humor...they help me make it through the day. I'll be going on vacation at the end of this week (I'll be back after New Year's). I'll probably talk to you all again before then...but just in case I don't, I hope you all have a very Merry Christmas and a Happy New Years!

 

[JFett]

From WMK:
From the "IGY" message, I can tell you are at an IBM shop. If you would like some IBM references to WHY you SHOULD use scope terminators (to show your boss), I would be happy to send them to you.

WMK, did you ever get around to finding those IBM references you mentioned (above)? I didn't see anything else here, so I was just checking.

Hope everyone is doing fine! I was on vacation, but now...back to work. UGH! X-P

Happy New Years, everyone! Hope your holidays were all great!

 

[WMK]

Send me your email address - and I will get you references in a few days. I can be reached at:

wmklein <at> ix.netcom.com

Bill Klein

 

[JFett]

I'm very sorry to bother everyone again, but this is somewhat urgent.

I may need to document all of your opinions to use in my defense in the very near future. I would greatly appreciate it if you would all provide me with your major credentials: Your job titles at work, how long you've been doing COBOL, and, if you feel comfortable doing it, where you work. You don't have to include your names, if you don't want to...I can certainly respect the need for privacy. But I would like to be able to present your opinions as credentialed, professional ones, by people who are knowledgable and/or respected in their fields.

I would VERY much appreciate the extra information. Also, if you know of anyone else who'd like to add their opinions and credentials to what's already been presented here, I'd be very thankful for that too. I'm in a situation where any extra firepower will most certainly be of use.

Everyone, please wish me luck...I'm going to need it.

JFett.

 

[TonHu]

Ah, seems the new job is on it's way , lots of luck!

H'm, I'm a bit reluctant to writing this all down, the work history that is, I'll be brief:

Years of programming: 20
Years of Cobol: 4 (since 2001)
Age: fourty-something ;-)
Languages: Basic, VisualBasic, Clipper/xBase, C, C++, Pascal, Delphi, Cobol, Java, PHP, Html, OS-scripting. (in random order)
OS's: CP/M, DOS, Windows, HP-UX, Linux, Unixware.

HTH
TonHu

 

[3gm]

JFett -

Rather than have us post our credentials to the forum, provide your e-mail address in a form that is not easy for spammers to harvest and let us get back to you individually.

Regards,

Glenn

 

[JFett]

Rather than have us post our credentials to the forum, provide your e-mail address in a form that is not easy for spammers to harvest and let us get back to you individually.

GREAT idea! But is there a way to send private messages to people? I looked around, but I can't find anything like that. If not, I'll give out my EMail address on this forum, but I thought I'd check for a private way to send it first.

 

[3gm]

See WMK's posting of 1/3/06 for an example of a way to obscur your e-mail address on this forum. I am unaware of any other way to communicate privately here.