Article 62079 of comp.os.vms:
Path: jac.zko.dec.com!pa.dec.com!decwrl!olivea!venus.sun.com!nntp-hub2.barrnet.net!news3.near.net!ssi.edc.org!giant!cwestbury
From: cwestbury@giant.intranet.com (Chris Westbury)
Newsgroups: comp.os.vms
Subject: Re: Sticky defaults "feature" of LINK   :-(
Message-ID: <1995May30.204904.11914@giant>
Date: 30 May 95 20:49:04 EDT
References: <9505231325.AA00658@uu3.psi.com> <3pu68f$c33@jac.zko.dec.com>
Distribution: world
Organization: IntraNet, Inc., Newton MA
Lines: 106

In article <3pu68f$c33@jac.zko.dec.com>,
winalski@gemgrp.enet.dec.com (Paul S Winalski) writes:
>
> It's been a while since I used them, but I think the linkage editors (Linkers,
> in VMS terminology) for IBM's System/360 and System/370 mainframe operating
> systems worked the way that this user wishes (i.e., if one linked against
> libraries A, B, and C, in that order, and an unresolved reference was picked
> up from a module included in C, libraries A and B would be searched again to
> resolve the reference).

The VMS file system and the OS file system have different design philopsophies.
I have to oversimplify a lot here, but OS disk space is allocated in extents.
An extent is identified by its starting disk address and its ending disk
address, and it can be any size.  A file is a list of one or more extents.  When
you use the Data Definition (DD) statement at run time to allocate a file to a
program, the reader (OSspeak for CLI) locates the file and passes the list of
extents to the Sequential Access Method (SAM).  SAM takes the list of disk
addresses and reads them, passing the records into your program as you request
them.

Suppose you have two files, A and B.  At run time, you can use two DD statements
to create a temporary virtual file that consists of A followed by B.  The files
themselves are unchanged and unmoved.  The reader passes a single list of
extents to SAM, but this list includes all the extents of file A followed by all
the extents of file B.  Your program receives the last record of A followed by
the first record of B without any indication that they came from different files
on different disks.  This is why you hardly ever see COPY A,B C on a mainframe.

"Partitioned dataset" (PDS) is OSspeak for library.  A PDS is made up of extents
like any other file, but within the first extent is a directory containing -
guess what? - the disk addresses of the members of the library.  This is why
libraries are almost first-class objects in OS.  At run time, if you specify a
sequential file, the reader prepares the list of disk extents from the volume
table of contents and passes it to SAM.  If you specify a member of a PDS, the
reader prepares the list of disk extents from the PDS directory and passes it to
SAM.  Your program can not tell whether the records are coming from a sequential
file or from a library.

What this means is that you never have to write anything extra in your program
to read from a library.  In VMS, for example, to edit a library module you have
to do something like this:
    $ LIBRARY/EXTRACT=A/OUTPUT=A.TXT LIB.TLB
    $ EDIT/TPU A.TXT
    $ LIBRARY/REPLACE LIB.TLB A.TXT
The VMS editor could be enhanced to edit library members directly, but I don't
think it will.  In OS, however, you can edit LIB(A) directly.  This is not
because of extra coding in the editor, but because LIB(A) can appear in any
context that A can, so the OS file system gives you this for free.

To take an extreme example, you could define a virtual file containing a member
of one library on one disk, a sequential file on another disk, a sequential file
on a reel of tape, a member of another library on a third disk, and another
sequential file on another reel of tape.  SAM would simply follow the pointers
and deliver the records in sequence to your program, without any indication of
where one file ends and the next file begins.

A program that needs to manage a library, such as the OS linkage editor, uses
the Partitioned Access Method (PAM).  When you use the Data Definition (DD)
statement at run time to allocate a PDS to a program, the reader locates the PDS
and passes the directory to PAM.  Your program can use PAM to locate, add, or
delete members.

Suppose you have two libraries, LIBA and LIBB.  At run time, you can use two DD
statements to create a temporary virtual library that consists of the union of
LIBA and LIBB.  The libraries themselves are unchanged and unmoved.  The reader
passes a single directory to PAM, but this directory is the directory of LIBA
merged with the directory of LIBB.  Your program accesses members of the virtual
library without being able to tell whether they are from LIBA on one disk or
from LIBB on another.

In the directory of a PDS, whether real or virtual, there can be only one member
with a given name.  Only the first occurrence of a given name will appear in the
directory of the virtual PDS.  As the directory of LIBB is being merged with the
directory of LIBA, if there is a member in LIBB with the same name as a member
in LIBA, the LIBB member can not appear in the virtual PDS.

Suppose that you store the current release version of your product in library
Rv.  In library Q, you put just those modules that are currently in QA.  It is
not necessary to copy the rest of the modules, because by concatenating
libraries Q and Rv you create a virtual library that appears to contain the QA
version of the entire product.  Furthermore, developer n has a library Dn that
contains just the modules on which he is working.  Library Dn,Q,Rv is his
virtual view of the product.  There are as many D libraries as there are
developers, and each has his own personal virtual view of the product.  You can
test against the previous release by using virtual library Dn,R(v-1).  JCL is so
ugly that it is hard to remember what an advance this was in 1965.

Whew!  Well, if anyone is still reading this, you know why Mr. Winalski's
example works the way it does.  The OS linkage editor was written to search one
library, whether real or virtual, so naturally a symbol referenced in library C
can be resolved in library A or in library B.  It would take extra effort to do
it the other way in OS.  On the other hand, the VMS linker was written to search
one library at a time, so naturally it closes library A before it opens library
B.  It would take extra effort to do it the other way in VMS.

What I am getting at is that the authors of the OS Linkage Editor did not decide
that resolving ping-pong references is a Good Thing.  They simply took the OS
file system as they found it.  Likewise, the authors of the VMS Linker did not
decide that resolving ping-pong references is a Bad Thing.  They simply took the
VMS file system as they found it.  Non-ping-pong-style linkers have become the
most common simply because rudimentary file systems have become the most common,
not because any conscious thought was given to which style was better.


--
Christopher Westbury, Midtown Associates, 15 Fallon Place, Cambridge, MA 02138


