| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3862.1 | | TRM::KWAK | | Tue Oct 06 1992 17:06 | 142 |
| RE: .0
I have issued the following command to check out your problem from FCL:
MCC> sho domain .mko.domain.nei-nh mem * all char
Domain TEMTY_NS:.mko.domain.nei-nh
AT 6-OCT-1992 13:43:23 Characteristics
No such entity: Domain TEMTY_NS:.mko.domain.nei-nh
Unknown Entity = Domain
TEMTY_NS:.mko.domain.nei-nh
MCC> sho domain dec:.mko.domain.nei-nh mem * all char
Domain DEC:.mko.domain.nei-nh Member DEC:.mko.DOMAIN.JOE
AT 6-OCT-1992 13:43:30 Characteristics
Examination of attributes shows
Member Type = Static
Member Entity = Collector DEC:.mko.DOMAIN.JOE
Domain DEC:.mko.domain.nei-nh Member DEC:.MKO.BR.MKO1_9028
AT 6-OCT-1992 13:43:33 Characteristics
Examination of attributes shows
Member Type = Static
Member Entity = Bridge DEC:.MKO.BR.MKO1_9028
Domain DEC:.mko.domain.nei-nh Member DEC:.MKO.BR.MKO1_9034
AT 6-OCT-1992 13:43:34 Characteristics
Examination of attributes shows
Member Type = Static
Member Entity = Bridge DEC:.MKO.BR.MKO1_9034
Domain DEC:.mko.domain.nei-nh Member DEC:.MKO.BR.MKO1L1BRL101
AT 6-OCT-1992 13:43:35 Characteristics
Examination of attributes shows
Member Type = Static
Member Entity = Bridge
DEC:.MKO.BR.MKO1L1BRL101
Domain DEC:.mko.domain.nei-nh Member DEC:.MKO.BR.MKO1H1BRH101
AT 6-OCT-1992 13:43:36 Characteristics
Examination of attributes shows
Member Type = Static
Member Entity = Bridge
DEC:.MKO.BR.MKO1H1BRH101
Domain DEC:.mko.domain.nei-nh Member DEC:.MKO.BR.MKO2G2BRG201
AT 6-OCT-1992 13:43:36 Characteristics
The requested operation cannot be completed
MCC Routine Error = %MCC-E-NOATTRIB, no such DNS
attribute
MCC>
From the above result, the last domain member successfully returned is
DEC:.MKO.BR.MKO2G2BRG201. And MCC found a problem in reading the next
domain member.
Now let's try to find the erroneous domain member.
The domain members information is stored in DNS$Members attribute of
MCC primary domain object and its extensions. In your case the MCC
primary domain object is DEC:.mko.domain.nei-nh and its extensions are
DEC:.mko.domain.nei-nh_MCC_EXT000, DEC:.mko.domain.nei-nh_MCC_EXT001,
and etc. The MCC_DOM_EXT_LIST attribute of the primary domain object
stores the list of domain extensions.
In order to look for domain members using DNS$Control, I issued the
following command:
DNS> sho obj DEC:.mko.domain.nei-nh attr DNS$MEMBERS
Member _____ DEC:.mko.DOMAIN.JOE
Timestamp _ 3-SEP-1992 12:58:35.90 aa-00-04-00-de-0c
DNS> sho obj DEC:.mko.domain.nei-nh_MCC_EXT000 attr DNS$MEMBERS
Member _____ DEC:.MKO.BR.MKO1_9028
Timestamp _ 9-SEP-1992 14:48:02.12 aa-00-04-00-de-0c
Member _____ DEC:.MKO.BR.MKO1_9034
Timestamp _ 9-SEP-1992 14:50:08.64 aa-00-04-00-de-0c
Member _____ DEC:.MKO.BR.MKO1L1BRL101
Timestamp _ 10-SEP-1992 18:40:13.71 aa-00-04-00-de-0c
Member _____ DEC:.MKO.BR.MKO1H1BRH101
Timestamp _ 10-SEP-1992 18:42:48.42 aa-00-04-00-de-0c
Member _____ DEC:.MKO.BR.MKO2G2BRG201
Timestamp _ 10-SEP-1992 18:46:32.87 aa-00-04-00-de-0c
Member _____ DEC:.MKO.SLEDGE
Timestamp _ 2-OCT-1992 13:04:20.39 aa-00-04-00-de-0c
Member _____ DEC:.MKO.CO.M1_33
Timestamp _ 2-OCT-1992 13:24:03.16 aa-00-04-00-de-0c
Member _____ DEC:.MKO.TS.M1F221
Timestamp _ 2-OCT-1992 13:30:49.99 aa-00-04-00-de-0c
Member _____ DEC:.MKO.VOGLIO
Timestamp _ 2-OCT-1992 13:36:25.98 aa-00-04-00-de-0c
Member _____ DEC:.MKO.E2BIG
Timestamp _ 2-OCT-1992 13:52:35.15 aa-00-04-00-de-0c
Member _____ DEC:.MKO.ST.M1F221
Timestamp _ 2-OCT-1992 14:00:04.84 aa-00-04-00-de-0c
I can see the domain member DEC:.MKO.BR.MKO2G2BRG201 in the list.
The next domain member is DEC:.MKO.SLEDGE.
Checking out the DNS object DEC:.MKO.SLEDGE, I found that the object
was Phase4 node (MCC_Class = 0xC (=12)). But it is missing binary
MCC attribute (%X4D43435F01000C00000.....) which stores all the
identifiers. This attribute is added during MCC registration.
When this attribute does not exist, you will get %MCC-E-NOATTRIB error
message.
It seems to me that the node4 DEC:.MKO.SLEDGE was incompletely
registered (due to Access control?).
In order fix your problem:
MCC> delete domain .mko.domain.nei-nh mem DEC:.MKO.SLEDGE
OR (if you want the nodee DEC:.MKO.SLEDGE in your domain)
MCC> register node4 DEC:.MKO.SLEDGE syn sledge
--> if the above mcc command does not work, do following: <--
DNS> delete object DEC:.MKO.SLEDGE
MCC> register node4 DEC:.MKO.SLEDGE syn sledge
William
|
| 3862.2 | fixed, but it shouldn't happen | BRAT::BUKOWSKI | | Wed Oct 07 1992 15:40 | 18 |
| William,
Thanks a million. That made sense and it worked. I have been
having problems registering node4 entitiies in the namespace and
sledge was the only one that happened to make it to the icon state
(partially registered). In my investigations of why I couldn't
register node4's I came across the netnode_remote.dat and
netnode_local.dat access control issue which I was going to try and
work around as soon as I had the map working again. If the access
control realy is the cause of this partial registration which
caused the troubles that I just had, then why do we allow partial
registration for node4's? Or why don't we document the need for proxy
to the netnode_xxxxx.dat files as a prerequisite? Or can we
change the node4 am/registration FM so that I doesn't need proxy?
Mike
|
| 3862.3 | | TRM::KWAK | | Wed Oct 07 1992 16:33 | 26 |
|
RE: .2
I think the reason for the partial registration is that you did not
have full access to the DNS object DEC:.mko.sledge becuase I did not
see the binary attribute mentioned in .1
(%X4D43435F11000C000000000000000000000000000000000000).
It seems that the DNS object was created before you used MCC
registration. What MCC does in such case is to add MCC_Class,
MCC_Version, MCC_UID, DNS$ACS, and the binary attribute in sequence.
(More operations happen after this). This sequence has to be
successfully completed for the node to be 'partially registered'.
If the sequence fails, MCC tries to delete the DNS object as a rollback
ONLY IF the object is created by MCC.
The MCC_Class, MCC_Version and MCC_UID attributes exists for the
DEC:.mko.sledge. But the binary attribute does not exist.
This means that modifying/writing DNS$ACS attribute failed.
In DNS, you need to have the full access rights (READ WRITE DELETE TEST
CONTROL) in order to modify DNS$ACS attribute. It looks like that
you did not have full access rights when you tried to register the
node.
William
|
| 3862.4 | I did have access now I have a crash | BRAT::BUKOWSKI | | Thu Oct 08 1992 17:56 | 39 |
| William,
Now I am confused again. I had John Regan with me when we tried
to register these entities (even sledge). We made sure,
absolutely, that I had read, write, delete, test and control access
to the object. I a matter of fact, for some reason sledge is the
only one that made it as far as partial registration. The rest of
them never made it (forgot the error message). I just tried to
add another node4 (.mko.lilac) that I have full access to and this
is what happened. After I clilked on the map window, I had to wait
approximately 4-4.5 minutes. Then the Icon "LILAC" appeard. This
is interesting, becuase when I was able to register partially
register .MKO.SLEDGE the Icon came up as ".MKO.SLEDGE". Anyway,
all though this look successfull, the my map window disappeared
about five seconds after I recieve the "LILAC" icon, and here is
the dump I received.
MK1DNS::HOME> SET DISPLAY/CREATE/NODE=NETSTR
MK1DNS::HOME> MANAGE/ENTER/INT=DECW
%CMA-F-EXCCOP, exception raised; VMS condition code follows
-SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=00000022, PC
=0020D815, PSL=03C00000
%TRACE-F-TRACEBACK, symbolic stack dump follows
module name routine name line rel PC
abs PC
0004B8C0
0004B8C0
0007C382
0007C382
000771DC
000771DC
0007A878
0007A878
MK1DNS::HOME>
Now what?? Help!!
Mike
|
| 3862.5 | access confirmation | CGHUB::JREGAN | | Fri Oct 09 1992 12:27 | 24 |
| Just to clarify..
Mike is working from node mk1dns::latmgr
mk1dns::latmgr and .mko.mk1dns.latmgr are bothmembers of the
admin grouip .mko.obj_admin
.mko.obj_admin has full access (r,w,d,t,c) to all objects in the
MKO directory,,,,,but NOT to the directory itself...
nor will it, since MCC folks are NOT DNS folks for the most
part.
.mko.obj_admin does have access to all non-node object dirs under
.mko and to the directory that contains all the domains
that are being used.
.mko.obj_admin also has full access to all the
.mcc_*_Backtranslation at the root of the namespace via a
group called .mcc_admin
I have 1 question...by virtue of the fact that at least some attributes
were applied to the obvject .mko.sledge, can we assume that we nolonger
have a DNS access control problem..(i.e., mcc was able to write some
of the attributes it needed to the object....right?,,it wouldn't
have even gotten this far if there was an access control problem with
DNS..)
|
| 3862.6 | DNS$ACS needs CONTROL access right and MCC attr needs not | TRM::KWAK | | Fri Oct 09 1992 14:23 | 8 |
|
RE: .4
Modifying the DNS attribute "DNS$ACS" requires all the access rights
to the object. But, modifying other MCC attributes does not require
CONTROL access right.
William
|
| 3862.7 | | FROSTY::JREGAN | | Tue Oct 13 1992 20:03 | 6 |
| hmmm,,,beats me...
Documentation says that CONTROL access says that the user MAY alter the
access control set attribute......that seems to match what you say...
|