!TITLE Errors and warnings associated with loading
!KEY ERRORS

    Usually   error   and  warning  messages  are  self-explanatory  but
sometimes it is not possible to convey the complexity of  a  failure  or
how  it  arose  in a short error message, let alone what to do about it.
In this section some of the less obvious errors  and  warnings  will  be
enlarged   upon.    Most  of  the  theoretical  background  to  specific
situations is dealt with in other sections and the explanations  can  be
further expanded by referring to them.

!<Errors
!KEY

Note 1. Loader action on encountering mismatching data entry/data
        reference lengths.

    A  data  reference  in an object file always has a length associated
with it to tell the loader how  long  the  expected  data  entry  should
be. If  there  is  a  data  entry of the correct name already loaded but
whose length does not match the data references expected value then  the
loader  may either a) do nothing, b) issue a warning or c) terminate the
load with an error. The action followed in any particular  case  depends
both  on  the  loadparms set for the load and the source language of the
object file which is being loaded when the  mismatch  occurs. The  rules
followed by the loader are tabulated below:
!PAGE

1.      All data entries except common entries.


Loading conditions     Ref len > Ent len    REF len < Ent len

Default(Cascade)             FAIL              WARN (except FORTE)

LET                          WARN              WARN (except FORTE)

MIN or call on dynamic
ref with default
loadparms                    FAIL              WARN (except FORTE)

MIN+LET or call on dynamic
ref with LOADPARM(LET) set   WARN              WARN (except FORTE)
!PAGE

