Cobol - COBOL subscript range checking

Author

COBOL subscript range checking

Frank Swarbrick

2007-08-08, 6:55 pm

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 w

s 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

Robert Jones

2007-08-08, 6:55 pm

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 set
> to ON at the runtime level.
>
> A few 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

Howard Brazee

2007-08-08, 6:55 pm

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.

Clark F Morris

2007-08-08, 6:55 pm

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 w

Frank Swarbrick

2007-08-08, 6:55 pm

>>> 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
[color=darkred]
> of
[color=darkred]
> it
> that
[color=darkred]
> it
> production
[color=darkred]
> if
[color=darkred]
> 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

LX-i

2007-08-08, 9:55 pm

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

foodman123@gmail.com

2007-08-09, 6:55 pm

On Aug 8, 12: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.

Any programmer not coding specific end-of-range tests within the
application program should be fired.

Depending on the OS to detect errors is amateurish.

Tony Dilworth

HeyBub

2007-08-09, 6:55 pm

foodman123@gmail.com wrote:
> On Aug 8, 12:19?pm, "Frank Swarbrick" <Frank.Swarbr...@efirstbank.com>
> wrote:
>
> Any programmer not coding specific end-of-range tests within the
> application program should be fired.
>
> Depending on the OS to detect errors is amateurish.

We once had a chap try to feed a pumpkin into the card reader. I don't know
how the software could have tested for that...

Howard Brazee

2007-08-09, 6:55 pm

On Thu, 09 Aug 2007 06:05:14 -0700, foodman123@gmail.com wrote:

>Any programmer not coding specific end-of-range tests within the
>application program should be fired.

Programmers mess up - look at all of the memory overflow problems
there are in applications and operating systems written in languages
that don't check for it.

>Depending on the OS to detect errors is amateurish.

OS?

Using a compiler that provides suspenders to supplement your belt is
professional.

Andreas Lerch

2007-08-09, 6:55 pm

?? Urspr=FCngliche Nachricht

Am 08.08.07, 18:19:42, schrieb "Frank Swarbrick"=20
<Frank.Swarbrick@efirstbank.com> zum Thema COBOL subscript range=20
checking:

Hi Frank

> I am wondering what philosophy other shops out there have with regard =

to
> COBOL, CICS, and subscript range checking. We currently have the=20
CHECK LE
> runtime option turned ON, but our compiler is set with NOSSRANGE. =20=

This
> means that the code for range checking is not compiled in to the
> executables, and therefore range checking is not done, even though=20=

it's set
> to ON at the runtime level.

COBOL calculates the addresses relative to the beginning of a table or=20=

MOVE.
With SSR, COBOL add something like this code to the object code:

IF POINTER BEFORE TABLE
OR POITER AFTER TABLE
CALL IGZ??? --> to Abend
END-IF

this code take about 6 to 8 or so instructions and can be 20 bytes=20
long (or so)

The runtime option is only a marker to tell IGZ???: to do or not to do=20=

an abend....

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

YES - YOU MUST.
Sorry - there is no significant performance degration, even you have=20=

no haevy load on your transactions. I have done some experiances with=20=

SSR oan NOSSR, and my resulty are:

Load module --> SSR is some bytes larger than NOSSR --> irrelevant -=20=

modules are loaded once an in storage.
CPU-cost --> irrelevant --> one transaction ist running in 0,0001 or=20=

0,0015 cpu-seconds

I have no other degrations with SSR, bit I think: a PERFORM has more=20=

overhaed than SSR.

We use SSR since the implementation of COBOL-II (late 80th of the last=20=

century) and we have a small number, 2 or 3, of programms, that are=20
compiled with NOSSR, to keep the runtime an cpu-load less, but these=20=

programms are called several million times in ONE process,(most batch)

more significant for a problem could this be:

01 table1 occurs 10 indexed by index1.
05 field-of-table1 pic x(10).
01 table2 occurs 10 indexed by index2.
05 field-of-table2 pic x(20).

With this commands:

SET INDEX1 TO 3
MOVE FIELD-OF-TABLE2 (INDEX1) TO ???

which bytes are moved?

Yes:=20
COBOL calculates 3 x 10 and add the result to the beginning of table2,=20=

then the MOVEwill be done like following:

MOVE TABLE2 (30:20) to ???

you can never find this mistake, with or without SSR....

The better way to reduce runtime and cpu-consuming ist to optimize=20
your I/O - IMS, VSAM, more DB2. When we change from ESCON to FICON,=20
our batch-runtimes are the half than before (german: halbiert see:=20
LEO)

the most, we save, are accesses to DB2............

I am an experiance since 1980 with COBOL and Assembler on MVS and=20
z/OS. I learned to read a systemdump of cobol backward to resolv the=20=

source field of a compute.

Einen schoenen Tag
Andreas Lerch

2007-08-09, 6:55 pm

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 set
> to ON at the runtime level.
>
> A few w

s 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

Howard Brazee

2007-08-09, 6:55 pm

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.

Howard Brazee

2007-08-09, 6:55 pm

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.

Binyamin Dissen

2007-08-09, 6:55 pm

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.

2007-08-09, 6:55 pm

In article <vcmmb3l7jkut1s0mhavotiukg8rm1cq9qr@4ax.com>,
Binyamin Dissen <postingid@dissensoftware.com> wrote:
>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.

Well, in the Oldene Dayse I recall being taught that a subscript was
supposed to be range-checked for every incrementing/decrementing... I
posted some code here a while back where that was done and even included
Classic Mistake Number (your choice) of checking the data-condition before
the subscript's range.

DD

Frank Swarbrick

2007-08-09, 6:55 pm

>>> On 8/9/2007 at 7:05 AM, in message
<1186664714.481032.142460@d55g2000hsg.googlegroups.com>,
<foodman123@gmail.com> wrote:
> On Aug 8, 12:19?pm, "Frank Swarbrick" <Frank.Swarbr...@efirstbank.com>
> wrote:
> LE
>
> Any programmer not coding specific end-of-range tests within the
> application program should be fired.
>
> Depending on the OS to detect errors is amateurish.

Yes, but that assumes the end-of-range checking is correct. For instance,
this helped me find a bug I had with this regard just the other day.

Relevant field definitions:

01 OBI-INFO.
05 OBI-INFO-TEXT OCCURS 6 TIMES
PIC X(35).
05 OBI-INFO-LINE OCCURS 3 TIMES
PIC X(71).

01 WIREMNT.
05 WIREMNT-FREE-FORM.
10 WIREMNT-FREE-FORM-INFO OCCURS 14 TIMES
PIC X(39).
05 REDEFINES WIREMNT-FREE-FORM.
10 OCCURS 14 TIMES.
15 WIREMNT-FREE-FORM-TYPE PIC X(4).
15 WIREMNT-FREE-FORM-TEXT PIC X(35).

