Re: IBM S/390 memory model and COBOL

Richard Maher wrote:

>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.
>
>Regards Richard Maher
>
>
Like Bill Klein, I am not familiar with the other IBM platforms, their
COBOL compilers,  and their operating systems.  I have been told that
the earliest COBOL compilers created Assembler Language, rather than
object code (though if this is true, I have never used one of them on a
S/360 or its successors).  The code got assembled, and then could be
link edited and executed.

This may be an "urban legend"; however, I happened to learn IBM S/360
Assembler before I learned COBOL (by a matter of ws), and I was
immediately struck by the strong similarity between a COBOL object
module and one that might have been written in Assembler Language.  The
first COBOL compiler I used on S/360 was COBOL(F), which was created by
a team at IBM headed by Ken Seidel, with whom I later worked on a number
of COBOL compilers.  Two other teams were concurrently working on
COBOL(D) and COBOL(E), according to my memory of what Ken told me.  I
believe this resulted in rather different compilers, possibly with
rather different designs.

COBOL(F), the various releases of ANS COBOL V1 - 4, and OS/VS COBOL all
seemed to me to have a good deal in common in terms of the way they
allocated memory, etc.  Compilers starting with VS COBOL II reputedly
used an entirely new code base, still in use with the latest COBOL
compilers.  Bill Klein wrote a book of approximately 300 pages detailing
the differences between "OldBOL" and "NewBOL".  OS/VS COBOL was famously
permissive of violations of the ANSI COBOL standard - phrases could be
written out of order, words which were not defined as reserved in the
standard could be used, etc.  Supposedly (and I think it is true), the
new compilers were much more closely based on the ANSI Standard.  People
made good money writing programs to convert old COBOL code to compile
with the new compilers.

A gentleman named Tom Ross is in charge of COBOL compiler development
for IBM, as of the last I was paying attention (last year).  I'm not
sure if he was involved from the start of "NewBOL".

In my view, however, the new compilers still have a lot in common with
the older compilers in terms of memory allocation.  Basically, all of
them have a short prolog of executable code, branch around an area used
for program storage and environmental data, and end with the executable
code required by the procedural statements.

