PERFORM WITH IF 6

[claudeb]

Hi, what's wrong with my coding ?
the compiler is screaming: "The "IF" verb did not have a matching scope terminator."

PERFORM
VARYING K FROM 1 BY 1 UNTIL K > 6
IF A-AMT (J) < B-AMT (K)
PERFORM 1000-WRITE
THRU 1000-WRITE-X
END-PERFORM.
thanks

 

[claudeb]

i am glad i asked the question.

 

[slade]

Hi Jan,

OK Jan, you asked for it. I can't say they’re interesting, but here’s some of the things I do to make a pgm more readable. They are by no means original thoughts and may sound nit-picky and trivial but I think, in aggregate, they make a pgm more readable and therefore more maintainable. It may be helpful for those starting out to think about the points made here and use what they think makes sense and modify and adapt or reject those that they don't.

Structure:

The most important thing to do to “structure” a pgm is to structure its logic. I ask “is this the simplest most straightforward way to solve this problem?” I try to envision the code through the eyes of the reader and ask “if this was the first time I saw this code would I know what it was doing?” I try to think in terms of “processing blocks” and code those blocks using performs. There is also a thread here called &quot;control break construct&quot; posted 4/05/01 by slade and ammended by Crox and others. It discusses 2 approaches to coding for control breaks. They can be used as a template for any control break situation.

I try to code the “logic” of the pgm in the 1st 2 or 3 screens of code. I think of a pgm as a “document”. The 1st 2 or 3 screens serve as the table of contents; the pgraphs as chapters; the pgraph comments serve as the lead pgraph that explains the intent of the chapter. If that isn’t enough, I improvise.

When I comment paragraphs I attempt to tell what was “intended” in business, not technical terms. I only comment code whose intent is not obvious. If an &quot;IF&quot; stmt or any other, for that matter, references field values that don't convey the intent of the stmt in business terms I'll comment it.


Naming stuff:

To get the “logic” of the pgm up front, I relegate most of the one time stuff (opens, init code, closes, term code) to the bottom of the pgm, e.g., I usually code the init pgraph as 8nnn-init, print as 6nnn-..., other I/O as 7nnn-..., utility pgraphs as 5nnn-... (this last one only sometimes). I also try to keep sub-pgraphs numbered as sub groups of the main pgraph, e.g.:

2000-...
    performs 2100-...
    performs 2200-...
        ....
2100-...	
    performs 2110-...     	

2110-... 
    .....
    .....

2200-...
    ....
    ....

I read somewhere that pgraphs should only perform 1 function and if you have a problem naming a pgraph, you probably have it doing too much. Sounded like sage advice to me. When naming “objects” (i.e. anything) I try to use known abbreviations, e.g. acct, prod, amt, cnt, etc. I also found that using nbr for number and num for numeric helps avoid confusion. I try to avoid names like ws-acct-1 ws-acct-2 when ws-master-acct and ws-tran-acct really defines what thes fields are. The same goes for pgraph names. It’s not easy to assign names, but it‘s worth the effort. And I’ll NEVER use 2 fields with names like this: ws-master-acct, ws-mstr-acct. This leads me to another point: try to be consistent, don’t use -ACCOUNT in one context and -ACCT in another. I even look at the copybooks I’ll be using to see what form of the word they use. Sometimes that works, but the idea is to keep it consistent. If I redefine a field I call it field-red. If I redefine it and change it from pic 9 to pic x, I call one field-num, the other field-an or field-9 field-x.

I consider “WS-” passe with the advent of power editing software available today. But doI use it to identify file record fields that reside in WS. I use FDxx- to identify file section record fields. The only exception is report recs. For them I use RH1-..., RH2-..., etc., RD1-..., RD2-..., etc., RT1-..., RT2-..., etc. I generally prefix any Linkage Section data items with LK- or LS-.

Miscelaney:

I don't use periods (.) to end sentences. I've found that it reduces errors when copying code from one part of a pgm to the middle of a nested if, as an example.

I end pgraphs with the mandatory period on a separate line. It also serves to delineate the pgraphs.

