Cobol - IBM S/390 memory model amd COBOL

Author

IBM S/390 memory model amd COBOL

ribjopabra@gmail.com

2005-05-18, 3:55 pm

Hello all,

I'm migrating IBM COBOL (OS390, DB2) to MF COBOL (HPUX, ORACLE) for a
client.
Now it's testing time and our client has a problem which I thought of
sharing with you.
I'm not a COBOL programmer, but as you, I am capable of reading the
algorithm.
This piece of code has a bug on line 35 and 36 (at least one...).
01 77 SUB1 PIC 9(03) VALUE ZERO.
02 77 SUB2 PIC 9(03) VALUE ZERO.
03 77 SUB3 PIC 9(03) VALUE ZERO.
04 01 WK-NAME.
05 03 WK-NAME1 PIC X(35) VALUE SPACES.
06 03 WK-NAME2 PIC X(35) VALUE SPACES.
07 01 TABELA-NAME VALUE SPACES.
08 03 TAB-NAME PIC X(01) OCCURS 60 TIMES.
09 01 WK-NAME-1 VALUE SPACES.
10 03 WK-NAME-11 PIC X(01) OCCURS 35 TIMES.
11 01 WK-NAME-2 VALUE SPACES.
12 03 WK-NAME-21 PIC X(01) OCCURS 35 TIMES.
13
*-----------------------------------------------------------------
14 R030-ANALIZE-NAME.
15 PERFORM VARYING SUB1 FROM 60 BY -1
16 UNTIL TAB-NAME(SUB1) NOT = SPACES OR SUB1 < 1
17 END-PERFORM
18 IF SUB1 < 36
19 MOVE TABELA-NAME TO WK-NAME
20 ELSE
21 IF (TAB-NAME(35) = SPACES OR TAB-NAME(36) = SPACES)
22 MOVE TABELA-NAME TO WK-NAME
23 ELSE
24 PERFORM VARYING SUB1 FROM 35 BY -1
25 UNTIL TAB-NAME(SUB1) = SPACES OR SUB1 < 21
26 END-PERFORM
27 IF SUB1 < 21
28 MOVE TABELA-NAME TO WK-NAME
29 ELSE
30 PERFORM VARYING SUB2 FROM 1 BY 1 UNTIL SUB2>SUB1
31 MOVE TAB-NAME(SUB2) TO WK-NAME-11(SUB2)
32 END-PERFORM
33 MOVE 1 TO SUB3
34 ADD 1 TO SUB1
35 PERFORM VARYING SUB2 FROM SUB1 BY 1 UNTIL SUB2>60
36 MOVE TAB-NAME(SUB2) TO WK-NAME-21(SUB3)
37 ADD 1 TO SUB3
38 END-PERFORM
39 MOVE WK-NAME-1 TO WK-NAME1
40 MOVE WK-NAME-2 TO WK-NAME2
41 MOVE SPACES TO WK-NAME-1 WK-NAME-2.

My question is: since the SUB3 goes beyond 35 in some cases of
TAB-NAME, it gives me segmentation fault on Unix. The client says it
runs well on OS390 but I cannot test this on OS390. Does this mean that
it has no memory protection?

Does OS390 and specially IBM COBOL allow for you to access memory
locations randomly and outside your declared size for the variable?

Thanks in advance.

Paulo Ribeiro

Chuck Stevens

2005-05-18, 3:55 pm

So far as I know, neither the '74 nor the '85 standard specifies what
happens if an index or subscript is outside the range permitted by the
associated OCCURS clause. Some implementors have options that strictly
enforce index and subscript values at run time, some don't. Code that
inadvertently or deliberately capitalizes on the ability to index or
subscript outside the array is inherently nonportable.

ISO/IEC 1989:2005 provides that the fatal EC-BOUND-SUBSCRIPT exception
condition is set to exist whenever a subscript is out of range on a
reference, or an attempt is made to set an index to a value that is out of
range.

-Chuck Stevens

<ribjopabra@gmail.com> wrote in message
news:1116427414.131266.308300@o13g2000cwo.googlegroups.com...
> Hello all,
>
> I'm migrating IBM COBOL (OS390, DB2) to MF COBOL (HPUX, ORACLE) for a
> client.
> Now it's testing time and our client has a problem which I thought of
> sharing with you.
> I'm not a COBOL programmer, but as you, I am capable of reading the
> algorithm.
> This piece of code has a bug on line 35 and 36 (at least one...).
> 01 77 SUB1 PIC 9(03) VALUE ZERO.
> 02 77 SUB2 PIC 9(03) VALUE ZERO.
> 03 77 SUB3 PIC 9(03) VALUE ZERO.
> 04 01 WK-NAME.
> 05 03 WK-NAME1 PIC X(35) VALUE SPACES.
> 06 03 WK-NAME2 PIC X(35) VALUE SPACES.
> 07 01 TABELA-NAME VALUE SPACES.
> 08 03 TAB-NAME PIC X(01) OCCURS 60 TIMES.
> 09 01 WK-NAME-1 VALUE SPACES.
> 10 03 WK-NAME-11 PIC X(01) OCCURS 35 TIMES.
> 11 01 WK-NAME-2 VALUE SPACES.
> 12 03 WK-NAME-21 PIC X(01) OCCURS 35 TIMES.
> 13
> *-----------------------------------------------------------------
> 14 R030-ANALIZE-NAME.
> 15 PERFORM VARYING SUB1 FROM 60 BY -1
> 16 UNTIL TAB-NAME(SUB1) NOT = SPACES OR SUB1 < 1
> 17 END-PERFORM
> 18 IF SUB1 < 36
> 19 MOVE TABELA-NAME TO WK-NAME
> 20 ELSE
> 21 IF (TAB-NAME(35) = SPACES OR TAB-NAME(36) = SPACES)
> 22 MOVE TABELA-NAME TO WK-NAME
> 23 ELSE
> 24 PERFORM VARYING SUB1 FROM 35 BY -1
> 25 UNTIL TAB-NAME(SUB1) = SPACES OR SUB1 < 21
> 26 END-PERFORM
> 27 IF SUB1 < 21
> 28 MOVE TABELA-NAME TO WK-NAME
> 29 ELSE
> 30 PERFORM VARYING SUB2 FROM 1 BY 1 UNTIL SUB2>SUB1
> 31 MOVE TAB-NAME(SUB2) TO WK-NAME-11(SUB2)
> 32 END-PERFORM
> 33 MOVE 1 TO SUB3
> 34 ADD 1 TO SUB1
> 35 PERFORM VARYING SUB2 FROM SUB1 BY 1 UNTIL SUB2>60
> 36 MOVE TAB-NAME(SUB2) TO WK-NAME-21(SUB3)
> 37 ADD 1 TO SUB3
> 38 END-PERFORM
> 39 MOVE WK-NAME-1 TO WK-NAME1
> 40 MOVE WK-NAME-2 TO WK-NAME2
> 41 MOVE SPACES TO WK-NAME-1 WK-NAME-2.
>
> My question is: since the SUB3 goes beyond 35 in some cases of
> TAB-NAME, it gives me segmentation fault on Unix. The client says it
> runs well on OS390 but I cannot test this on OS390. Does this mean that
> it has no memory protection?
>
> Does OS390 and specially IBM COBOL allow for you to access memory
> locations randomly and outside your declared size for the variable?
>
> Thanks in advance.
>
> Paulo Ribeiro
>

