| Does anyone have any thoughts on .0?
I have some new information that will makes things even more
interesting. I would like to be able to register my repository name in DNS
using the registration FM. Unfortunately, since my MM is an FM, it is
writing over the REGISTER verb that is already in the FM dispatch table. So,
how can I register a support object that is managed from an FM without using
the Registration FM?
Carl
|
|
>> Unfortunately, since my MM is an FM, it is
>> writing over the REGISTER verb that is already in the FM dispatch table. So,
>> how can I register a support object that is managed from an FM without using
>> the Registration FM?
There are two possible ways to make it work in the short term (not
necessarily guaranteed to be the correct answer for the long term).
The first is to convert the REGISTER entry point in your FM into a
CREATE entry point. When the iconic map adds an entity to a domain it
calls CREATE first and then REGISTER, sooooo, you do all your set-up
and getting the entity-specific stuff out of the way in the CREATE and
then during the REGISTER, when the Registration FM calls the SHOW IDENT
entry point in your FM, you return the identifiers and the info gets
added to the instance database. This means that the sequence has to be
the same from the FCL, as well. The user would have to enter a CREATE
command followed by the REGISTER command. This becomes a documentation
issue.
IF, by chance this doesn't work; for example, if the Registration FM
issues an mcc_call_access specifically for the SHOW IDENTs instead of a
more generic call, there is a second, less attractive (read not really
kosher) way to accomplish your goal.
The second way is to go back to the way you originally had the code -
with a REGISTER entry point. In this case, you would enter your
REGISTER entry point into the access table instead of the function table
and then you won't overwrite the Registration FMs function table entry
and your REGISTER entry point will be called automatically as part of
the registration process.
This can sort of be justified because your FM is acting as the agent for
the entity you are registering and so the access table is appropriate.
We have done this with the Domain FM when necessary.
...kjn
|
| RE: .2,
>The first is to convert the REGISTER entry point in your FM into a
>CREATE entry point. When the iconic map adds an entity to a domain it
>calls CREATE first and then REGISTER, sooooo, you do all your set-up
>and getting the entity-specific stuff out of the way in the CREATE and
>then during the REGISTER, when the Registration FM calls the SHOW IDENT
>entry point in your FM, you return the identifiers and the info gets
>added to the instance database. This means that the sequence has to be
>the same from the FCL, as well. The user would have to enter a CREATE
>command followed by the REGISTER command. This becomes a documentation
>issue.
>
>IF, by chance this doesn't work; for example, if the Registration FM
>issues an mcc_call_access specifically for the SHOW IDENTs instead of a
>more generic call, there is a second, less attractive (read not really
>kosher) way to accomplish your goal.
>
>The second way is to go back to the way you originally had the code -
>with a REGISTER entry point. In this case, you would enter your
>REGISTER entry point into the access table instead of the function table
>and then you won't overwrite the Registration FMs function table entry
>and your REGISTER entry point will be called automatically as part of
>the registration process.
>
>This can sort of be justified because your FM is acting as the agent for
>the entity you are registering and so the access table is appropriate.
>We have done this with the Domain FM when necessary.
I have tested both of these out and they work. The only problem is
that I do two enrolls in the same MM, one for the FM services, and another for
the MM self-management services, register, and the show all idents with the
same enroll ID. This seems like a hack but it works. So my CREATE calls the
REGISTER and the REGISTER is in the AM table.
Carl
|