COBOL subscript range checking

I am wondering what philosophy other shops out there have with regard to
COBOL, CICS, and subscript range checking.  We currently have the CHECK LE
runtime option turned ON, but our compiler is set with NOSSRANGE.  This
means that the code for range checking is not compiled in to the
executables, and therefore range checking is not done, even though it's set
to ON at the runtime level.

A few ws ago we started having some problems with a program writing of
ECDSA.  As you can imagine this was not a good thing.  Based on the names of
the programs being written to the console I took a guess at which program it
was.  I recompiled the program with the SSRANGE option set and voila, that
was it.  Of course this didn't actually make the program itself work, but it
did 1) show us where the problem was and 2) stop it from writing over
storage unexpectedly.

So the question is, is range checking in production (especially production
CICS) programs a good idea?  What type of performance hit can be expected if
we turn it on?

Just for the heck of it, I turned on SSRANGE for a program I implemented
yesterday.  For better of for worse, the program started abending with
reason 1006, which corresponds to COBOL error IGZ0006S (The reference to
table <name> by verb number <number> on line <number> addressed an area
outside the region of the table.)  This was bad in that it caused the
program to stop working (under certain circumstances), but it was good in
that we can now eliminate a bug.  (Yes, I did fix the problem prior to
posting this message!  <g> )

My thought is to, at the very least, have the test compile job set the
SSRANGE option.  We'll certainly come upon more subscript overflows.  But I
don't we'd find all of them.  At some point I'm thinking that perhaps we'd
also want to do this in production, but there are definitely down sides.

So what does everyone think?

Thanks,
Frank

--

Frank Swarbrick
Senior Systems Analyst - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO
(303) 235-1403

On Aug 8, 5:19 pm, "Frank Swarbrick" <Frank.Swarbr...@efirstbank.com>
wrote:
> I am wondering what philosophy other shops out there have with regard to
> COBOL, CICS, and subscript range checking.  We currently have the CHECK LE
> runtime option turned ON, but our compiler is set with NOSSRANGE.  This
> means that the code for range checking is not compiled in to the
> executables, and therefore range checking is not done, even though it's se
t
> to ON at the runtime level.
>
> A few ws ago we started having some problems with a program writing of
> ECDSA.  As you can imagine this was not a good thing.  Based on the names 
of
> the programs being written to the console I took a guess at which program 
it
> was.  I recompiled the program with the SSRANGE option set and voila, that
> was it.  Of course this didn't actually make the program itself work, but 
it
> did 1) show us where the problem was and 2) stop it from writing over
> storage unexpectedly.
>
> So the question is, is range checking in production (especially production
> CICS) programs a good idea?  What type of performance hit can be expected 
if
> we turn it on?
>
> Just for the heck of it, I turned on SSRANGE for a program I implemented
> yesterday.  For better of for worse, the program started abending with
> reason 1006, which corresponds to COBOL error IGZ0006S (The reference to
> table <name> by verb number <number> on line <number> addressed an area
> outside the region of the table.)  This was bad in that it caused the
> program to stop working (under certain circumstances), but it was good in
> that we can now eliminate a bug.  (Yes, I did fix the problem prior to
> posting this message!  <g> )
>
> My thought is to, at the very least, have the test compile job set the
> SSRANGE option.  We'll certainly come upon more subscript overflows.  But 
I
> don't we'd find all of them.  At some point I'm thinking that perhaps we'd
> also want to do this in production, but there are definitely down sides.
>
> So what does everyone think?
>
> Thanks,
> Frank
>
> --
>
> Frank Swarbrick
> Senior Systems Analyst - Mainframe Applications Development
> FirstBank Data Corporation - Lakewood, CO
> (303) 235-1403

SSRANGE involves a serious performance hit, I seem to remember that
the programmers guide gave some guidance.  Having said that, a
mishehaving program can also cause serious performance probloms that
are more likely if it hasn't been tested adequately.  Perhaps a useful
compromise would be to run programs in production with it on for the
first w or month, then recompile with it off once you are
reasonably confident, with the option to turn it on again if
circumstances indicate a potential problem.  It's probably a good idea
to always use it when testing, except perhaps when doing performnce
analysis.  You should be wary of using it with old programs, which may
deliberately go out of range for specific reasons, such as trying to
read the leading record descriptor on a variable length record.  I
think it would be advisable to test old programs with SSRANGE on
before applying it in production.

HTH Robert

On Wed, 8 Aug 2007 10:19:42 -0600, "Frank Swarbrick"
<Frank.Swarbrick@efirstbank.com> wrote:

>My thought is to, at the very least, have the test compile job set the
>SSRANGE option.  We'll certainly come upon more subscript overflows.  But I
>don't we'd find all of them.  At some point I'm thinking that perhaps we'd
>also want to do this in production, but there are definitely down sides.

Many shops still have standards created decades ago by persons long
gone that include turning off "expensive" options such as SSRANGE.
What's funny is that many of those shops allowed languages such as
PL/I that didn't give us the option of turning range checking off -
citing the advantage of such languages' checking.

(Use Java vs C++ for a modern version of this argument).

