!TITLE Technical Aspects of Loading
!KEY

    The following are a series of sections devoted to various aspects of
loading  and  how  the  loader  copes with them.  It is appreciated that
several of the topics covered  are  fairly  technical  and  the  average
reader  may  have  neither  the background nor the interest to persevere
with all of them.

    Before proceeding, however it  might  be  sensible  to  define  what
exactly is meant by 'the loader' in this documentation.

    A  loader  is a piece of system software whose job it is to set up a
suitable machine environment for executable files.   There  are  several
different  types  of loader, however the 2900 EMAS program loader, which
is part of the subsystem, is an example of the class of loader known  as
a linking loader.  As well as loading executable files, a linking loader
handles  external linkage between executable modules at load time.  This
eliminates the  need  for  a  separate  link-edit  step  or  for  module
collection or consolidation.
!PAGE

!<Executable files - EMAS 2900 object file format
!KEY EXECUTABLE,OBJECT

    As  stated  above,  the  most  basic  task  of the loader is to load
executable files i.e.  EMAS  2900  object  files.   These  are  normally
generated  as  the  primary  output  of  the  various language compilers
available on EMAS.  The files conform to  a  standard  format  so  that,
subject  to  any  parameter  passing restrictions imposed by the various
languages, cross-calling between modules written in different  languages
is possible.

    The  essence  of  EMAS  is  shareability  and  object file format is
designed to exploit this.  Many users can be executing the  same  object
file  at  the same time with all the efficiency and savings in resources
that implies, while each has his own  unique  values  of  variables  and
run-time addresses.

    Therefore  an  object file consists of two parts - one shareable and
capable of being executed directly in place and  the  other  unshareable
and representing a database for initialisation.

    To  achieve overall shareability of object files, areas described by
the database to contain run-time dependent  items  are  set  up  by  the
loader in the user's private space.

    The  shareable part of the object file comprises two separate areas,
the executable code(CODE) and the shared symbol tables(SST).  The latter
contains information relevant to run-time diagnostics.

    The unshareable database, sometimes known as the General Linkage And
initialisation Pattern or GLAP, describes five separate areas to be  set
up  by the loader - the general linkage area(GLA), the procedure linkage
table(PLT), the unshared  symbol  tables(UST),  the  initialised  common
areas(INITCMN) and the static initialised area on stack(INITSTACK).  The
first  four  of  these  are  set  up  in the 'user GLA', which is a file
specially created by the loader for each user,  and  contain  such  user
dependent  information  as  global variables, linkage tables to external
objects and common areas.  The INITSTACK is set up by the  loader  in  a
reserved  area of the 'user stack', which is another file created by the
loader for the user  when  required,  and  used  exclusively  for  stack
operations.

    The  executable  code  always  refers to run-time dependent items in
terms of offsets in the user gla  or  the  user  stack  to  achieve  the
desired generality and shareability.

    Note  that  the  unshareable areas in total are generally very small
relative to the size of the (shared) object file.  This is  why  sharing
is  so  valuable  and  is  one  of the great virtues of EMAS object file
format.
!>
!<EMAS fundamentals - Stacks, GLAs, Logging-on, Stack switching.
!KEY STACK,GLA

    As implied by the previous section an  executing  object  file  will
require   access  to  a  stack  file,  where  local  variables  and  the
intermediate results of calculations are stored, and a 'gla' file, where
linkage information, global variables, common areas etc. unique to  that
process are kept.

    In  this  document  we  are primarily concerned with the loading and
linking activities which take place at the subsystem interface.  However
it may be of some interest to place this in context by considering how a
process is created and how the system protects itself  against  programs
which, so to speak, 'go berserk'.

    The  log-on  sequence  is  initiated by a request from the front end
processor which is passed through the global part of the Supervisor, the
Global Controller, to process DIRECT.  DIRECT creates several  files  on
behalf  of  the  embryonic  process: #STK,  the process or base stack on
which the process Director and Subsystem will  run,  #LCSTK,  the  Local
Controller stack, on which the process local Supervisor will run, #DGLA,
a  file  for  the  Director's gla, T#IT, a file used for i/o buffers and
#UINFI, a file to contain information about the user.  DIRECT then calls
the Global Controller to start the process.

    The Global Controller starts up the Local Controller for the process
