- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- DCL$OUTPUT_XXXXX.LOG files being generated
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-15-2006 02:06 AM
08-15-2006 02:06 AM
DCL$OUTPUT_XXXXX.LOG files being generated
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-15-2006 02:29 AM
08-15-2006 02:29 AM
Re: DCL$OUTPUT_XXXXX.LOG files being generated
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-15-2006 03:10 AM
08-15-2006 03:10 AM
Re: DCL$OUTPUT_XXXXX.LOG files being generated
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-15-2006 03:14 AM
08-15-2006 03:14 AM
Re: DCL$OUTPUT_XXXXX.LOG files being generated
DCL uses DCL$OUTPUT_
Volker.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-15-2006 03:21 AM
08-15-2006 03:21 AM
Re: DCL$OUTPUT_XXXXX.LOG files being generated
that may be it !
A system('dcl command') call will most likely be implemented as a LIB$SPAWN.
Volker.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-15-2006 04:55 AM
08-15-2006 04:55 AM
Re: DCL$OUTPUT_XXXXX.LOG files being generated
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-15-2006 04:58 AM
08-15-2006 04:58 AM
Re: DCL$OUTPUT_XXXXX.LOG files being generated
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-15-2006 05:10 AM
08-15-2006 05:10 AM
Re: DCL$OUTPUT_XXXXX.LOG files being generated
(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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-15-2006 06:45 PM
08-15-2006 06:45 PM
Re: DCL$OUTPUT_XXXXX.LOG files being generated
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-16-2006 12:37 AM
08-16-2006 12:37 AM
Re: DCL$OUTPUT_XXXXX.LOG files being generated
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-16-2006 01:03 AM
08-16-2006 01:03 AM
Re: DCL$OUTPUT_XXXXX.LOG files being generated
This is where the mailbox logical name will be created.
Why is is there? Someone opted to deviate from the standard there. What was the reason? Did they do a good job? what is the protection on that table? Has anything chnaged with this setup per chance right around when a new VMS version was installed? Double check the dates on the first dcl$output_xxxxx.log. Did they start exactly with the new VMS version or a day before or after?
Hein.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-16-2006 01:06 AM
08-16-2006 01:06 AM
Re: DCL$OUTPUT_XXXXX.LOG files being generated
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-16-2006 01:18 AM
08-16-2006 01:18 AM
Re: DCL$OUTPUT_XXXXX.LOG files being generated
This table was created by a third-part application. The files started to be created after the VMS upgrade, and also the application upgrade (both of them where done at the same day). Maybe they changed the application setup.
I will check with them and let you know.
Fernando
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-16-2006 01:22 AM
08-16-2006 01:22 AM
Re: DCL$OUTPUT_XXXXX.LOG files being generated
show log/tab=lnm$temporary_mailbox should show YOUR job table. Because it shows something else, I think lnm$job in tab lnm$process_directory is pointing to the wrong table.
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-16-2006 01:34 AM
08-16-2006 01:34 AM
Re: DCL$OUTPUT_XXXXX.LOG files being generated
That woudl not be the cause, just a sign things are not cosher in the area of logical names.
Mostly I suspect the protection on the OMNI_BRASIL200_MBX_TABLE.
Check out:
$ show secu OMNI_BRASIL200_MBX_TABLE/class=LOGICAL_NAME_TABLE
Also... just eyeballing your logical name, your application seems to have 4 groups. Things come in 4: 41, 42, 43, 44.
Sometimes the first element is called 0: 200, 202, 203 and 204.
Notably this is the case for OMNI_BRASIL200_MBX_TABLE.
Is all software in agreement that it shoudl be 200, nor 201?
fyi, the defintion of
"LNM$PERMANENT_MAILBOX" = "LNM$SYSTEM"
"LNM$TEMPORARY_MAILBOX" = "LNM$JOB"
in
(LNM$SYSTEM_DIRECTORY)
are the same on my system.
Good luck,
Hein.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-16-2006 01:53 AM
08-16-2006 01:53 AM
Re: DCL$OUTPUT_XXXXX.LOG files being generated
200 is correct. At the past, we never though that we should increase the number of applications, so it started with 200. After a while, when we realized that we need to grow, we chose to go for 202, otherwise 201 would be system 2, 202 system 3 and so on, and things could be confusing.
Here's the result for the sho secu command:
Br200_GUNGA> show secu OMNI_BRASIL200_MBX_TABLE/class=LOGICAL_NAME_TABLE
OMNI_BRASIL200_MBX_TABLE object of class LOGICAL_NAME_TABLE
Owner: [BRASIL200]
Protection: (System: RWCD, Owner: RWC, Group: R, World)
Access Control List:
(IDENTIFIER=OMNI_BRASIL200_CONTEXT,ACCESS=READ)
The sho full results asked by Wim are attached.
I'm contacting my vendor, and let you know.
Fernando
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-16-2006 02:19 AM
08-16-2006 02:19 AM
Re: DCL$OUTPUT_XXXXX.LOG files being generated
The outputs seem to have been created online, not in a in batch job. That may or might not distort the result.
(in a bathc job sys$output points to a disk, and "tt" to nla0:. Both point to a terminal in the example.
The owner for table 204 is different from the rest. Is that the one with trouble?
(OMNI_BRASIL204_MBX_TABLE) [Owner=[OMNINET,BRASIL204]]
(OMNI_BRASIL204_TABLE) [Owner=[304,101]]
The others all have [BRASIL20x] as owner.
back to real work...
Hein.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-16-2006 02:25 AM
08-16-2006 02:25 AM
Re: DCL$OUTPUT_XXXXX.LOG files being generated
Wim
(back to school to restudy how the logicals work)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-22-2009 11:24 AM
05-22-2009 11:24 AM