IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Cobol Compiler Options - discussion


IBM Mainframe Forums -> COBOL Programming
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Mon May 02, 2011 3:44 am
Reply with quote

This is a preparation for a discussion about the Cobol compiler option NUMPROC. This one is pretty-much "Cobol Only".

This is a short piece about Compiler Options.

When Cobol is installed, it is done so with a set of "Default" options. These might be the IBM defaults (as listed in the Programmers Guide), or the specific site Defaults, or a mixture (which are effectively site defaults, some of which happen to co-incide with IBM defaults). By choice at installation, any option can be "locked" so that it cannot be overridden.

The defaults can be changed, easily and temporarily, when compiling a program by specifying the option in question on a PARM in the JCL (or from TSO) or on a CBL/PROCESS card in the program (there is also the possibility to use an options file). The installed defaults can also be changed by the Systems Programmers if necessary/required. Some, or all, compiler options can be "fixed", meaning that they cannot be overridden by PARM/CBL.

All of the above, and more, is from the Programmer's Guide.

Once you are out of initial testing, to my mind you should be using the same compile options as the production system which is the "target" for your new/changed program. IBM don't agree with me on this. It is my view. IBM suggest, as an example, that you can run your production compiles with OPTIMIZE, with the implication that until that point you have not done it.

Comments, questions, views, disagreements all welcome.
Back to top
View user's profile Send private message
prino

Senior Member


Joined: 07 Feb 2009
Posts: 1306
Location: Vilnius, Lithuania

PostPosted: Mon May 02, 2011 1:12 pm
Reply with quote

At every site that I worked at, I've always insisted that they use the same compiler options for both development and production, and where required I always added (in PL/I) my own '*process' options to reach this equality. The simple fact is that the load module of a program compiled with option "opt(0)" (unoptimized) is not the same as the load module of the same program compiled with "opt(3)" (fully optimized). In fact at one client there was a problem where one program did not work when compiled optimized (to long ago to remember the details).

However, right now I do have a problem with the PL/I compiler for Windows where there are differences between the output of "opt(0)" and "opt(3)" compiled versions of the program, and in fact I spent most of the past weekend removing code from a 10,000 line program to one that would still exhibit the behaviour, and emailed the results to IBM yesterday!

In short, I fully support your view that all compiles, test, acceptance and production, should use exactly the same compiler options (with the possible exception of those options that affect just the compiler listing - I prefer a short XREF and no pagination for testing work)

FWIW, at one client, where the same options were used for test and production, this even included putting programs in production with all test hooks!
Back to top
View user's profile Send private message
Kjeld

Active User


Joined: 15 Dec 2009
Posts: 365
Location: Denmark

PostPosted: Mon May 02, 2011 2:03 pm
Reply with quote

If you use a library system like Endevor, the compile processors also has a defined set of options, or at least a set of overrides to the environment (site) details.

Different element types can have different options.
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Mon May 02, 2011 2:30 pm
Reply with quote

I basically agree with everything said, especially about Test equal to PROD.

one thing:
in test use SSRANGE, in PROD NOSSRANGE.
Back to top
View user's profile Send private message
prino

Senior Member


Joined: 07 Feb 2009
Posts: 1306
Location: Vilnius, Lithuania

PostPosted: Mon May 02, 2011 2:44 pm
Reply with quote

dbzTHEdinosauer wrote:
I basically agree with everything said, especially about Test equal to PROD.

one thing:
in test use SSRANGE, in PROD NOSSRANGE.

The same site that put its programs in production with all test hooks, also put every CICS program in production with SUBSCRIPTRANGE. It turned out the overhead for most programs was pretty low, CICS programs are not really using huge arrays.

The policy was that all new programs, and maintenance to old ones should replace hard-coded array bounds with the PL/I LBOUND & HBOUND builtin functions, but stick to SUBRG until that conversion was done. (A few years ago they outsourced their entire IT department to the Philippines, so it will never be done...)
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Mon May 02, 2011 3:50 pm
Reply with quote

dbzTHEdinosauer wrote:
I basically agree with everything said, especially about Test equal to PROD.

one thing:
in test use SSRANGE, in PROD NOSSRANGE.


Why I strongly prefer the same options is because the code generated is different. The program is longer/shorter, statements start in a different place. If something is overwriting (through a "wild" subscript, for instance) the time to find it is not when going to NOSSRANGE. Yes, I carefully chose that sort of example.

