T.R | Title | User | Personal Name | Date | Lines |
---|
857.1 | NOT a MCC_DNS problem | TOOK::JESURAJ | | Tue Apr 02 1991 12:24 | 12 |
|
>>> 3. #2 worked from the FCL.
If it works for FCL not for Iconoic map, then it is NOT a MCC_DNS
problem. May be there is some restriction in the ICONIC Map.
Jesuraj
|
857.2 | lowercase output from SYS$SYSTEM:MCC_DNS_SETUP.EXE | NETCUR::WADE | Bill Wade T&N Course Development | Tue Apr 02 1991 16:58 | 63 |
|
I'm sure that the behind the scenes of this isn't a revelation to most
readers of this conference but -
MCC_COMMON:MCC_DNS_SETUP.COM runs SYS$SYSTEM:MCC_DNS_SETUP.EXE
and passes it the parameters -
p2 - file name
p3 - namespace:.DNA_Node
p4 - IDP value
SYS$SYSTEM:MCC_DNS_SETUP.EXE then creates the phase4 node registration
command files using SYS$SYSTEM:NETNODE_REMOTE.DAT but it creates the
registration commands in this format -
$ !
$ ! Format for a registration command:
$ !
$ ! REGISTER NODE4 node-full-name SYNONYM=phase-iv-name
$ !
$ ON WARNING THEN EXIT
$ MANAGE/ENTERPRISE
REGISTER NODE4 comms_ns:.dna_node.HIDRT1 SYNONYM=HIDRT1 !IDP=49:: ADDRESS=63.0300
REGISTER NODE4 comms_ns:.dna_node.NITWIZ SYNONYM=NITWIZ !IDP=49:: ADDRESS=63.0366
REGISTER NODE4 comms_ns:.dna_node.COMMS SYNONYM=COMMS !IDP=49:: ADDRESS=63.0367
REGISTER NODE4 comms_ns:.dna_node.NITDEV SYNONYM=NITDEV !IDP=49:: ADDRESS=63.0369
REGISTER NODE4 comms_ns:.dna_node.DECDEV SYNONYM=DECDEV !IDP=49:: ADDRESS=63.0371
REGISTER NODE4 comms_ns:.dna_node.NITMG2 SYNONYM=NITMG2 !IDP=49:: ADDRESS=63.0373
REGISTER NODE4 comms_ns:.dna_node.MYJAVA SYNONYM=MYJAVA !IDP=49:: ADDRESS=63.0872
This forces a user, from the IMPM, to add Phase4 entities to a domain
in this format-
dna_node.COMMS
"...entered exactly as it was registered".
If the user doesn't enter them this way, the Historian and PA don't
work correctly and the user doesn't have a clue why.
If you use the FCL to add node4 entities to a domain the above
restriction does not seem to hold. You can go to the IMPM and the
historian seems to work fine.
I agree that the problem would seem to be in the IMPM but,
SYS$SYSTEM:MCC_DNS_SETUP.EXE is breaking the rule of mixing case
for a Phase4name. I modified MCC_COMMON:MCC_DNS_SETUP.COM so it
passes P3 to SYS$SYSTEM:MCC_DNS_SETUP.EXE in all uppercase but, it
still writes it out in lower case.
The Phase4 use doc on page 2-21 lists a node reg command file in all
uppercase but, that's not the way it is.
My only regret is that I didn't see this before SSB.
Any comments on recommending to customers that the node registration
command files be edited prior to executing them and changing dna_node
to DNA_NODE? That is if a namespace isn't already in place and the
files have to be edited to reflect the directory structure for any
existing Phase4 nodes.
/bill
|
857.3 | re:.1,.2 | BARREL::LEMMON | | Fri Apr 05 1991 14:07 | 18 |
| I am a bit confused. Why is it a Iconic Map problem? The Iconic Map passes
EXACTLY what the user enters across the call interface. It does not make
any assumptions based on the case of the data.
It is the managagement modules and some MCC routines that are having the
difficulties with respect to case. If the user stores it in lower case,
then accesses it in upper case, the user is told by the management module
(via the presentation module) that the data could not be found. If the
management module does not care about the case, it should convert it to
either all upper or lower case before storing the data. The same
should be done prior to retrieving it.
A generic presentation module should not make assumptions about case
sensitivity. It should always pass it along as entered. The management
modules know what should be done with it. After all the management module
is the one that wants the user input.
/Jim
|
857.4 | It's a V1.1 problem | NSSG::R_SPENCE | Nets don't fail me now... | Fri Apr 05 1991 15:44 | 13 |
| Jim, it is a DECmcc V1.1 problem. Users of the Iconic Map see it.
Users have one product, not a bunch of independant products. Users
don't know about nor care about call interfaces and which module does
what about what.
It is simply a case of part of the product being out of compliance with
a restriction that is documented in the release notes.
We, the users or testers of the product arn't trying to point fingers
at one or another management module (the IMPM is an MM too). We are
pointing out issues that need to be addressed.
s/rob
|
857.5 | Problem is in MIR routines | NSSG::R_SPENCE | Nets don't fail me now... | Fri Apr 05 1991 15:46 | 5 |
| Oh, and for clarification, the problem is a case sensitivity in the MIR
routines that the Historian and Exporter use. They need to be fixed for
V1.2.
s/rob
|
857.6 | NO FINGERS | NETCUR::WADE | Bill Wade T&N Course Development | Mon Apr 08 1991 10:14 | 9 |
| I second the comment in .4. I'm looking at it from the perspective
of a user and am not pointing fingers.
In the Network Management Using DECmcc course I will include material
on editing the nodes command files and changing dna_node to DNA_NODE.
bill
|