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 request

This message can generally be ignored. Some PMDF components can 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.log

If 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 can detect PMDF Process Symbiont server queues and believe that they are print queues. In particular, the DECwindows print facility can 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