2.      Common entries (inc.  FORTRAN blank common - F#BLCM).


Loading conditions     Ref len > Ent len    REF len < Ent len

Default(Cascade)                *                 -

LET                             *                 -

MIN or call on dynamic
ref with default
loadparms                    FAIL              WARN (except F#BLCM)

MIN+LET or call on dynamic
ref with LOADPARM(LET) set   WARN              WARN (except F#BLCM)

* Common  is  created  at  the end of a cascade load if no data entry is
  found and is always made as long as the longest reference.
!PAGE

1. 'Unable to create USERSTACK - '
   'Create AUXSTACK fails - '
   'Create USER GLA fails - '

What happened:
   When  you  first  run  commands  which are not in the subsystem,  the
   loader will create  up  to  3  temporary  files  on  your  behalf  as
   required.    These   are   the   user  stack(T#USTK),  the  auxiliary
   stack(T#ASTK) and the user gla(T#UGLA).  The attempt  to  create  the
   file named in the error message failed.

What to do:
   The  second half of the message should indicate what the problem is -
   e.g. too many files connected, too  little  file  space,  etc. -  and
   action  should  be  taken accordingly.  You cannot run whatever it is
   you wanted to run  until  the  file  which  couldn't  be  created  is
   created.
!PAGE

2. 'Extend USERGLA fails - '

What happened:
   When the user gla file T#UGLA is set up it is quite small but has the
   capacity to extend itself as necessary up to a certain system imposed
   limit.  You have tried to exceed that limit.

What to do:
   The most likely cause of this failure is trying  to  load  a  program
   which  demands  huge  amounts  of space from the gla, e.g. very large
   arrays or common blocks.  You should find out why so  much  space  is
   being  requested and which object files are causing the problem.  You
   can set up common blocks in separate data  files  using  the  command
   DATASPACE if you are using FORTRAN.  Similarly, large internal arrays
   can  be made external (e.g.  %external in IMP, named common blocks in
   FORTRAN) and mapped on to data files with DATASPACE.
!PAGE

3. 'Base gla full - '

What happened:
   You have tried to 'permanently load' an object file and there is  not
   enough  space  in the base gla file to satisfy the gla requirement of
   the file.  This failure can occur if you use PRELOAD a lot.

What to do:
   If there are several files already permanently loaded then if you  no
   longer  require  them  call  RESETLOADER  to  unload  them.  This may
   release sufficient space on the base gla.  Failing that,  proceed  as
   in 2. above.
!PAGE

4. 'Loader tables full'

What happened:
   You  have  loaded  so  much  software  that  the  loader  tables have
   completely filled up.  This is an extremely unlikely failure.

What to do:
   Inform your local advisory service.  If you are  loading  FORTRAN  it
   may  be possible to suppress many of the entry points with the object
   file editor MODIFY.
!PAGE

5. 'Too little space for initialised stack'

What happened:
   The  user  stack  has  a  hardware  imposed  upper  limit  of   252K.
   OPTION(INITSTACKSIZE=nn)  reserves  whatever you request of this 252K
   to be used as initialised stack.  The area is used by some languages,
   especially FORTRAN, to store variables  between  calls  of  routines.
   Your  program  has requested more initialised stack than you have set
   up.

What to do:
   Increase the INITSTACKSIZE.  If you  turn  on  loader  monitoring  or
   ANALYSE  or  OBJANAL  the  object  files  you  can  find out how much
   initialised stack is being requested if you are  not  sure.   If  the
   problem  is  being  caused  by  cumulative  requests from a number of
   object files then LOADPARM(MIN)  may  be  worth  trying  if  you  are
   currently  on  default  loadparms  and  you  think that all the files
   loaded may not be called.  If you are still having problems  and  you
   are   a   FORTRAN   user  then  it  may  be  worth  recompiling  with
   PARM(MINSTACK).
!PAGE

6. 'Data ref ENTRY in FILE longer than entry and LOADPARM LET not set'

What happened:
   You  have  a  data entry called ENTRY already loaded.  A reference to
   ENTRY has been found in FILE which expects the length of ENTRY to  be
   bigger  than  it  actually  is.   Since  you  have  not  specifically
   permitted this  situation  (by  the  command  LOADPARM(LET)),  it  is
   treated as a fatal error.  See table in note 1.

What to do:
   You  could  set LOADPARM(LET), but this is potentially very dangerous
   since you may start overwriting other areas of store.  This is one of
   the classic ways of getting address errors which are  very  difficult
   to  trace.   If  you are using FORTRAN and the problem is mismatching
   common areas then you  are  probably  using  LOADPARM(MIN)  or  using
   PRELOAD.  In both, the first file with a data reference to ENTRY will
   cause  it  to  be  created with the length specified in the file.  If
   this is not the maximum length for ENTRY, then  at  some  point  this
   error  will  occur.   You  should  always  ensure  that  the  longest
   reference gets loaded first.
   
       If you are not a FORTRAN user then the best plan is to modify the
   software so that data entries and  their  references  have  the  same
   length.
!PAGE

7. 'Load initiated by dynamic call to ENTRY failed'

What happened:
   Your program made a dynamic call to ENTRY but the load failed.

What to do:
   There  will  be  an  error message immediately following this message
   which will give the reason for the failure.  The most common is  that
   the loader could not find a particular entry point.
!PAGE

8. 'Attempt to call unsatisfied ref ENTRY'

What happened:
   A  previous  search for ENTRY failed but as LOADPARM(LET) was set the
   reference was made unresolved.  You have tried to call it.

What to do:
   Depends whether you expected the failure.  You could provide a  dummy
   entry  point  or use one of the alias facilities if you must persist.
   It would be better however to provide the expected software.
!PAGE

9. 'Inconsistent directory entry for ENTRY'

What happened:
   When the loader searched for ENTRY it was not loaded but a  reference
   to  it  was found in one of the directories in the search list.  When
   the loader loaded the file which the directory said  contained  ENTRY
   it found that it wasn't there at all.  This can happen when an object
   file  is recompiled with different entries but the directory in which
   it is inserted is not updated. (Note that if you recompile an  object
   file  which  is  inserted in to your active directory then the active
   directory is automatically updated.)

What to do:
   Find out which directory is inconsistent by repeating the  load  with
   monitoring  turned  on.   If  it's  one  of your own directories then
   update it, if it's a system directory e.g.  PUBLIC,  UKCLIB,  ERCLIB,
   CONLIB, SUBSYS etc then tell the Advisory Service who will notify the
   relevant  person  otherwise  send  a  TELL  message  or  MAIL  to the
   directory owner  suggesting  politely  that  the  directory  requires
   updating!
!>
!<Warnings
!KEY WARNINGS

1. 'Warning - connect directory fails DIRECTORY NAME'

What happened:
   At  log  on or when the active directory or searchdir list is changed
   the loader builds a new list  of  directories  it  must  search  when
   looking  for  entries.   One  of  the  files in the list could not be
   connected so it is not in the current search list.
!PAGE

2. 'Warning - Satisfying non-dynamic ref to ENTRY by entry at higher
   loadlevel.  Ref made dynamic'

What happened:
   The loader satisfied a static reference to ENTRY with an entry  point
   from  an object file which was certain to be unloaded before the file
   containing the reference.  To ensure that the reference did not point
   to a file  which  was  no  longer  loaded,  the  loader  changed  the
   characteristics of the reference to be dynamic.  See below.
!PAGE

3. 'Warning - Code ref to ENTRY made dynamic while unloading'
   'Warning - Data ref to ENTRY made dynamic while unloading'

What happened:
   The  file  which  contained entry point ENTRY has been unloaded but a
   reference to ENTRY has been found in  an  object  file  which  is  to
   remain  loaded.   The  reference  has  been unfixed and turned into a
   dynamic reference.  If the dynamic reference is called later then the
   loader will once  again  carry  out  a  full  search  for  ENTRY.   A
   reference which generated warning 2. above while loading will produce
   this warning at unload time.
   Beware of dynamic data references.
!PAGE

4. 'Code ref ENTRY made dynamic'
   'Data ref ENTRY made dynamic'

What happened:
   You  have  set  LOADPARM(MIN).   A static reference to ENTRY has been
   made dynamic.  Beware of dynamic data references.
!PAGE

5. 'Code ref ENTRY made unresolved'
   'Data ref ENTRY made unresolved'

What happened:
   You have set LOADPARM(LET).  A static reference to ENTRY could not be
   satisfied after a full search so the reference has  been  changed  to
   type  unresolved to allow the run to proceed.  If you attempt to call
   it you will get error 8.
       If this warning comes as an unpleasant surprise  then  check  you
   have  the  object  file  containing  ENTRY  inserted  in  one  of the
   directories  in  the  search   list.    Also   check   for   spelling
   inconsistencies.
!PAGE

6. 'n data ref(s) to ENTRY in FILE LONGER than current entry'
   'n data ref(s) to ENTRY in FILE shorter than current entry'

What happened:
   You  have  a data entry ENTRY already loaded.  There are n references
   to this entry in the file you are currently trying  to  load  (FILE).
   These  references expect ENTRY to be longer or shorter - depending on
   which message you got - than it actually is.
!PAGE

What to do:
   This depends on the loading conditions at the time.  Data  references
   longer  than the entry is by far the more serious condition (which is
   why 'LONGER' is output in capitals), since you may try to read  from,
   or  write  to, an area of store outwith the defined scope of the data
   entry.  It is very dangerous to  proceed  with  a  computation  under
   these circumstances unless you are quite confident that there will be
   no  problems.   You  will  only  get the 'LONGER' warning if you have
   LOADPARM(LET) set, otherwise such a condition will cause  termination
   of the load with error 6.
   
       The  'shorter'  condition  is usually less serious.  At least you
   won't be trampling over other areas of store, but nevertheless it  is
   always  worth looking into the reason for the mismatch.  While not as
   immediately dangerous as the 'LONGER' condition it might  still  mean
   that the run will provide erroneous results.
   
       When  in  doubt,  try  to  ensure  that  the  lengths of all data
   references have the same length as the entry.
!>
!<Warnings generated in loader monitoring
!KEY

1. 'Warning - CODE relocated - crosses segment boundary'

What happened:
   You  are  running an object file which is a member of a pd file.  Its
   CODE area straddles a segment(256K) boundary.  The loader is creating
   a file called T#CODE and copying the CODE and SST areas of the object
   file into it so that the file can be run.  This is highly inefficient
   and you should reorganise your pd file.
!PAGE

2. 'Warning - CODE flagged as unshareable and relocated'

What happened:
   The object file has told the loader that the CODE area is unshareable
   so the loader is taking the action described in 1.  There is  nothing
   you can do about this.
!PAGE

3. 'Warning - CODE not connected at preferred site'
   'Warning - GLA not connected at preferred site'

What happened:
   You  are  loading  a  bound  object  file  but  the  shared(CODE)  or
   unshared(GLA) areas respectively could  not  be  connected  at  their
   preferred  site.   The site is either occupied by another file or you
   are trying to run a bound file which is a member of a pd  file.   The
   loader  has  to  recalculate all the run time addresses for the named
   areas and plant them in the appropriate locations so there is a  loss
   in  efficiency.   If  you  are  going  to  run  the  file  again, try
   DISCONNECT(.ALL) before you do to maximise the  number  of  available
   sites.
!PAGE

4. 'Warning - ISTK not connected at preferred site'

What happened:
   You  are loading a bound object file but the initialised stack cannot
   occupy its preferred location.  There is only  one,  fixed,  location
   for  the  initialised  stack  since  the user stack is connected at a
   fixed address.  The warning was  generated  because  you  are  either
   permanently  loading  a  bound file or temporarily loading it and the
   preferred  location  is  already  in  use. (See  'EMAS  fundamentals'
   section  for  further  explanation of allocation of initialised stack
   for permanently and  temporarily  loaded  object  files).   Run  time
   addresses which refer to initialised stack are recalculated with some
   loss in loading efficiency.  It is not always possible to do anything
   about  this,  e.g. if you are loading >1 bound file, and even when it
   is it may not be worth doing.
!>