The general form of my PIC clauses look like this:

         PIC  X(002).

The leading zeros align the digits allowing easier totaling when the bytes in a group need totaling.
Note that there are 2 spaces before the X. This again aids alignment when signed numerics are coded, e.g.
         PIC  X(002).
         PIC S9(004)V99.

 

[BettyScherber]

My observation, whatever it's worth, on putting in all those periods.

If you use the periods wherever allowed, then it is easy to tell whether a given statement is being inserted into straight code or conditional code. If you don't have the periods, you have to look through the whole paragraph to tell for sure. Of course, it should be indented if it's conditional, but don't get me started about people who don't indent when they should or do indent when they shouldn't. Betty Scherber
Brainbench MVP for COBOL II

http://www.brainbench.com

 

[JanSweden]

Hi Slade

I agree to your way of doing things - and mostly because you have done some thinking - escpecially in the area of solving a problem the most straight way.

In my opinion isn't the 'layout' the most important - there is no such thing as a 'true' way of doing things.

I think the most important is to try doing those reports basically the same way over and over again - that way I make sure others can read and understand my code - and it also free my mind from 'inventing' the report. When a new problem eraises I try to find out - will I run into this again? If so I try to make a general solution to it. Perhaps also put into a subroutine - that routine can then be further developed over the time - but still solve the first problem the same way for years.

There are of course guide lines established that can be good - for example IBM put some thogether a number of years ago - but most important - we are different and I think this kind of work should reflect something about us as persons

Jan

 

[turnipman]

Don't use GO TO anymore....I am now a structure guy. Anyway, was helping a co-worker try to decipher an ALTER GO TO, no kidding. Fortunately, we don't have too many of these programs left. I really hate ALTER GO TO.

 

[Guest_imported]

In laying out a program I have found most breaking out the tasks like an outline. One paragraph to start, the main process and the final routine. Under each of these you may add logic or more paragraphs to address each function (open files, build output record, etcetera). Use common sense in having many paragraphs with a couple of lines of code each. I once worked in a shop where the standards required us to have each i/o command in its own paragraphs. This meant that we had to code one paragraph with nothing other than an open statement for each file. I think it was ridiculous.

The second suggestion that helps others when the look at your program is to use verbs in the paragraph names. A name like 1000-print-totals makes more sense than just 1000-totals. Verbs like read, write, accumulate, verify, print helps the reader determine what the paragraphs main function is.

 

[RonaldB]

Viz,

an open statement in it's own paragraph seems like a bit over the top; however, some structuring methods tend to standardize everything to make every program uniform looking. Opening an other file type or data structure of some sort may require more than one statement and might make it sensible to create a paragraph for.
A better example would be a read or write paragraph; allthough the basic read an write statements are fairly simple, such a paragraph may allso contain validity checks, statements for maintaining sort marks, etc. Performing a paragraph in this case makes the code more readable and prevents clutter.

The bottom line is: you'll have to decide every time what the benifits and drawbacks are of one construct of another.

Regards,
Ronald.

 

[slade]

Hi All,

I agree Ronald. VSAM file functions are usually awarded their own pgraphs because of the status test after the function.

Rather than open, read, write pgraphs (always saw it as a tragic waste of a pname), I like to use pgraphs like:

     8000-1st-read.
         open
         perf 8100-read-next-rec
         if eof display 'err msg' goback end-if 
         .
    7000-get-next-matching-rec.
        perform until cur-key >= prev-key
           read into
           etc.
        end-perform
        etc.
        .
   6100-print-detl-line.
       if page-full
          perf 6000-print-heads 
       end-if
       write from etc.
       .

Well, you get the idea.

Regards, Jack.

 

[jkapcia]

Two comments regarding &quot;GO TO&quot; vs. &quot;PERFORM&quot;:

1. Rather than having the first statement in a paragraph be &quot;IF condition GO TO EXIT&quot;
you'll achieve greater efficiency and readability by coding &quot;IF condition PERFORM&quot;.

IF PROCESS-ME
PERFORM 1000-PROCESS-RECORDS THRU 1000-EXIT.

