Guardian Procedure Calls Reference Manual

• Library considerations
A "user library" is an object file containing one or more procedures. Unlike a program, it
contains no main procedure (no program entry point). Native user libraries can contain global
instance data; TNS user libraries cannot.
In a TNS process, unresolved symbols in the program are resolved first in the user library, if
any, and then in the system library.
In a non-PIC native process (TNS/R only), a user library is a shared runtime library (SRL);
unresolved symbols in the program are resolved first in the user library, if any, then in any
other SRLs loaded with the program, and finally in the native system library. Symbols bound
at link time to a specific named SRL will be resolved only in that SRLs at load time.
In a PIC process, a user library is a dynamic-link library (DLL); unresolved symbols in the
program are resolved first in the user library, if any, then in any other DLLs loaded with the
program, and finally in the native system library. On TNS/E systems, the “native system
library” is the set of implicit DLLs. At load time, symbols are bound to the first definition found
in the search list of the program.
If no library specification is provided (library-file or library-file-length is omitted or
library-file-length is 0), the process runs with whatever library file, if any, is specified
in the program file.
The library-file parameter and a positive library-file-length, specify a library
file name; a library-file-length of -1 specifies that no library is used.
If the library specification differs from what is recorded in the program file, the process must
have write access to the program file. For a TNS or non-PIC native process, a different library
specification used in a successful PROCESS_CREATE_ invocation replaces the one in the
program file; if an instance of the program is already running that replacement cannot occur
and a library conflict error is reported. For a PIC process, the library specification in the
program file is not replaced, so multiple processes can be running the same program with
different libraries simultaneously.
The association of a library with a program file can be recorded in the program file by the
Binder or linker.
For more information about building TNS user libraries, see the Binder Manual. For more
information about building non-PIC TNS/R SRLs, see the nld Manual and the noft Manual. For
more information about building PIC TNS/R DLLs, see the ld Manual. For more information
about building PIC TNS/E DLLs, see the eld Manual and the enoft Manual. For more information
about loading PIC programs and DLLs, see the rld Manual.
• Device subtypes for named processes (process subtypes)
The device subtype (or process subtype) is a program file attribute that can be set by a TAL
compiler directive at compile time, nld flag at link time, or Binder command at bind time.
You can obtain the device type and subtype of a named process by calling
FILE_GETINFO[BYNAME]_, FILEINFO, or DEVICEINFO.
Note that a process with a device subtype other than 0 must always be named.
There are 64 process subtypes available, where 0 is the default subtype for general use. The
other subtypes are as follows:
are reserved for definition by HP. Currently, 1 is a CMI process, 2 is a security monitor process, 30
is a device simulation process, and 31 is a spooler collector process. Also, for subtypes 1 to 15,
1 to 47
PROCESS_CREATE_ rejects the create request with an invalid process subtype error unless the caller
has a creator access ID of the super ID, or the program file is licensed, or the program file has the
PROGID attribute set and an owner of the super ID.
are for general use. Any user can create a named process with a device subtype in this range.48 to 63
For a list of all device types and subtypes, see Appendix A: Device Types and Subtypes.
PROCESS_CREATE_ Procedure (Superseded by PROCESS_LAUNCH_ Procedure) 993