It shouldn't be so hard to change obsolete standards.     I got our
shop to put SSRANGE in the TEST proc (although lots of programmers
in-line that proc).   But I was unable to get it into the production
compiler.

On Wed, 8 Aug 2007 10:19:42 -0600, "Frank Swarbrick"
<Frank.Swarbrick@efirstbank.com> wrote:

>I am wondering what philosophy other shops out there have with regard to
>COBOL, CICS, and subscript range checking.  We currently have the CHECK LE
>runtime option turned ON, but our compiler is set with NOSSRANGE.  This
>means that the code for range checking is not compiled in to the
>executables, and therefore range checking is not done, even though it's set
>to ON at the runtime level.
>
>A few ws ago we started having some problems with a program writing of
>ECDSA.  As you can imagine this was not a good thing.  Based on the names o
f
>the programs being written to the console I took a guess at which program i
t
>was.  I recompiled the program with the SSRANGE option set and voila, that
>was it.  Of course this didn't actually make the program itself work, but i
t
>did 1) show us where the problem was and 2) stop it from writing over
>storage unexpectedly.
>
>So the question is, is range checking in production (especially production
>CICS) programs a good idea?  What type of performance hit can be expected i
f
>we turn it on?
>
>Just for the heck of it, I turned on SSRANGE for a program I implemented
>yesterday.  For better of for worse, the program started abending with
>reason 1006, which corresponds to COBOL error IGZ0006S (The reference to
>table <name> by verb number <number> on line <number> addressed an area
>outside the region of the table.)  This was bad in that it caused the
>program to stop working (under certain circumstances), but it was good in
>that we can now eliminate a bug.  (Yes, I did fix the problem prior to
>posting this message!  <g> )
>
>My thought is to, at the very least, have the test compile job set the
>SSRANGE option.  We'll certainly come upon more subscript overflows.  But I
>don't we'd find all of them.  At some point I'm thinking that perhaps we'd
>also want to do this in production, but there are definitely down sides.
>
>So what does everyone think?
Have you reviewed the generated code to see what is added by turning
on the check?
>
>Thanks,
>Frank

>>> On 8/8/2007 at 1:51 PM, in message
<kj7kb3hjvt3dhngqjsmfjku2dsn570up8u@4ax.com>, Clark F
Morris<cfmpublic@ns.sympatico.ca> wrote:
> On Wed, 8 Aug 2007 10:19:42 -0600, "Frank Swarbrick"
> <Frank.Swarbrick@efirstbank.com> wrote:
> 
> LE 
> set 

> of 

> it 
> that 

> it 
> production 

> if 

> I 
> we'd 
> Have you reviewed the generated code to see what is added by turning
> on the check?

No, but it does make the executable quite a bit larger.
I may do this when I have some time.  (I have time to post here but no time
to do this research.  <g> )

Frank

Frank Swarbrick wrote:
> I am wondering what philosophy other shops out there have with regard to
> COBOL, CICS, and subscript range checking.

Well, we weren't IBM, so we didn't have CICS.  But, we didn't do range
checking in production.  We did occasionally turn it on during
development and debugging (especially if we had a hunch).  The overhead
was "significant" according to the manual, but in practice, we never ran
it long enough to get concrete numbers on the performance penalty.

--
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
~     / \/ _ o     ~          Live from Albuquerque, NM!          ~
~     _ /\   |     ~                                              ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ Business E-mail  ~ daniel @ "Business Website" below            ~
~ Business Website ~ http://www.djs-consulting.com                ~
~ Tech Blog        ~ http://www.djs-consulting.com/linux/blog     ~
~ Personal E-mail  ~ "Personal Blog" as e-mail address            ~
~ Personal Blog    ~ http://daniel.summershome.org                ~
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~

GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ !O M--
V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e h---- r+++ z++++

"Who is more irrational?  A man who believes in a God he doesn't see,
or a man who's offended by a God he doesn't believe in?" - Brad Stine

Frank Swarbrick wrote:
> I am wondering what philosophy other shops out there have with regard to
> COBOL, CICS, and subscript range checking.  We currently have the CHECK LE
> runtime option turned ON, but our compiler is set with NOSSRANGE.  This
> means that the code for range checking is not compiled in to the
> executables, and therefore range checking is not done, even though it's se
t
> to ON at the runtime level.
>
> A few ws ago we started having some problems with a program writing of
> ECDSA.  As you can imagine this was not a good thing.  Based on the names 
of
> the programs being written to the console I took a guess at which program 
it
> was.  I recompiled the program with the SSRANGE option set and voila, that
> was it.  Of course this didn't actually make the program itself work, but 
it
> did 1) show us where the problem was and 2) stop it from writing over
> storage unexpectedly.
>
> So the question is, is range checking in production (especially production
> CICS) programs a good idea?  What type of performance hit can be expected 
if
> we turn it on?
>
> Just for the heck of it, I turned on SSRANGE for a program I implemented
> yesterday.  For better of for worse, the program started abending with
> reason 1006, which corresponds to COBOL error IGZ0006S (The reference to
> table <name> by verb number <number> on line <number> addressed an area
> outside the region of the table.)  This was bad in that it caused the
> program to stop working (under certain circumstances), but it was good in
> that we can now eliminate a bug.  (Yes, I did fix the problem prior to
> posting this message!  <g> )
>
> My thought is to, at the very least, have the test compile job set the
> SSRANGE option.  We'll certainly come upon more subscript overflows.  But 
I
> don't we'd find all of them.  At some point I'm thinking that perhaps we'd
> also want to do this in production, but there are definitely down sides.
>
> So what does everyone think?

