- Integrated Systems
- About Us
- Integrated Systems
- About Us
12-09-2008 06:06 AM
Example output from DIR/SIZ=ALL
12-09-2008 06:11 AM
They are not present on my standard systems. I would suggest enabling accounting and track down which processes account for the file creation.
- Bob Gezelter, http://www.rlgsc.com
12-09-2008 06:17 AM
Could be a cxx program (check Heins answer).
The 'system' call as used by the cxx program is implemented internally using a system library routine called LIB$SPAWN. This in tunr uses a system service SYS$CREPRC to get the work done. To communicated the SPAWN call uses MAILBOXES. Your environment will define where those mailboxes go. If your environment does NOTHING then all will be well. The mailbox is created using LNM$TEMPORARY_MAILBOX and when supprocess opens SYS$OUTPUT it will find the mailbox through LNM$FILE_DEV. If it can not find the mailbox, then this 'funny' filename will be used.
12-09-2008 06:29 AM
12-09-2008 06:57 AM
I found also many of those Logfiles in my TCPIP$SSH Directory. All those files contain something like this:
add nodename.domain.CH:10.0 MIT-MAGIC-COOKIE-1 1f9322da8a87c80d1ac668d05dcf3307
Could it be that one of your user accounts has SYS$SYSTEM as it's login directory?
12-09-2008 07:00 AM
No, the sys$login for the system account is [sysmgr] and I don't have SSH enabled.
12-09-2008 12:39 PM
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_
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.
12-09-2008 12:49 PM