Original code:

MOVE ZERO TO FF-SUB2
PERFORM VARYING FF-SUB1 FROM 1 BY 1
UNTIL FF-SUB1 > 14
OR FF-SUB2 > 6
IF WIREMNT-FREE-FORM-TYPE (FF-SUB1) = 'OBI'
OR 'SVC'
ADD +1 TO FF-SUB2
MOVE WIREMNT-FREE-FORM-TEXT (FF-SUB1)
TO OBI-INFO-TEXT (FF-SUB2)
END-IF
END-PERFORM

Fixed code:

MOVE ZERO TO FF-SUB2
PERFORM VARYING FF-SUB1 FROM 1 BY 1
UNTIL FF-SUB1 > 14
OR FF-SUB2 = 6
IF WIREMNT-FREE-FORM-TYPE (FF-SUB1) = 'OBI'
OR 'SVC'
ADD +1 TO FF-SUB2
MOVE WIREMNT-FREE-FORM-TEXT (FF-SUB1)
TO OBI-INFO-TEXT (FF-SUB2)
END-IF
END-PERFORM

This code has been for two years and never noticed until I just happened to
turn on SSRANGE.
And yes, I did code the original, buggy code. No one's perfect. Most
'modern' languages already do subscript range checking (among other things!)
at run-time.

Frank

Frank Swarbrick

2007-08-09, 6:55 pm

>>> On 8/9/2007 at 10:08 AM, in message
<cf20e$46bb3bf5$d06620ed$10913@FUSE.NET>,
CG<Carl.Gehr.ButNoSPAMStuff.4@MCGCG.Com> wrote:
> Frank Swarbrick wrote:
> LE
> set
> of
> names of
> program it
> that
> but it
> production
> expected if
> in
> But I
> we'd
>
> 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:

That's kind of an odd comment. Certainly they are not advocating a time
when you should *intentionally* note code your own range checks? The
problem with explicit range checks is that, well, they may be wrong. So, in
my way of thinking, SSRANGE gives you *two* types of range checking: the
explicitly coded one which will hopefully handle an out of range by doing
something sensible, and SSRANGE which will simply blow up if your explicit
range checking logic is faulty.
[color=darkred]

I'm afraid I don't understand what is meant by "...a range of equivalent
to...".
[color=darkred]
> 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...]

Thanks for the info!

Frank

HeyBub

2007-08-09, 9:55 pm

Binyamin Dissen wrote:
>
>
> 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.

Ah, but the subscript could change without having been changed. For example:

01 MYSTUFF.
02 MYNAME OCCURS 5 PIC X(50).
02 MYADDR OCCURS 5 PIC X(60).
...
02 MYINDX PIC S9(7) COMP-5.
02 MYOTHERTHING OCCURS 5 PIC X(100).
...

PERFORM VARYING MYINDX FROM 1 BY 1 UNTIL MYINDX > 5
...
IF (something-really-weird)
MOVE SPACE TO MYSTUFF
END-IF
...
MOVE 'RESIDENT' TO MYNAME(MYINDX)
...

The subscript was not changed under program control - it was changed by a
completely unrelated bug. Bounds checking would catch the error, manual
checking would not.

William M. Klein

2007-08-10, 3:55 am

(I have followed some - but not all - of this thread in both IBM-MAIN and
comp.lang.cobol - but haven't replied yet).

As far as I can tell from the notes that I have read so far, no one has pointed
to the performance paper comments on this. It should be noted that Frank is
usually interested in COBOL under VSE, so Enterprise COBOL *may* not be exactly
the same. However, if you look at the paper at:

http://www-1.ibm.com/support/docvie...g27001475&aid=1

It has the following (exceprted) information:

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

(COB PG: pp 313, 333, 545)"

***

My personal GENERAL rules-of-thumb are:

1) Have the default compiler option set to SSRANGE (for production and test)

2) Have the run-time option for test set to CHECK(ON)

3) Have the run-time option for production set to CHECK(OFF) - but know how to
turn it on when symptoms indicate the need.

4) Make certain that VERY performance-sensitive applications that use many
subscripts and reference modification, compile with NOSSRANGE (but document
this)

In general, these rules apply to both batch and online applications. However,
having the ned for NOSSRANGE for online may occur more often than for batch
(depending upon system design).

--
Bill Klein
wmklein <at> ix.netcom.com
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:46B998BE.6F0F.0085.0@efirstbank.com...
>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 w

William M. Klein

2007-08-10, 3:55 am

OOPS - I read further and found that the Performance Paper was quoted. Sorry to
repeat the input of others.

--
Bill Klein
wmklein <at> ix.netcom.com
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:S0Sui.144549$Zr1.94902@fe06.news.easynews.com...
> (I have followed some - but not all - of this thread in both IBM-MAIN and
> comp.lang.cobol - but haven't replied yet).
>
> As far as I can tell from the notes that I have read so far, no one has
> pointed to the performance paper comments on this. It should be noted that
> Frank is usually interested in COBOL under VSE, so Enterprise COBOL *may* not
> be exactly the same. However, if you look at the paper at:
>
> http://www-1.ibm.com/support/docvie...g27001475&aid=1
>
> It has the following (exceprted) information:
>
> "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.
>
> (COB PG: pp 313, 333, 545)"
>
> ***
>
> My personal GENERAL rules-of-thumb are:
>
> 1) Have the default compiler option set to SSRANGE (for production and test)
>
> 2) Have the run-time option for test set to CHECK(ON)
>
> 3) Have the run-time option for production set to CHECK(OFF) - but know how to
> turn it on when symptoms indicate the need.
>
> 4) Make certain that VERY performance-sensitive applications that use many
> subscripts and reference modification, compile with NOSSRANGE (but document
> this)
>
> In general, these rules apply to both batch and online applications. However,
> having the ned for NOSSRANGE for online may occur more often than for batch
> (depending upon system design).
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
> news:46B998BE.6F0F.0085.0@efirstbank.com...
>
>

Binyamin Dissen

2007-08-10, 3:55 am

On Thu, 9 Aug 2007 20:54:08 -0500 "HeyBub" <heybubNOSPAM@gmail.com> wrote:

:>Binyamin Dissen wrote:

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

:>Ah, but the subscript could change without having been changed. For example:

:>01 MYSTUFF.
:> 02 MYNAME OCCURS 5 PIC X(50).
:> 02 MYADDR OCCURS 5 PIC X(60).
:> ...
:> 02 MYINDX PIC S9(7) COMP-5.
:> 02 MYOTHERTHING OCCURS 5 PIC X(100).
:> ...

:>PERFORM VARYING MYINDX FROM 1 BY 1 UNTIL MYINDX > 5
:> ...
:> IF (something-really-weird)
:> MOVE SPACE TO MYSTUFF
:> END-IF
:> ...
:> MOVE 'RESIDENT' TO MYNAME(MYINDX)
:> ...

