| AH hah... I may know what your problem is.
I did not see all of the information needed to be positive, but here is
something to check. Since your global entity appears to have registered
properly - deduced from the fact that the AM Register returned success
and the AM SHOW idents returned success, I suspect that your problem is
in registering child entities.
During the Registration process for the global entity, the REGISTRATION FM
will query the dictionary about child classes. If any of your child
classes have the definition DYNAMIC = FALSE, then the REGISTRATION FM
will try to register the child. This is done with an mcc_call_function:
SHOW <global class> <name> <child class> * ALL IDENT
If you have not yet implemented the SHOW for the child classes or the
SHOW fails in any way - like the wildcard is not supported, you will see
behaviour similar to what you have reported. `Unsupported
combination....' means that no entry was found in the dispatch table.
Automatic registration of children is a very nice feature for users, but
can be tricky for developers. The registration algorithm is published
in the back of the Toolkit Guide to MM Development, but its easy to get
confused.
Here is how you can check to see if this is your problem:
1) if you have not specified the DYNAMIC definition for the
child classes in your MS, then DYNAMIC = FALSE is the default
- look in the dictionary to confirm, check all the child
classes ALL the way down the hierarchy
2) if you have implemented SHOW for the child classes, make sure
that the entry point for the children is in the dispatch
table
You can fix the problem by adding the DYNAMIC=TRUE definition to your
child classes, retranslating the MSL, reloading the dictionary,...
Although it is safest to always rebuild your AM anytime you change the
MSL, in this case, the change affects only the dictionary.
On Ultrix, since the processes keep running, you must re-enroll the
Registration FM to see the change as the Registration FM keeps in-memory
tables from the dictionary for performance purposes.
Hope this solves your problem.
...kjn
|
|
I have a couple of questions regarding the registration of a CHILD
entity with multiple attribute identifiers ?
From what I understand from registration process, here are the following
steps/services that should be performed/provided:
- the am should provide an entry point REGISTER
- REGISTER directive must be called with arguments. The arguments
are the attribute identifiers I want the entity to be registered with.
- When the mcc_call is performed, the am is called on the
register entry point in first place, then on the SHOW entry point.
Suppose I have a child entity with a name, and two other ids,
one integer, one latin1 string.
The sequence should be something like :
At entry point register
get attributes identifiers and values from input_p
set a flag for registration
save attribute identifiers and values either in MIR or in
CACHE
At entry point show ids
If registration flag set then
encode attributes in out_p
=> should I encode in the out_p the two saved attribute identifiers and
values + the entity name, or only the two attributes ?
Register requires a FULL_ENTITY_NAME, so I understand that
even if I want to register a child entity I should give the
full_entity_name.
So if I have to encode 3 attributes in the show, their datatypes
are: 1 full entity name, 1 integer, 1 latin1 string.
=> Right ?
Or I am only interested by the last pair class/instance
of the entity name ?
Last question:
Should the code be re-entrant ?
I mean, could there be a Show command made on another entity
processed by my am while I am processing a registration for another
entity ? In which case the flag is
not valid for that latter show, and I should also store the entity name
in the MIR/CACHE in register entry point.
if yes,
=> On VMS ?
=> On Ultrix (considering future client /server mechanisms)
Thank to answer,
Florence
|
| RE: -1
WHEW!!
> I have a couple of questions regarding the registration of a CHILD
> entity with multiple attribute identifiers ?
> From what I understand from registration process, here are the following
> steps/services that should be performed/provided:
>
> - the am should provide an entry point REGISTER
> - REGISTER directive must be called with arguments. The arguments
> are the attribute identifiers I want the entity to be registered with.
> - When the mcc_call is performed, the am is called on the
> register entry point in first place, then on the SHOW entry point.
All of the above is true - FOR THE GLOBAL PARENT, not the automatically
registered child. When child entities are automatically registered as
part of the parent's registration, it is done with an mcc_call
SHOW <parent class> <instance> <child class> *
No user-supplied arguments are allowed here for the child, unless
supplied as input arguments on the REGISTER <parent>. The AM REGISTER
entry point is not called during an automatic register of children.
If you want the user to manually register the child, then you can define
the REGISTER directive to take input arguments specific to the child.
In your MSL, you would mark the child class DYNAMIC = TRUE and define
the REGISTER directive for the child class to have input arguments.
> Suppose I have a child entity with a name, and two other ids,
> one integer, one latin1 string.
> The sequence should be something like :
> At entry point register
> get attributes identifiers and values from input_p
> set a flag for registration
> save attribute identifiers and values either in MIR or in
> CACHE
> At entry point show ids
> If registration flag set then
> encode attributes in out_p
> => should I encode in the out_p the two saved attribute identifiers and
> values + the entity name, or only the two attributes ?
The above sounds like what you would want to do for the parent, not a
normal child. Usually, if child entities have multiple identifiers,
then they are able to support them. If not, then you would have to go
through a sequence similar to that described. -- I am not sure whether
the Registration FM calls the AM REGISTER entry point for a the manual
register of a child entity? Pat, do you know?
The whole point of saving the identifiers in a cache is to make the
association (in the AM) between the identifiers for the span of the
REGISTER operation so that the SHOW IDENTs can return the entire
identifier partition. Once the REGISTER is done, the identifiers are
associated in the MIR.
SHOW IDENTIFIERS always returns an ilv-encoded attribute list in out_p.
all identifier attributes for the specified entity should be returned in
the list. So, if your child entity has three identifiers - name,
integer, latin1string - you must return an ilv-encoded attribute list,
with three identifier attributes, in out_p.
> Register requires a FULL_ENTITY_NAME, so I understand that
> even if I want to register a child entity I should give the
> full_entity_name.
> So if I have to encode 3 attributes in the show, their datatypes
> are: 1 full entity name, 1 integer, 1 latin1 string.
> => Right ?
> Or I am only interested by the last pair class/instance
> of the entity name ?
REGISTER only requires a FULLNAME datatype for the global parent. It
doesn't make sense for a child entity. The attribute list should
include just the identifiers for the child entity. No class
information, no information from the parent, just the name/address/other
of the child. It sounds here like you are getting confused between the
FULLNAME datatype and the FULL_ENTITY datatype. FULLNAME is essentially
a counted string with stuff on the front added by the DECdns nameserver.
FULL_ENTITY is a constructed datatype (MCC_A_AES) that is an abstract
datatype made up of class/instance pairs. You might want to do some
more reading in the SRM Chapter 9 Datatypes.
> Last question:
> Should the code be re-entrant ?
> I mean, could there be a Show command made on another entity
> processed by my am while I am processing a registration for another
> entity ? In which case the flag is
> not valid for that latter show, and I should also store the entity name
> in the MIR/CACHE in register entry point.
> if yes,
> => On VMS ?
> => On Ultrix (considering future client /server mechanisms)
Absolutely, your code should be re-entrant!! All of the DECmcc MMs are
run as multi-threaded, re-entrant entities. The MM simply won't work
properly if it is not re-entrant.
The cache flag is meant just to tell the SHOW IDENTS to check the cache.
The cache always should hold all of the identifiers and any other
pertinent user_supplied information you want to reference later. It is
the job of the cache to hold the name-to-address (or other information)
associations until they can be stored. You cannot assume that the next
operation after the REGISTER will be the associated SHOW IDENT. The
value(s) stored in the cache should always be checked against the value
in in_e to determine whether the entities referenced are the same. You
very well might have mulitple threads of operations in progress
simultaneously within the AM, just on different entities (maybe on the
same entity). The behaviour of MCC in this case is independent of
operating system.
> Thank to answer,
> Florence
|