Bill,

You're not wrong about those kinds of COBOL warnings.  No "stupid perform" 
program passes a code review that I am tasked with, but I do have to say I've 
never seen one.

The failure to use scope terminators is unfortunately a very personal "style" 
issue when it is not directly addressed by any company-wide standard.  I have 
had co-workers who flat refused to use them except where absolutely required 
(like in the context of another IF or ELSE or PERFORM).  They tended to be 
quite careful users of "full stop/period" terminators though, so they weren't 
generating any bugs that I saw.

And yes, you may assume "we are not the owner of the copybook, so (we) can't 
change it", so even adding a FILLER is not possible (we're not even authorized 
to bring another group's COPY book into a change setup).  And I am not in any 
position to write or create a COBOL "message exit" for the standard compilation 
system, that is controlled by others.  I may suggest a change to a COPY member 
to the owning group, but "it will be have to be prioritized below other 
important work . . . ".

As for confronting auditors, again I am far from their environments.  I've 
never actually seen one at my current employer, they never get down to our 
level.

Peter

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Woodger
Sent: Friday, October 14, 2016 5:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ABO Automatic Binary Optimizer

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:

 <stupid perform example snipped>

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.
--


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to