Since OpenVMS does make some distinction between the capabilities of a batch queue and those of a server queue, there are several parameters used on a typical SUBMIT command which will not carry over to the Process Symbiont. Parameters such as /LOG, /NOPRINT, or /WSEXTENT will result in an informational message
%JBC-I-ITMREMOVED, meaningless items removed from requestThis message can generally be ignored. Some PMDF components may produce this message as well, but will nevertheless function properly.
There is currently no way to specify batch job process parameters such as /WSEXTENT on jobs submitted to a PMDF Process Symbiont queue. The working set parameters used will be those specified in the system authorization file for the username under which PMDF jobs are submitted, typically SYSTEM. An informational message will be displayed and the parameter will be ignored.
The Process Symbiont is not intended as a general purpose replacement
for OpenVMS batch queues, and is only supported for use with the
standard PMDF procedures master.com
,
post.com
, and return.com
. Procedures
submitted to a process queue will execute under the username of the
submitter as would any batch job. The detached server process created
for executing jobs queued to the queue queue-name
will unconditionally log output to the file
PMDF_LOG:task_server_queue-name.logIf the submitting user does not have write access to the PMDF log directory, then the server process will not be able to execute. This effectively limits the Process Symbiont queue to use only by privileged users or the PMDF account, if present, which owns the PMDF log directory. Accordingly, it is suggested that PMDF Process Symbiont queues be protected against user write access to prevent inadvertent loss of user print or batch jobs, (e.g., as shown in the sample INITIALIZE/QUEUE/.../PROTECTION=... commands shown earlier this chapter). For instance, some OpenVMS components or layered products may detect PMDF Process Symbiont server queues and believe that they are print queues. In particular, the DECwindows print facility may send print jobs to Process server queues since it defaults to using any print or server queue that it sees first in an alphabetic list.
Information is passed from the symbiont to the task server process
through the process name. Therefore, a user or system-wide
login.com
which modifies the process name will prevent the
task server process from functioning correctly. Such a
login.com
can avoid adverse effects by checking the
process mode:
$ if F$MODE() .eqs. "OTHER" then exit