1000-PROCESS-RECORDS.

|
|
|
---> REMAINING CODE FOR THIS PARAGRAPH
|
|
|

1000-EXIT.
EXIT.



This method is equally valid for VS/COBOL and COBOL/II. If the paragraph will be performed from numerous locations throughout the program and its too complex for nested IF's or EVALUATE, use the following technique:

PERFORM 1000-SELECT-RECORDS THRU 1000-EXIT.

1000-SELECT-RECORDS.
IF PROCESS-ME
PERFORM 1500-PROCESS-RECORDS.

1000-EXIT.
EXIT.

1500-PROCESS-RECORDS.
|
|
|
---> REMAINING CODE FOR THIS PARAGRAPH
|
|
|

EXITs were only needed prior to the introduction of the structured paradigm, when
many programmers coded routines which could be entered through either linear fall-through or PERFORM logic. Many programmers still use it use either thtrough force of habit or to provide a more visually striking end to a paragraph.


2. A program with no &quot;GO TO&quot;s which is poorly-structured, from the stand-point of business functionality, or whose paragraphs are arranged hap-hazardly, is just as difficult to debug or maintain as one with no &quot;PERFROM&quot;s. Take it from someone who has written and maintained both types over more years than I care to admit.

 

[JanSweden]

Hi again

I think there are X number of reasons to keep
a specific structure of a program (among all the
other programs that build up a system)
.. I'm in a position maintaing a system that is
some 20 years old and consists of some 300 big
programs and many small subroutines ..

So as you understand there is
- almost 2 generations of programmers involved
over the years
- old technology (segmentation as one example)
- old cobol standards - and vendor extensions
- special routines for low level programming
that doesn't exist today - because the
hardware platform is no more

I have worked with this jurassic park monster for
5 years - every singel day I try to find a way to
modernize - and some of the problems I have been
able to rewrite into subprograms and this way get
a more structured code - also in the main code as
the &quot;call XXX using parm1 parmX ...&quot; in it self does
bring some order. At the same time I can't justify
rewriting everything at the same time - the customer
says &quot;it has always worked for us..???&quot;

So what I try to do is:
- add comments when I find out what the guy before me
actually DID do!

- every time when I find that same code is repeated
exactly the same way in another program - just a few
values that makes the differences - I put that code in
a subroutine or a copy book and delete the original
code.

- I'm using tools to search variables like ws-date
ws-dates w-date-today - checking out if they are
used what way and why - so that I can trough them out
to dev NULL or put them into a reusable subroutines.
I do the same with calculations filehandling screen I/O
printer handling and so on.


My plan is to 'routine' by 'routine' modernize and one
day all that is left of the 'old' programs is calls and
use of copy books. At that time it will be no big effort
to clean up and put together easy to read main programs

How do you go about 'modernizing' old code?

Jan

 

[slade]

Hi All,

jkapcia, this is not intended as an ad hominum attack, but a general comment about the &quot;go to&quot; controversy.

I just don't understand this aversion to its use, even admitting the ill effects of unrestricted and injudicious gotoing.

Almost any COBOL feature can be misused. I don't hear anybody advocating &quot;MOVEless code&quot; with the advent of the INITIALIZE stmt. Joke, just a bad joke.

I've seen PERFORM 1000-SEND-MAP-AND-RETURN stmts in CICS pgms.
I've seen PERFORM 1000-TERMINATE-PGM in batch pgms.

It's in the definition of a PERFORM to return to the NSI, but these 1000-... pgraphs don't go back to the NSI, they exit the pgm. So what's so structurally sound about that?

I've seen nested IFs that would curl your toes; I've seen constructs used to avoid them. I've seen a lot of strange things done to avoid a goto when the most straightforward thing to do is to use it. This avoidance seems to border on superstition. I don't get it. Is there some mathematical or systems theory or religious principle that the occasional judicious use of a goto violates?

Jack

 

[RonaldB]

All,

the direction this thread is going in proves once again a fact about programming:

&quot;... it's not a trade, it's an ART &quot;

Regards,
Ronald.