docdwarf@panix.com

2005-05-18, 3:55 pm

In article <1116427414.131266.308300@o13g2000cwo.googlegroups.com>,
ribjopabra@gmail.com <ribjopabra@gmail.com> wrote:

[snip]

>Does OS390 and specially IBM COBOL allow for you to access memory
>locations randomly and outside your declared size for the variable?

It used to be that in the Oldene Dayse before OS390 - ahhhhh, for the
Oldene Dayse, when a coder could code code such as *ten* coders cannot,
today! - some folks would depend on just this possibility to create and
address WORKING-STORAGE tables ('arrays') greater than 32K.

DD

Richard Maher

2005-05-18, 3:55 pm

Hi,

DEC COBOL has the /CHECK=(BOUNDS) compiler qualifier. Normally, for
debugging, you have it on. When you ship an image for production performance
you can take it off.

Regards Richard Maher

<ribjopabra@gmail.com> wrote in message
news:1116427414.131266.308300@o13g2000cwo.googlegroups.com...
> Hello all,
>
> I'm migrating IBM COBOL (OS390, DB2) to MF COBOL (HPUX, ORACLE) for a
> client.
> Now it's testing time and our client has a problem which I thought of
> sharing with you.
> I'm not a COBOL programmer, but as you, I am capable of reading the
> algorithm.
> This piece of code has a bug on line 35 and 36 (at least one...).
> 01 77 SUB1 PIC 9(03) VALUE ZERO.
> 02 77 SUB2 PIC 9(03) VALUE ZERO.
> 03 77 SUB3 PIC 9(03) VALUE ZERO.
> 04 01 WK-NAME.
> 05 03 WK-NAME1 PIC X(35) VALUE SPACES.
> 06 03 WK-NAME2 PIC X(35) VALUE SPACES.
> 07 01 TABELA-NAME VALUE SPACES.
> 08 03 TAB-NAME PIC X(01) OCCURS 60 TIMES.
> 09 01 WK-NAME-1 VALUE SPACES.
> 10 03 WK-NAME-11 PIC X(01) OCCURS 35 TIMES.
> 11 01 WK-NAME-2 VALUE SPACES.
> 12 03 WK-NAME-21 PIC X(01) OCCURS 35 TIMES.
> 13
> *-----------------------------------------------------------------
> 14 R030-ANALIZE-NAME.
> 15 PERFORM VARYING SUB1 FROM 60 BY -1
> 16 UNTIL TAB-NAME(SUB1) NOT = SPACES OR SUB1 < 1
> 17 END-PERFORM
> 18 IF SUB1 < 36
> 19 MOVE TABELA-NAME TO WK-NAME
> 20 ELSE
> 21 IF (TAB-NAME(35) = SPACES OR TAB-NAME(36) = SPACES)
> 22 MOVE TABELA-NAME TO WK-NAME
> 23 ELSE
> 24 PERFORM VARYING SUB1 FROM 35 BY -1
> 25 UNTIL TAB-NAME(SUB1) = SPACES OR SUB1 < 21
> 26 END-PERFORM
> 27 IF SUB1 < 21
> 28 MOVE TABELA-NAME TO WK-NAME
> 29 ELSE
> 30 PERFORM VARYING SUB2 FROM 1 BY 1 UNTIL SUB2>SUB1
> 31 MOVE TAB-NAME(SUB2) TO WK-NAME-11(SUB2)
> 32 END-PERFORM
> 33 MOVE 1 TO SUB3
> 34 ADD 1 TO SUB1
> 35 PERFORM VARYING SUB2 FROM SUB1 BY 1 UNTIL SUB2>60
> 36 MOVE TAB-NAME(SUB2) TO WK-NAME-21(SUB3)
> 37 ADD 1 TO SUB3
> 38 END-PERFORM
> 39 MOVE WK-NAME-1 TO WK-NAME1
> 40 MOVE WK-NAME-2 TO WK-NAME2
> 41 MOVE SPACES TO WK-NAME-1 WK-NAME-2.
>
> My question is: since the SUB3 goes beyond 35 in some cases of
> TAB-NAME, it gives me segmentation fault on Unix. The client says it
> runs well on OS390 but I cannot test this on OS390. Does this mean that
> it has no memory protection?
>
> Does OS390 and specially IBM COBOL allow for you to access memory
> locations randomly and outside your declared size for the variable?
>
> Thanks in advance.
>
> Paulo Ribeiro
>

ribjo

2005-05-18, 3:55 pm

That's it!

With NOBOUND directive I can ommit this ugly "feature" and the COBOL
runs fine.

Thank you very much!

Regards,
Paulo Ribeiro

William M. Klein

2005-05-18, 8:55 pm

I know that you have already received the BOUND/NOBOUND answer, but I thought I
would reply with a couple of comments:

