Conference azur::mcc

    
    Hi Hank,
    
    Two questions:
    
     1. What version of MCC are you running?
     2. What entity are you recording?
    
    Sam

    Hello,
    
    Thank you for response.
    
    1- Version 1.1.0
    2- Entity .LTA158_1 
       In domain AIRCO_FASE2
    
    
    Henk.

Hello Sam

We're trying to get the historian work with our home-brewed AM.

This Access Module monitors an airconditioning in a computerroom and
the global entity is called WRIGHT (and has no childs).

We have augmented our dictionary using WRIGHT_HIST_AUGMENT.COM and
                                       WRIGHT_EXP_AUGMENT.COM

In the Iconic Map PM we're able to select the RECORD and EXPORT directives,
but we are not able to actually record attribute information because the
background process is not running.

We initialized a batch-queue history as described in the BMS-use-documentation.

If we try to submit the background process the error mentioned in 885.0 occurs.

Hope this information and the information of reply 2 can ansers your questions
of reply 1.

Regards     P.Goes    (Partner-developer of Henk v.Steeg)

  Thank you for pointing to this problem. This is a bug in the Historian
  background.

	Historian background process does not handle correctly the size of
    the p_out in the mcc_call when it does Show for the specified entity and
    partition. As a result if the size of the returned p_out is more that
    1024 bytes the mcc_call fails.

	I submitted qar number 601 in mcc_internal.

	Sam
    

Thanks for your effort, but we don't understand the cause of the problem

> Historian background process does not handle correctly the size of
> the out_p in the mcc_call when it does Show for the specified entity and
> partition. 

specified entity and partition ?  Where are these specified ?

The only things we did are :

$ initialize /queue /start /batch /job_limit=10 /owner_uic=[goes] -
_$  /protection=(system:e, owner:d, group:rw, world) HISTORY

$  submit /queue=HISTORY /restart /parameters=(.airco_fase3) -
_$  sys$manager:mcc_historian_background.com /notify


The message that appears on the screen (after 2-3 seconds) is:

Job MCC_HISTORIAN_BACKGROUND (queue HISTORY, entry 436) terminated with
error status
%NONAME-E-NOMSG, Message number 1326CEFA

The log file contains the error message mentioned in 885.0:

%MCC-F-INSUFBUFFER,   data not returned due to lack of return data buffer space
%MCC-F-INSUFBUFFER,   data not returned due to lack of return data buffer space

We're wondering now : where did we specify an entity or a partition ?
The only thing we specified in these commands is the domain-name.

Does the background process determine which entities are registered in the 
given domain and determine the partitions of these entities (and how ?) ?

From reply 4 we understand that the background process places a MCC_call.
But which call(s) and with what purpose ?

Can someone clear some of this things up ?

Another question:
In the documentation BMS-use V11-EFT page 2-8 (Establish background process)
the following sentence is printed:
"You must establish a background process for each RECORD directive you issue."

Establishing a background process is done by submitting the
MCC_HISTORIAN_BACKGROUND.COM in a queue. But the only parameter with this
submit command is the domain name.
What happens if we want to RECORD information for two entities in the same 
domain ?  Do we have to submit two background processes with the same
domain name ? How is determined which background process is for which 
RECORD directive ?

Regards     Paul

	RE: .5

	Paul,
 Here are answers on your questions:

>We're wondering now : where did we specify an entity or a partition ?
>The only thing we specified in these commands is the domain-name.
>
>Does the background process determine which entities are registered in the
>given domain and determine the partitions of these entities (and how ?) ?
>
>From reply 4 we understand that the background process places a MCC_call.
>But which call(s) and with what purpose ?

 An entity and a partiton were specified in the Record directive.

 The background process knows which entities and partitions were reqiested
 to record (as well as polling interval,begin and end time). For each recording
 request background process creates a thread which issues mcc_call for a 
 desired entity and partition according to the specified schedule . Even if the
 system  reboots the background process will recreate threads for all active 
 recording requests. Data received from mcc_call are stored in the historical
 repository and can be obtained later using Show directive with past time
 scope of interest time.

>In the documentation BMS-use V11-EFT page 2-8 (Establish background process)
>the following sentence is printed:
>"You must establish a background process for each RECORD directive you issue."
>
>Establishing a background process is done by submitting the
>MCC_HISTORIAN_BACKGROUND.COM in a queue. But the only parameter with this
>submit command is the domain name.
>What happens if we want to RECORD information for two entities in the same
>domain ?  Do we have to submit two background processes with the same
>domain name ? How is determined which background process is for which
>RECORD directive ?

 This is an error. From the final SSB version of the BMS USE manual:
"... you must submit a job that starts a Historian background process for each
 domain for which you will record data".

    ----------------------------------------------------------------------------
    
 After investigation I found that the bug described in .4 should not give the 
 broblem you have. Would you, please, do the following experiment:

	1. Try to record "well_known entity", for example NODE4:
	   a. Create a new domain
	   b. SHOW domain new_domain ALL CHAR
	   c. DIRECTORY NODE4 node4_name  
	   d. SHOW NODE4 node4_name ALL COUNTERS
	   e. submit a historian background for a new domain
	   f. RECORD NODE4 node4_name -
			PARTITION=counters,
			IN DOMAIN new_domain
	    ( if are free to specify polling period and end time but,please,
	      do not specify begin time argument).

	2. If the first part of the test is successfull try to record "your"
           entity:
	   a. DELETE RECORDING NODE4 node4_name-
                        PARTITION=counters,
                        IN DOMAIN new_domain
           b. DIRECTORY entity_you_want_to_record
	   c. SHOW entity_you_want_to_record ALL partition_you_want_to_record
	   d. RECORD entity_you_want_to_record -
			PARTITION=partition_you_want_to_record,-
			IN DOMAIN new_domain
	    ( if are free to specify polling period and end time but,please,
	      do not specify begin time argument).

  I'd appreciate if you can send the results of this test to 
  TOOK::SHMUYLOVICH
	   
			Regards, Sam
    

    
    	Whatever happened to this problem?  I have been seeing
        the same behavior with a NODE4 LINE record instance.
        Is there any way that someone can configure a NODE4 to
        cause the error?
    
    	Ted.