Re: DCL$OUTPUT_XXXXX.LOG files being generated

So what is this "OMNI_BRASIL200_MBX_TABLE"
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.

Note that your lnm$file_dev is defined twice with ifferent values. 1 exec and 1 super.

Wim

Wim

Hein

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

May be post a show log/tab=*/fu too.

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

Wim

As Wim noticed the [exec] definition for LNM$FILE_DEV is probably wrong.
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.

Hein,

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

Fernando,

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.

Are all the users with the same uic or in the same group ? If not the same uic, I think the protection on OMNI_BRASIL200_MBX_TABLE for group users should be rw instead of r.

Wim
(back to school to restudy how the logicals work)

Wim

tks.