1) Current IBM COBOL has an SSRANGE option which will detect "out-of-bounds"
subscripts.

2) For older (OS/VS COBOL) programs, the 3rd party CA-OPTIMIZER (aka "CAPEX")
also had a subscript checker.

3) The interesting (to me) issue with the ISO 2002 EC-BOUND-SUBSCRIPT condition
is that it *requires* checking for each level of a multi-level table being
correct - even if the "combination" leaves an item within a table, e.g.

05 Tabl.
10 Level-1 Occurs 10 times.
15 Level-2 Occurs 5 Times.
20 Elem Pic X.

Move "x" to Elem (1 6)

raises an EC-BOUND-SUBSCRIPT condition. However, neither the Micro Focus
BOUND/NOBOUND nor the IBM SSRANGE will have any problem with this. I do not
know what other vendors do with their (optional) '85 Standard detection
facilities.

4) One *SHOULD* write code to check for subscripts out-of-range and NOT "rely"
on NOBOUND, NOSSRANGE, etc techniques. As you see, these are not portable and
MAY change in a future release of your current compiler.

--
Bill Klein
wmklein <at> ix.netcom.com
<ribjopabra@gmail.com> wrote in message
news:1116427414.131266.308300@o13g2000cwo.googlegroups.com...
> Hello all,
>
> I'm migrating IBM COBOL (OS390, DB2) to MF COBOL (HPUX, ORACLE) for a
> client.
> Now it's testing time and our client has a problem which I thought of
> sharing with you.
> I'm not a COBOL programmer, but as you, I am capable of reading the
> algorithm.
> This piece of code has a bug on line 35 and 36 (at least one...).
> 01 77 SUB1 PIC 9(03) VALUE ZERO.
> 02 77 SUB2 PIC 9(03) VALUE ZERO.
> 03 77 SUB3 PIC 9(03) VALUE ZERO.
> 04 01 WK-NAME.
> 05 03 WK-NAME1 PIC X(35) VALUE SPACES.
> 06 03 WK-NAME2 PIC X(35) VALUE SPACES.
> 07 01 TABELA-NAME VALUE SPACES.
> 08 03 TAB-NAME PIC X(01) OCCURS 60 TIMES.
> 09 01 WK-NAME-1 VALUE SPACES.
> 10 03 WK-NAME-11 PIC X(01) OCCURS 35 TIMES.
> 11 01 WK-NAME-2 VALUE SPACES.
> 12 03 WK-NAME-21 PIC X(01) OCCURS 35 TIMES.
> 13
> *-----------------------------------------------------------------
> 14 R030-ANALIZE-NAME.
> 15 PERFORM VARYING SUB1 FROM 60 BY -1
> 16 UNTIL TAB-NAME(SUB1) NOT = SPACES OR SUB1 < 1
> 17 END-PERFORM
> 18 IF SUB1 < 36
> 19 MOVE TABELA-NAME TO WK-NAME
> 20 ELSE
> 21 IF (TAB-NAME(35) = SPACES OR TAB-NAME(36) = SPACES)
> 22 MOVE TABELA-NAME TO WK-NAME
> 23 ELSE
> 24 PERFORM VARYING SUB1 FROM 35 BY -1
> 25 UNTIL TAB-NAME(SUB1) = SPACES OR SUB1 < 21
> 26 END-PERFORM
> 27 IF SUB1 < 21
> 28 MOVE TABELA-NAME TO WK-NAME
> 29 ELSE
> 30 PERFORM VARYING SUB2 FROM 1 BY 1 UNTIL SUB2>SUB1
> 31 MOVE TAB-NAME(SUB2) TO WK-NAME-11(SUB2)
> 32 END-PERFORM
> 33 MOVE 1 TO SUB3
> 34 ADD 1 TO SUB1
> 35 PERFORM VARYING SUB2 FROM SUB1 BY 1 UNTIL SUB2>60
> 36 MOVE TAB-NAME(SUB2) TO WK-NAME-21(SUB3)
> 37 ADD 1 TO SUB3
> 38 END-PERFORM
> 39 MOVE WK-NAME-1 TO WK-NAME1
> 40 MOVE WK-NAME-2 TO WK-NAME2
> 41 MOVE SPACES TO WK-NAME-1 WK-NAME-2.
>
> My question is: since the SUB3 goes beyond 35 in some cases of
> TAB-NAME, it gives me segmentation fault on Unix. The client says it
> runs well on OS390 but I cannot test this on OS390. Does this mean that
> it has no memory protection?
>
> Does OS390 and specially IBM COBOL allow for you to access memory
> locations randomly and outside your declared size for the variable?
>
> Thanks in advance.
>
> Paulo Ribeiro
>

Richard

2005-05-18, 8:55 pm

> With NOBOUND directive I can ommit this ugly "feature" and the COBOL
> runs fine.

That may stop the program failing but it does not make it run 'fine'
nor even the same as the original code.

When 01 records are compiled there is no guarantee that they will be
continuous in the memory of the resulting program nor that they will
have any particular spatial relationship.

It is likely that on the original machine the two followed each other
in memory with just a single slack byte between. On some machines the
various 01 levels might not even be in the same memory segments. On
others it may be that additional variables or literal are put between
the 01 levels.

In particular some compilers, even if they put all 01s in the same
memory area, will place the 01 levels on 8 byte boundaries which would
put a 5 slack bytes between the two areas in question.

My best guess at the code is that it is dropping character 36 when this
is not space.

The results are likely to be wrong. You will be dropping an extra 4
characters of the text.

Allowing a program to overwrite random data items outside the defined
areas is danderous and foolish. The BOUND check is there for a reason,
to stop programmers making mistakes and to ensure that the program is
reliable.

Also: this is the wrong way around:

15 PERFORM VARYING SUB1 FROM 60 BY -1
16 UNTIL TAB-NAME(SUB1) NOT = SPACES OR SUB1 < 1
17 END-PERFORM

It should be:

16 UNTIL SUB1 < 1 OR TAB-NAME(SUB1) NOT = SPACES

