"CONTINUE" as first line in Procedure Division ?? 1

[RICHINMINN]

This is a large IBM/DB2 shop, and I've just gotten a big bundle of programs to support. The programmer who wrote these programs started out the Procedure Division as follows:

PROCEDURE DIVISION.
CONTINUE.

FIRST-PARAGRAPH-NAME.
....

My question is: What good does it do to stick that "CONTINUE" in there as the first line of code in the PROCEDURE DIVISION?

I've been writing COBOL code for 20+ years, most of it spent on non-IBM platforms. What I've noticed is that IBM programmers do a lot of things in one particular way because that's the way that their professor in college did it, or their mentor at the first programming job they held. A lot of what IBM programmers do carry all the way back to the '50s when programmers were working on mainframe systems that make today's PCs look like supercomputers.

So what's up with this "CONTINUE"?

Rich (in Minn.)

 

[Dimandja]

Hi Rich,

If you think that is crazy, hear this.

Some years ago, I gave a COBOL program to a co-worker, to add a couple of lines of code. When I got the program back, it was bulkier than 2 lines of code would warrant. Curious, I reviewed the code and found that he had unfurled a PERFORM statement into several pages of IF statements! The explanation? He does not understand nor like PERFORM statements, so...

It can get hairy out there.

Dimandja

 

[3gm]

I have NO idea. CONTINUE is a "new" verb with COBOL 85, so the dinosaurs among us would have had no reason to use it until that version of COBOL came out. My best guess is s/he confused it with ON ERROR RESUME NEXT in Visual Basic. That statement is used to tell VB to turn off its error trapping and let the program handle errors itself.

To contribute my own war story, I once ran across a programmer who would not put blank lines in their COBOL, insisting on using the '*' in column 7. Turns out that somewhere back in their mainframe days, CA Optimizer would abend if it encountered blank lines. I'm sure that problem was fixed eons ago, but the programmer still adhered to that practice.

Glenn
Brainbench MVP for COBOL II

 

[MarcLodge]

Hi All,
Rich, loved the story, made me laughed out loud. Dimandja, an equally classic and amusing tale, why are there so many people stuck in their ways?

The other day I wrote a program on the mainframe and went to move to thru to system testing using a tool called endevor where you have to specify what type of program it is in order to get the correct compile. I defined it as a non DB2 program (because it was), only to be told that I must define it as DB2 and include the blank DBRM in the bind cards. When I queried why it was done like this, which was wrong, I was told 'Because it's always been done like that'. When I pressed further, as I knew it was wrong, I was told 'Not only has it always been done like like, but if someone comes along and accidently puts DB2 in the program, then doing it this way will cater for the error'. AAAAAAAGGGHHH!!!

I think it was at this point that I flick open my mobile phone and said 'Beam me up Scottie'. Lord save us from the sheep.

Marc

 

[RICHINMINN]

I'm enjoying reading what other people have encountered in the great big world of COBOL programming. Any other quirky/unique coding practices out there?