:>The subscript was not changed under program control -

It certainly was.

:> it was changed by a
:>completely unrelated bug. Bounds checking would catch the error, manual
:>checking would not.

And the bounds checking would not provide any useful information.

Perhaps some folk need training wheels - a real programmer will do his own
bounds checking.

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

Howard Brazee

2007-08-10, 6:55 pm

On Thu, 9 Aug 2007 17:00:33 -0600, "Frank Swarbrick"
<Frank.Swarbrick@efirstbank.com> wrote:

>This code has been for two years and never noticed until I just happened to
>turn on SSRANGE.

I like to have all of those type of comparisons with ">" instead of
"=", so I can see that mistake.

I often make my subscript sizes into "constants", to make it easier
for maintenance programmers to catch that they need to be changed when
they change table sizes. I suppose I could be paranoid and code in a
check to see if the table is the size I think it is - but I have only
done that with database records.

I just thought of another reason why the old standard was not to have
the compiler do table size checking. Until recently, we had code to
get around table size limits - with fillers after the table which held
the rest of the table. That was subject to having an optimizer
break the code, but it never was any problem in real life. That
said, I was very glad when we were able to get rid of that construct.

Howard Brazee

2007-08-10, 6:55 pm

On Fri, 10 Aug 2007 09:54:26 +0300, Binyamin Dissen
<postingid@dissensoftware.com> wrote:

>Perhaps some folk need training wheels - a real programmer will do his own
>bounds checking.

In real life, memory leaks are a huge problem. Requiring that all
programmers be "real programmers" is not a real solution.

I knew someone who was creating a class on debugging, and he purposely
created a bounds error - but got a data exception (SOC-7). It seems
that his out-of-bounds change hit program memory instead of data
memory.

Frank Swarbrick

2007-08-10, 6:55 pm

>>> On 8/10/2007 at 9:51 AM, in message
<h02pb3psoiov1v33fi63o7s1l3fum2i390@4ax.com>, Howard
Brazee<howard@brazee.net> wrote:
> On Thu, 9 Aug 2007 17:00:33 -0600, "Frank Swarbrick"
> <Frank.Swarbrick@efirstbank.com> wrote:
>
> to
>
> I like to have all of those type of comparisons with ">" instead of
> "=", so I can see that mistake.

Yeah, I could have restructured it a bit to get this:

MOVE 1 TO FF-SUB2
PERFORM VARYING FF-SUB1 FROM 1 BY 1
UNTIL FF-SUB1 > 14
OR FF-SUB2 > 6
IF WIREMNT-FREE-FORM-TYPE (FF-SUB1) = 'OBI'
OR 'SVC'
MOVE WIREMNT-FREE-FORM-TEXT (FF-SUB1)
TO OBI-INFO-TEXT (FF-SUB2)
ADD +1 TO FF-SUB2
END-IF
END-PERFORM

But I decided to change just one line instead of two.

> I often make my subscript sizes into "constants", to make it easier
> for maintenance programmers to catch that they need to be changed when
> they change table sizes. I suppose I could be paranoid and code in a
> check to see if the table is the size I think it is - but I have only
> done that with database records.

I do this sometimes. Occasionally even do calculation by dividing the
length of the table by the length of a single occurrence. That's the
safest, since you don't have to remember to change anything else when you
change the number of occurrences.

What I usually do now, though obviously not when I wrote the program above,
is something like:

REPLACE ==:ME-MAX:== BY ==10==.

01 MY-TABLE.
05 MY-ENTRIES OCCURS :ME-MAX: TIMES
INDEXED BY ME-IDX.
10 ME-SOMETHING PIC X.
10 ME-SOMETHING-ELSE PIC X(10).

PERFORM VARYING ME-IDX FROM 1 BY 1 UNTIL ME-IDX > :ME-MAX:
...
END-PERFORM

Hmm, I think we discussed exactly this just a few months ago. :-)

Frank

Roger While

2007-08-11, 7:55 am

But don't we miss the 78 level in the standard :-)
(Yes, it can be done in other ways)
78 MAX-OCCS VALUE 6.

..... OCCURS MAX-OCCS ....

IF .. > MAX-OCCS

One place to change; no code checking necessary
(except if you screewed the IF)

Roger

William M. Klein

2007-08-12, 3:55 am

Of course 78-levels are not part of "Standard COBOL" - and the OP was talking
about IBM Enterprise COBOL (or VSE COBOL) where there are not
- 78 levels
- '02 Standard Constants
or
- the (old) Constant Section

--
Bill Klein
wmklein <at> ix.netcom.com
"Roger While" <simrw@sim-basis.de> wrote in message
news:f9k9bd$k8t$03$1@news.t-online.com...
> But don't we miss the 78 level in the standard :-)
> (Yes, it can be done in other ways)
> 78 MAX-OCCS VALUE 6.
>
> .... OCCURS MAX-OCCS ....
>
> IF .. > MAX-OCCS
>
> One place to change; no code checking necessary
> (except if you screewed the IF)
>
> Roger
>

Frank Swarbrick

2007-08-13, 6:55 pm

>>> On 8/11/2007 at 6:16 AM, in message
<f9k9bd$k8t$03$1@news.t-online.com>,
Roger While<simrw@sim-basis.de> wrote:
> But don't we miss the 78 level in the standard :-)
> (Yes, it can be done in other ways)
> 78 MAX-OCCS VALUE 6.
>
> .... OCCURS MAX-OCCS ....
>
> IF .. > MAX-OCCS
>
> One place to change; no code checking necessary
> (except if you screewed the IF)

Yep, except my compiler does not support that.

I believe the standard offers something similar.

01 MAX-OCCS CONSTANT AS 6.

Of course my compiler does not support that either...

Does remind me of an OpenCobol program I wrote recently, where I still had
to resort to a REPLACE statement:

program-id. x937cvt.
environment division.
replace ==:MAX-LEN:== by ==100000==.

input-output section.
file-control.
select x937in-file
organization sequential
assign to x937in-file-name.

select x937out-file
organization sequential
assign to x937out-file-name.

data division.
file section.
fd x937in-file
record varying from 1 to :MAX-LEN:
depending on inreclen.
01 x937inrec.
05 pic x occurs 1 to :MAX-LEN: times
depending on inreclen.
01 x937inrec-fixed-area.
05 x937inrec-type
pic x(2).
05 pic x(78).

fd x937out-file
record varying from 1 to :MAX-LEN:
depending on outreclen.
01 x937outrec.
05 pic x occurs 1 to :MAX-LEN: times
depending on outreclen.

