The RC=4 thing was not directed at you. I don't think anyone with "experience" 
(being counted as just turning up for years, or "one year of experience many 
times") would be contributing to this list.

I'm pointing out that "RC=4 is OK, get on with the test" is reasonably common. 
And with such systems, whether implied from one of the diagnostic messages, or 
simply associated with the sloppiness of the method, *I guarantee there are 
careless bugs in the system*. 

Someone sent me a program a couple of weeks ago. Numerous W and I diagnostics, 
including the interesting "hey, here's a SECTION, the prior paragraphs aren't 
within SECTIONs, watch it buddy, could be very bad" message.

Looking at the program, written originally in the early 80s and changed a 
number of times since, you could see that it had started out fairly well, and 
was still quite readable. Whereas when written, the full-stop/period in the 
PROCEDURE DIVISION had much greater significance, once using compilers which 
didn't require it, most, but not all, new statements were terminated with a 
full-stop/period (so they had become sloppy), and also no END- scope 
terminators were used. So, you immediately expect to find an IF where the 
indentation shows one intention, and the code (presence or absence of 
full-stop/period) shows reality. Lo, there it was.

They had become sloppy, and sloppy always costs.

Take the stupid PERFORM. Here's an example program:

       PROGRAM-ID. STAB59. 
           DISPLAY "GOING TO B" 
           PERFORM B THRU A 
           DISPLAY "COMING BACK FROM... A?" 
           DISPLAY "IN A" 
           DISPLAY "IN B" 

Compile that, and you get: 

     7  IGYPA3086-W   "PERFORM" start-of-range "B" follows the "PERFORM" 
end-of-range "A".  The "PERFORM" end-of-range may be unreachable.  The 
statement was processed as written.                                             

Run it and you get this:

GOING TO B                                                                      
IN B                                                                            
IGZ0037S The flow of control in program STAB59 proceeded beyond the last line 
of the program.                         
         From compile unit STAB59 at entry point STAB59 at compile unit offset 
+0000039E at entry offset +0000039E at 
         address 1210039E.                                                      

Basically it fell of the end of the program, in this case. Of course if there 
was a paragraph after B, it would have fallen into that. If there was some 
'rithmetic it could have S0C7'd, or with other code caused some other abend. 
But it needn't have caused another system abend, it depends what the code it 
drops into does.

If it continues to wimble along and still falls off the end of the program, you 
get the user abend, as above.

However, if, below B, there is a PERFORM range which is still active... then as 
it falls, it will arrive at the termination of the active PERFORM.

And if later in the program control passes to A, then, as if by magic, control 
will fly to the position after PERFORM B THRU A.

Now, the diagnostic, only a W, is indicating you may have a problem. Anyone who 
reads that and leaves it is... only superseded by anyone who doesn't even read 
it because "RC=4 is OK".

Back to your REDEFINES in copybooks. I'll assume that "we are not the owner of 
the copybook, so can't change it". If that is the case, that is where auditors 
are your friends - play the "sloppy" story to them, and explain that it is 
unacceptable (to you) that such practice is acceptable from an audit point of 

If that has no direct impact, and you have at least V4.2, you can use a 
"message exit" for the compiler (can be written in COBOL even) which "upgrades" 
the status of any W and I that you select. Then your programs won't compile. 
Then they'll have to change the copybook?

Or are we driven back to "if we change the copybook, we have to recompile and 
change, and test, 200 programs". Well, if you only fix those REDEFINES with 
FILLERs (explicit or implicit) then a) you don't *need* to recompile any 
program just for the copybook change b) if you do recompile anything/everything 
then the object code *should be identical* c) if proven identical (except for 
date/time of compile) then it is already as tested as the current version d) if 
not proved identical you know that something else is wrong and whatever that 
is, it is unexpected for your test cases.

Now, I'd like to run that past an auditor if I was in a position to do so, even 
if only to become aware of their response.

For IBM-MAIN subscribe / signoff / archive access instructions,
send email to with the message: INFO IBM-MAIN

Reply via email to