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

Peter Ludemann wrote:


(snip)


> Sorry to disagree with you on ancient history, especially when I don't
> have any manuals,


IBM has many newer manuals online, bitsavers.org and mirrors have many
older manuals online.


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


I believe one is allowed three regions, and within each region a
nested tree of overlays. I never liked the Microsoft overlay
system, but the Watcom linker has an overlay system somewhat similar
to OS/360, and even reads MS object files.


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


The linker creates static overlays. The position of each module in
(possibly virtual) storage is determined at link time. LINK and XCTL
allow a dynamic overlay, where the position is not determined in
advance, but when the module is actually brought in. Relocation is
then done in just about the same way as when the initial program
is loaded. (It might even be done by LINK.) Dynamic overlay requires
the program (or programmer) to do more work, such as actually coding
LINK and XCTL macros.


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


It is also in the Linkage Editor and Loader PLM. I should scan mine
and send it in.


(snip on MTS)


WATFIV could read object modules, but not load modules.


There is also a program, DELINK, that will convert a load module
back to an object module one CSECT at a time.


-- glen

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