Peter,
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:
IDENTIFICATION DIVISION.
PROGRAM-ID. STAB59.
DATA DIVISION.
WORKING-STORAGE SECTION.
PROCEDURE DIVISION.
DISPLAY "GOING TO B"
PERFORM B THRU A
DISPLAY "COMING BACK FROM... A?"
GOBACK
.
A.
DISPLAY "IN A"
.
B.
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
view.
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 [email protected] with the message: INFO IBM-MAIN
