B,
Yes you can delete them. They're junk left over from [personal opinion] a bug in DCL.
The files are probably from batch jobs run in processes that redefine LNM$TEMPORARY_MAILBOX and execute PIPE commands. Here's what happens...
A PIPE command can result in the creation of multiple (sub)processes, one for each pipe segment. The output from the LAST pipe segment needs to feed back into SYS$OUTPUT for the main process. That's not a problem for an interactive process because the pipe subprocess can write directly to the (shareable) terminal owned by the master process.
However, in BATCH or NETWORK mode, or where SYS$OUTPUT is redirected to a file, that can't be done, as the file isn't shareable. Instead, DCL feeds the output into a mailbox, which the master process reads and echos to SYS$OUTPUT. The mailbox is pointed to by a logical name "DCL$OUTPUT_
" created in logical name table LNM$TEMPORARY_MAILBOX.
The catch is, DCL has at least two design flaws in this mechanism. The first is that LNM$TEMPORARY_MAILBOX is not propagated to the spawned subprocesses, so they can't translate the logical name. By RMS file name rules, that means the OPEN operation will create the DCL$OUTPUT_pid.LOG files that you see.
This has been fixed to some extent by forcing the logical name to be defined in LNM$JOB, regardless of LNM$TEMPORARY_MAILBOX. This change should reach a DCL or UPDATE patch for V8.3 and above, eventually (or may already be there, check the release notes).
The second flaw is the master process waits until after all the pipe processes have been created before creating the mailbox and defining the logical name. As such there is a timing window. If a pipe segment writes output too quickly it can happen before the mailbox is created, and generate the same file. I've been bitten by this when attempting to send data from intermediate pipe segments back to the master process (for example, writing log or debug information back to the master SYS$OUTPUT, rather than sending it down the pipe).
I have some rather convoluted code to find and wait for the DCL$OUTPUT device from intermediate segments. To my way of thinking this is a bug. The way I see it, every pipline must have an end pipe, and therefore must have a back channel to the pipe initiator, so I'd create it before any of the processes, and define the logical name so it's available to all segments and guaranteed to be ready, but DCL engineering don't see it that way.
You may find that adding a short delay at the beginning of your last pipe segment will fix the problem (or, rather, hide it ;-). Alternatively you can loop until you see a non-null translation for DCL$OUTPUT.
The attachment is a procedure to demonstrate the delay in creating the mailbox and logical name. SUBMIT it to a batch queue. The results are in the LOG file. Note that it does nothing if executed interactively.
A crucible of informative mistakes
