Conference azur::mcc

The domain name, which defines where it sits in the namespace hierarchy, 
does not govern whether Exporting or Recording can be done.

You can export data from  DOMAIN .test and from DOMAIN .group1.test in 
exactly the same manner with exactly the same syntax.

...kjn

That's true, but can you record against a domain that sits within a subdirectory

ie .domain.test where .domain is a subdirectory and not a domain. You would then
have to submit your batch jobs against .domain.test. I is going to complain
because .domain isn't a domain but a subdirectory in which resides the obj test.

Bipin.

I think that there is some confusion here about how the DECdns namespace 
works and how DECmcc uses the namespace.

1)  You should read the DECdns documentation
2)  There is documentation in the DECmcc doc set on how DECmcc uses the 
    namespace

The following directives:

	RECORD DOMAIN .group1.test ...
	RECORD DOMAIN .test ...
	RECORD NODE4  .dna_node.kajun
	RECORD NODE4  .group1.took

each ask the DECmcc system to record attribute values for an entity.  The 
domain names `.group1.test' and `.test' are irrelevant to the RECORD 
directive, except to identify the entity whose attributes you want 
recorded.

Now, as to the meaning of a DECdns fullname, or as the industry calls it 
a `fully distinguished name'...  ".group1.test" merely specifies the 
unique name of an object `test' in the subdirectory `group1'.  It is 
just a way of naming objects in a hierarchical fashion and ensuring a 
way to uniquely name objects.  

Any identifier of a global entity that is of datatype fullname only 
names that entity.  The way you name global entities (objects in the
namespace) does not suggest to DECmcc any hierarchical relationship to
other global entiies known to DECmcc.  You could name a domain

	.domain.test

and a node

	.domain.fred

Certainly this would be confusing to the end user, but totally legal.  
Again, the structure of the name of the global entity does not suggest any 
relationship to other entities OR make any statements about the class of 
the entity.

Hi,

That's fine, .group1.test would be domain test residing in dns directory group1.
Therefore to reference the domain test with historian (ie param part) you would
have to give the complete object pathname ie .group1.test, which should in 
theory submit a batch job against the domain test.

Now, if i do this i get parent entity does not exist when the historian command
file tries to pass the param to the hist_xxx.exe (not sure of the exact image 
name). If however, i move the domain object and put it under root (.) then all
works fine.

Am i doing something wrong.

Bipin.

I am confused because a domain is a global entity and has no parent, so
you should never get the error you indicated when trying to record for
the domain entity.  Are you trying to record attributes for members of 
the domain or the domain entity itself?

Could you try the operation from the FCL and post the results here so
that what you are attempting to accomplish is really clear? 

...kjn

kjn,

You are right I've just created a directory in dns and used mcc to put a domain
into it. I then put a node4 entity into this domain and submitted the historian
batch job, all worked fine.

What i suspect happened on the customer site is that the domain hadn't been 
created correctly

ie show domain .xxx.xxx all char probably didn't come back with a correct dir
spec. I can't prove this now because the system has been changed.

many apologies

Bipin.