Cobol will 'short circuit the test'. If SUB1 becomes zero the latter
version will result in TRUE before using a zero subscript. The version
in your code will fail when TableA-Name is all spaces because the zero
subscript will give a bound failure.

Richard

2005-05-18, 8:55 pm

> continuous in the memory

Should be 'contiguous' (obviously).

Michael Mattias

2005-05-18, 8:55 pm

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:y5Mie.273464$QY2.199422@fe01.news.easynews.com...
> I know that you have already received the BOUND/NOBOUND answer, but I
thought I
> would reply with a couple of comments:
>
> 1) Current IBM COBOL has an SSRANGE option which will detect
"out-of-bounds"
> subscripts.

Meaning.. "at runtime".. and your DUMP will tell even you the name of the
table upon which you have sinned - VERY handy..

BUT.....

From Experience: Using this option is an absolute performance KILLER.
Suggest you use ONLY to debug, then recompile without this option for
production after you've fixed your program.

MCM
..

ribjo

2005-05-19, 8:55 am

Richard,

Thanks for your help. I agree that memory is a delicate matter.
I am not the programmer here, I just deal with portability/migrating
the code.
Thanks for your eye on that bug!
I do not plan to recode the client's code :)

Regards

ribjo

2005-05-19, 8:55 am

I totally agree with you Bill, but since I am not the programmer, just
the migration engineer, I am not responsible for the code.

Thank you for your help.

Richard

2005-05-19, 8:55 pm

> I do not plan to recode the client's code :)

At least bump up the OCCURS 35 to 40.

The minuimum for SUB1 is 22 when the PERFORM to 60 is done, so the max
for SUB3 is 38.

Colin Campbell

2005-05-20, 3:55 am

ribjopabra@gmail.com wrote:

>Hello all,
>
>I'm migrating IBM COBOL (OS390, DB2) to MF COBOL (HPUX, ORACLE) for a
>client.
>Now it's testing time and our client has a problem which I thought of
>sharing with you.
>I'm not a COBOL programmer, but as you, I am capable of reading the
>algorithm.
>This piece of code has a bug on line 35 and 36 (at least one...).
>(code snipped)
>
>My question is: since the SUB3 goes beyond 35 in some cases of
>TAB-NAME, it gives me segmentation fault on Unix. The client says it
>runs well on OS390 but I cannot test this on OS390. Does this mean that
>it has no memory protection?
>
>Does OS390 and specially IBM COBOL allow for you to access memory
>locations randomly and outside your declared size for the variable?
>
>Thanks in advance.
>
>Paulo Ribeiro
>
>
>
The way the IBM COBOL compilers build a program results in some
COBOL-defined storage being generated after Working-Storage. Level 01
items start at a doubleword boundary. The generated storage starts at
the next doubleword boundary, so at least the locations indicated by
subscripts 36 through 40 are "undefined". I don't have a Programming
Guide manual handy to tell you what is at the start of the generated
storage; however, it belongs to the program to be used as the generated
code decides. (In other words, no protection exception will be
generated if an overflow condition in the subscript writes to it.) The
procedural code follows that storage.

Programs which have logic errors involving subscripts and/or index items
will often run successfully if an array is exceeded but the generated
storage is not. Sometimes, they will run for a while even if some of
the code in the Procedure Division is overwritten, but usually if the
code is written in a structured manner, there is code near the start
which is executed at the end of a program (like a STOP RUN, GOBACK, or
EXIT PROGRAM), so finally, most such programs fail. Of course, the data
that is written "out of bounds" can in some cases look like executable
instructions, leading to the possibility of really odd results.

You have uncovered badly written code. The way the mainframe compiler
builds programs let the programmer get away with the error. In my
opinion, the responsible programmer and supervisor ought to be thanking
you profusely, while trying to hide at least one very red face. Once
they have fixed their program, they can give it back to you to migrate
to the other platform. Of course, everyone makes mistakes, but
programming is about fixing them, not saying "It works on the
mainframe." What they really mean is "We didn't check the subscripts
properly, but we got away with it."

Richard Maher

2005-05-20, 3:55 pm

Hi Colin,

> Sometimes, they will run for a while even if some of
> the code in the Procedure Division is overwritten

I'm very surprised that that's the way it works with IBM. Is it just on MVS
the compilers do this or OS/400, AIX as well? What I'm use to seeing,
admittedly on non-IBM platform, is the compiler generating a Read-Only
Program Section for the code which subsequently gets built into a read-only
image section that would trigger an Access Violation if a dodgy pointer
tried to write to it.

Regards Richard Maher

"Colin Campbell" <cmcampb@adelphia.net> wrote in message
news:pq2dnfS_a__hxhDfRVn-jQ@adelphia.com...
> ribjopabra@gmail.com wrote:
>
> The way the IBM COBOL compilers build a program results in some
> COBOL-defined storage being generated after Working-Storage. Level 01
> items start at a doubleword boundary. The generated storage starts at
> the next doubleword boundary, so at least the locations indicated by
> subscripts 36 through 40 are "undefined". I don't have a Programming
> Guide manual handy to tell you what is at the start of the generated
> storage; however, it belongs to the program to be used as the generated
> code decides. (In other words, no protection exception will be
> generated if an overflow condition in the subscript writes to it.) The
> procedural code follows that storage.
>
> Programs which have logic errors involving subscripts and/or index items
> will often run successfully if an array is exceeded but the generated
> storage is not. Sometimes, they will run for a while even if some of
> the code in the Procedure Division is overwritten, but usually if the
> code is written in a structured manner, there is code near the start
> which is executed at the end of a program (like a STOP RUN, GOBACK, or
> EXIT PROGRAM), so finally, most such programs fail. Of course, the data
> that is written "out of bounds" can in some cases look like executable
> instructions, leading to the possibility of really odd results.
>
> You have uncovered badly written code. The way the mainframe compiler
> builds programs let the programmer get away with the error. In my
> opinion, the responsible programmer and supervisor ought to be thanking
> you profusely, while trying to hide at least one very red face. Once
> they have fixed their program, they can give it back to you to migrate
> to the other platform. Of course, everyone makes mistakes, but
> programming is about fixing them, not saying "It works on the
> mainframe." What they really mean is "We didn't check the subscripts
> properly, but we got away with it."
>

