| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 5589.1 | that's why DNS is used. | TOOK::MCPHERSON | Imagine whirled peas. | Mon Sep 13 1993 17:23 | 3 |
| Why not use DNS and shared map files?
/doug
|
| 5589.2 | Not exactly what the customer is looking for. | CSC32::W_MCGAW | | Wed Sep 15 1993 18:50 | 13 |
| Hi,
The customer is actually looking to have the alarm fire on the
registration because he has other applications running NOT related to
DECmcc which he needs to update. Sharing the maps and using DNS is not
the answer he was looking for. BTW, he is running DECmcc on one
workstation and using the local mir for storage.
Is it possible to alarm against successful registrations under DECmcc?
Thanks,
Walt McGaw
|
| 5589.3 | Always a way. | TOOK::MCPHERSON | Imagine whirled peas. | Wed Sep 15 1993 20:49 | 12 |
| I'm a little rusty on the innards of the regsitration FM, but I believe it
*does* search for a "register entry point" for whatever class it's registering.
If this is trure, then I believe that you could do what you want by writing a
small MM that does whatever you want (maybe do an event put or some sort of
signal). You'd have to create a vector.mar file and enroll it in the AM
dispatch table, with one entry for each class you want to have "registration
notification".
Maybe KJ or Pat will tune in and verify this...
/doug
|
| 5589.4 | an alternative for monitoring changes | TOOK::CALLANDER | | Fri Sep 17 1993 15:19 | 23 |
| since the registration FM does enroll using wildcarded entities it is
possible to do the equivalent of the old (circa v1.1) control FM and
put in more specific entry points for the classes you want to pick up
the registers on. The kernel will dispatch to the most exact match, the
problem is that even though you can pick the command up there will be
no way of passing the command on to the registration FM (you will
instead get in an endless loop calling back to yourself). Sorry but
in the release you have I don't believe that domain or registration
events are supported.
Now there are other non-elagant solutions you can use. If you don't
need immediate update of the other applications (say once or twice a
day is fine), then you can use the tool in took::user$778:[survival]
for dumping the namespace. How ever often you want you invoke the tool
and then do a comparison of the output files. If changes are found you
can make the necessary calls into the other applications/tools you want
to update. What you would need to do is to write a command procedure
that handles invoking the dump tool, doing the comparison and then
purging away the previous runs output files so that you don't run out
of disk space.
hope this helps
|
| 5589.5 | The dump tool might work!!! | CSC32::W_MCGAW | | Wed Sep 22 1993 15:55 | 13 |
| Hi,
Thanks for the quick replies... Sorry for the delayed response.
This may be an alternative (.4) for the customer. Is this tool o.k. to
give to a customer? If so, could you reply with a more detailed
pointer to the tool or send me mail at csc32::w_mcgaw so that I can
pull it across and get it to the customer. I am waiting to notify the
customer about this until I have all the pieces in place.
Thanks,
Walt McGaw
USCSC
|
| 5589.6 | took::user$778:[mcc.vms.mir-tools]mcc_dump_ns.com | GOSTE::CALLANDER | | Mon Oct 04 1993 16:32 | 8 |
| the "tool" is a DCL/MCC command procedure for dumping the namespace by
doing DIRECTORY Class * commands and reformatting the output into
register commands. Looks like you would have to write the part to
do the output comparisons, and you can even tweek the com file to
only check for entity classes you are interested in. Give it a look.
It is documented and includes a disclaimer at the top.
jill
|