Another question?
What numbering scheme do you use in the DATA DIVISION (and why)?
01, 02, 03...
01, 03, 05...
01, 04, 07...
01, 05, 10...
01, 05, 07, 13... (I've seen some that make no sense!)

Also, what paragraph numbering/lettering scheme do you use in the PROCEDURE DIVISION? (And again, why?) I've worked with programs that had no paragraph sequencing at all, kinda like this:
PROCESS-DATA.
PERFORM READ-INPUT-DATA.
PERFORM EDIT-DATA.
PERFORM MOVE-DATA.
PERFORM WRITE-DATA.

And then the paragraphs themselves were all jumbled up, making it a real headache to "walk through the code".

I'm interested in seeing what other people have encountered and/or do themselves.

Rich (in Minn.)

 

[Dimandja]

Hi Rich,

Let me share some of my coding strategies.

In the DATA DIVISION, I tend to separate my data items into 01 levels each. This avoids problems such as data alignment. When you use various tools to define your data and generate copy books and such, data alignment can be quite a handfull. If they must be grouped, I would level them by five (05, 10, 15, etc...), easy to insert an unforseen level (rarely happens, though).

However, when I am coding and debuggging, I find it most useful to group all my variables under one 01 level, making it easier to check on my code by using a single display statement.

My paragraph names are usually taylored in increments of 1000: 1000-main, 2000-process, 9000-finalize, etc... This allows me to insert details for each major function: 1100-initialize/PERFORM 2000-process, 2100-read-master, 9100-clean-up, etc... (quite mundane, really).

Dimandja

 

[3gm]

Rich -

I do 01, 05, 10 for Data Division (although since we got rid of cards, there's no real reason not to do 01, 02, 03; I never insert an unusual level number, I renumber if I need to).

I don't use 77's anymore. Beyond the normal record groupings and other obvious groupings, I tend to have an 01 for similar data types, e.g. all switches, comp-3 accumulators, comp accumulators, general work areas, key save areas.

I use 4 digit numbers for paragraphs (If I go beyond 9000, I use A000...) starting with 0000-MAIN for the initial one. Generally begin/end housekeeping and utility paragraphs are 0xxx; the main process is 1000-; increment by 1000 for major control breaks or logical division in processing (e.g. 2000- for processing an ADD transaction, 3000- for a DELETE). Of course there are other schemes that are equally good; perhaps better. I tried at one time to number sort of "top down" following the structure chart, but I found I got down too many levels too quickly in many programs and the numbers became unwieldy.

Glenn

 

[slade]

Hi Rich,

My .02; The following "rules" are flexible and can change as circumstances warrent.

I like to begin copybooks w/an 05 level, not 01. Makes redefines, etc. easier. Also like to begin each field with
"re-:". This allows use of the same c/b more than once in a pgm by just using the REPLACING/BY option.

I usually try to use pgraph #s (e.g. 1000-) as hierarchies. That is, I use 1100-, 1200-, for pgraphs performed from 1000-, except for "utility pgraphs" like i/o, etc. Pgraphs performed from 1100- would be numbered 1110-, 1120-, etc. Sometimes this is not practical because of the quantity of pgraphs involved, but it makes it easier to recognize what major function a pgraph is helping to perform.

I tend to number my print pgraphs at the 6000- level, other i/o at 7000-, initialization at 8000-, and EOJ at 9000- (Abends at 9900-).

I put the init routines at the bottom of the code because I want to present the main processing loops up front. I feel that they, more than anything else, define the program.

The one time stuff I generally relegate to an out of the way corner of the room.

Regards, Jack.

 

[NVSbe]

In the procedure division, we always start with B01-begin and end with B01-einde. All paragraphs in between are then given numbers, which I think is random as long as they augment as you walk through the program. B100-insert; B200-update and so on.

After the B's come the R's, which are reading modules. R01-ReadArticle, R02-ReadEmployee, and so on.

Finally come the Z's which are small conversion and testfunctions. Z01-TestArticle, Z02-ConvertDate and so on.

About weird constructions, we have a lot of these in our programs:

PERFORM paragraph VARYING I FROM 1 BY 1 UNTIL I > 1. --------------------------------------
It's not the monsters under your bed, it is the men next door.
That make you fear, make you cry. Make you cry for the Child.
All the wars are fought amongst those lonely men. Unharmed, unscarred.

 

[ShadowFox333]

I have been a cobol, basic, machine language programmer since 1969 and long ago when I had way to much time on my hands I would make up procedure names like HELL
CLEVELAND or YOUR-GRANDMOTHERS-HOUSE and along with 88 levels like IF-YOUR-A-JERK-TODAY. Once in a while I'll end
up with a sentence like. go to HELL, CLEVELAND, YOUR-GRANDMOTHERS-HOUSE DEPENDING UPON IF-YOU-ARE-A-JERK-TODAY.
I have heard other programmers chuckle a bit reading thru some of my younger day programs.
Enjoy Bob

 

[confusedlady]

When I first started at this shop (2 yrs. ago), I was given a printout for paragraph numbering "rules" that have been (and will be) followed by anyone that programs here. They've been using the same procedure since 1996, and since eveyone does the same thing it's very easy to follow someone else's program (especially after they're gone and you have to maintain it. The "rules" are pretty easy to remember, too:

0000-0999 for main-routine and initialization stuff

1000-5999 processing paras.

6000-6999 utility routines (ie function keyprocessing,table loads, computations

7000-7999 edits

8000-9899 file I/O routines (these are further broken down, ie. all file open paragraphs are NN00, writes NN60, closes NN90, etc)

9900-9999 Critical error handling

There is also extensive reuse of coding (copybooks, copy/paste) so that also, so that all programs are as consistant as possible, no matter who wrote it.
confusedlady

 

[MarcLodge]

01,05 or 01, 03, 05 doesn't really matter. Having been around long enough to be really cantankerous, I'm more interested in the PIC statement. I like to code it always in a specific column as such:

PIC S9(004) COMP.
PIC X(001).
PIC 9(002)V99.

This makes everything line up and look pretty! I also line up the TO statements and have quite specific ideas on indentation. Yup, I'm really sad!

As for paragraph names, one that I've used that has not been mentioned here is just the straight alpha, and then cascade down from that.

A-CONTROL
B-INIT
C-MAIN
D-TERMINATE

All common sections begin XA, XB etc. Any section under a section goes down a letter, so you get CA- performs CAA- CAB- etc. This gives you a drill down and you don't have to worry about fitting numbers in.

I'm not saying it's the best, it's just another to mention. Take your pick all, and thanks for the star.

Marc

 

[RayatBiSaver]

I once coded a level 88 item with the name "cool-people" instead of "administrator", which represented users that were given a couple special rights within this one program. Over the years, end users found out about the name and requested to be cool-people.

I avoid level 77's as much as possible, and minimize my 01's. I put all my switches and counters underneath one 01 level item for minimization of object file purposes.

(.02) I got away from paragraph/statement numbering schemes when I left FORTRAN in 1981. I felt that the paragraph numbering schemes limit growth, and took away from clarity as much as it added. In fact, up until today, I thought that paragraph numbering schemes were a sign of out-of-the-box inexperienced college programmers and didn't think they were all that popular in the real world. So now I have otherlywise have learned.

 

[tgoepfert]

I agree with RayatBiSaver. Why?

In former times i also used paragraph numbering schemes, because this structure was told me by teachers and the companies in my region used this structure of code. But times are changing and so the styles of programming. The old way was based on monster programs written on mainframes. But as you all know, if you have to read programs not written by yourself, it's a burden to understand them, when everything
is included in one big code with thousands of lines. What does it mean to you, if you are reading such things 1000-, 2000-, or A-, B-, X-, absolutely nothing! So since a couple of years i'm writing code as small as possible with a limited number of sections and HUMAN readable names. Avoid any "go to" statements, so that it is impossible to split your sections with unnecessary paragraph names. This way will extremely help you in the future to read and write programs in OO syntax.

Regards, Torsten

 

[Dimandja]

Most of my clients like their code written in uppercase.

Left to my own devices, I prefer to uppercase all reserved words and lower-case my variables.

I also avoid using any punctuation (;,) except a single period at the end of my paragraph.

I delimit all my statements with the appropriate END-.

I never use GO TO.

I never PERFORM THROUGH anything, nor do I use EXITs.

Dimandja

 

[NVSbe]

Programming standards here are opposite.

Use PERFORM THRU as much as possible.

Put a dot after every line of code.

Don't use END- 's, use a dot to mark the end of something.

Every paragraph must have an EXIT statement.

Code loops with GO TO's as much as possible.

Lemme tell you, it drove me mad the first week I worked here. --------------------------------------
It's not the monsters under your bed, it is the men next door.
That make you fear, make you cry. Make you cry for the Child.
All the wars are fought amongst those lonely men. Unharmed, unscarred.

 

[confusedlady]

I think the shop here is a mix of older programming style and good, structured programming. Consistency among all of us is the main objective. Although at any time there are usually only 2 of us programming for AS/400 apps (Cobol), the turnover here is high, so it's a fairly good bet that you're going to be doing maintanance of something someone else wrote (probably in the early '90's).

In addition to the numbering I mentioned earlier, the only GO TO is used to GO TO 9999-CRITICAL-ERROR, a paragraph in EVERY program here, which does the same thing (causes the pgm to generate a dump and end processing).

Each individual pgm can (and usually does) have code to handle the errors in which you don't want the program to abort processing, but they are in addition to this.

The error conditions that can occur for each file used are level 88's (example FILENAME-STAT-EOF), and then the non-critical ones are redefined.

I'm doing a VERY poor job of explaining this, but what I'm trying to get at is that in every pgm, after an I/O operation, you will see something like:

IF CRITICAL-ERROR
GO TO 9999-CRITICAL-ERROR
END-IF

and the critical error is a switch in working storage that would be set in the I/O para.

I apologize for this being so long, but had to stick my two cents in! confusedlady

 

[MarcLodge]

The reason why you have paragraph names is so that you can easily and quickly locate the piece of code that you require. The paragraph names, whether the standard is numerical or alphabetical acts as an index and enables you to go straight to the code.
I'm surprised that anybody questions this, all I can assume is that they have not had to do support and been on site (or on a modem at a slow baud rate) at 2.30 in the morning with Ops contacting you asking when it's going to be fixed, and knowing that unless you solve the problem soon, the local grocery store's not going to get it's daily delivery. Trust me, when that happens, one's sense of humour goes out of the window and GO TO HELL, or PERFORM TABLE-UPDATE (where is table update to be found?) is not funny. Also field names should give you a clue of what they're about, so WS-COOL-PEOPLE as opposed to WS-ADMINSTRATORS will be equally unfunny when you're stressed and keeping your eyes open with matchsticks.

My two penneth.

Marc

 

[ceh4702]

Sometimes you get compiler errors if you have a paragraph with no verbs in it. I think if you look up the definition of a paragraph you will find it ends at the first period following the paragraph name line. The compiler expects another line so he put one in that does nothing. If you do not like my post feel free to point out your opinion or my errors.

 

[3gm]

ceh -

Not sure exactly what you were reacting to in the thread, but I've never gotten any errors with a PROCEDURE DIVISION paragraph that's empty. I use them all the time as empty stubs as I build programs from the top down.

My HP COBOL manual says: "In the PROCEDURE DIVISION, a paragraph begins with a paragraph name, optionally followed by one or more sentences comprising the paragraph body."

My COBOL/VSE manual says a paragraph is "A paragraph-name followed by a separator period, optionally followed by one or more sentences".