Michael Mattias

2005-05-20, 3:55 pm

"Richard Maher" <maher_rj@hotspamnotmail.com> wrote in message
news:d6kfmq$q4i$1@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com...
>
> I'm very surprised that that's the way [exceeding table bounds subscripts]
works with IBM. Is it just on MVS
> the compilers do this or OS/400, AIX as well?

It doesn't even "work" with the newer compilers... and as someone pointed
out in an earlier post in this thread, the deliberate use of 'table
overflow' was a 'generally known and used method' to create tables > 64K on
the eariler machines/compilers.

I do not have the documentation available, but IIRC the compiler documented
that working-storage was always created in a contiguous block (except for
any alignment bytes required) ; meaning this "table overflow" technique was
,if not formally supported, a logical extension of this 'contiguity' (is
that a word?).

The newer compilers/OSs introduced some optimizing techniques which meant
working-storage was no longer necessarily contiguous; but at the same time
the officially supported table sizes were increased.

What I'm saying here is, the use of this 'table overflow' technique on IBM
mainframes with the then-current compilers was hardly a mortal sin.

Of course, no one (guilty myself) ever commented their code that were
exploiting this contiguity.. which probably should qualify as a venial sin.

MCM

docdwarf@panix.com

2005-05-20, 3:55 pm

In article <VPkje.1422$H24.656@newssvr17.news.prodigy.com>,
Michael Mattias <michael.mattias@gte.net> wrote:

[snip]

>Of course, no one (guilty myself) ever commented their code that were
>exploiting this contiguity.. which probably should qualify as a venial sin.

Speak for yourself, Mr Mattias... granted that my memory is, admittedly,
porous but I recall pointing out my use of this in comments and warning
that 'TWO-YEAR PROGRAMMER CODE STOPS HERE!!!'... or something along those
lines.

DD

Richard Maher

2005-05-20, 3:55 pm

Hi Michael,

I wasn't surprised at the table overflow. What I said I was surprised at, is
that on IBM it lets you overwrite executable code and not just user-mode
working-storage.

If you re-read my note you'll see that the bit I was quoting from colin was

> Sometimes, they will run for a while even if some of
> the code in the Procedure Division is overwritten

Regards Richard Maher

"Michael Mattias" <michael.mattias@gte.net> wrote in message
news:VPkje.1422$H24.656@newssvr17.news.prodigy.com...
> "Richard Maher" <maher_rj@hotspamnotmail.com> wrote in message
> news:d6kfmq$q4i$1@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com...
subscripts][color=darkred]
> works with IBM. Is it just on MVS
>
> It doesn't even "work" with the newer compilers... and as someone pointed
> out in an earlier post in this thread, the deliberate use of 'table
> overflow' was a 'generally known and used method' to create tables > 64K
on
> the eariler machines/compilers.
>
> I do not have the documentation available, but IIRC the compiler
documented
> that working-storage was always created in a contiguous block (except for
> any alignment bytes required) ; meaning this "table overflow" technique
was
> ,if not formally supported, a logical extension of this 'contiguity' (is
> that a word?).
>
> The newer compilers/OSs introduced some optimizing techniques which meant
> working-storage was no longer necessarily contiguous; but at the same time
> the officially supported table sizes were increased.
>
> What I'm saying here is, the use of this 'table overflow' technique on IBM
> mainframes with the then-current compilers was hardly a mortal sin.
>
> Of course, no one (guilty myself) ever commented their code that were
> exploiting this contiguity.. which probably should qualify as a venial
sin.
>
> MCM
>
>
>
>
>

Michael Mattias

2005-05-20, 3:55 pm

"Richard Maher" <maher_rj@hotspamnotmail.com> wrote in message
news:d6kp2t$kbi$1@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com...
> Hi Michael,
>
> I wasn't surprised at the table overflow. What I said I was surprised at,
is
> that on IBM it lets you overwrite executable code and not just user-mode
> working-storage.
>
> If you re-read my note you'll see that the bit I was quoting from colin
was[color=darkred]
>

My comment was not necessarily directed at you... it was the whole thrust of
the thread, that somehow finding a way to work around the limitations of a
specific compiler was an evil or unprofessional action.