which loads and calls the local copy of the Director (running  on  #STK,
gla  in  #DGLA).   The Director continues the initialisation sequence by
creating and connecting another stack  file,  #STK,  the  signal  stack,
which  is  used  when  contingencies  occur.   At  the end of Director's
initialisations it connects the subsystem basefile then creates the file
#BGLA,  the  base gla.  The local Director loads and calls the Subsystem
(running on #STK, gla in #BGLA).  After some Subsystem initialisation we
finally arrive at 'command level'.

    It  will  have  been  observed  that at each stage a given component
loads and calls the next in the sequence.  Each component  has  its  own
piece  of  code  which  functions as a loader.  The Subsystem's piece of
code is what we are calling 'the loader' in this document.  It will load
and call the next level up,  i.e.  user commands.  The  other  'loaders'
are all short and simple since they only have one task to perform.

    The  Local  Controller  runs at a higher level of privilege than the
rest of the user process and the two can  be  regarded  as  co-operating
processes  with  the  Local  Controller  in  charge.   When  cpu becomes
available to the process as a whole, the Local Controller  has  priority
and  runs  on  its own stack.  When the local Director is called a stack
switch is executed and the Director (and eventually the Subsystem)  runs
on the stack file #STK.

    To  summarise thus far: after the log-on sequence, Subsystem code is
executing,  stack operations are being carried on the base stack  (#STK)
and linkage information and own variables for the system are held in the
base  gla  (#BGLA).   The situation remains thus until the first command
which  is  not  in  the  subsystem  is  called.    User   commands   are
intrinsically  less  'trustworthy'  than system commands, but run at the
same level of privilege.  To protect the system, which is running on the
base stack, a new stack, the user stack (T#USTK), is created.   A  stack
switch is then executed which ensures that the user command runs on this
stack.   Return from the user command causes a return to the base stack.
A catastrophic program failure which corrupts the user  stack  will  not
therefore corrupt the system.

    The  user stack has a hardware imposed upper size limit of 252K.  Of
this  252K,  a  portion  can  be   reserved   by   the   user   by   the
OPTION(INITSTACKSIZE=  )  command.  This area, though part of the stack,
is essentially static; normal stack operations take  place  between  the
top of the initialised stack area and the top of the stack.

    The  initialised  stack  area  is used by some languages, especially
FORTRAN, to store variables between calls of routines.  In the  case  of
FORTRAN,  the  language  definition guarantees preservation of variables
between calls of the same  function  or  subroutine.   In  normal  stack
operations  all local variables would be lost between calls.  The loader
distinguishes  between  routines  which are to be  'permanently'  loaded
(i.e. those which are to remain loaded to the end of the current session
or the first call of RESETLOADER) and those which are only loaded  until
the  end  of  the  current  command.   To  avoid  fragmentation  of  the
initialised stack area,  therefore,  'permanent'  initialised  stack  is
taken  from the top of the area and temporary initialised stack from the
bottom.  The gla requirements of permanently loaded files are taken from
the basegla for convenience but a call to  load  the  first  temporarily
loaded  object  file  triggers off the creation of the user gla, T#UGLA.
This file is used to satisfy the gla  requirements  of  all  temporarily
loaded  object  files  -  except  bound  object  files which are treated
somewhat differently (see below).
!>
!<Loader tables
!KEY

    Loading  information  for subsystem entries is held in a single file
which is shared by all users.  Private loader data in the form of a  set
of  tables for each user is held in a file, T#LOAD, created at subsystem
start up time in each process.  T#LOAD is organised into 3 areas each of
which can be extended as required up to the maximum file size for T#LOAD
imposed by the process.  The areas  are  assigned  to  1)  a  table  for
external  references,  2)  a table for 'permanently' loaded entry points
and 3) a table for temporarily loaded entries.  Each table is  similarly
organised  and consists of a set of listheads (currently 251) from which
entry or reference records, as appropriate,  are  organised  in  chains.
The  particular  listhead that a specific entry or reference is attached
to is determined by hashing the name.  This form of organisation has the
advantage of short chain lengths (and hence fast look  up)  and  compact
tables.   Additionally,  the entry tables operate on a last-in first-out
basis which eases many of the problems associated with unloading.
!>
!<LOADLEVEL
!KEY LOADLEVEL

    All  object  files  require some unshareable space from the gla when
they are loaded. 'Permanently' loaded object files  acquire  space  from
the  base  gla  and  temporarily loaded files from the user gla.  When a
command or program has been run or a load has failed in mid  flight  for
whatever  reason,  then  the  loader must know what to unload.  Provided
that the loader has noted the address of the next free byte of user  gla
before  loading  began  and the same information at termination then all
the object files assigned areas of user  gla  within  the  starting  and
finishing  addresses  of  the  'top of the user gla' should be unloaded.
Similarly, if a load has failed,  then  in  addition  to  unloading  any
temporarily  loaded  files,  any  'permanently'  loaded files which were
loaded as a result of the failed load should also be unloaded.  This  is
done  by  noting  the  start and finishing values of the top of the base
gla.

    However  as  well  as   distinguishing   between   permanently   and
temporarily  loaded  files,  EMAS recognises 'degrees of temporariness'.
For example, EMAS provides facilities whereby files may be  loaded  from
within  programs,  executed,  then  unloaded  again  before  the calling
program resumes.  The subsystem routine CALL and its FORTRAN  equivalent
EMASFC  operate like this as does the EMAS command RUN when it is issued
from within a program.  Each time we decide that we want to be  able  to
do  a partial unload of temporarily loaded files, we must store away the
current 'top of the gla' at least.  To formalise the concept we define a
global integer LOADLEVEL.  A change in loading conditions  as  described
above  is  associated  with  an  increment in LOADLEVEL and the eventual
partial unload with a decrement.  Increments and decrements are always 1
(except in the case of receiving INT:A described below).

    Strictly speaking  it  is  sufficient  to  know  the  range  of  gla
addresses  to  be  discarded,  but  unloading can be made much faster by
storing some extra information when the loadlevel is incremented.   Just
as  the  gla  is organised on a last-in, first-out basis so also are the
initialised stack and the loader's tables of entries.  Unloading can  be
vastly speeded up if the current values of the 'tops' of these areas are
noted.   When  the  loadlevel  is  incremented, then, we are effectively
taking a snapshot of  conditions  at  that  moment,  so  each  value  of
LOADLEVEL  has  an associated record, LLINFO, in which the required data
is kept.  When we  unload  a  loadlevel  then  we  discard  all  loading
information associated with it.

    Formally, each loadlevel has three associated integers:
   - the  offset  of  the  first  entry in loader's entry tables at this
     loadlevel
   - the address of the first byte of gla used at this loadlevel
   - the address of the first byte of initialised  stack  used  at  this
     loadlevel

    Currently,  loadlevel  is  defined as an integer in the range 0 - 31
and with each loadlevel there is an  associated  record,  LLINFO,  which
holds  the  addresses required at unload time.  Level 0 and level 1 have
predefined meanings.  Level 0 is the level at which 'permanently loaded'
files are loaded. (In this context  'permanently  loaded'  means  loaded
until  the  end of the current session or a call of RESETLOADER.  A file
is 'permanently loaded' if it is found via the subsystem base  directory
or  is  specifically  PRELOADed). 'Permanently  loaded' files have their
entries in a separate permanent entries table, use gla  taken  from  the
base  gla  and  initialised stack from the 'permanent initialised stack'
area.

    Loadlevel 1 is 'command level'.  Levels 1 to 31  use  the  temporary
entries  table,  the user gla and the 'temporary initialised stack area'
respectively.

    The programmer  cannot  directly  alter  LOADLEVEL  but  can  select
whether or not a file is to be permanently loaded.  The current value of
LOADLEVEL  is  returned  by  a  supplied function, CURRENTLL.  As stated
above, LOADLEVEL is normally incremented or decremented  by  1  but  the
loadlevel  will  revert  automatically  to  1  -  command level - on the
receipt of INT:A whatever the current value.

    To illustrate, consider the following  example: Suppose  we  have  a
user  written  command which makes several external references, at least
one of which will be found  via  the  subsystem  base  directory.   This
command  also  calls  CALL  at  some point.  The following events should
occur when the command is executed: (We restrict our  attention  to  the
loader entry tables for simplicity.)

    Just before the command is run then the permanent entries table will
contain  the  entry  point  names  of  any 'permanently loaded' files or
specially defined items  (see DATASPACE,ALIASENTRY).   The  loadlevel  0
entry  table  pointer  will point to the next free byte in the permanent
entries table.  The temporarily loaded entries table will be  empty,  so
the  the  loadlevel  1  entry table pointer will point to the first free
byte.  Since we are at command level then the loadlevel is 1.

    The command is then typed and loading commences.  The first file  to
be  loaded  is the file which contains the command just typed, and entry
point names from this file are added to the temporarily  loaded  entries
table.   We  have  assumed  that  this  file  contains  several external
references which were not already loaded and the loader  now  starts  to
search  for each in turn, loading more files as required.  Provided that
these references are not found through the subsystem base directory then
further entry points are added at loadlevel 1 to the temporarily  loaded
entries  table.   Finally  a  reference  is  encountered  which  can  be
satisfied by loading a file pointed at by the subsystem base  directory.
This  must  be  'permanently'  loaded  so  the  local loadlevel switches
temporarily to 0 and all the entries are added to the permanent  entries
table.  And so on until the load is complete.

    Note  that  the loadlevel 0 entry table pointer is not updated until
the load  has  completed  successfully  conclusion  for,  if  otherwise,
everything loaded by a failed load is unloaded.

    Execution of the code then begins and proceeds until CALL is called.
This  causes  a  jump  to  the  loader which has to load the entry point
CALLed.  Loadlevel 1 is 'frozen' and the loadlevel incremented to 2 with
the loadlevel 2 entry table pointer set to the next  free  byte  in  the
entries  table. If  the  CALL  causes  files to be loaded then the entry
point  information  is added to the temporarily loaded entries table (or
the  permanent entries table if found via the subsystem base directory).
Control is then passed to the code CALLed, which executes.  Assuming  no
failure,  control  is passed back to the loader which unloads everything
at loadlevel 2.  The  loadlevel  is  decreased  to  1  and  loadlevel  2
abandoned.   Execution  of  the  user  program  resumes  and proceeds to
termination at which everything loaded at loadlevel 1 is unloaded and we
are back where we began with  the  exception  that  there  may  be  more
permanently loaded material.
!>
!<Bound object files
!KEY

    Before  discussing  the  binding  of object files, a short resume of
object file structure would be in order.

    From the viewpoint of the loader, object files on  EMAS  consist  of
seven  distinct  areas  each  of  which  can  be  assigned to one of two
categories: shareable and unshareable.  The  object  file  in  total  is
shareable,  so  the initial stage in loading an object file is to create
the unshareable areas in private (unshared) space.  Five  of  the  seven
areas  are  normally  unshared;  four  -  PLT,GLA,UST  and INITCMN - are
assigned space in the 'user gla' which is a private file used solely for
procedure linking and data areas, and the fifth, INITSTK, an  area  from
the  initialised  stack area of the user stack.  The remaining two - the
CODE and SST - are usually,  though not always,  shareable.

    In essence, then, the loader requires the addresses of the  separate
object  file areas, which in turn boils down to the connect addresses of
three files - the object file, the user's gla file and the user's stack.
Now in the general case, none of these addresses is known in advance  so
the loader has to go to every location which requires an actual run time
address and plant the appropriate value.  This can be expensive as these
lists  of  'relocations' can be long and may involve extensive paging as
the loader  jumps  from  location  to  location  filling  in  addresses.
Obviously  if  it  was  possible to fix the addresses of the object file
areas  beforehand  then  all  the  relocations  could  be   done   once,
independently  of  the loader.  Loading the object file thereafter would
avoid the necessity of doing relocations.   This  process  is  known  as
'binding the object file' and can be done by the EMAS object file editor
MODIFY,  details  of  which  are available elsewhere.  Using MODIFY, the
user nominates two sites, one for the shareable areas and one for a file
to contain the four gla areas. (The user stack from  which  any  INITSTK
requests  must  be  satisfied  is  assigned  the same fixed site for all
users.) The utility  then  processes  the  object  file  and  obeys  the
relocation requests.  When a bound object file is loaded then the loader
checks  the shareable and unshareable preferred sites.  If the shareable
preferred site  is  free  then  the  object  file  is  disconnected  and
reconnected  at  that  site.  If the site is occupied the object file is
left where it is and all relocation requests involving the CODE  or  SST
are  executed.   If  the  unshareable  preferred  site  is  free  then a
temporary file, T#GLAnn where nn is a unique identifying  suffix  chosen
by the system, is created at that site and the PLT, GLA, UST and INITCMN
areas set up in it.  Should the site not be free then any available site
is  used  for the T#GLAnn file, the unshareable areas are set up and all
relocation requests involving these areas  are  honoured.   The  INITSTK
requests  are  handled  slightly  differently.  A user has only one user
stack so it follows that only one file can  claim  the  preferred  site.
All others will be assigned other areas within the initialised stack and
for  these  cases  all relocation requests will have to be done.  Loader
monitoring (#MONLOAD) will warn when a bound file  cannot  be  connected
at all its preferred sites.

!<Exceptional conditions
!KEY

   (Condition 1 refers to ALL object files, 2 only to bound files)

1.  Code  is unshareable if a) the area is flagged as such in the object
    file (rare) or b) the area crosses a segment boundary (A segment  is
    256K). This latter condition can arise if an object file is a member
    of  a  large (>256K) pd file and its CODE area straddles the segment
    boundary.   In  these  circumstances,  the  loader  will  create   a
    temporary file called T#CODEnn where nn is a unique suffix chosen by
    the  system,  and  copy  the  CODE  and  SST areas into it.  This is
    expensive and should be avoided if at all possible by suitable  file
    organisation.
    
        Note  that  pd  files  can  be  checked for object code crossing
    segment boundaries by the command ANALYSE(pdfilename,M)  which  will
    print a warning.
!PAGE

2.  Code cannot be connected at its preferred site if the object file is
    a  member  of  a  pd file, even if the preferred site is free.  This
    means that bound files should NEVER be collected into a pd file  for
    running.

    Note that any T#CODE or T#GLA files created during loading  will  be
destroyed when the file that gave rise to them is unloaded.
!>
!>
!<External References

    A  piece  of  code  can  refer to other pieces of code or data areas
external to it.  For each reference  there  is  an  associated  location
eight  bytes  long  in  the  gla  of  the  calling  routine into which a
'descriptor' to the called  item  must  be  placed  by  the  loader.   A
descriptor  consists  of  two integers.  The first contains fields which
describe the type, and for data descriptors, the length, of the item and
the second holds the address of the item.   For  a  code  reference  the
loader  must  plant the complete descriptor whereas for a data reference
the loader is only required to provide the address.  With some compilers
(e.g.  COBOL) and some non-EMAS generated 2900 object  code,  there  are
items  designated as 'single word references'.  These references are not
defined as either code or data references - although  in  practice  they
are  likely  be  one  or  the  other  -  and  indeed  the  loader has no
information available on their nature.  The loader is only  required  to
provide the address of these items.

    In  EMAS  2900  object  file  format, code references are flagged as
either  static  or  dynamic.   Static  references  are  expected  to  be
satisfied at the same time the file is loaded whereas dynamic references
are  only  satisfied  when  actually called.  Data references and single
word references are assumed to be static.

    However it is not always convenient or  desirable  to  accept  these
strictures  and  the LOADPARM command can be used to instruct the loader
to pursue a different course of action.  For instance, at load  time  it
may  be  desired  to  load  the  absolute minimum number of object files
necessary to do the desired run i.e. a reference would only be satisfied
if called, whether  it  started  life  as  a  static  or  as  a  dynamic
reference.   LOADPARM(MIN)  has the effect of treating all references as
dynamic.  Another possibility is that  even  after  a  complete  search,
there  are  still some static code or data references which could not be
found.  By default the load would fail but we may wish to run anyway and
take the chance that the unsatisfied references would not be called.  It
is not possible to leave the contents of the descriptor locations in the
gla untouched since a call to any  of  them  would  prove  catastrophic.
Similarly  it  is pointless to make them dynamic since a search for them
has already failed.  The solution is to  make  them  a  special  type  -
'unresolved'  -  which  will  ensure that the effect of a call will be a
controlled rather than a catastrophic  failure.   LOADPARM(LET)  follows
this course of action.

    It  is  fairly  obvious  how the loader can satisfy references while
loading files but it is not so obvious how a program can be  interrupted
in  full flow for the loader to do some more searching and loading, then
the program resume as though  nothing  had  happened.   To  do  this,  a
special  feature of the 2900 hardware, the hardware escape mechanism, is
used.  Dynamic and unresolved references have a special descriptor known
as an escape descriptor planted at the required  location  in  the  gla.
When the reference is called, the escape descriptor is recognised by the
hardware  which invokes the escape mechanism.  The net effect of this is
to suspend execution of the calling  routine  and  cause  a  jump  to  a
previously  nominated  piece  of  code  in  the loader.  The loader will
search for and load the entry, if appropriate, or will fail the  calling
routine  tidily.   If  the  loader  search  has been successful then the
escape descriptor in the gla is overwritten by  the  actual  descriptor,
the  environment  restored  exactly  as  it was at the moment the escape
mechanism was invoked and control is passed back to the called routine.
   N.B.  For most uses of the loader, dynamic references  do  not  occur
unless  they  are specifically requested.  The difficulties described in
the following subsections should not therefore affect the innocent user.
For those who want to use dynamic references,  loading  code  entries  -
routines,  functions,  subroutines  etc. -  is  safe  and reliable.  But
dynamic references to data should be avoided unless you are very sure of
what you are doing.

!<Dynamic Data References
!KEY

    Code  references  pose  no  problems  as  the  eight  bytes  of  the
descriptor   location   contain   no   information  and  can  be  safely
overwritten, however data references have the first four  bytes  already
assigned  to  the descriptor type and length and the second four contain
an offset which has to be added to the address supplied by  the  loader.
This  information  must  therefore  be  safely stored away by the loader
before the location can be overwritten by an escape descriptor and  must
be restored again exactly during the escape sequence.

    The  basic assumption behind the foregoing is, of course, that it is
possible to invoke the escape mechanism at the  appropriate  time.   The
trigger for this is the presence of an escape descriptor in the hardware
descriptor  register.   Calling  a  code reference will ensure that this
occurs, but whether  a  data  reference  does  or  not  depends  on  the
individual  compiler  writer.   As  was  pointed  out above, all that is
required to  satisfy  a  data  reference  is  an  address,  not  a  full
descriptor,  and  in  some  situations  the item may be addressed via an
offset from another register e.g. 'load the integer 10 bytes on from the
address in the CTB register'.  If this occurs the escape  descriptor  is
never  loaded  into the descriptor register, the escape mechanism is not
invoked and the program fails catastrophically.

    On EMAS however, for the currently most heavily used compilers, i.e.
IMP, FORTRAN and PASCAL, the  situation  is  not  as  bad  as  the  last
paragraph  might  suggest.  FORTRAN and PASCAL only refer to common data
areas which are always created by the loader at load time by default, so
dynamic data references will never arise.  IMP on the  other  hand  does
have  %extrinsic  data items and these do create dynamic data references
if the relevant loader parms are set.  Of  the  various  possible  types
only  extrinsic  records can cause trouble; all the others do invoke the
escape mechanism.  The problem can  be  avoided  by  ensuring  that  any
records  which  are shared among program modules are data entries in the
first module to be loaded.  Note, however, that if such a  reference  is
not  called  directly but the appropriate entry point happens to be in a
module which gets loaded to satisfy  a  different  reference,  then  the
dynamic data reference will be satisfied correctly.
!>
!<'Dynamic' Single Word References.
!KEY

    As  the  loader  does  not  have any information as to the nature of
single word references, then it cannot make them truly  dynamic  in  the
sense  that  code and data references can be made dynamic.  The solution
adopted has been to make them 'pseudo dynamic' by planting an impossible
address (-1) in the single word location in the gla.  The user is warned
of the dire consequences of calling the reference  but  the  program  is
allowed  to  run.   However,  if  a dynamic single word reference is not
called directly but happens to be in a module which is loaded to satisfy
a different reference, then the single word reference will be  fixed  up
correctly.

    A  program  is  never  allowed to run with an unresolved single word
reference.
!>
!<Possible states of an external reference.
!KEY

    From the above discussion it is possible to define and summarise the
four possible states for an external reference:

1.  Unsatisfied.
      The location of the descriptor to the reference  in  the  gla  has
  been  noted  but  the  entry  point  required to satisfy the reference
  either has not been searched for, or has been and not found.   Nothing
  has  been written to the descriptor location.  A program or routine is
  never allowed to run with unsatisfied references.

2.  Dynamic.
      Dynamic references  can  arise  in  several  ways: by  the  user's
  explicit  request  (LOADPARM  MIN),  or  by  the  programmer's request
  (%dynamicroutinespec, etc) or in complicated loading  situations  when
  some object code is unloaded while another module, which refers to it,
  remains loaded.
      If  a  reference is dynamic then the location of the descriptor to
  the reference has been fixed up with an escape descriptor.  The  entry
  point  to  satisfy the reference has not been searched for.  A program
  or routine  is  allowed  to  run  with  dynamic  references.   If  the
  reference  is  called  during  execution  then the escape mechanism is
  invoked which causes a jump to  the  dynamic  reference  code  in  the
  loader.  The loader will conduct a full search for the entry name.  If
  found  then  the  required entry will be loaded, the escape descriptor
  overwritten and execution resumed, otherwise a failure occurs.

3.  Unresolved.
      The location of the descriptor to the reference  in  the  gla  has
  been fixed up with an escape descriptor which, if accessed, will cause
  a  jump  to  the  unresolved  reference code in the loader.  The entry
  point required to satisfy the reference may have  been  searched  for,
  but if it has then it has not been found.  A program or routine may be
  allowed  to  run  with  unresolved  references,  but  only if the user
  explicitly requests it (by LOADPARM LET).  If the reference is  called
  then the escape sequence is entered, no searching is performed and the
  program or routine fails tidily.

4.  Satisfied.
      A reference is satisfied when the location of the descriptor to
  the reference in the gla has been fixed up with a descriptor to an
  entry point of the same name and type.  Normally a satisfied reference
  is of no further interest to the loader, but there are special
  circumstances, referred to in 2 above, when the loader has to remember
  where specific satisfied references occurred.  This is in case the
  reference has to be 'unfixed' and made dynamic.
!>
!<Loader action on encountering an alias
!KEY ALIAS

    This  is  best  illustrated  in parallel with an example.  Suppose a
loader search has been initiated for entry point AA and further  suppose
that  there  are  3  user  nominated directories in the searchdir list -
SEARCHDIR1, SEARCHDIR2 and SEARCHDIR3.  The loader searches in the order
given in Note 1.

    Suppose AA is not loaded and the loader encounters the  alias  AA=BB
in  the  active  directory.   The general rule is that the loader always
follows the right hand side of the alias but  stores  an  'alias  branch
record'  on  a  small,  private, last in - first out stack.  This record
contains the l.h.s. of the alias and an integer  to  indicate  in  which
directory the alias occurred.  The stack can hold up to 10 records.

    If  a  chain of aliases comes to a dead end then the loader pops the
last record on the stack.  The last l.h.s. is restored  and  the  search
for  it  resumes in the next directory down the search list from the one
where the alias occurred.  When a new  alias  occurs  the  loader  first
checks  the stack of alias branch records.  The failure 'Alias chain too
long' will occur if the stack is already full.  If an  identical  record
appears  on  the  stack then a closed loop of aliases has been detected,
e.g.  A=B,B=C,C=A, and a failure is reported.  Both  of  these  failures
will  print  the  current  alias  branch  record  stack  for  additional
information.  If neither failure happens then a new alias branch  record
is  pushed  on  to the stack and the search resumes for the r.h.s of the
alias at the top of the search list.

    To return to the example, we push an alias branch record on  to  the
stack  and  start looking for BB at the top of the search list (i.e. the
system entries).  Suppose we find the further alias BB=CC in SEARCHDIR2.
A new record is pushed on to the stack and we start  searching  for  CC.
Suppose  no  entry point CC is found.  We have reached a dead end so the
loader pops the top record on the stack to find  out  what  spawned  the
search  for CC.  This was the alias BB=CC in SEARCHDIR2 so we restore BB
and start searching for it in SEARCHDIR3.  Should BB not be  there  then
the  stack  is popped again and we find that this alias was generated by
AA=BB in the active directory.  AA is restored and the search resumes in
the subsystem base directory.  And so on until we find a file to load or
exhaust the search.

    Although some time has  been  taken  to  describe  what  happens  in
complex situations, it is unusual to find an alias chain longer than 1.
!>
!>