Re: linking in OS/360, was The History of the ALGOL Effort

Peter Ludemann <p_ludemann@yahoo.com>
13 Sep 2006 02:37:57 -0400

          From comp.compilers

Related articles
[2 earlier articles]
Re: The History of the ALGOL Effort Juergen.Kahrs@vr-web.de (=?ISO-8859-1?Q?J=FCrgen_Kahrs?=) (2006-08-18)
Re: The History of the ALGOL Effort p_ludemann@yahoo.com (Peter Ludemann) (2006-08-29)
Re: The History of the ALGOL Effort henry@spsystems.net (2006-09-11)
Re: The History of the ALGOL Effort Peter_Flass@Yahoo.com (Peter Flass) (2006-09-11)
Re: linking in OS/360, was The History of the ALGOL Effort Peter_Flass@Yahoo.com (Peter Flass) (2006-09-12)
Re: linking in OS/360, was The History of the ALGOL Effort gah@ugcs.caltech.edu (glen herrmannsfeldt) (2006-09-12)
Re: linking in OS/360, was The History of the ALGOL Effort p_ludemann@yahoo.com (Peter Ludemann) (2006-09-13)
Re: linking in OS/360, was The History of the ALGOL Effort gah@ugcs.caltech.edu (glen herrmannsfeldt) (2006-09-16)
OT: Delinking, was Re: linking in OS/360, was The History of the ALGOL Peter_Flass@Yahoo.com (Peter Flass) (2006-09-18)
| List of all articles for this month |

From: Peter Ludemann <p_ludemann@yahoo.com>
Newsgroups: comp.compilers
Date: 13 Sep 2006 02:37:57 -0400
Organization: SBC http://yahoo.sbc.com
References: 06-08-082 06-08-086 06-08-105 06-08-138 06-09-050 06-09-053 06-09-065
Keywords: linker, comment

On 9/12/2006 4:19 PM, Peter Flass wrote:
[snip]
> ... The "overlays"
> are done using OS/360 LINK and XCTL macros rather than via the Linkage
> Editor. The execute loads a small root phase that links in turn to s
> series of second-level modules, each of which links to a series of
> third-level modules. I think three is it, but the important point is
> that none of this is done with the help of the Linkage Editor, but
> through dynamic allocation of storage and dynamic program loading.


Sorry to disagree with you on ancient history, especially when I don't
have any manuals, but I have done overlays on OS/370 entirely with
commands to the linkage-editor. The programmer did need to specify the
overlays; but the compiler didn't need to do anything at all. Also,
one could go as deep as desired in the overlay structure, although I
suspect that 3 was the practical limit.


You can see an example here: http://www.iecc.com/linker/linker08.html
... scan for "Defining overlays" and "Implementation of overlays". The
glue code wasn't LINK and XCTL; there were some other system macros that
were usually relegated to appendices because they weren't normally used
by programmers - the link-editor created all the glue code and system
macro calls.


One of the problems with the OS/360 linkage-editor was that it had an
unnecessarily complex executable format (the object format, however, was
fairly simple - the best documentation is in Gries). By comparison, the
MTS operating system used the same object file format as OS/360 but
didn't have a special executable format - instead, it had a program that
would combine object files into a single large object file, resolving
addresses wherever possible (and also making long TXT records instead of
the 80-byte object-format records), so it was about as space- and
time-efficient as the OS/360 executable format). The net effect was that
MTS had a fast linker that an undergrad could implement and which easily
supported incremental linking and incremental loading, something which
more "modern" OSes such as Un*x either can't do, or do with a lot of
pain. So, you could do something like this:
        $RUN p1.o+p2.o+p3.o+*LIBC*
which is roughly the equivalent of this in Unix:
        exec <(cat p1.o p2.o p3.o /lib/libc.so)
or, for convenience/efficiency:
        $LINK p1.o+p2.o+p3.o+*LIBC* SINK=p.exe
        $RUN p.exe
(*LIBC* would be in a shared segment, so it behaved more like a .so than
a .a library) (And for anyone who remembers MTS - yes, I'm making a few
small simplifications for pedagogic purposes)


And the MTS linker was seldom used because the incremental loader was
fast enough.


- peter ludemann


[I don't think the two of you are disagreeing. The OS linker let
(still lets) you do digital origami and fold up a single program into
overlays, with the creases at CSECT boundaries, each CSECT typically
being a subroutine. But for some reason PL/I F didn't use that, and
instead faked it by dividing up the compiler into a whole bunch of
little programs and using LINK and XCTL to glue them all together.


IBM puts an amazing amount of stuff on line. A 1991 edition of the
linkage editor manual, which isn't very different from a 1969 edition,
is here:


http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGG3L100/CCONTENTS?SHELF=EZ2MV122&DN=SC26-4564-01&DT=19911220122242


Appendix C tells you not to use the overlay system, then tells you all
about how to use it if you do. -John]


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.