On the overwrite the code segment and keep running (until the 'invalid
opcode' exception invariably occurs) ... I have to believe that would be
operating-system specific. I know I can't write to the code area of my
Windows programs without getting an immediate page fault exception. (Not
that I ever did this on purpose). ,,, but I do seem to recall some
excursions into the program code on IBM mainframes... at least that's what
the dump analyzer told me... (FWIW, you *can* under Windows execute code
from a user-writable memory area... but AFAIK you have to go out of your way
to do so..).

--
Michael Mattias
Tal Systems, Inc.
Racine WI
mmattias@talsystems.com

William M. Klein

2005-05-20, 8:55 pm

IBM (z/OS, VM, and VSE) does provide ways for good (better, best) "memory"
protection. However, with the OLDER COBOL compilers, they did NOT do much of
this. The newer compilers are better in doing this, but there are still ways of
"getting at" memory that you shouldn't be able to modify. In fact, the RENT
(re-entrant) compiler option (and linkage-editor / binder) option are built on
the UN-enforced assumption that you do not have "self-modifying" code.

I am not certain about AIX or OS/400.

--
Bill Klein
wmklein <at> ix.netcom.com
"Richard Maher" <maher_rj@hotspamnotmail.com> wrote in message
news:d6kfmq$q4i$1@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com...
> Hi Colin,
>
>
> I'm very surprised that that's the way it works with IBM. Is it just on MVS
> the compilers do this or OS/400, AIX as well? What I'm use to seeing,
> admittedly on non-IBM platform, is the compiler generating a Read-Only
> Program Section for the code which subsequently gets built into a read-only
> image section that would trigger an Access Violation if a dodgy pointer
> tried to write to it.

Arnold Trembley

2005-05-21, 3:55 am

Richard Maher wrote:
> Hi Michael,
>
> I wasn't surprised at the table overflow. What I said I was surprised at, is
> that on IBM it lets you overwrite executable code and not just user-mode
> working-storage.
>
> If you re-read my note you'll see that the bit I was quoting from colin was
>
>
>
>
> Regards Richard Maher

One of the ways you can overwrite executable code in your zOS COBOL
program is by calling a subprogram and misusing an address passed to
it. In my limited experience, zOS is pretty good at protecting itself
from being overwritten, but your COBOL program cannot be prevented
from shooting itself in the foot.

In other words, trying to overwrite operating system code fails on a
protection exception, but overwriting your own application code
eventually fails on an invalid opcode. Your application program can
self-destruct, but the operating system won't be affected.

As for the other issue with working-storage, most oldtime IBM
mainframe COBOL programmers assume that their working-storage section
is one contiguous chunk of memory, as if working-storage were a single
01 record. I believe that was true with OS/VS COBOL (no longer
supported), but with COBOL II and later compilers the uninitialized
working-storage 01 records were GETMAIN'ed at runtime, and were not
contiguous with initially VALUE'ed working-storage. Old-timers found
those storage dumps confusing.

I might be wrong on this, but I think that's how it works.

With kindest regards,

--
http://arnold.trembley.home.att.net/

Michael Mattias

2005-05-21, 3:55 pm

"Arnold Trembley" <arnold.trembley@worldnet.att.net> wrote in message
news:Q7yje.234543$cg1.138688@bgtnsc04-news.ops.worldnet.att.net...
> As for the other issue with working-storage, most oldtime IBM
> mainframe COBOL programmers assume that their working-storage section
> is one contiguous chunk of memory, as if working-storage were a single
> 01 record. I believe that was true with OS/VS COBOL (no longer
> supported), but with COBOL II and later compilers the uninitialized
> working-storage 01 records were GETMAIN'ed at runtime, and were not
> contiguous with initially VALUE'ed working-storage. Old-timers found
> those storage dumps confusing.
>
> I might be wrong on this, but I think that's how it works.

That's exactly how I remember it... the use of otherwise 'dead'
Working-Storage to expand a table worked terrific on OS/VS COBOL, but when
VS COBOL II came along, it stopped working.. but nobody really cared,
because VS COBOL II included the expanded table size limit. (I think OS/VS
COBOL was limited to 64 Kb table size.)

MCM

2005-05-21, 3:55 pm

Arnold Trembley wrote:
>
>
> Richard Maher wrote:
>
>
>
> One of the ways you can overwrite executable code in your zOS COBOL
> program is by calling a subprogram and misusing an address passed to
> it. In my limited experience, zOS is pretty good at protecting itself
> from being overwritten, but your COBOL program cannot be prevented from
> shooting itself in the foot.
>
> In other words, trying to overwrite operating system code fails on a
> protection exception, but overwriting your own application code
> eventually fails on an invalid opcode. Your application program can
> self-destruct, but the operating system won't be affected.
>
> As for the other issue with working-storage, most oldtime IBM mainframe
> COBOL programmers assume that their working-storage section is one
> contiguous chunk of memory, as if working-storage were a single 01
> record. I believe that was true with OS/VS COBOL (no longer supported),
> but with COBOL II and later compilers the uninitialized working-storage
> 01 records were GETMAIN'ed at runtime, and were not contiguous with
> initially VALUE'ed working-storage. Old-timers found those storage
> dumps confusing.
>
> I might be wrong on this, but I think that's how it works.
>
> With kindest regards,
>
You are essentially correct. There is no way to protect someone who is
intent on violating the language and the system rules from blowing their
application out of the water. Such thing will not impact the z/OS
system as it is well protected.

One key reason for the somewhat unpredictability of the operation when
addressing outside of valid Working-Storage [W-S] is because the size of
the area in which W-S is placed will vary widely. There is a run-time
option [HEAP] that specifies the size of the initial heap allocation.
This size can vary from the minimum required to hold the W-S to a huge
amount of extra storage. If the size is near the minimum for W-S, it is
quite likely that addressing violations will result in program checks.
On the other hand, if there is a very large heap allocated, but the
unused part is never referenced or used except by addressing violations,
then it would not be unexpected that the invalid addressing could go
undetected and the program might actually run successfully. Or, it may
run until some change is made to the application that cause storage
references to the previously unused [except invalidly] storage.

Net: Language definitions indicate what WILL happen with VALID coding.
Violate the rules and, as it is so often stated, the results are
unpredictable. Thus, trying to predict the unpredictable is rather futile.

Carl

William M. Klein

2005-05-21, 3:55 pm

I thought that I would add one other bit of information to this thread. I think
there MAY be some confusion based on how many of today's programmers work in
"current" operating environments.

IBM's older COBOL's "started out" in a batch-only environment. Furthermore,
they originated BEFORE IBM even supported "MVS" (Multiple Virtual Storage or
Space ?? - well "S" is something). Therefore, there was NEVER a chance of a
COBOL program interfering with another "simultaneously" executing program.

When MVS (or actually VS1 or some other early OS) came along, there was STILL no
chance of COBOL programs' "clobbering" other applications, because the OS *did*
specifically BLOCK (protect) interaction between "simultaneously" executing
applications. (Different Address Spaces - among other things).

Now, for many, MANY decades, IBM has supported systems such as CICS, TSO, and
IMS (as well as 3rd party products) that provided support for "concurrent"
applications (and instances of the same application). However, each of these
ALSO provided software for "application isolation".

Therefore, although it is true that a COBOL application could (and with some
effort still CAN) negatively impact its own "procedural code" by doing "bad
things". It is also true that is almost impossible (and has been for years) for
a COBOL program to negatively impact someone else's (application or system's)
procedural code.

P.S. For those familiar with S/3nn systems, I remember hearing about someone
trying to create an APF authorized COBOL program to run in "supervisor state".
With OS/VS COBOL, this would have been impossible, but I *think* with the
current COBOL's it is THEORETICALLY possible - but sufficiently unused not to be
considered in this thread.

