| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 221.1 | Example MSL | BARREL::LEMMON | | Wed Aug 01 1990 12:59 | 165 |
| (*
TITLE: Reference Directives Service Interface Specification
MODULE NAME: MCC_CONFIG_DIRECTIVES.MS
Copyright (c) Digital Equipment Corporation, 1990
All Rights Reserved. Unpublished rights reserved
under the copyright laws of the United States.
The software contained on this media is proprietary
to and embodies the confidential technology of
Digital Equipment Corporation. Possession, use,
duplication or dissemination of the software and
media is authorized only pursuant to a valid written
license from Digital Equipment Corporation.
RESTRICTED RIGHTS LEGEND Use, duplication, or
disclosure by the U.S. Government is subject to
restrictions as set forth in Subparagraph (c)(1)(ii)
of DFARS 252.227-7013, or in FAR 52.227-19, as
applicable.
FACILITY:
DECmcc -- Digital Equipment Corporation Management Control Center
ABSTRACT:
These Directives (DIRECTORY, REGISTER, DEREGISTER, RENAME and ERASE)
are required for any Access Module that may have entities or
attributes Registered through CONFIG.
CONFIG FM support also requires directives SET and SHOW to be defined
in the management specification.
The following code fragment should be added to the directive section
of all entities to be supported by CONFIG FM.
*)
(* *)
(* Include reference directives for Configuration FM *)
(* support. Also must have MCC_REFERENCE_ATTRIBUTE.MS *)
(* include file in attribute section. *)
(* *)
(* INCLUDE MCC_CONFIG_DIRECTIVES.MS; *)
(*
ENVIRONMENT:
VAX/VMS
Management Specification Language (MSL) Translator
AUTHOR:
NMSE
*)
(* CONFIG Directives *)
DIRECTIVE Deregister = 30 :
DIRECTIVE-TYPE = ACTION,
DISPLAY = TRUE,
CATEGORIES = (CONFIGURATION),
RESPONSE Entity Deregistered = 1 :
SYMBOL = DEREGISTER_SUCCESS,
TEXT = "Deregistration Successful",
END RESPONSE Entity Deregistered;
END DIRECTIVE Deregister;
DIRECTIVE Directory = 26 :
DIRECTIVE-TYPE = EXAMINE,
DISPLAY = TRUE,
CATEGORIES = (CONFIGURATION),
RESPONSE Directory Success = 1 :
SYMBOL = DIRECTORY_SUCCESS,
TEXT = "Directory successful.",
ARGUMENT Directory Values = 1 : ATTRIB_LIST
SYMBOL = ARG_DIR_VALUES
END ARGUMENT Directory Values;
END RESPONSE Directory Success;
RESPONSE Directory Empty = 2 :
SYMBOL = DIR_EMPTY,
TEXT = "Empty Group to Directory",
END RESPONSE Directory Empty;
(* EXCEPTION Common exceptions only *)
END DIRECTIVE Directory;
DIRECTIVE Erase = 33 :
DIRECTIVE-TYPE = ACTION,
DISPLAY = TRUE,
CATEGORIES = (CONFIGURATION),
RESPONSE Erase Performed = 1 :
SYMBOL = ERASE_SUCCESS,
TEXT = "All information about entity erased.",
END RESPONSE Erase Performed;
END DIRECTIVE Erase;
(* CONFIG REGISTER Directive *)
DIRECTIVE Register = 29 :
DIRECTIVE-TYPE = ACTION,
DISPLAY = TRUE,
CATEGORIES = (CONFIGURATION),
(* Request args for register are optional and entity specific*)
(* entity specific request arguments go here *)
(* Child Entities of Node4 and Node have no REGISTER
REQUEST arguments *)
RESPONSE Entity Registered = 1 :
SYMBOL = REGISTER_SUCCESS,
TEXT = "Registration Successful",
END RESPONSE Entity Registered;
END DIRECTIVE Register;
(* End CONFIG REGISTER Directive *)
(* RENAME Directive *)
DIRECTIVE Rename = 34 :
DIRECTIVE-TYPE = MODIFY,
DISPLAY = TRUE,
CATEGORIES = (CONFIGURATION),
(* Request args for rename are optional and entity specific*)
(* entity specific request arguments go here *)
REQUEST
ARGUMENT Identifier Values = 1 : ATTRIB_LIST
SYMBOL = ARG_RENAME_VALUES
END ARGUMENT Identifier Values;
END REQUEST;
RESPONSE Entity Renamed = 1 :
SYMBOL = RENAME_SUCCESS,
TEXT = "Rename Successful",
END RESPONSE Entity Renamed;
END DIRECTIVE Rename;
(* End RENAME Directive *)
(* End CONFIG Directives *)
(* DEC/CMS REPLACEMENT HISTORY, Element MCC_DNA4_AM_CFGDIR_ALL.MS *)
(* *2 6-JUN-1990 18:09:28 BALL "add updated include file names..." *)
(* *1 6-JUN-1990 16:19:49 BALL "msl for config directive (including rename)..." *)
(* DEC/CMS REPLACEMENT HISTORY, Element MCC_DNA4_AM_CFGDIR_ALL.MS *)
|
| 221.2 | re.1 continued....
| BARREL::LEMMON | | Wed Aug 01 1990 13:08 | 7 |
| I believe you only need to add the register and deregister directives to
your .MS file. Use the example in .1 as a guide.
You do not have to add an entry to your vector.mar file because the register
directive dispacthes to the configuration FM, not your AM.
/Jim
|
| 221.3 | keep going | MKNME::DANIELE | | Wed Aug 01 1990 14:03 | 16 |
| > I believe you only need to add the register and deregister directives to
> your .MS file. Use the example in .1 as a guide.
and ERASE, DELETE, RENAME perhaps? Not to mention the reference
attributes, and the SET directive for those attributes...
You probably won't need an entry point, if your entities are vanilla.
It all works generically, but you have to define everything the
'generic way' in your MSL. This info is not well documented. I'm sure
someone will soon be listing EXACTLY what to add to your MSL, and
how registration works, and what doc updates are planned, in
subsequent replies.
Tread carefully,
Mike
|
| 221.4 | You probably need AM support... | WLYWLD::BRIENEN | Chris Brienen - DECmcc (non-DECnet) AMs | Wed Aug 01 1990 15:33 | 16 |
| RE: <<< Note 221.2 by BARREL::LEMMON >>>
> I believe you only need to add the register and deregister directives to
> your .MS file. Use the example in .1 as a guide.
>
> You do not have to add an entry to your vector.mar file because the register
> directive dispacthes to the configuration FM, not your AM.
I don't know anything about the entity you're implementing support for,
but the entities I'm familiar with (Bridge, Station, Terminal Server,
TransLAN, LTM-Listener, etc) *require* REGISTER/DEREGISTER directive
support in the Access Module.
A chapter (maybe two?) is being added to the AM Guide which should answer
some of the questions around how to do this.
|
| 221.5 | | COOKIE::KITTELL | Richard - Architected Info Mgmt | Wed Aug 01 1990 16:09 | 26 |
|
Thanks for the help. Conceptually, I think the flow is:
1. I issue a REGISTER <class> <instance>
2. The PM knows to use the function dispatch table, and passes
the directive to the Config FM.
3. The Config FM issues an MCC_CALL_ACCESS specifying verb=show,
class=<class>, instance=<instance>, attribute=identifiers
4. The show command dispatches to my AM and is processed as usual,
the Config PM gets back the name and UID for the instance I want
to register.
5. It does the registration
6. If the class has sub-classes, there is probably some amount of
recursion to register the sub-class instances.
So I need to add the REGISTER/DEREGISTER directives to my .MS only to
get them into the dictionary and the parse table, so the PM will recognize
them for my class. I would need dispatch entries and entry points only
if the directives ever got into my AM as REGISTER/DEREGISTER. I've actually
got that coded up, but I have no idea what to do if they ever get called.
|
| 221.6 | reference attrs include file? | COOKIE::KITTELL | Richard - Architected Info Mgmt | Wed Aug 01 1990 18:35 | 13 |
| From .1
(* *)
(* Include reference directives for Configuration FM *)
(* support. Also must have MCC_REFERENCE_ATTRIBUTE.MS *)
(* include file in attribute section. *)
(* *)
(* INCLUDE MCC_CONFIG_DIRECTIVES.MS; *)
I take it that .1 is MCC_CONFIG_DIRECTIVES.MS, can someone post or point me
at a copy of MCC_REFERENCE_ATTRIBUTE.MS?
Thanks.
|
| 221.7 | my 2 cents | MKNME::DANIELE | | Wed Aug 01 1990 18:56 | 3 |
| I really recommend you wait until an accurate, complete description
of what you have to do to plug and play vis a vis REGISTER is
available.
|
| 221.8 | MCC_REFERENCE_ATTRIBUTES.MS | BARREL::LEMMON | | Wed Aug 01 1990 20:42 | 134 |
| Re:.7 Mike may be right in that you should wait until the info is available.
There may be additional MS requirements.
Re:.6 Below is the file requested but beware that this might not be enough.
/Jim
(*
TITLE: Reference Attributes Service Interface Specification
MODULE NAME: MCC_REFERENCE_ATTRIBUTES.MS
Copyright (c) Digital Equipment Corporation, 1990
All Rights Reserved. Unpublished rights reserved
under the copyright laws of the United States.
The software contained on this media is proprietary
to and embodies the confidential technology of
Digital Equipment Corporation. Possession, use,
duplication or dissemination of the software and
media is authorized only pursuant to a valid written
license from Digital Equipment Corporation.
RESTRICTED RIGHTS LEGEND Use, duplication, or
disclosure by the U.S. Government is subject to
restrictions as set forth in Subparagraph (c)(1)(ii)
of DFARS 252.227-7013, or in FAR 52.227-19, as
applicable.
FACILITY:
DECmcc -- Digital Equipment Corporation Management Control Center
ABSTRACT:
These are the CONFIG FM supported attributes for reference data.
The following code fragment should be added to the Attribute section
of all entities to be supported by CONFIG FM.
*)
(* *)
(* Include reference directives for Configuration FM *)
(* support. Also must have: *)
(* MCC_CONFIG_DIRECTIVES.MS *)
(* MCC_SET_DIRECTIVE.MS *)
(* MCC_SHOW_DIRECTIVE.MS *)
(* MCC_RENAME_DIRECTIVE.MS *)
(* include files or code in directive section. *)
(* *)
(* INCLUDE MCC_REF_ATTRIBUTES.MS; *)
(*
ENVIRONMENT:
VAX/VMS
Management Specification Language (MSL) Translator
AUTHOR:
NMSE
*)
REFERENCE ATTRIBUTES (* All repeater reference attributes
are handled by the Config FM *)
(* Entity's physical location. *)
ATTRIBUTE Location = 100 : Latin1String
ACCESS = SETTABLE,
DISPLAY = TRUE,
CATEGORIES = (CONFIGURATION),
SYMBOL = REF_ATTR_LOCATION
END ATTRIBUTE Location;
(* product/version ID information not in characteristics *)
ATTRIBUTE Implementation Desc = 101 : Latin1String
ACCESS = SETTABLE,
DISPLAY = TRUE,
CATEGORIES = (CONFIGURATION),
SYMBOL = REF_ATTR_IMPLEMENTATION
END ATTRIBUTE Implementation Desc;
(* who ya gonna call? *)
ATTRIBUTE Responsible Person = 102 : Latin1String
ACCESS = SETTABLE,
DISPLAY = TRUE,
CATEGORIES = (CONFIGURATION),
SYMBOL = REF_ATTR_PERSON
END ATTRIBUTE Responsible Person;
(* Responsible person phone number *)
ATTRIBUTE Phone Number = 103 : Latin1String
ACCESS = SETTABLE,
DISPLAY = TRUE,
CATEGORIES = (CONFIGURATION),
SYMBOL = REF_ATTR_PHONE
END ATTRIBUTE Phone Number;
(* Computer Mail address *)
ATTRIBUTE MAIL Account = 104 : Latin1String
ACCESS = SETTABLE,
DISPLAY = TRUE,
CATEGORIES = (CONFIGURATION),
SYMBOL = REF_ATTR_MAIL_ACCT
END ATTRIBUTE MAIL Account;
(* Remarks *)
ATTRIBUTE Remarks = 105 : Latin1String
ACCESS = SETTABLE,
DISPLAY = TRUE,
CATEGORIES = (CONFIGURATION),
SYMBOL = REF_ATTR_REMARKS
END ATTRIBUTE Remarks;
(* Pointer to text file. *)
ATTRIBUTE Text File = 106 : FileSpec
ACCESS = SETTABLE,
DISPLAY = TRUE,
CATEGORIES = (CONFIGURATION),
SYMBOL = REF_ATTR_TEXT
END ATTRIBUTE Text File;
END ATTRIBUTES; (* REFERENCE *)
|
| 221.9 | Documentation | MKNME::BLACK | | Thu Aug 02 1990 11:34 | 7 |
| An appendix has been added to "Management Module Programming" which
tells you about your AM's role in the registration process.
You'll find it in the public area for MCC documents, as soon as the
writer puts it there (hopefully today). Look for:
WORDY::USER$657:[PUBLIC.NMS]MM_PROGRAMMING.PS this afternoon.
|
| 221.10 | APPENDIX E "DECmcc and DNS" | COOKIE::KITTELL | Richard - Architected Info Mgmt | Fri Aug 03 1990 19:07 | 3 |
|
Got it, looks good after an initial go through, let's see if I can make
it work.
|
| 221.11 | Getting "Cannot Complete..." | COOKIE::KITTELL | Richard - Architected Info Mgmt | Wed Aug 08 1990 19:26 | 146 |
| 221.12 | UID as an identifier ??? | TENERE::DUNON | Paul Dunon - Telecom Engineering - VBO | Thu Aug 09 1990 09:50 | 21 |
| Richard,
I don't know the answer to your registration problem, but I'm suprised
to see that you've defined the UID as an identifier attribute. I think that
identifier attributes can only be attributes whom you can set the value
upon creation time. When you type
MCC> CREATE NODE4 alezan OBJECT xyz
*you* choose the name xyz for your OBJECT entity.
A UID is a unique identifier that is generated by the entity itself, not by you.
It should be a non settable characteristic attribute.
Could an EMA architect tell me if I'm right ?
By the way, how did you generate the UID value ?
-- Paul
|
| 221.13 | | COOKIE::KITTELL | Richard - Architected Info Mgmt | Thu Aug 09 1990 14:29 | 11 |
| re: .12
Before taking the step to registration, the UID of the global entity is
the value generated by the MIR when I create the instance. The attributes
are then stored under that key. Given the name of the entity I can look
it up in the instance MIR and get the key. Given the UID of the entity I
already have the key and can look up the attributes directly.
When I take the step of registering the global entity, the UID becomes that
of the DNS entry, which is assigned by DNS. I think. Not having made this
work yet, I could be all wet.
|
| 221.14 | | CAPN::SYLOR | Architect = Buzzword Generator | Fri Aug 10 1990 19:34 | 7 |
| Global Entities must/should have a DNS name as their primary identifier.
They can have other attributes as secondary identifiers (node addresses,
node synonyms, bridge names, UIDs etc. etc.)
Does that help?
Mark
|
| 221.15 | Nice to know the UID isn't the problem | COOKIE::KITTELL | Richard - Architected Info Mgmt | Fri Aug 10 1990 22:28 | 13 |
|
re: .14
Mark, that answers Paul's question as to whether a UID is valid as an
alternate identifier.
But I'm still stuck, getting "cannot complete operation" when I try to
register something. As noted in .11, the service error display is the text
of the response from SHOW ALL IDENT:
The requested operation cannot be completed
MCC Service Error = Examination of attributes shows:
MCC>
|
| 221.16 | Got it! | COOKIE::KITTELL | Richard - Architected Info Mgmt | Wed Aug 15 1990 19:05 | 9 |
|
MCC> register pbd .kittell.aug15_1302
PBD AIM_NS:.kittell.aug15_1302
AT 15-AUG-1990 13:00:04
Registration Successful
|
| 221.17 | ** CONGRATULATIONS ** | GOSTE::CALLANDER | | Wed Aug 15 1990 22:02 | 1 |
|
|
| 221.18 | Dynamic Children | COOKIE::KITTELL | Richard - Architected Info Mgmt | Thu Sep 20 1990 03:11 | 17 |
| I've defined some new global entities, and am surprised to find that
REGISTER insists that whenever I register one it must have at least one
instance of each sub-class.
I issue the register, and my AM gets a SHOW ge ALL IDENT as usual. But
then it gets a SHOW ge Child * ALL IDENT for all the sub-classes it
supports. If any of those fail with NOENTITY the Register fails.
I understood that Register would sample all the DYNAMIC=FALSE entities
below the Global Entity, but I didn't expect it to insist on finding
instances for all of them.
So I guess I should make all non-global entities DYNAMIC=FALSE. I don't
think I lose anything by that, since my global entities keep track of
all their sub-ordinates. Does DYNAMIC affect anything other than
Register?
|
| 221.19 | | GOSTE::CALLANDER | | Thu Sep 20 1990 14:26 | 6 |
|
RE: .18
Not really. Dynamic for global entities and their children is primarily
for the use of registration.
|
| 221.20 | Dispatcher runs a bad entry point | VERS::PETROU | | Thu Mar 14 1991 14:47 | 32 |
|
Hello world.
Developing an AM on TIMA application, I have a problem
to register instances.
I followed steps given in the previous replies;
1. Set up manualy DNS
2. I have a show identifier entry point
3. I load the register directive in services MS
but it seems that the dispatcher translates the register command
I entered to my AM show identifier entry point???
Can anybody help me?
Regards philippe.
-----------------------------------------------------------------
The error is the following:
MCC> register timapcc pape
Running SHOW IDENTIFIERS directive...
TIMAPCC CAPITN_NS:.pape
AT 14-MAR-1991 17:15:58
The requested operation cannot be completed
MCC Routine Error = %MCC-E-INV_VERB, directive not
supported for specified entity
MCC>
|
| 221.21 | XMs must support ALL IDENTIFIERS partition | ALLZS::MORRISON | The world is a network | Fri Mar 15 1991 16:19 | 8 |
| As I recall, during the course of a REGISTER directive, a SHOW <entity>
ALL IDENTIFIERS directive is issued to the entity that you want to register.
So the dispatcher is not getting fouled up, it's just part of the normal
sequence of events for REGISTER. Does your AM support the ALL IDENTIFIERS
partition as required. From the error message in your note, it doesn't
look like it does.
Wayne
|
| 221.22 | Yes, Show identifiers is supported | VERS::PETROU | | Mon Mar 18 1991 08:32 | 46 |
|
Hello world,
> Does your AM support the ALL IDENTIFIERS partition as required.
Yes, my AM does support it. Here is an example of this directive;
MCC> show timapcc pape all identifiers
Running SHOW IDENTIFIERS directive...
TIMAPCC CAPITN_NS:.pape
AT 18-MAR-1991 11:21:55 Identifiers
Cette commande active TIMA =>
Username = CAPITN_NS:.pape
UID = F85D8A80-E20A-01C9-0000-AA00040054BE
MCC>
As you can see there is two identifiers Username(primary) and UID
(alternate). Here down is their MSL definition;
IDENTIFIER ATTRIBUTES
ATTRIBUTE Username = 1 : FullName
DNS_IDENT = PRIMARY_NAME,
ACCESS = NONSETABLE,
DISPLAY = TRUE,
SYMBOL = ATTR_Username,
CATEGORIES = ( CONFIGURATION )
END ATTRIBUTE Username;
ATTRIBUTE UID = 2 : UID
DNS_IDENT = ALTERNATE_NAME,
ACCESS = NONSETABLE,
DISPLAY = TRUE,
SYMBOL = ATTR_UID,
CATEGORIES = ( CONFIGURATION )
END ATTRIBUTE Username;
END ATTRIBUTES; (* IDENTIFIER *)
Is there any mistake in this code?
Regards Philippe.
|
| 221.23 | Bad database | SIEVAX::TMJ | The meek won't want it | Tue Mar 19 1991 13:32 | 5 |
|
I had a similar problem to this a while ago. Your database - the parse tables
or dispatch tables - is corrupt or out-of-date. In another note (under my name)
I have included command procedures to create a fresh database: I found these
extremely useful during development of an AM.
|
| 221.24 | Ok I got it now!!! | VERS::PETROU | | Fri Mar 22 1991 06:42 | 11 |
|
Hello world,
My problem of registering is now solved. It was my dispatch tables that
were corrupted because in previous developments the register verb was assigned
to the show identifiers entry point. Since this time, I forgot this development
step and then I had this problem.
Thanks for your help
Regards, philippe.
|