DCL$OUTPUT_XXXXX.LOG files being generated

Hey Guys,

I have a cluster of DS-25 running OpenVMS 7.3-2, and I just find out that since my upgrade from 7.3-1 to 7.3-2 there are hundreds of DCL$OUTPUT*.LOG files being created at an specific common directory. I read somewhere that this was an old VMS bug (from 7.1), and I'm not sure how can I fix the problem. Can you give a piece of advice?

Regards,

Fernando Mühe

18 REPLIES 18

The Wizard mentions this in:

http://h71000.www7.hp.com/wizard/wiz_9681.html

As you say, supposedly it was fixed.

Please clarify best you can under what circumstances those files appear to be created?
1) size/contents? empty or command output or error output?
2) date&time ? corresponds with which activity?
3) owner?

This may have something to do with MAILBOXES and LOGICAL NAME TABLES and LNM$TEMPORARY_MAILBOX and such.

Once you identify the job(s) triggering this, check out the (SY)LOGIN.COM for those jobs. If need be, do some experiments after pruning down those LOGIN.COM files to a bare mimimum, running a minimal task (like "show time")

fwiw,
Hein.

Hein,

Thanks for answering.

These files are very small files (1 or 2 blocks only) with command outputs of batch job processes that run every hour. Sometimes, there are different versions of the same file. Please see an example of the file content:

%PURGE-I-FILPURG, $21$DKA100:[REPORTS41.MUF]CUSTNOVO.OUT;1291 deleted (18078 blocks)

I'd also checked the owner's LOGIN.COM, and there is nothing there that could generate that command output. The other .COM's I checked have some purges, but none of them for that particular file CUSTNOVO.OUT.

However, I could be able to trace which process is generating that particular command output. It's an EXE file, compiled from a CXX source with a call like this

system("purge muf:custnovo.out")

It seems that the 'purges' inside COM files are not generating DCL$OUTPUT's, but the embedded 'purges' inside EXE files are.

Any clues?

Fernando

Fernando,

DCL uses DCL$OUTPUT_ logical names for output mailboxes in conjunction with SPAWN. This may at least explain the circumstances for using the DCL$OUTPUT_ name.

Volker.

Fernando,

that may be it !

A system('dcl command') call will most likely be implemented as a LIB$SPAWN.

Volker.

Fernando,

these temporary files should be named DCL$OUTPUT_xxxxxxxx - where xxxxxxxx is the PID (Process ID) of the parent process calling LIB$SPAWN. You should be able to verify this using the ACCOUNTING data.

Volker.

Volker,

Sorry to ask, but... what does it mean? I'm afraid my skills aren't good enough to realize what is happening and what should I do...

Fernando

Fernando,

(welcome to the OpenVMS forum btw!)

What it means is that you need to go back to my reply and carefully re-read it twice over.

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.

in your script, just before the image with the purge, do a SHOW LOG *
and/or specifically

$ show log/table=LNM$TEMPORARY_MAILBOX
and
$ show log/table=LNM$FILE_DEV

LNM$TEMPORARY_MAILBOX should probaly be LNM$JOB...
And that in turn SHOULD be part of LNM$FILE_DEV.

If it is not someone broke it!
Solicit help from you local sys admins!
(is that you? Then start thinking and searching :-)

Hein.

Fernando,

Very probably Hein is right but if not, check the quotas of the process running the program that does the system() call.

Or even privs (tmpmbx but never tried living without that one).

Or channelcnt (anal/system , set proc/id=xxx , evaluate @ctl$gl_chindx and compare with mc sysgen show channelcnt).

Or system memory (sh mem/pool and check free and largest).

Wim

Wim

Hein

Thanks for the welcome! I changed the script as you told, results attached. It seems that you're right...

However, I found LNM$TEMPORARY_MAILBOX defined as LNM$JOB inside LNM$SYSTEM_DIRECTORY (see file attached).

It seems that something is missing somewhere...

Fernando