working-storage section.
78 MAX-LEN value :MAX-LEN:.
78 MAX-SAVE value 6.
77 x937in-file-name pic x(80).
77 x937out-file-name pic x(80).
77 inreclen binary-long unsigned.
77 outreclen binary-long unsigned.
77 rec-in-count binary-long unsigned.
77 pic x value 'N'.
88 at-end value 'Y'
false 'N'.
77 in-rectype pic x(2).
88 file-header value '01'.
88 bundle-header value '20'.
88 debit-detail value '25'.
88 credit-detail value '61'.
88 bundle-control value '70'.
77 pic x value 'N'.
88 save-credits value 'Y'
false 'N'.
77 out-rectype pic x(2).

01 saved-items-table.
05 saved-item-cnt binary-long value zero.
05 saved-item occurs MAX-SAVE times
indexed by sidx.
10 saved-item-len
binary-long unsigned.
10 saved-item-rec.
15 saved-item-rectype
pic x(2).
15 pic x(MAX-LEN).

The constants are defined in working-storage and therefore (I assume) can
not be used in the file section.

[...minutes later...]

Just tried something, a little funky, but seems to work:

program-id. x937cvt.
environment division.
input-output section.
file-control.
select dummy-file assign to dummy.

select x937in-file
organization sequential
assign to x937in-file-name.

select x937out-file
organization sequential
assign to x937out-file-name.

data division.
file section.
* dummy-file declared only so some constant entries
* can be defined in the file section.
fd dummy-file.
78 MAX-LEN value 100000.
78 MAX-SAVE value 6.

fd x937in-file
record varying from 1 to MAX-LEN
depending on inreclen.
01 x937inrec.
05 pic x occurs 1 to MAX-LEN times
depending on inreclen.
01 x937inrec-fixed-area.
05 x937inrec-type
pic x(2).
05 pic x(78).

fd x937out-file
record varying from 1 to MAX-LEN
depending on outreclen.
01 x937outrec.
05 pic x occurs 1 to MAX-LEN times
depending on outreclen.

Too bad that the constant can't be defined outside of a file description
entry, but the standard seems to have this restriction as well.

Frank

Rick Smith

2007-08-13, 6:55 pm

"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:46C027A1.6F0F.0085.0@efirstbank.com...
[snip]
> Just tried something, a little funky, but seems to work:
[snip]
> data division.
> file section.
> * dummy-file declared only so some constant entries
> * can be defined in the file section.
> fd dummy-file.
> 78 MAX-LEN value 100000.
> 78 MAX-SAVE value 6.
>
> fd x937in-file
> record varying from 1 to MAX-LEN
> depending on inreclen.
> 01 x937inrec.
> 05 pic x occurs 1 to MAX-LEN times
> depending on inreclen.
> 01 x937inrec-fixed-area.
> 05 x937inrec-type
> pic x(2).
> 05 pic x(78).
>
> fd x937out-file
> record varying from 1 to MAX-LEN
> depending on outreclen.
> 01 x937outrec.
> 05 pic x occurs 1 to MAX-LEN times
> depending on outreclen.
>
> Too bad that the constant can't be defined outside of a file description
> entry, but the standard seems to have this restriction as well.

What was done in the standard is very inconvenient for
the programmer; but it is not, unfortunately, a material
defect. The same problem exists for both constant-entries
and typedefs. Even the DEFINE directive is of no help.

I think it is past time to restore the CONSTANT
SECTION as the location of choice for global constants
and typedefs.

Howard Brazee

2007-08-13, 6:55 pm

On Mon, 13 Aug 2007 12:46:47 -0400, "Rick Smith" <ricksmith@mfi.net>
wrote:

>I think it is past time to restore the CONSTANT
>SECTION as the location of choice for global constants
>and typedefs.

And allow those constants to be used in the OCCURS clause.

Frank Swarbrick

2007-08-13, 6:55 pm

>>> On 8/13/2007 at 10:46 AM, in message
<13c12vgjujfrc9@corp.supernews.com>,
Rick Smith<ricksmith@mfi.net> wrote:

> "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
> news:46C027A1.6F0F.0085.0@efirstbank.com...
> [snip]
> [snip]
>
> What was done in the standard is very inconvenient for
> the programmer; but it is not, unfortunately, a material
> defect. The same problem exists for both constant-entries
> and typedefs. Even the DEFINE directive is of no help.
>
> I think it is past time to restore the CONSTANT
> SECTION as the location of choice for global constants
> and typedefs.

I'd never even heard of the "CONSTANT SECTION" before Bill Klein mentioned
it, but it sounds like a good idea to me! Anyone know why it went away in
the first place? I assume this was prior to the 1974 standard, since I
don't think the 1974 era mainframe compilers even supported it.\

What was the format of this section, anyway?

Frank

Rick Smith

2007-08-13, 6:55 pm

"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:46C04743.6F0F.0085.0@efirstbank.com...
> <13c12vgjujfrc9@corp.supernews.com>,
> Rick Smith<ricksmith@mfi.net> wrote:
[snip]
>
> I'd never even heard of the "CONSTANT SECTION" before Bill Klein mentioned
> it, but it sounds like a good idea to me! Anyone know why it went away in
> the first place? I assume this was prior to the 1974 standard, since I
> don't think the 1974 era mainframe compilers even supported it.\

According to an article on CODASYL COBOL, the
recommendation for deletion of the CONSTANT
SECTION was made in 1969; but this may have been
because it was never included in ANSI COBOL 68.

> What was the format of this section, anyway?

I don't know, never having seen it in a program.

William M. Klein

2007-08-13, 6:55 pm

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:13c12vgjujfrc9@corp.supernews.com...
>
> "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
> news:46C027A1.6F0F.0085.0@efirstbank.com...
<snip>
>
> I think it is past time to restore the CONSTANT
> SECTION as the location of choice for global constants
> and typedefs.
>

Rick,
Not that I think what is and is not in the Standard has much impact on anyone,
can you tell me what you think is bad about the DRAFT Standard definition for
Constants? This allows for "elementary" items or records to be defined as
constants. (See the CONSTANT RECORD clause in WD 1.7)

--
Bill Klein
wmklein <at> ix.netcom.com

Rick Smith

2007-08-13, 9:55 pm

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:dt2wi.205221$ss3.140750@fe01.news.easynews.com...
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:13c12vgjujfrc9@corp.supernews.com...
>
> Rick,
> Not that I think what is and is not in the Standard has much impact on
anyone,
> can you tell me what you think is bad about the DRAFT Standard definition
for
> Constants? This allows for "elementary" items or records to be defined as
> constants. (See the CONSTANT RECORD clause in WD 1.7)

With respect to the definition of constants, nothing, I
know of, is bad and the problem is unrelated to the
CONSTANT RECORD clause.

