| Richard, I'll try to answer some of the questions:
>> T1.2.4 VMS
>>
>> I'm trying the non-DNS namespace to see if it is a good way to run our
>> development environment, and let us avoid messing about with the DEC:
>> DNS namespace.
>>
>> 1. I notice that once MCC_DNS_SELECTION is set to "MIR", all names created in
>> the namespace seem to be lowercase. Using the IMPM I created a domain,
>> entering the name as TEST_DOMAIN in all caps. It showed up from both PMs
>> as LOCAL_NS:.test_domain.
>>
That's right. The DNS Local MIR stores fullnames in lower case. The
MIR routines cannot handle case-insensive fullnames.
>> 2. Is there a utility equivalent to dns$control, for examining and modifying
>> entries in the MIR namespace?
>>
We use a development tool which uses DAP-like syntax/commands for
reading/writing/deleting MIR records. However, I believe there are
plans for a scaled down program to simply dump and delete DNS Local
MIR namespace entries. We know this functionality is needed.
>> 3. While on the one hand the intent is for the scope of the MIR namespace to
>> be one node or cluster, what if the disk with the MIR files is DFS-mounted
>> elsewhere? DFS doesn't allow shared access so we wouldn't be able to have
>> concurrent updaters. But once we've got things registered, could things
>> run on the DFS-mounted disk in read-only mode and still look up objects
>> in the namespace?
>>
This should work. The DNS Local MIR routines open up the same files
for both read-only and read-write access. When a DNS routine is
called which requires write access (CreateInstance, WriteAttribute,
etc.), the read-write Repositories get used, but otherwise the
read-only repositories get used. If/when someone directly or
indirectly calls an mcc_dns routine which require write access to a
DFS disk, there will be an error message.
>> 4. Do we still access the namespace via the mcc_dns routines?
>>
Yes! Please do not call the MIR routines directly, the records are
stored in a special format.
>> 5. Should there be any problem setting up a namespace local to, for instance,
>> our test system? I would copy the MCC_DNS_ENT and ...ATT.DAT files into
>> a test system local directory, then make MCC_SYSTEM a searchist to find
>> the local copies first. Should that do it?
>>
Sounds good to me.
>> I've done just that, and while I can create domains and access them from
>> both PMs, any attempt to show or register our global entities from either
>> FM results in %ERF-W-NOMSG, Message number 00088A60.
>>
Pretty funky stuff. Looks like QAR material to me. Could you give
more detail? are MCC_SPECIFIC and MCC_COMMON the "usual" disks? I
test using the same setup that you describe (I copy the mcc dns files
to my private directory) and I have never had any problems.
-Matt.
|
| RE: .1
Matt,
Excellent info, thanks. Seeing that you're using the setup I describe in
.5, but aren't seeing the problem I report in .6, I'll go through and
checks for shorts between my headphones, ;-) and if the problem still
persists file a QAR with tons of detail.
One thing that might give me a clue, though, can you give me an idea
in which context the %ERF-W-NOMSG, Message number 00088A60 error might
be generated?
Richard
|