| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1662.1 | SRM Figure 7.6 could be considered incomplete | NANOVX::ROBERTS | Keith Roberts - DECmcc Toolkit Team | Thu Oct 17 1991 10:26 | 42 |
| >> In the MSL example page 149 (figure 7.6) there is no identifier
>> of type FullName, only Phase4Address and Phase4Name.
>>
>> Does this mean:
>>
>> 1). There is an inconsistency in the SRM ?
Yes - I would say so
>> 2). If these two identifiers are being used, it is required to have a
>> third identifier of type FullName?
You need another identifier (say, Registered Name) which is of type
fullname - if you want to register your entity to MCC.
>> 3). The Name attribute should be of type FullNname, but in addition the
>> AM should register something as a SYNONYM as a required input argument
>> during the register phase, and it is the responsability of the AM to
>> make a MCC_DNS call to convert from FullName to Phase4Name, using the
>> SYNONYM from the DNS name space, any time that identifier is used?
Yes, this is correct. For the Sample AM & v1.2 we have added Registration.
The Identifiers are set up as:
Registered Name: FullName
Name: Phase4Name
Address Phase4Address
>> If that example on page 149 would have the 3 identiferes, how will
>> DECmcc make a distinction between the Identifer of type FullName,
>> against the identifier Phase4Name ?
The FullName Identifier begins with a "." and the Phase4Name doesn't
--------
The rest of your note regarding the SHOW DOMAIN and the ILV output
I am not familiar with - sorry
/keith
|
| 1662.2 | DNS name not always starts with a "." ! | KETJE::PACCO | To manage you have to be a (manag..) skilled person! | Mon Oct 21 1991 07:23 | 6 |
| I am not sure a DNS FullName always starts with a ".", because a
generic DNS name is of the following form:
NAME_SPACE:.dir.subdir.object
Dominique.
|
| 1662.3 | A DNS Fullname | NANOVX::ROBERTS | Keith Roberts - DECmcc Toolkit Team | Mon Oct 21 1991 11:24 | 11 |
| >> I am not sure a DNS FullName always starts with a ".", because a
>> generic DNS name is of the following form:
>>
>> NAME_SPACE:.dir.subdir.object
You are correct. The "." prefix means to use the default name space. If
you prefix the fullname with a specific name space, the parser still knows
its a fullname and uses the name space you specify.
/keith
|
| 1662.4 | Phase4Address/FullName discrimination possible? | KETJE::PACCO | To manage you have to be a (manag..) skilled person! | Wed Oct 23 1991 19:39 | 44 |
| I am managing a VMS application, accessed by a DECnet logical link.
The DNS PRIMARY identifier is a FullName
The only DNS ALTERNATE identifier ia a Phase4Address
Also I use the algorithm, that the last part of a DNS FullName is used
as the DECnet node name: e.g.
MY_NAMESPACE:.root.mydirectory.MYNODE corresponds to the DECnet phase 4
node name "MYNODE"
The real data was
Nodename BRSADV
Address 48.15 (49179)
FullName DECTOWN:.mcc_servers.BRSADV
First, MCC seems not be able to distinguish between an Address or a
Fullname. This means that a command as
SHOW application 48.15 all identifiers
does encode the "48.15" with a MCC data type "FullName", where I
expected a Phase4Address. This puts me really into troubles, as I have
no means any more to distinguish between a node name and a node Address,
except perhaps with dirty tricks.
How is this solved in the modified version of the MCC SAMPLE access
module? Are the sources reachable over the network?
Secondly, I was astonished that my access module still worked. This
is a bug or a feature of DECnet:
Because 48.15 was passed as a FullName, the AM decided that the
DECnet nodename had to be "15", and encoded this in the Network
Control Block. So the DECnet connect executed something as
15::"Task=MY_TASK"
which means node number 15 in my DECnet area. That's why the
application works, although DECnet did not got the full DECnet address.
The main problem however remains:
WILL DECmcc will ever distinguish between a Phase4Address and a DNS
FullName ?
Dominique.
|
| 1662.5 | Sample AM - with Registration | NANOVX::ROBERTS | Keith Roberts - DECmcc Toolkit Team | Wed Oct 23 1991 19:57 | 52 |
| >> How is this solved in the modified version of the MCC SAMPLE access
>> module? Are the sources reachable over the network?
I will double check that the Sample AM works properly under the conditions
that you have described.
Yes - the source code is available - I can mail it to you. It is a routine
which determines if the Global Instance is a FULLNAME, and if so pulls out
the last simple name (.mcc_servers.brsadv --> brsadv).
But, if you are passed the phase4address with a datatype of fullname,
my code won't help much. Perhaps it is the order in which the identifer
attributes are defined in your MSL - sounds silly, but I've heard stranger
things before.
The sample identifiers are defined as:
(*
* Identifier Attributes
*)
IDENTIFIER ATTRIBUTES
ATTRIBUTE Address = 1 : Phase4Address
DNS_IDENT = ALTERNATE_NAME,
ACCESS = NONSETABLE,
DISPLAY = TRUE,
CATEGORIES = (CONFIGURATION),
SYMBOL = SAMPLE_ADDR
END ATTRIBUTE Address;
ATTRIBUTE Name = 2 : Phase4Name
DNS_IDENT = ALTERNATE_NAME,
ACCESS = NONSETABLE,
DISPLAY = TRUE,
CATEGORIES = (CONFIGURATION),
SYMBOL = SAMPLE_NAME
END ATTRIBUTE Name;
ATTRIBUTE Registered Name = 10 : FullName
DNS_IDENT = PRIMARY_NAME,
ACCESS = NONSETABLE,
DISPLAY = TRUE,
CATEGORIES = (CONFIGURATION),
SYMBOL = SAMPLE_REGISTERED_NAME
END ATTRIBUTE Name;
END ATTRIBUTES; (* IDENTIFIER *)
/keith
|
| 1662.6 | RE: .4, a small change to your .MS may fix it | KAJUN::NELSON | | Thu Oct 24 1991 12:39 | 53 |
| RE: .4
You are having a parsing experience. If your .MS looks like the one
below, there may be help. Essentially, when you type in your instance,
the parser is trying to figure out what datatype this ASCII string maps
to.
Notice the line
IDENTIFIER = ( Name, Address ),
the parser is going to try to fit whatever you typed into the datatypes
specified for your identifier attributes IN THE ORDER YOU SPECIFIED.
I am willing to bet that you listed the identifier of datatype Fullname
first. Fullname is a broad datatype. Most ASCII strings will be valid
fullnames. If you reverse the order and put Address first, your
problems will probably be solved. Non-numeric characters are not valid
for Phase IV addresses so the Name will never be mistaken for an
address. And the form dd.dddd will be correctly identified as an
address.
Hope this works for you
...kjn
MANAGEMENT SPECIFICATION MCC_yourentity_am_srvc_if;
VERSION = V1.1.0;
SYMBOL-PREFIX = MCC_;
GLOBAL ENTITY YOURMM = xx :
IDENTIFIER = ( Name, Address ),
SYMBOL = CLASS_YOURENTITY,
IDENTIFIER ATTRIBUTES
ATTRIBUTE Name = 1 : FullName
DNS_IDENT = PRIMARY_NAME,
ACCESS = NONSETABLE,
DISPLAY = TRUE,
SYMBOL = ATTR_Name,
CATEGORIES = ( CONFIGURATION )
END ATTRIBUTE Name;
ATTRIBUTE Address = 1 : Phase4Address
DNS_IDENT = ALTERNATE_NAME,
ACCESS = NONSETABLE,
DISPLAY = TRUE,
SYMBOL = ATTR_Address,
CATEGORIES = ( CONFIGURATION )
END ATTRIBUTE Address;
END ATTRIBUTES; (* IDENTIFIER *)
|
| 1662.7 | parse order versus primary identifier | TOOK::CALLANDER | MCC = My Constant Companion | Thu Oct 24 1991 18:16 | 17 |
| Before you change your MS know that help is on the way!!!!
As it is now the use of the identifier definition in MS is over-
burdened. It is used to denote both the parse order and the
primary,secondary identifier ordering for the entity. Well
these things need to be mutually exclusive or you have a big
problem on your hands, like what you are seeing. 4.111 IS a
valid fullname that is why you aren't seeing it as an address,
and without changing your MS you won't ever see it as an address.
In V1.2 we are working to make it so that your parse order can
be anything you want, and that whenever you enter a register
command (the only one that we know REQUIRES you use a fullname)
that is is always interpretted as a fullname. More on that when
the fixes are complete with v1.2 EFT.
|
| 1662.8 | Now Parsing works as expected. | KETJE::PACCO | To manage you have to be a (manag..) skilled person! | Fri Oct 25 1991 14:18 | 8 |
| IDENTIFIERS = (.....) was the key to the success.
With first the Address identifier, followed by the FullName identifier,
it works as expected.
Thanks to you all who responded.
Regards,
Dominique.
|
| 1662.9 | global names required fullnames for 1.2? | MICROW::LANG | | Mon Jan 13 1992 13:59 | 9 |
|
Is it a requirement to have global names fullnames for DECmcc 1.2?
If it is not, what are the implications of not having fullnames?
(Looks like it won't appear in iconic map, and I wonder about global
instance wildcarding.)
thanks,
Bonnie
|
| 1662.10 | | TOOK::SWIST | Jim Swist LKG2-2/T2 DTN 226-7102 | Mon Jan 13 1992 18:23 | 13 |
| At least one of the identifiers of your entity must be a fullname
datatype in order to register the entity. If you can't register the
entity you can't do global instance wildcards obviously. And you can't
put it into a domain - so no iconic map support.
However, there is no enforcement of this requirement. People have
written AMs for simple non-registerable entities without fullnames
and have successfully used them from the command line interface.
Also note that once you've registered yout entity, you don't need
to use its fullname to refer to it - you can use one of its native
identifiers.
|