Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

DCL$OUTPUT_<PID#>.LOG

 
B Novak
Advisor

DCL$OUTPUT_<PID#>.LOG

I've noticed that there are a lot of files named in the format DCL$OUTPUT_.LOG in the directory SYS$SYSDEVICE:[SYSx.SYSEXE]. They are all zero blocks in size. Does anyone know where these come from and ... can I just delete these things?

Example output from DIR/SIZ=ALL
DCL$OUTPUT_2121216A.LOG;1 0/0
DCL$OUTPUT_21214320.LOG;1 0/0
Any temporary fix in place longer than 6 months becomes permanent.
12 REPLIES 12
Robert Gezelter
Honored Contributor

Re: DCL$OUTPUT_<PID#>.LOG

Bob,

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
Wim Van den Wyngaert
Honored Contributor

Re: DCL$OUTPUT_<PID#>.LOG

B Novak
Advisor

Re: DCL$OUTPUT_<PID#>.LOG

Sorry... OpenVMS V7.3-2
Any temporary fix in place longer than 6 months becomes permanent.
Wim Van den Wyngaert
Honored Contributor

Re: DCL$OUTPUT_<PID#>.LOG

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1051563

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.

Wim
Wim
B Novak
Advisor

Re: DCL$OUTPUT_<PID#>.LOG

Thanks for the replies. Wim you pointed me in the right direction. I'll have to do some digging to find out where "it's broke." Points to be assigned!

Cheers!
Bob
Any temporary fix in place longer than 6 months becomes permanent.
B Novak
Advisor

Re: DCL$OUTPUT_<PID#>.LOG

Thanks to all for the replies!

Bob
Any temporary fix in place longer than 6 months becomes permanent.
Heinz W Genhart
Honored Contributor

Re: DCL$OUTPUT_<PID#>.LOG

Hi Bob

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?

Regards

Geni
B Novak
Advisor

Re: DCL$OUTPUT_<PID#>.LOG

Geni,

No, the sys$login for the system account is [sysmgr] and I don't have SSH enabled.

Bob
Any temporary fix in place longer than 6 months becomes permanent.
John Gillings
Honored Contributor

Re: DCL$OUTPUT_<PID#>.LOG

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
John Gillings
Honored Contributor

Re: DCL$OUTPUT_<PID#>.LOG

Another procedure for demonstrating this issue. SUBMIT PIPE_BUG to deliberately create a DCL$OUTPUT file. Remove comments to investigate different aspects of the issue.
A crucible of informative mistakes
B Novak
Advisor

Re: DCL$OUTPUT_<PID#>.LOG

John,

Thanks for the detailed reply as well as the attachements!

Bob
Any temporary fix in place longer than 6 months becomes permanent.
B Novak
Advisor

Re: DCL$OUTPUT_<PID#>.LOG

John,

Thanks for the detailed reply as well as the attachments!

Bob
Any temporary fix in place longer than 6 months becomes permanent.