Rather than speculating, I have pasted the results from the IBM COBOL
Performance Tuning document below.  Note:  This was done with Enterprise
COBOL V3.1, so it is a bit obsolete with V3.4 as the current product
level.  OTOH, I don't believe there has been significant changes in this
area.

I would also suggest that, the overhead would be less for the compiler
doing the same number of tests versus hand coding the tests in the
program.  As indicated below, testing all versus some of the subscript
references should be your guide.

My experience is that, it is very common to compile with SSRANGE and run
with CHECK(OFF).  It can significantly reduce problem determination time
by not having to recompile.  And, in some shops, there are major
impediments to recompiles, but a run-time option change is much easier
to do, especially when the objective is fixing a production problem.

Here are the IBM results:
> SSRANGE or NOSSRANGE
> Using SSRANGE generates additional code to verify that all
> subscripts, indexes, and reference modification | expressions do
> not refer to data beyond the bounds of the subject data item.
> This in-line code occurs at every reference to a subscripted or
> variable-length data item, as well as at every reference
> modification expression, and it can result in some degradation at
> run time.  In general, if you need to verify the subscripts only a
> few times in the application instead of at every reference, coding
> your own checks may be faster than using the SSRANGE option.  For
> performance sensitive applications, NOSSRANGE is recommended.
>
> Performance considerations using SSRANGE:
> *  On the average, SSRANGE with the run-time option CHECK(ON) was
>    1% slower than NOSSRANGE, with a range of equivalent to 27%
>    slower.
>
> *  On the average, SSRANGE with the run-time option CHECK(OFF) was
>    1% slower than NOSSRANGE, with a range of equivalent to 9%
>    slower.
>
> *  On the average, SSRANGE with the run-time option CHECK(ON) was
>    1% slower than SSRANGE with the run-time option CHECK(OFF)
>    with a range of equivalent to 16% slower.

So, in the second, more recommended situation:  You may not have much
penalty at all [equivalent] but the worst case is 9%.  So, I'd say other
decision points:  How critical is the application?  How critical is the
application's performance?  How important is it to get the application
fixed if it does fail?  [YMMV...]

Carl

On Thu, 09 Aug 2007 12:08:18 -0400, CG
<Carl.Gehr.ButNoSPAMStuff.4@MCGCG.Com> wrote:

>I would also suggest that, the overhead would be less for the compiler
>doing the same number of tests versus hand coding the tests in the
>program.  As indicated below, testing all versus some of the subscript
>references should be your guide.

That's something that always bothered me about any standard to turn
off an overflow check.    This doesn't mean we should save cycles by
not checking for overflow - it only means that we code the check by
hand.   How does that save cycles?    Especially since it is easier to
optimize code where the compiler understands exactly what is desired
than when it is guessing what is significant to the programmer.

Lots of coding would be more efficient with exception processing
rather than checking everything ahead of time.    This isn't always
part of the design of CoBOL - calling a function to find out whether
we can call a function is inefficient and ugly.

On Thu, 09 Aug 2007 12:08:18 -0400, CG
<Carl.Gehr.ButNoSPAMStuff.4@MCGCG.Com> wrote:

>So, in the second, more recommended situation:  You may not have much
>penalty at all [equivalent] but the worst case is 9%.  So, I'd say other
>decision points:  How critical is the application?  How critical is the
>application's performance?  How important is it to get the application
>fixed if it does fail?  [YMMV...]

And what are the alternatives to having the compiler check?   Options
include:

1.   Have the program check - that doesn't save cycles.
2.   Have the program abort with overflow.
3.   Have the program run - with unpredictable results.

I know, sometimes the design can mean that no checking is necessary -
until maintenance makes changes.    And we see lots of highly paid
programmers write critical applications with overflow vulnerabilities.

On Thu, 09 Aug 2007 10:26:12 -0600 Howard Brazee <howard@brazee.net> wrote:

:>On Thu, 09 Aug 2007 12:08:18 -0400, CG
:><Carl.Gehr.ButNoSPAMStuff.4@MCGCG.Com> wrote:

:>>So, in the second, more recommended situation:  You may not have much
:>>penalty at all [equivalent] but the worst case is 9%.  So, I'd say other
:>>decision points:  How critical is the application?  How critical is the
:>>application's performance?  How important is it to get the application
:>>fixed if it does fail?  [YMMV...]

:>And what are the alternatives to having the compiler check?   Options
:>include:

:>1.   Have the program check - that doesn't save cycles.

False.

The program does not need to check every reference, i.e., if SUB is used 20
times it need only check when it is set.

--
Binyamin Dissen <bdissen@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.