Conference azur::mcc

	Please  review    the  DECmcc  v1.1  SPD/SSA  (posted  in  this
	conference).  It  will  answer  most of your questions, but not
	all.

	Min Memory if 16M although 24 is much nicer
	Min disk if 330  (RZ55),  although  RZ56  gives  you  plenty of
	breating room.
	We  use DECwindows (x based).    Any  windowing  terminal  that
	really supports x should work.

	JCE

    RE. 1 Thanks for your response.
    
    However, any X window terminal "should work" isn't appropriate enough
    of a response for a customer.  I can't say spend the $50k and it
    "should work".  They need to know that it will work.  If I have to say
    that you MUST use one of our X terminals and it WILL work GUARANTEED
    that is OK.  However, when the support center in Colorado Springs says
    that there are some glitches or possible problems with the use of X
    terminals (ours or anybodys) but can't tell me what those problems
    might be I am not in a position to recommend the solution to my
    customer.  Is there anyone within DEC that has used DECmcc Director
    with all of its components on a general purpose (timeshared) VAX with X
    window terminals (ours or anyones)?  If so please let me know who they
    are.  I need to know what the risk, loss of features, possible problems 
    that might exist if my customer uses a timeshare VAX with X terminals
    verses a VAXstation.
    
    THanks for any input.
    
    jerry
    
    Jerry
    exist 

    
    	We're using dual host 4000-200 cluster with vt1300's and vt1200's.
    So far no problems but the vt1200 is awfull slow with 2mb (have ordered 
    more memory).  The VT1300 is much nicer but we can't use the com port
    on the back like the VT1200.
    
    
    
    Scott

Folks,

What would be the optimum graphics adapter for MCC on VMS and RISC/ULTRIX?

My guess it that an SPX for VMS and an PXG.  Could anyone comment?



Thanks,
Ted

    when DSTEG is done with their evaluation we should be able to answer.
    I use SPX personally.
    

    I have been running this on a MV3100/16Meg/RZ55. Some things are
    clearly slow. Most notably, the exporter. The customer has offices in
    10-15 towns in Long Island and each one of offices has atleat on DR2000
    (or a 250) and we have set each one of the offices to be domain. So
    during "record"ing, there are about 10-15 "background" jobs and when
    you add the exporter and the iconic PM, it is not pretty. Each "export"
    for a line/circuit for a 24-hour period takes any where between 5-10
    minutes. I looked at the SSA (of the SPD) and it still states that a
    MV3100 with 32M/RZ56 is the minimum requirement. Realistically, I think
    for any network (medium sized), a more powerful cpu may be required. II
    hope this is part of the "evaluation" that Jill (-1) is referring to.
    
    Raja

    Minimum is minimim, not optimum. This is the smallest config that the
    software will run on at all.
    
    You are asking the system to do a lot more than the minimum work so
     no surprise it is slow.
    
    I have a few questions and then (based on what answers I get), perhaps
    some suggestions to reduce the load on your system.
    
    In each domain, how many entities are having recording done?
    
    And since you can also record on child entities (LINE, CIRCUIT etc),
     how many RECORD directives total are issued for each domain?
    
    s/rob

   >> In each domain, how many entities are having recording done?
    
    It varies. The maximum number of nodes is about 10-15 nodes (Ph IV) and 
    the min is 2. However, recording is done only on a select set of
    Routers (currently only 2) and am recording just the line & circ
    entities (I currently have partion=*, since the line speed from Char is
    used, although I not sure if I have to record the Char all the time).
    The record itself doesn't look bad, its the "export" (I do one export
    at a time, interactively) and it virtually grinds the system to a halt.
    The Iconic PM also takes a long time to show up and between
    double-clicks.
    
    reg
    
    Raja
    

    Ok, good. Here is what I suggest...
    
    Since DECmcc permits you to have entities in any number of domains
    you can create a domain for historical data recording. This is what
    I do.
    
    Create a domain for recording, start ONE background job, and place in
    the domain the entities that you want to record. Then issue the
    record commands.
    
    This should reduce the load on your system significantly.
    
    s/rob

    Re: .-1
    
    Rob,
    
    Right now the domains are setup to match the customers remote offices,
    and hence there are routers in each of the domain. From your reply, it
    seems that an entity (like a node4) can belong to more than one domain
    (if it doesn't, then it doesn't help); this was not readily apparent to
    me on a quick scan of the documents. The bigger problem I think is the
    Exporter. I will give you an example; last night I started "Export"ing
    data from 2 routers (4 lines & circuits on each, 16 exports in all) at
    around 6:00 in the evening and it completed this morning at 08:00
    clock. It seemed to have taken roughly 14 hours to export 16 line/circ
    info spanning over 2-3 days of info. Now this site has roughly 10-15
    routers and I can't imagine how long it would take to export all the
    info.
    
    reg
    
    Raja

    What is you workingset sizes for the export background? Is there a
    limit being imposed by your batch queues?
    
    I suspect that the slowness is being caused by excessive paging.
    
    What workingset sizes are you using for the username that run DECmcc?
    
    I find that for V1.1 I want 10000 - 14000 pages for WSEXTENT for sure.
    For T1.2.4 I use larger values.
    
    s/rob
    

    Rob,
    
    	Have you put together a command procedure for auditing system 
    resources for DECmcc T1.2 ?
    
    -Dan 

    The most recent version of the auditor checks for T1.2 needs. It's
    name has been updated as we expect to ship it on the VMS kit.
    
    You can get it at:
    	NETS::USER$NETS:[MCC011.S-KIT]MCC_AUDIT.COM
    
    s/rob

     -?
    
    yes an entity can be in multiple domains, that is why Robs
    idea for one recording domain works.