There are some differences if the RENT option is used.  Then, the space
for program storage is obtained and initialized at execution time,
rather than built into an object module.  The storage area would not be
contained in the same logical place, and it could even have a different
storage protection key (though I don't believe it does).  This would
change the way overflow works; if the overflow reached the end of that
storage area, a protection exception should occur.  Overflow that stays
within the Working-Storage (or Local-Storage) area still would not be
detected.

>"Colin Campbell" <cmcampb@adelphia.net> wrote in message
>news:pq2dnfS_a__hxhDfRVn-jQ@adelphia.com...
>
> 

Colin Campbell <cmcampb@adelphia.net> wrote:

>
>COBOL(F), the various releases of ANS COBOL V1 - 4, and OS/VS COBOL all
>seemed to me to have a good deal in common in terms of the way they
>allocated memory, etc.  Compilers starting with VS COBOL II reputedly
>used an entirely new code base, still in use with the latest COBOL
>compilers.

It's been many years since I worked on this stuff, but as I remember
those days, IBM started the work on VS-COBOL II in the late 1970's
based on COBOL 77 and then shelved because of lack of a need,
controversy over the standard and major backwards compatibility
issues. It got revived based on the COBOL 85 standard mainly because
they needed a 31-bit compiler for XA and for advanced versions of
CICS.

While it did use a new code base for the VS-COBOL-II modules, it
included an updated set of VS-COBOL run-time modules intended to work
within a 31-bit code environment for a mixed code environment. Some of
those modules were simply front-ends for the VS-COBOL-II run-time
code, some were modified VS-COBOL modules.

>Bill Klein wrote a book of approximately 300 pages detailing
>the differences between "OldBOL" and "NewBOL".  OS/VS COBOL was famously
>permissive of violations of the ANSI COBOL standard - phrases could be
>written out of order, words which were not defined as reserved in the
>standard could be used, etc.  Supposedly (and I think it is true), the
>new compilers were much more closely based on the ANSI Standard.  People
>made good money writing programs to convert old COBOL code to compile
>with the new compilers.

The new compiler was much stricter on syntax and plugged a lot of
holes and programming tricks that were commonly used in VS-COBOL.

I remember that we had a couple of critical systems that had been
written exploiting bugs in the VS-COBOL 1.1 release that were patched
in version 2. Those programs could not be upgraded and we had to keep
the old compiler for years to support them.  I still remember the
fights we had because programmers wanted to use the same bug to write
new code. Fortunately we won most of those battles.

I remember working with a couple of programmers from IBM France who
developed the IBM Cobol and CICS Conversion Aid. Without that program,
it would have taken years longer to convert.  Even so, there were
enough subtle differences in data handling that things had to be
carefully tested.

>
>There are some differences if the RENT option is used.  Then, the space
>for program storage is obtained and initialized at execution time,
>rather than built into an object module.  The storage area would not be
>contained in the same logical place, and it could even have a different
>storage protection key (though I don't believe it does).  This would
>change the way overflow works; if the overflow reached the end of that
>storage area, a protection exception should occur.  Overflow that stays
>within the Working-Storage (or Local-Storage) area still would not be
>detected.

Well, that's the whole point of having reentrant code.  You have one
copy of the program and as many copies of the working storage as
needed. I'm pretty sure, as you state, that as long as the address
stayed within allocated storage boundaries you'd get whatever was
there.  If it exceeded that, OC4.   The exception was if you had the
SSRANGE option on.  Then it would stop you if you exceeded the bounds
of the table, but the overhead was far too high for most proecution
code.



Scott Peterson

--
You can swear at the keyboard and
it won't be offended. It was going to
treat you badly anyway

508/612

Colin Campbell wrote:

> Like Bill Klein, I am not familiar with the other IBM platforms, their
> COBOL compilers,  and their operating systems.  I have been told that
> the earliest COBOL compilers created Assembler Language, rather than
> object code (though if this is true, I have never used one of them on a
> S/360 or its successors).  The code got assembled, and then could be
> link edited and executed.

You are going WAY back!  That was before S/360.  None of the S/360
compilers generated intermediate Assembler.  But, for example, the
1401/1440/1460 COBOL compilers generaged Autocoder [one of the 1400
assembler equivalents] that then had to be assembled.  I believe the
1410/7010 also worked this way.  I never had enough exposure to the
7070/7074 compiler enough to remember how it worked.

> This may be an "urban legend"; however, I happened to learn IBM S/360
> Assembler before I learned COBOL (by a matter of ws), and I was
> immediately struck by the strong similarity between a COBOL object
> module and one that might have been written in Assembler Language.  The
> first COBOL compiler I used on S/360 was COBOL(F), which was created by
> a team at IBM headed by Ken Seidel, with whom I later worked on a number
> of COBOL compilers.  Two other teams were concurrently working on
> COBOL(D) and COBOL(E), according to my memory of what Ken told me.  I
> believe this resulted in rather different compilers, possibly with
> rather different designs.
>
> COBOL(F), the various releases of ANS COBOL V1 - 4, and OS/VS COBOL all
> seemed to me to have a good deal in common in terms of the way they
> allocated memory, etc.
All of the compilers you mentioned up through OS/VS COBOL were all based
on the same COBOL(F) architecture [if you want to flatter it].  COBOL(E)
was an earlier compiler, similar to (F) but enough different to be
considered a different compiler.

COBOL(D) was not an OS/360 compiler; it was for DOS/360 [a.k.a. '16K
BOS', a.k.a., VSE when it finally got virtual storage.]  It was more
closely related to COBOL(E) than to COBOL(F) because it was designed for
a smaller memory footprint.

Don't forget, all of the compilers until OS/VS COBOL were targeted to
real memory [non-Virtual] systems.    In fact, the letter designations
were intended to specify the minimum storage required to run the
package.  D=16K, E=32K, F=44K, G=96K.  But, by the time COBOL(F) was
delivered, it required 88K to run.  [Rumor was that they underestimated
the space required for all of the reserved words and stuff that was pure
program documentation versus actual program logic...  ;-) ...]

> . . . Compilers starting with VS COBOL II reputedly
> used an entirely new code base, still in use with the latest COBOL
> compilers.

True!  COBOL II was a start from scratch, complete rewrite using an all
new architecture.  Not only a new compiler architecture, but the
run-time environment was also completely different.  Some of the
run-time concepts were similar to the run-time design used by the OS
PL/I compiler, but there are enough differences that InterLanguage
Communication [ILC] was [and still is] a non-trivial exercise.  This is
one of the objectives that LE had to tackle.

> . . .  Bill Klein wrote a book of approximately 300 pages detailing
> the differences between "OldBOL" and "NewBOL".  OS/VS COBOL was famously
> permissive of violations of the ANSI COBOL standard - phrases could be
> written out of order, words which were not defined as reserved in the
> standard could be used, etc.  Supposedly (and I think it is true), the
> new compilers were much more closely based on the ANSI Standard.  People
> made good money writing programs to convert old COBOL code to compile
> with the new compilers.
>
> A gentleman named Tom Ross is in charge of COBOL compiler development
> for IBM, as of the last I was paying attention (last year).  I'm not
> sure if he was involved from the start of "NewBOL".
>
> In my view, however, the new compilers still have a lot in common with
> the older compilers in terms of memory allocation.

Sorry, Colin, but this is where I have to disagree.  Memory allocation
is not at all the same.   All of the old compilers really did no
'allocation.' All of the storage used by the program is compiled into
the object code as static areas.  This is why OS/VS COBOL is inefficient
in a CICS environment and why, as of CICS TS V3.1, OS/VS COBOL programs
will no longer execute.  The special code to make OS/VS COBOL
quasi-reentrant has been removed from CICS.

And, yes, before someone comments, if you specify NORENT for the new
compilers, you negate the use of dynamic allocation for Working-Storage.
But, the way storage is used is still different from the old compilers.

>  . . .   Basically, all of
> them have a short prolog of executable code, branch around an area used
> for program storage and environmental data, and end with the executable
> code required by the procedural statements.
>
> There are some differences if the RENT option is used.  Then, the space
> for program storage is obtained and initialized at execution time,
> rather than built into an object module.  The storage area would not be
> contained in the same logical place, and it could even have a different
> storage protection key (though I don't believe it does).  This would
> change the way overflow works; if the overflow reached the end of that
> storage area, a protection exception should occur.  Overflow that stays
> within the Working-Storage (or Local-Storage) area still would not be
> detected.
> 

Colin Campbell wrote:

> Richard Maher wrote:
> 

I have worked on applications which did this by design and it worked
fine unless you gobbled up memory ahead of the execution path. There was
no concept of RENT (or even REUS) at all here, of course.
 
> Like Bill Klein, I am not familiar with the other IBM platforms, their
> COBOL compilers,  and their operating systems.  I have been told that
> the earliest COBOL compilers created Assembler Language, rather than
> object code (though if this is true, I have never used one of them on a
> S/360 or its successors).  The code got assembled, and then could be
> link edited and executed.
>
> This may be an "urban legend"; however, I happened to learn IBM S/360
> Assembler before I learned COBOL (by a matter of ws), and I was
> immediately struck by the strong similarity between a COBOL object
> module and one that might have been written in Assembler Language.

Do you mean other than compiled PL/I or FORTRAN code? Once compiled
they're all S/360 object code, so they'll contain the op codes &
instruction formats you learn in Assembly class.

I learned COBOL on a 1400 (early 1966) and IIRC that compiler's output
was Autocoder (as someone else has mentioned), which was assembled into
an object deck in a 2nd pass (this was before the concept of a "load
module" for me).

1400 series COBOL also supported "ENTER AUTOCODER" / "ENTER COBOL"
directives so the programmer could place Autocoder statements inline and
have them compiled into the binary deck (definitely an IBM-only option!).

This is genuine historical nonsense here BTW

http://www.ibiblio.org/pub/academic...
pdp8/9308.asp