--
Bill Klein
wmklein <at> ix.netcom.com
"CG" <carl.gehr.RemoveThis@ThisToo.attglobal.net> wrote in message
news:6ec0c$428f7161$453ddae3$32665@FUSE.NET...
> Arnold Trembley wrote:
> You are essentially correct. There is no way to protect someone who is intent
> on violating the language and the system rules from blowing their application
> out of the water. Such thing will not impact the z/OS system as it is well
> protected.
>
> One key reason for the somewhat unpredictability of the operation when
> addressing outside of valid Working-Storage [W-S] is because the size of the
> area in which W-S is placed will vary widely. There is a run-time option
> [HEAP] that specifies the size of the initial heap allocation. This size can
> vary from the minimum required to hold the W-S to a huge amount of extra
> storage. If the size is near the minimum for W-S, it is quite likely that
> addressing violations will result in program checks. On the other hand, if
> there is a very large heap allocated, but the unused part is never referenced
> or used except by addressing violations, then it would not be unexpected that
> the invalid addressing could go undetected and the program might actually run
> successfully. Or, it may run until some change is made to the application
> that cause storage references to the previously unused [except invalidly]
> storage.
>
> Net: Language definitions indicate what WILL happen with VALID coding.
> Violate the rules and, as it is so often stated, the results are
> unpredictable. Thus, trying to predict the unpredictable is rather futile.
>
> Carl

docdwarf@panix.com

2005-05-21, 8:55 pm

In article <6ec0c$428f7161$453ddae3$32665@FUSE.NET>,
CG <carl.gehr.RemoveThis@ThisToo.attglobal.net> wrote:

[snip]

>Thus, trying to predict the unpredictable is rather futile.

Oh, I *cannot* resist...

.... is that what you predict?

DD

Richard

2005-05-22, 3:55 am

> Oh, I *cannot* resist...

Well, _that_ was predictable.

docdwarf@panix.com

2005-05-22, 3:55 am

In article <1116718372.839800.133240@g47g2000cwa.googlegroups.com>,
Richard <riplin@Azonic.co.nz> wrote:
>
>Well, _that_ was predictable.

Strange how that comment appears to get made primarily in retrospect, aye.

DD

docdwarf@panix.com

2005-05-23, 8:55 am

Sparky Spartacus

2005-05-24, 8:55 am

Michael Mattias wrote:

> "Arnold Trembley" <arnold.trembley@worldnet.att.net> wrote in message
> news:Q7yje.234543$cg1.138688@bgtnsc04-news.ops.worldnet.att.net...
>
>
>
> That's exactly how I remember it... the use of otherwise 'dead'
> Working-Storage to expand a table worked terrific on OS/VS COBOL, but when
> VS COBOL II came along, it stopped working.. but nobody really cared,
> because VS COBOL II included the expanded table size limit. (I think OS/VS
> COBOL was limited to 64 Kb table size.)

IIRC the max was 32K, but my memory is not what it once was.

Michael Mattias

2005-05-24, 3:55 pm

<docdwarf@panix.com> wrote in message news:d6v3no$pib$1@panix5.panix.com...
> 01 A-TBL.
> 05 A-ROW OCCURS 10000 PIC X(500).
>
> ... compiled with:
>
> PP 5740-CB1 RELEASE 2.4 IBM OS/VS COBOL JULY 1, 1982 7.18.19
> (DATE MAY 24,1905... hee hee hee!)
>
> ... the following errors result:
>
> IKF2116I-E FIXED LENGTH GROUP ITEM IN WORKING-STORAGE OR LINKAGE
> SECTION IS GT 131,071 BYTES.
> TRUNCATED TO 131,071.
>
> 131,071? Nothing strikes me as 'magic' about that number...

131071 = 128Kb - 1

If not 'magic' surely 'intriguing'

MCM

docdwarf@panix.com

2005-05-24, 3:55 pm

In article <w9Fke.1203$uu.1192@newssvr33.news.prodigy.com>,
Michael Mattias <michael.mattias@gte.net> wrote:
><docdwarf@panix.com> wrote in message news:d6v3no$pib$1@panix5.panix.com...
>
>131071 = 128Kb - 1
>
>If not 'magic' surely 'intriguing'

That's what makes it odd... so close, yet so far. Perhaps it is another
bit of memory-porosity but I recall seeing 32,768, not 32,767... but it
has been a while, aye. Perhaps it comes from that border between Start
Counting At Zero-land and Start Counting At One-land.

DD

docdwarf@panix.com

2005-05-24, 3:55 pm

In article <FFyke.655$So7.588@fe10.lga>,
Sparky Spartacus <Sparky@universalexports.org> wrote:
>Michael Mattias wrote:

[snip]

>
>IIRC the max was 32K, but my memory is not what it once was.

I recalled 32K also, something to do with the maximum value that could be
stored in an INDEXED BY field... but my memory is, as previously admitted,
porous and/or things seem to have changed. Given:

01 A-TBL.
05 A-ROW OCCURS 10000 PIC X(500).

.... compiled with:

PP 5740-CB1 RELEASE 2.4 IBM OS/VS COBOL JULY 1, 1982 7.18.19
(DATE MAY 24,1905... hee hee hee!)

.... the following errors result:

IKF2116I-E FIXED LENGTH GROUP ITEM IN WORKING-STORAGE OR LINKAGE
SECTION IS GT 131,071 BYTES.
TRUNCATED TO 131,071.

IKF2198I-E MAXIMUM LIMIT OF 255 BL, BLL OR SBL CELLS HAS BEEN
EXCEEDED. UNPREDICTABLE RESULTS
WOULD OCCUR IF EXECUTION ATTEMPTED.

The 'card' towards which the first message pointed was 05 of A-ROW and the
'card' towards which the second message pointed was the last entry in the
LINKAGE SECTION (next line was the PROCEDURE DIVISION label).

131,071? Nothing strikes me as 'magic' about that number... but that
might speak more of my ability to recognise 'magic' than anything else. I
realise that 131,070 = 255 * 514 so each 'BL, BLL or SBL' seems to have a
maximum size of 514... but 514? 255 is 'magic', 512 is 'magic'... in some
circles 1,920 is 'magic'... but 514?

