|  |     Brad,
    	Hi.  I had a similar situation, which I'll *briefly* share with
    you...  I had 5 domains, and figured I'd setup 5 HISTORIAN background
    processes for my historical recording...  Next, I setup 5 EXPORTER
    background processes for my exporting of data, which I intended to use
    for the REPORTER.  DON'T TRY THIS AT HOME!!!  It caused all kinds of
    problems, related to performance...smile.
    	Here's what I've done.  I setup 1 domain,  and using FCL (note, I
    don't believe you can do this with the IMPM), I setup all my recording
    to point to 1 domain!
    
    An example of the syntax would be like this:
    
    	MCC> RECORD BRIDGE 'bridge_name' PARTITION='name', IN DOMAIN -
    	RECORDING_COLLECTOR
    
    	As a footnote, when you create the domain, I would recommend that
    you put the directory for the domain on an alternate disk, that way if
    the disk space becomes an issue, which it shouldn't, but you never
    know, you're not clobbering your system disk.  8^)
    
    	Hope this helps, I've had alot of recent experience using
    HISTORIAN/EXPORTER/REPORTER, mostly bad due to my stupidity...smile, so
    if you get into trouble you can drop me a line, JUNG::GALVIN.
    
    good luck,
    
    /Mic
    
 | 
|  | Hi Mic,
>    	Hi.  I had a similar situation, which I'll *briefly* share with
>    you...  I had 5 domains, and figured I'd setup 5 HISTORIAN background
>    processes for my historical recording...  Next, I setup 5 EXPORTER
>    background processes for my exporting of data, which I intended to use
>    for the REPORTER.  DON'T TRY THIS AT HOME!!!  It caused all kinds of
>    problems, related to performance...smile.
Learning the hard way hurts but you never forget (been there too). I first had
12 historian processes to match our map domains, which I changed to 4 later
because of performance. I'm collecting on 100 circuits so I don't know if I
can get away with a single process but I'm going to try in the near future.
  
>    	As a footnote, when you create the domain, I would recommend that
>    you put the directory for the domain on an alternate disk, that way if
>    the disk space becomes an issue, which it shouldn't, but you never
>    know, you're not clobbering your system disk.  8^)
 
I've found that space typically isn't our problem, but the I/O rate on the 
disk has bottlenecked causing yet more performance problems. This problem is
a bit more deceiving and can bring the system (and/or mcc) to its knees so
you're absolutely right about being careful which disks to use. At this point
we are using 3 seperate disks, one each for system, mcc_common, and 
user/history.
Good info but the origin question still stands, do the entities *HAVE* to be
members of the domain which the historian process was set up for???
thanks,
brad...
    
 | 
|  |     
 Re: .0
>So can is it ok for RECORDs and SHOW STATIS commands for non-members or do I
>lose something that I cannot see today??? This would mean several less domains 
>to maintain.
 RE: .2
>Good info but the origin question still stands, do the entities *HAVE* to be
>members of the domain which the historian process was set up for???
  The only requirement for a target entity is to be registered.
 RE: .1
>    	Here's what I've done.  I setup 1 domain,  and using FCL (note, I
>    don't believe you can do this with the IMPM), I setup all my recording
>    to point to 1 domain!
    You can do it from IMPM as well as from FCL.
     SAm     
    
 |