The problem occurs when including application-wide
constants and typedefs in every program, function,
method, and class definition that uses them. When
these constants and typedefs are copied into the source,
the only "safe" place, to put the COPY statement, is prior
to the record definition for the first file in the file section,
unless there are no files. A CONSTANT SECTION,
immediately following the DATA DIVISION header,
would provide a "safe", consistent and well-understood
place for such a COPY statement.

William M. Klein

2007-08-14, 3:57 am

Rick,
Is there some place that prohibits "forward references" to constant-names in
either the '02 Standard or the draft of the next one? This is a serious
question - as I was wondering about it for an interpretation that I did. As far
as I can tell (when I looked - and I haven't looked again) you can define a
Constant in the Working-Storage section and use that name in the Special-Names
paragraph. There are rules about "circular" references, but I don't remember
finding any "forward reference" prohibitions.

--
Bill Klein
wmklein <at> ix.netcom.com
"Rick Smith" <ricksmith@mfi.net> wrote in message
news:13c1u70s8s3gvfc@corp.supernews.com...
>
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:dt2wi.205221$ss3.140750@fe01.news.easynews.com...
> anyone,
> for
>
> With respect to the definition of constants, nothing, I
> know of, is bad and the problem is unrelated to the
> CONSTANT RECORD clause.
>
> The problem occurs when including application-wide
> constants and typedefs in every program, function,
> method, and class definition that uses them. When
> these constants and typedefs are copied into the source,
> the only "safe" place, to put the COPY statement, is prior
> to the record definition for the first file in the file section,
> unless there are no files. A CONSTANT SECTION,
> immediately following the DATA DIVISION header,
> would provide a "safe", consistent and well-understood
> place for such a COPY statement.
>
>
>

William M. Klein

2007-08-14, 3:57 am

(replying to myself)

I should have mentioned that I *know* that the '02 Standard has places where you
need "forward references". For example, the SELECT/USING structure. Also, I
am almost positive that TYPEDEFs do not need appear physically in the source
code before they are used.

Now, if the question of whether this is "good" (easy to maintain) coding is
another question. I suspect that having a CONSTANT SECTION where all of this
"scuff" is together would be more (maintenance) programmer friendly - and that
may have been what you were saying and I just missed it.

--
Bill Klein
wmklein <at> ix.netcom.com
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:N6awi.448183$LL7.77458@fe08.news.easynews.com...
> Rick,
> Is there some place that prohibits "forward references" to constant-names in
> either the '02 Standard or the draft of the next one? This is a serious
> question - as I was wondering about it for an interpretation that I did. As
> far as I can tell (when I looked - and I haven't looked again) you can define
> a Constant in the Working-Storage section and use that name in the
> Special-Names paragraph. There are rules about "circular" references, but I
> don't remember finding any "forward reference" prohibitions.
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:13c1u70s8s3gvfc@corp.supernews.com...
>
>

Pete Dashwood

2007-08-14, 7:55 am

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:13c19vgrto2dv9d@corp.supernews.com...
>
> "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
> news:46C04743.6F0F.0085.0@efirstbank.com...
> [snip]
>
> According to an article on CODASYL COBOL, the
> recommendation for deletion of the CONSTANT
> SECTION was made in 1969; but this may have been
> because it was never included in ANSI COBOL 68.
>
>
> I don't know, never having seen it in a program.
>

It was very simple...

following WORKING-STORAGE...

CONSTANT SECTION.

01 some-constant pic <whatever, exactly as in WS>
77 some-other-constant pic <whatever, exactly as in WS>

I used it quite a bit just to document fields that did not get changed by
the program (READ-ONLY, if you like.)

As the facilities in it were also available through WS, it was considered
redundant and removed.

I don't think anyone was thinking in terms of typedefs at the time...:-)

I agree with you, it would be nice to see it back, especially if 78 levels
were implemented.

(Don't hold your breath... :-))

Pete.

--
"I used to write COBOL...now I can do anything."

Rick Smith

2007-08-14, 7:55 am

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:sbawi.212706$u82.113159@fe09.news.easynews.com...
> (replying to myself)
>
> I should have mentioned that I *know* that the '02 Standard has places
where you
> need "forward references". For example, the SELECT/USING structure.
Also, I
> am almost positive that TYPEDEFs do not need appear physically in the
source
> code before they are used.
>
> Now, if the question of whether this is "good" (easy to maintain) coding
is
> another question. I suspect that having a CONSTANT SECTION where all of
this
> "scuff" is together would be more (maintenance) programmer friendly - and
that[color=darkred]
> may have been what you were saying and I just missed it.
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:N6awi.448183$LL7.77458@fe08.news.easynews.com...
constant-names in[color=darkred]
As[color=darkred]
define[color=darkred]
but I[color=darkred]

[snip]

FDIS ISO/IEC 1989:2002, page 1, 1 Scope,
"This International Standard does not specify:

- The means whereby a compilation group written in
COBOL is compiled into code executable by a
processor.
...."

--, page 29, 7 Compiler directing facility,
"The compilation stage completes the compilation
process utilizing the structured compilation group."

There is nothing in the respective sections of the
standard that prohibits forward references for at least
these three items: constant-names, typedefs, and the
object of a SAME AS clause. [These are not mere
references; but affect the size of the item containing
the reference.]

The question is: Are such forward references permitted?

The answer is: No.

Forward references, for the above items, require a
non-sequential "means" for processing the "structured
compilation group". Requiring a particular "means" is not
within the scope of the standard.

Requiring the above items to be defined before they are
referenced, has no apparent effect on the "means whereby
a compilation group written in COBOL is compiled ...."

At least, that's how I see it!

Clark F Morris

2007-08-14, 6:55 pm

On Tue, 14 Aug 2007 21:16:12 +1200, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>
>
>"Rick Smith" <ricksmith@mfi.net> wrote in message
>news:13c19vgrto2dv9d@corp.supernews.com...
>
>It was very simple...
>
>following WORKING-STORAGE...
>
>CONSTANT SECTION.
>
>01 some-constant pic <whatever, exactly as in WS>
>77 some-other-constant pic <whatever, exactly as in WS>
>
>I used it quite a bit just to document fields that did not get changed by
>the program (READ-ONLY, if you like.)
>
>As the facilities in it were also available through WS, it was considered
>redundant and removed.

At the time I agreed with the removal not even having a clue about the
concept of reentrant code and the initialization savings a CONSTANT
SECTION would allow.
>
>I don't think anyone was thinking in terms of typedefs at the time...:-)
>
>I agree with you, it would be nice to see it back, especially if 78 levels
>were implemented.
>
>(Don't hold your breath... :-))
>
>Pete.

William M. Klein

2007-08-22, 3:55 am

Rick,
I remember discussion (during the '02 Standard development) about "single pass
compilers". My memory is that there is no requirement in the current standard
that such be "supported" (or even allowed). If you really cared, you could
submit an interpretation request, but I certainly do think that those who have
"constants" now (any format) allow forward references - and I am also 99%
certain that MF (for example) allows forward references for typedefs.

--
Bill Klein
wmklein <at> ix.netcom.com
"Rick Smith" <ricksmith@mfi.net> wrote in message
news:13c34ih2h8d0m9b@corp.supernews.com...
>
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:sbawi.212706$u82.113159@fe09.news.easynews.com...
> where you
> Also, I
> source
> is
> this
> that
> constant-names in
> As
> define
> but I
>
> [snip]
>
> FDIS ISO/IEC 1989:2002, page 1, 1 Scope,
> "This International Standard does not specify:
>
> - The means whereby a compilation group written in
> COBOL is compiled into code executable by a
> processor.
> ..."
>
> --, page 29, 7 Compiler directing facility,
> "The compilation stage completes the compilation
> process utilizing the structured compilation group."
>
> There is nothing in the respective sections of the
> standard that prohibits forward references for at least
> these three items: constant-names, typedefs, and the
> object of a SAME AS clause. [These are not mere
> references; but affect the size of the item containing
> the reference.]
>
> The question is: Are such forward references permitted?
>
> The answer is: No.
>
> Forward references, for the above items, require a
> non-sequential "means" for processing the "structured
> compilation group". Requiring a particular "means" is not
> within the scope of the standard.
>
> Requiring the above items to be defined before they are
> referenced, has no apparent effect on the "means whereby
> a compilation group written in COBOL is compiled ...."
>
> At least, that's how I see it!
>
>
>

Rick Smith

2007-08-23, 3:55 am

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:2QPyi.2107$fh4.476@fe01.news.easynews.com...
> Rick,
> I remember discussion (during the '02 Standard development) about
"single pass
> compilers". My memory is that there is no requirement in the current
standard
> that such be "supported" (or even allowed). If you really cared, you
could
> submit an interpretation request, but I certainly do think that those who
have[color=darkred]
> "constants" now (any format) allow forward references - and I am also 99%
> certain that MF (for example) allows forward references for typedefs.
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:13c34ih2h8d0m9b@corp.supernews.com...
coding[color=darkred]
of[color=darkred]
and[color=darkred]
serious[color=darkred]
did.[color=darkred]
can[color=darkred]
references,[color=darkred]

Given the following code (numbered lines have forward
references):

01 A.
02 D PIC X.
1 02 E SAME AS E OF B.
01 B.
02 D PIC 9.
2 02 E TYPE TO C.
3 01 C TYPEDEF PIC X(PIC-SIZE).
01 PIC-SIZE CONSTANT 9.

The errors I would expect for each is a message indicating
that the referenced items: E OF B, C, and PIC-SIZE,
respectively, are undefined; because the compiler can not
apply the appropriate rules. Note that in each case, the rules
that apply are general rules, not syntax rules; that is, rules that
specify the action required by the compiler when it encounters
the respective elements: the SAME AS clause, TYPE clause,
and constant-name. [For comparison, it is the general rules in
the COPY statement and the REPLACE statement that
specify actions to be taken by the compiler.]

Reverse the sequence of the level-number 1 items and the
problem goes away.

Note, also, that references in the environment division to
data-names use syntax rules that do not apply until the
data-name is defined (or need not be applied until the end
of the data division).

William M. Klein

2007-08-25, 3:55 am

Rick,
You may expect such messages (or the possibility of such messages), but I do
not believe that the designers of the '02 Standard would consider a compiler
issuing such messages to be "conforming". Again, this is MY understanding (and
the lack of any explicit syntax rule seems to confirm it). If you disagree, you
certainly could submit an interpretation request - or wait until there is a
compiler claiming to conform to the '02 Standard.

--
Bill Klein
wmklein <at> ix.netcom.com
"Rick Smith" <ricksmith@mfi.net> wrote in message
news:13cqhb08ttqa331@corp.supernews.com...
>
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:2QPyi.2107$fh4.476@fe01.news.easynews.com...
> "single pass
> standard
> could
> have
> coding
> of
> and
> serious
> did.
> can
> references,
>
>
> Given the following code (numbered lines have forward
> references):
>
> 01 A.
> 02 D PIC X.
> 1 02 E SAME AS E OF B.
> 01 B.
> 02 D PIC 9.
> 2 02 E TYPE TO C.
> 3 01 C TYPEDEF PIC X(PIC-SIZE).
> 01 PIC-SIZE CONSTANT 9.
>
> The errors I would expect for each is a message indicating
> that the referenced items: E OF B, C, and PIC-SIZE,
> respectively, are undefined; because the compiler can not
> apply the appropriate rules. Note that in each case, the rules
> that apply are general rules, not syntax rules; that is, rules that
> specify the action required by the compiler when it encounters
> the respective elements: the SAME AS clause, TYPE clause,
> and constant-name. [For comparison, it is the general rules in
> the COPY statement and the REPLACE statement that
> specify actions to be taken by the compiler.]
>
> Reverse the sequence of the level-number 1 items and the
> problem goes away.
>
> Note, also, that references in the environment division to
> data-names use syntax rules that do not apply until the
> data-name is defined (or need not be applied until the end
> of the data division).
>
>
>

Rick Smith

2007-08-25, 7:55 am

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:izPzi.6595$SB3.5422@fe03.news.easynews.com...
> Rick,
> You may expect such messages (or the possibility of such messages), but
I do
> not believe that the designers of the '02 Standard would consider a
compiler
> issuing such messages to be "conforming". Again, this is MY understanding
(and
> the lack of any explicit syntax rule seems to confirm it). If you
disagree, you
> certainly could submit an interpretation request - or wait until there is
a
> compiler claiming to conform to the '02 Standard.

-----
FDIS ISO/IEC 1989:2002, page 3, 3.1.1 Acceptance
of standard language elements,
"An implementation shall accept the syntax and provide
the functionality for all standard language elements required
by this International Standard and the optional or
processor-dependent language elements for which support
is claimed.

An implementation shall provide a warning mechanism that
optionally can be invoked by the user at compile time to
indicate violations of the general formats and the explicit
syntax rules of standard COBOL. This warning mechanism
shall provide a suboption for selection or suppression of
checking for violations of the set of conformance rules
specified in 14.7, Conformance for parameters and returning
items, and in 9.3.7.1.2, Conformance between interfaces.

There are rules in standard COBOL that are not identified
as general formats or syntax rules, but nevertheless specify
elements that are syntactically distinguishable. This warning
mechanism shall indicate violations of such rules. For elements
not specified in general formats or in explicit syntax rules, it is
left to the implementor's judgement to determine what is
syntactically distinguishable.

There are general rules in standard COBOL that could have
been classified as syntax rules. These rules are classified as
general rules for the purpose of avoiding syntax checking,
and do not reflect errors in standard COBOL. An
implementation may, but is not required to, flag violations of
such rules."
-----

With specific reference to the last sentence of the third
paragraph, above; in my judgement, the use of a
constant-name is not "syntactically distinguishable" until its
constant-entry is defined. This is a direct consequence of
the explicit general rules for 13.9, Constant entry.
Furthermore, as a consequence of the second sentence
of the third paragraph, above, I not only expect a warning
message; but, were I an implementor, I would be obligated
to provide it!

In other words, the lack of an explicit syntax rule (or rules)
"requiring" forward references for constant-names, means the
implementor's judgement prevails; not interpretation based on
belief in intent. If you disagree, you could submit a defect
report to add such an explicit syntax rule. <G>

Alistair

2007-08-25, 6:55 pm

On 23 Aug, 09:26, "Rick Smith" <ricksm...@mfi.net> wrote:
> "William M. Klein" <wmkl...@nospam.netcom.com> wrote in messagenews:2QPyi.2107$fh4.476@fe01.news.easynews.com...
>
>
>
>
>
> "single pass
> standard
> could
> have
>
>
>
>
> coding
> of
> and
>
> serious
> did.
> can
> references,
>
>
>
>
>
>
>
>
>
>
>
> Given the following code (numbered lines have forward
> references):
>
> 01 A.
> 02 D PIC X.
> 1 02 E SAME AS E OF B.
> 01 B.
> 02 D PIC 9.
> 2 02 E TYPE TO C.
> 3 01 C TYPEDEF PIC X(PIC-SIZE).
> 01 PIC-SIZE CONSTANT 9.
>
> The errors I would expect for each is a message indicating
> that the referenced items: E OF B, C, and PIC-SIZE,
> respectively, are undefined; because the compiler can not
> apply the appropriate rules.

That would assume that the compiler is a single-pass compiler. IIRC,
even the S/370 Assembler takes two passes to assemble code correctly
and it would not be too much for a compiler to reach a forward
reference and READ FORWARD from that point to resolve the issue.

Rick Smith

2007-08-25, 6:55 pm

"Alistair" <alistair@ld50macca.demon.co.uk> wrote in message
news:1188047337.835940.89460@x35g2000prf.googlegroups.com...
> On 23 Aug, 09:26, "Rick Smith" <ricksm...@mfi.net> wrote:
messagenews:2QPyi.2107$fh4.476@fe01.news.easynews.com...[color=darkred]
who[color=darkred]
99%[color=darkred]

[snip]
[color=darkred]
>
> That would assume that the compiler is a single-pass compiler. IIRC,
> even the S/370 Assembler takes two passes to assemble code correctly
> and it would not be too much for a compiler to reach a forward
> reference and READ FORWARD from that point to resolve the issue.

I make no such assumption!

The following could be done:
Pass 1: Produce logically-converted compilation group
Pass 2: Produce expanded compilation group
Pass 3. Produce conditionally-processed compilation group
Pass 4: Produce structured compilation group
Pass 5: Produce intermediate code
Pass 6: Optimization
Pass 7: Produce object code
Pass 8: Produce source listing
Pass 9: Produce cross-reference listing
Pass 10: Produce assembler listing

It is during Pass 5 that syntax rules and those general rules
affecting compilation are applied. This is where the errors,
noted above, are recognized.

What you seem to be saying is that Pass 5, in this scenario,
could be written (i.e., "butchered" <g> ) to accommodate
certain forward references, while I find no explicit requirement
to treat them as forward references.

I see the following as practical equivalents:

(1)
01 item pic x(pic-size).
replace ==pic-size== by ==20==.
(2)
01 item pic x(pic-size).
01 pic-size constant 20.

And, in both cases, I see it as an error. Reverse the sequences
and both are valid. While the general rules for the REPLACE
statement and the constant-entry are very different, their end is
the same. Neither has, as far as I can tell, any explicit rule(s)
regarding forward references. Thus, to treat the first as an error;
but claim the second is valid is illogical.

William M. Klein

2007-08-26, 7:55 am

You still have NOT provided any rule that is not marked as a syntax rule or
general rule that explicitly prohibts "forward references". General Rules are
*NEVER* supposed to be "detected" at compile-time. (Well a vendor MAY detect a
logically invalid construct but is not required to).

Rick,
I think you are just trying to turn the Standard into saying something that it
simply doesn't. Have you tried Micro Focus' TYPEDEFs? (I have NOT). My guess
is that they allow foward references.

It doesn't sond (to me) as if I will convince you of either the INTENT (to allow
foward refences) or the rules of the '02 Standard. I *might* submit my own
interpretation request, but as I still see minimal signs of any implementor
actually IMPLEMENTING a fully conforming (to the '02 Standard) compiler, I don't
know what this would get either of us.

If you plan on submitting public review comments when the draft of the next
Standard comes out, you might want to mention this.

SR(1) of the CONSTANT entry seems pretty clear to me when it states,

"Constant-name-1 may be used anywhere that a format specifies a literal of the
class and category of constant-name-
1."

This is where I would expect a rule to exist that says, "previously defined in
the current source element" - if that was what was meant or intended.

--
Bill Klein
wmklein <at> ix.netcom.com
"Rick Smith" <ricksmith@mfi.net> wrote in message
news:13d0772t303f405@corp.supernews.com...
>
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:izPzi.6595$SB3.5422@fe03.news.easynews.com...
> I do
> compiler
> (and
> disagree, you
> a
>
> -----
> FDIS ISO/IEC 1989:2002, page 3, 3.1.1 Acceptance
> of standard language elements,
> "An implementation shall accept the syntax and provide
> the functionality for all standard language elements required
> by this International Standard and the optional or
> processor-dependent language elements for which support
> is claimed.
>
> An implementation shall provide a warning mechanism that
> optionally can be invoked by the user at compile time to
> indicate violations of the general formats and the explicit
> syntax rules of standard COBOL. This warning mechanism
> shall provide a suboption for selection or suppression of
> checking for violations of the set of conformance rules
> specified in 14.7, Conformance for parameters and returning
> items, and in 9.3.7.1.2, Conformance between interfaces.
>
> There are rules in standard COBOL that are not identified
> as general formats or syntax rules, but nevertheless specify
> elements that are syntactically distinguishable. This warning
> mechanism shall indicate violations of such rules. For elements
> not specified in general formats or in explicit syntax rules, it is
> left to the implementor's judgement to determine what is
> syntactically distinguishable.
>
> There are general rules in standard COBOL that could have
> been classified as syntax rules. These rules are classified as
> general rules for the purpose of avoiding syntax checking,
> and do not reflect errors in standard COBOL. An
> implementation may, but is not required to, flag violations of
> such rules."
> -----
>
> With specific reference to the last sentence of the third
> paragraph, above; in my judgement, the use of a
> constant-name is not "syntactically distinguishable" until its
> constant-entry is defined. This is a direct consequence of
> the explicit general rules for 13.9, Constant entry.
> Furthermore, as a consequence of the second sentence
> of the third paragraph, above, I not only expect a warning
> message; but, were I an implementor, I would be obligated
> to provide it!
>
> In other words, the lack of an explicit syntax rule (or rules)
> "requiring" forward references for constant-names, means the
> implementor's judgement prevails; not interpretation based on
> belief in intent. If you disagree, you could submit a defect
> report to add such an explicit syntax rule. <G>
>
>
>

Rick Smith

2007-08-26, 7:55 am

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:oMbAi.152024$sR4.54373@fe08.news.easynews.com...
> You still have NOT provided any rule that is not marked as a syntax rule
or
> general rule that explicitly prohibts "forward references". General Rules
are
> *NEVER* supposed to be "detected" at compile-time. (Well a vendor MAY
detect a
> logically invalid construct but is not required to).

Yet, the items: SAME AS clause, TYPEDEF clause,
and contant-entry; have general rules but no runtime
behavior!

> Rick,
> I think you are just trying to turn the Standard into saying something
that it
> simply doesn't. Have you tried Micro Focus' TYPEDEFs? (I have NOT). My
guess
> is that they allow foward references.

Micro Focus COBOL 3.2 does not allow forward
references; but that version is from 1994. I don't
know what is done currently, though I suspect and
hope it is the same.
-----
* Micro Focus COBOL Version 3.2.24 [...] 26-Aug-07 06:35 Page 1
* C:\CBL-CHAL\A27B17.CBL
* Options: WB ERRQ EDITOR(MF) LIST() NOOSVS ANS85
1 program-id. A27B17.
2 data division.
3 01 item-1 pic x(pic-size).
* 230-S************************* [...] ( 0)**
** PICTURE string has illegal precedence or illegal character
4 78 pic-size value 20.
5
6 01 item-2 uint.
* 233-S************** [...] ( 1)**
** Unknown data description qualifier
7 01 uint typedef pic 9(9) comp-5.
8
9 01 item-3 pic x(pic-size).
10
11 01 item-4 uint.
* Micro Focus COBOL Version 3.2.24 L2.5 revision 000
* Last message on page: 1
*
* Total Messages: 2
* Unrecoverable : 0 Severe : 2
* Errors : 0 Warnings: 0
* Informational : 0 Flags : 0
* Data: 524 Code: 57
-----

> It doesn't sond (to me) as if I will convince you of either the INTENT (to
allow
> foward refences) or the rules of the '02 Standard. I *might* submit my own
> interpretation request, but as I still see minimal signs of any
implementor
> actually IMPLEMENTING a fully conforming (to the '02 Standard) compiler, I
don't
> know what this would get either of us.

I have had the unfortunate experience of leaning too
late that errors of omission do occur with intellegent,
well-educated, knowledgeable, and sincere people.
In this case, conformance is to the written standard;
not to unstated intent; thus, intent (or belief in intent)
has no weight, while the result of an interpretation
request would have weight if, and only if, it reveals
an error of omission.

> If you plan on submitting public review comments when the draft of the
next
> Standard comes out, you might want to mention this.
>
> SR(1) of the CONSTANT entry seems pretty clear to me when it states,
>
> "Constant-name-1 may be used anywhere that a format specifies a literal of
the
> class and category of constant-name-
> 1."
>
> This is where I would expect a rule to exist that says, "previously
defined in
> the current source element" - if that was what was meant or intended.

This is where I would expect a note (statement of intent)
to the effect that the rule permits forward references.
But, I am relying on GR(1),

"If literal-1 or compilation-variable-name-1 is specified,
the effect of specifying constant-name-1 in other than
this entry is as if literal-1 or the text represented by
compilation-variable-name-1 were written where
constant-name-1 is written."

And, the fact that it can not be applied until after the
constant-entry occurs in the source unit, as was
demonstrated in the program posted above.

Roger While

2007-08-27, 3:55 am

"Rick Smith" <ricksmith@mfi.net> schrieb im Newsbeitrag
news:13d2rm6ho25no66@corp.supernews.com...
>
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:oMbAi.152024$sR4.54373@fe08.news.easynews.com...
> or
> are
> detect a
>
> Yet, the items: SAME AS clause, TYPEDEF clause,
> and contant-entry; have general rules but no runtime
> behavior!
>
> that it
> guess
>
> Micro Focus COBOL 3.2 does not allow forward
> references; but that version is from 1994. I don't
> know what is done currently, though I suspect and
> hope it is the same.

MF SE up to and including 4.0 does the same.

Roger

> -----
> * Micro Focus COBOL Version 3.2.24 [...] 26-Aug-07 06:35 Page 1
> * C:\CBL-CHAL\A27B17.CBL
> * Options: WB ERRQ EDITOR(MF) LIST() NOOSVS ANS85
> 1 program-id. A27B17.
> 2 data division.
> 3 01 item-1 pic x(pic-size).
> * 230-S************************* [...] ( 0)**
> ** PICTURE string has illegal precedence or illegal character
> 4 78 pic-size value 20.
> 5
> 6 01 item-2 uint.
> * 233-S************** [...] ( 1)**
> ** Unknown data description qualifier
> 7 01 uint typedef pic 9(9) comp-5.
> 8
> 9 01 item-3 pic x(pic-size).
> 10
> 11 01 item-4 uint.
> * Micro Focus COBOL Version 3.2.24 L2.5 revision 000
> * Last message on page: 1
> *
> * Total Messages: 2
> * Unrecoverable : 0 Severe : 2
> * Errors : 0 Warnings: 0
> * Informational : 0 Flags : 0
> * Data: 524 Code: 57
> -----
>
> allow
> implementor
> don't
>
> I have had the unfortunate experience of leaning too
> late that errors of omission do occur with intellegent,
> well-educated, knowledgeable, and sincere people.
> In this case, conformance is to the written standard;
> not to unstated intent; thus, intent (or belief in intent)
> has no weight, while the result of an interpretation
> request would have weight if, and only if, it reveals
> an error of omission.
>
> next
> the
> defined in
>
> This is where I would expect a note (statement of intent)
> to the effect that the rule permits forward references.
> But, I am relying on GR(1),
>
> "If literal-1 or compilation-variable-name-1 is specified,
> the effect of specifying constant-name-1 in other than
> this entry is as if literal-1 or the text represented by
> compilation-variable-name-1 were written where
> constant-name-1 is written."
>
> And, the fact that it can not be applied until after the
> constant-entry occurs in the source unit, as was
> demonstrated in the program posted above.
>
>
>

Sponsored Links