Anyway, it does look like you can almost have-your-cake-and-eat-it with SSRANGE. There is a run-time option, NOCHECK, which turns off the SSRANGE checking. No recompile, nothing moving around in the program. Just a different route through the code generated by the SSRANGE option.

I would still avoid it. To an extent, I'd even avoid SSRANGE. Because its use might get to make new coders sloppy. When I code a looping-construct, I'm already "mentally" testing it. By the time I have a new program, I am happy that there are no wild subscripts. Then I test them all. I'd even use SSRANGE at that point. After I'm convinced that nothing can go wild, then I don't need SSRANGE out of initial unit-testing.

Of course, there are other people's programs. If you can't sit hard enough on everyone, then SSRANGE might be a big help. How many times has it kicked-in?
Back to top
View user's profile Send private message
prino

Senior Member


Joined: 07 Feb 2009
Posts: 1306
Location: Vilnius, Lithuania

PostPosted: Tue May 03, 2011 2:17 am
Reply with quote

This just arrived from IBM's lead PL/I developer after I sent him a link to this thread:
Quote:
Robert,

for SSRANGE, the COBOL equivalent of SUBSCRIPTRANGE, the compiler conditionally executes code to test the subscripts with the conditional code testing a flag set at run-time

In PL/I, we have improved the code for this test, that I would suggest that it would probably be ok to compile all code with PREFIX(SUBRG). And, of course, in Java, it is always enabled
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Tue May 03, 2011 3:43 am
Reply with quote

Bill Woodger wrote:
[...] There is a run-time option, NOCHECK, which turns off the SSRANGE checking. [...]


Correction: CHECK(OFF), not NOCHECK. That was CHECK, with a "CHE".
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Tue May 03, 2011 3:59 am
Reply with quote

Bill,

This is a post from just over a year ago, regarding my opinion of COBOL compile option PFD -

www.ibmmainframes.com/viewtopic.php?p=231337&highlight=#231337

Bill
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Tue May 03, 2011 4:25 am
Reply with quote

SSRANGE is unique amongst the Cobol options.

It generates code, but not code that can affect the logic of the program (OK, except for the obvious - it "stops" the program with diagnostic messages when something goes "outside the range").

The code itself, the checking, can be turned on or off at runtime.

It would be possible to compile for production, and run with CHECK(OFF). There would be some performance impact, as for each affected statement the run-time switch would be tested before the range-checking code was bypassed, but nothing like the range-checking itself. You can also turn the range-checking on again without having to re-compile.

The problem with going into the final phases of the cycle and production itself with suddenly compiling without SSRANGE is the potential that, having now got program code which is a different size, with instructions in different locations, something which was over-writing something else before, which at that time didn't matter, now is over-writing something that does matter. Of course, the biggest culprit in over-writing things are out-of-bounds subscripts etc.

That all sounds complicated, so I'll play it out again from a different angle.


  • It is possible to over-write data/code in a program
  • It is possible to over-write data/code in a program without causing a "direct" problem - if the data/code that is over-written is not used after the over-writing has occurred
  • It is possible through changing the size of the program by changing compile options (OPT and NOSSRANGE would make the code shorter, for instance) that now something that has been over-written does become a direct problem


OK, the scenario is unlikely, but it does happen. Simply running everything up to production with SSRANGE will not be any guarantee that a combination of data that exists in production the day after you go live, but didn't exist before, doesn't over-write something.

Of course, to follow on from my jokey statement earlier, if you are running with the range-checking, then you are not going to get over-writing from out-of-bounds access, are you?

The other culprits for over-writing, the program which called yorus and the programs you call, aren't affected by SSRANGE. If the calls are DYNAMIC, you have some protection from some possibilities, but not all.

I guess at the end of the day what I am suggesting is that if you run your test cycle with SSRANGE, keep it in production, with CHECK(OFF). It is the way that JAVA does it, after all, and nearly there for PL/I (thanks Prino). Cobol can't be more than 20 years behind, can it? So it's coming anyway, maybe :-)
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> COBOL Programming

 


Similar Topics
Topic Forum Replies
No new posts Replace each space in cobol string wi... COBOL Programming 3
No new posts How I Found a Bug in a FORTRAN Compiler All Other Mainframe Topics 4
No new posts COBOL -Linkage Section-Case Sensitive COBOL Programming 1
No new posts COBOL ZOS Web Enablement Toolkit HTTP... COBOL Programming 0
No new posts Calling DFSORT from Cobol, using OUTF... DFSORT/ICETOOL 5
Search our Forums:

Back to Top