DD

Arnold Trembley

2005-05-24, 3:55 pm

Michael Mattias

2005-05-24, 3:55 pm

docdwarf@panix.com

2005-05-24, 3:55 pm

Richard

2005-05-24, 3:55 pm

> Oh, I *cannot* resist...

Well, _that_ was predictable.

docdwarf@panix.com

2005-05-24, 3:55 pm

Richard

2005-05-24, 8:55 pm

> 131,070 = 255 * 514

Try ( 256 * 512 ) - 1 -> 131,071

131,071 is the maximum value that can be held in an 18 bit signed
integer.

> '255 is 'magic', 512 is 'magic'

256 is the number of discrete values in 8bits ( 0 to 255 ).
512 is ... 9bits ( 0 - 511 )

Pete Dashwood

2005-05-25, 3:55 am

<docdwarf@panix.com> wrote in message news:d6v8cv$dmn$1@panix5.panix.com...
> In article <w9Fke.1203$uu.1192@newssvr33.news.prodigy.com>,
> Michael Mattias <michael.mattias@gte.net> wrote:
news:d6v3no$pib$1@panix5.panix.com...[color=darkred]
>
> That's what makes it odd... so close, yet so far. Perhaps it is another
> bit of memory-porosity but I recall seeing 32,768, not 32,767... but it
> has been a while, aye. Perhaps it comes from that border between Start
> Counting At Zero-land and Start Counting At One-land.
>
I think it comes from a border dispute between 'use one bit to indicate the
sign' land and 'twos complement land' :-)

BTW, '514' is half of 1028, which is 1024 with a full word (4 byte) length
indicator. Or it could be simply 512 with a halfword (2 byte) length
indicator... :-)

Here's a truly 'magic' number: Strouhal >0.2 AND <0.4

Outside that, we're simply flapping around... :-)

Pete.

docdwarf@panix.com

2005-05-25, 8:55 am

In article <1116962272.683968.177710@f14g2000cwb.googlegroups.com>,
Richard <riplin@Azonic.co.nz> wrote:

[snip]

>
>256 is the number of discrete values in 8bits ( 0 to 255 ).
>512 is ... 9bits ( 0 - 511 )

It might just be that my sense of 'magic' was too-strongly shaped in the
Oldene Dayse and needs a bit of expanding... ahhhhhh, what a wonderful
world it is, that has such Magicks in it!

DD

Michael Mattias

2005-05-25, 3:55 pm

"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:3fi7ovF7vscpU1@individual.net...
> news:d6v3no$pib$1@panix5.panix.com...
>
> Here's a truly 'magic' number: Strouhal >0.2 AND <0.4
>
> Outside that, we're simply flapping around... :-)

Bummer.

I was kind of hoping to make 131071 the 'fact' supporting Yet Another
Conspiracy Theory.

MCM

Chuck Stevens

2005-05-25, 3:55 pm

Is that anything like the product of six and nine in base thirteen?

-Chuck Stevens

"Michael Mattias" <michael.mattias@gte.net> wrote in message
news:aC_ke.1621$rk.1383@newssvr17.news.prodigy.com...
> "Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
> news:3fi7ovF7vscpU1@individual.net...
>
> Bummer.
>
> I was kind of hoping to make 131071 the 'fact' supporting Yet Another
> Conspiracy Theory.
>
> MCM
>
>
>
>

Sparky Spartacus

2005-05-26, 3:55 am

docdwarf@panix.com wrote:

> In article <FFyke.655$So7.588@fe10.lga>,
> Sparky Spartacus <Sparky@universalexports.org> wrote:
>
>
>
> [snip]
>
>
>
> I recalled 32K also, something to do with the maximum value that could be
> stored in an INDEXED BY field...

i.e., the greatest value which can be stored in 16 bits, given that the
high order bit is the sign bit.

> but my memory is, as previously admitted,
> porous and/or things seem to have changed. Given:
>
> 01 A-TBL.
> 05 A-ROW OCCURS 10000 PIC X(500).
>
> ... compiled with:
>
> PP 5740-CB1 RELEASE 2.4 IBM OS/VS COBOL JULY 1, 1982 7.18.19
> (DATE MAY 24,1905... hee hee hee!)
>
> ... the following errors result:
>
> IKF2116I-E FIXED LENGTH GROUP ITEM IN WORKING-STORAGE OR LINKAGE
> SECTION IS GT 131,071 BYTES.
> TRUNCATED TO 131,071.
>
> IKF2198I-E MAXIMUM LIMIT OF 255 BL, BLL OR SBL CELLS HAS BEEN
> EXCEEDED. UNPREDICTABLE RESULTS
> WOULD OCCUR IF EXECUTION ATTEMPTED.
>
> The 'card' towards which the first message pointed was 05 of A-ROW and the
> 'card' towards which the second message pointed was the last entry in the
> LINKAGE SECTION (next line was the PROCEDURE DIVISION label).
>
> 131,071?

128k-1

I don't think this is a good example because it's not defined as a
table, i.e., something either INDEXED or containing an OCCURS.

docdwarf@panix.com

2005-05-26, 8:55 am

In article <Kycle.49336$HJ2.28444@fe11.lga>,
Sparky Spartacus <Sparky@universalexports.org> wrote:
>docdwarf@panix.com wrote:

[snip]

>
>i.e., the greatest value which can be stored in 16 bits, given that the
>high order bit is the sign bit.

Makes sense, aye.

>

[snip]
[color=darkred]
>
>128k-1

Thanks much... but such a large number! *No* programmer worth his salary
needs more than 16K, or so I recall someone's being taught.

>
>I don't think this is a good example because it's not defined as a
>table, i.e., something either INDEXED or containing an OCCURS.

As stated above:

01 A-TBL.
05 A-ROW OCCURS 10000 PIC X(500).

My eyes aren't what they used to be... but isn't there an OCCURS between
A-ROW and 10000?

DD

docdwarf@panix.com

2005-05-28, 8:55 am

docdwarf@panix.com

2005-05-29, 8:55 am

docdwarf@panix.com

2005-05-30, 3:55 pm

Sponsored Links