| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3980.1 | Looks like an oversite | TOOK::MINTZ | LKG2-2 near pole X3, cube 6072, dtn 226-5033 | Wed Oct 28 1992 11:01 | 7 |
| Sure looks like a bug.
Please enter a QAR on MUSEUM (see note 7).
Thanks,
-- Erik
|
| 3980.2 | | EMC2::POTTS | | Wed Nov 04 1992 05:33 | 21 |
| A related problem:
I have DECMCC installed in a diskless area on our server under /usr/mcc. This
is actually /dlenv0/root0.mips/usr/mcc on the server which is mounted read-only
on the clients. I am told that this is the correct way to set up a diskless
area. However, the .dat files, in particular mcc_fdictionary.dat are in that
area and cannot be updated. Is the dictionary file supposed to be shared between
all clients? In that case, should the shared /usr area in a diskless environment
be exported from the server as read/write?
Also, when I installed MCC on the server, I mounted a separate partition for
/usr/mcc. Is it ok in a diskless environment to do the same thing? If so, should
I be able to simply delete /usr/mcc/* in the shared /usr area and create a link
to the /usr/mcc partition? I can't see why not but would like to be sure before
I do it! This however would still mean that the dictionary file was being shared.
It would be shared by the server itself as well as all the clients.
Hope somebody can cast light on this for me!
Thanks,
Graham
|
| 3980.3 | | EMC2::POTTS | | Wed Nov 04 1992 06:12 | 7 |
| I have it working by renaming the /dlenv0/root0.mips/usr/mcc directory and
creating an empty directory called mcc in it's place.
On the client I have mounted the /usr/mcc partition on /usr/mcc. I now have write
access to the dictionary. Is this a supported way to go?
Thanks,
Graham
|
| 3980.4 | Glad to hear it works | TOOK::MINTZ | LKG2-2 near pole X3, cube 6072, dtn 226-5033 | Wed Nov 04 1992 13:39 | 4 |
| It has not been tested by engineering, so we probably can't
officially support it. But I don't see why it wouldn't work.
-- Erik
|
| 3980.5 | Will work until ... | TAEC::LAVILLAT | | Thu Nov 05 1992 05:11 | 28 |
| re .3:
>
>I have it working by renaming the /dlenv0/root0.mips/usr/mcc directory and
>creating an empty directory called mcc in it's place.
>On the client I have mounted the /usr/mcc partition on /usr/mcc. I now have write
>access to the dictionary. Is this a supported way to go?
>
It should work until...
Be aware that you have no NFS locking on the dictionary files if you do so.
So, if 2 clients try to update the dictionary at the same time, weird things
may happen.
Using /usr/mcc as read-only is much more safer : in this case you know that
you can update the dictionary only from the DMS server : i.e. from one machine
at a time.
What we use to do (TeMIP development team) is work with the default read-only
/usr partition where we install the default dictionary, plus the released
versions of TeMIP, then, each developer uses its own dictionary (generally
~/mcc_system), by setting the MCC_SYS_LOCATION env. variable.
Regards.
Pierre.
|
| 3980.6 | Can also share /usr | TOOK::MINTZ | LKG2-2 near pole X3, cube 6072, dtn 226-5033 | Thu Nov 05 1992 07:27 | 24 |
| From our point of view, we expect that most of the dictionary updates
occur during product installations. In that case, having the dictionary
writable only from the server is not a problem.
This does not hold for SNMP MIB updates, which require write access to
the dictionary.
A more supported workarround for your configuration would be to
share /usr on the server with the DMS clients (I believe this is supported
according to the DMS manual). In that case, you could do all of your
dictionary updates on the server, and maintain the read-only /usr on
the clients, as designed.
As noted in .-1, developers typically use private dictionaries,
so access to /usr/mcc/mcc_system is not an issue.
In any case, we can find no evidence of ANY customers using DECmcc
in a DMS environment. This limits the development resources that we can invest
to make this scenario more convenient. If you know of customers
encountering problems with this configuration, let use know through
the requirements process.
-- Erik
|
| 3980.7 | Dispatch table | EMC2::POTTS | | Thu Nov 05 1992 11:09 | 4 |
| That all seems fair enough! What about mcc_dispatch_table.dat? Doesn't
that get updated more frequently?
Graham
|
| 3980.8 | Dispatch updates less often than dictionary | TOOK::MINTZ | LKG2-2 near pole X3, cube 6072, dtn 226-5033 | Thu Nov 05 1992 11:30 | 10 |
| Nope, mcc_dispatch_table.dat is only updated when a management module
is enrolled, and that typically only happens at install time.
Again, in a development environment, developers usually use the
MCC_SYS_LOCATION environmental variable to point to a private dispatch table.
As noted in the base note, there may be a problem in the FDS installation
procedure, but it is intended to work in this environment.
-- Erik
|