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