Guardian Procedure Calls Reference Manual (G06.25+)
Guardian Procedure Calls (P)
Guardian Procedure Calls Reference Manual—522629-013
12-193
PROCESS_SPAWN_ Procedure
3. The caller process receives the processor down message from processor 6.
At this point, the caller process does not know whether its OSS child process
still exists, because the child process could have migrated from processor 2 to
processor 6. The caller process calls PROCESS_GETINFOLIST_ with the
OSS process ID of the child process. PROCESS_GETINFOLIST_ returns
error 4 indicating that the specified process does not exist.
4. The caller process receives the process deletion message with a -12
completion code (indicating that the child process has migrated to a new
process handle by calling one of the OSS
tdm_exec set of functions), but the
child process no longer exists.
Creator Access ID and Process Access ID
The creator access ID (CAID) of the new process is always the same as the process
access ID (PAID) of the creator process. The process access ID of the new process is
the same as that of the creator process unless the program file has the PROGID
attribute set; in that case, the process access ID of the new process is the same as the
Guardian user ID of the program file’s owner, and the new process is always local.
Compatibility Considerations
•
If the new process is unnamed, it must be run at a low PIN if it is to be accessible
to processes which cannot access high-PIN processes.
•
If the new process has a high PIN and also has a name with up to five characters
(not counting the /G/), it is accessible to any process running on the same system.
•
For further information on compatibility, refer to the Guardian Programmer’s Guide
and the
Guardian Application Conversion Guide.
•
If a client attempts a nontrithroughl call to the OSS chroot() function, the client
cannot create remote processes, because
/E will not be visible.
DEFINE Considerations
•
DEFINEs are propagated to the new process from either the process context of the
caller, from a caller-supplied buffer containing DEFINEs collected by calls to the
DEFINESAVE procedure, or from both of these. DEFINEs are propagated to the
new process according to the DEFINE mode of the new process and the
propagation option specified in the Z^CREATEOPTIONS field of the
process_extension parameter. If both sets of DEFINEs are propagated and
both sets contain a DEFINE with the same name, the DEFINE in the caller-
supplied buffer is used. When a caller is creating its backup, the caller’s DEFINEs
are always propagated, regardless of the options chosen.
The =_DEFAULTS DEFINE is always propagated, regardless of the options
chosen. If the DEFINE buffer contains a =_DEFAULTS DEFINE, that one is
propagated; otherwise, the =_DEFAULTS DEFINE in the caller’s context is
propagated.