P.S. What i mean to say is: every programmer develops his / her own style. As long as the code is understandable to and maintainable for some else, and indeed to/for the author him-/herself after a week or two, and implements the functions it was supposed to, there can really be nothing wrong with it.

 

[confusedlady]

That is definetly the whole point, RonaldB. I am new to this shop, and I couldn't believe the &quot;rules&quot; here at first. Perform thrus and exit paragraphs stardard for every program, gotos to exit paragraphs in almost every IF statement, and yes, each I/O command gets it's own paragraph! And it's been that way for a long time-over most of the country.

What I've found, though, is that it what makes the pgm good/bad is not how many GOTOs vs. PERFORMs there are, but how well it's designed and the actual logic.

I also support the I/O paragraphing now, since it makes so much of the code re-usable. A lot of the same files are used among many prgs., but there's code already there to select the file, open, close, read it, etc. and the naming conventions are fairly simple. It was a lot easier for me to get used to saying call this, or copy that in my prg, and definitely easier to understand someone else's code. Since everyone follows the same procedures, you can understand the code that was written 2 years ago by some retired programmer five states away.

 

[slade]

It's me again,

Continuing my rant and swerving into CL's discussion about &quot;standarized code&quot;, it's probably too late for COBOL now, but I always thought a company would be wise to pay double/triple the going rate for 1 or 2 pgmmrs (consultants), and let them write the code for a few core pgms for them. Then release them and hire your permenant staff. If they're like me, they'll start copying code and the shop will ultimately house an inventory of well written code. Well, let's say better written code than could otherwise be expected.

As I said, it's too late for COBOL. Is it too late for Java, or whatever the lastest flavor of the month is in the new environments?

Jack

 

[jkapcia]

Jack,
I think you may have misunderstood some of my post. I probably didn't make my point clearly enough, as I agree completely with your 4-19 post regarding the importance of proper logical structure. Other than technically irrelevant stylistic differences in the formatting of data definition statements, my only point of contention would be on the importance/value of punctuation. Most of the COBOL code I currently work with is 30-40 years old and it's not unusual to find a program with multiple statements on one line, only mandatory punctuation (e.g., end of IF, end of paragraph) and indentation which is inconsistent or entirely absent. I end every statement with either a period or semi-colon (inside conditional constructs, although it occasionally confuses PL/1 programmers) and use commas to separate most optional clauses and multiple items within a list. As for copying code from one location to another, if it needs to be used in more than one place it ought to be a PERFORMed paragraph or CALLed sub-routine.
I once felt as you do regarding the logical gymnastics used in writing &quot;GO TO&quot;-less &quot;psuedo-structured&quot; code in VS/COBOL and was a strong proponent of what I refer to as linear code. My opinion changed after being exposed to COBOL/II, a true structured language. I discovered that they really aren't necessary if you use enough paragraphs,
give careful thought to the business (as opposed to technical) structure of the problem to be solved (the object-oriented paradigm is quite helpful in visualizing this) and VERY liberal use of condition-names (especially with switches.) Those toe-curling nested IFs you mentioned are usually evidence of poor structure within the context of the business problem, and can be cured by limiting the depth of nesting inside a paragraph (how many levels is a personal choice, although indentation should never force a single condition to multiple lines unless vveerryy long field names are being used), PERFORMing the internal processes, and making liberal use of condition-names.
The RETURN and TERMINATE examples you cited exhibit poor technical structure. They should be separated from the other functions and appear at the end of the mainline. CICS programs present a special case as they may exit, never to return, to different places depending on conditions. The solution to this problem is to check all relevent conditions and set switches (with condition-names) to control exiting from normal processing and direct traffic to the proper external location.

Jay

 

[jkapcia]

I got so caught up in the other issues that forgot to clarify my original point, which is that I don't think &quot;GO TO&quot;s really add much clarity and avoiding them is more a case of getting practice in developing good logic habits than anything else.

 

[slade]

OK,

I give up. I have to perform eat now.

Regards, Jack.

 

[jkapcia]

Excellent example of the object-oriented paradigm.

Regards,
Jay Jay