Conference azur::mcc

Nope I was not aware of this problem until you reported it.
It is due I suspect to a conflict between the Port session entity
and the the session limit attribute.  We will have to change the
attribute name to correct the problem.

Thanks for the bug report.

-Dave

Ooops spoke too soon.  There is no attribute Initial Session Limit.
Because of the conflict I alluded to in the previous reply, this attribute
was named Port Session Limit.

Thus the SET or SHOW command would have the word PORT twice:

set PORT 1 initial PORT session limit = 4

-Dave

    Dave,
    
    	Thanks and apologies. You may want to look at the help text. I think
    it still refers to INITIAL SESSION LIMIT. 
    
    regards,
    Andrew

Gee, you are the first person I've ever heard of who has used on-line help!
(If you think finding the info you want in DECmcc's on-line help is
difficult, its even worse trying to maintain it! :-)

Thanks for the report, I'll check it out...

-Dave

    Yes,
    	Amazing what a lack of manuals will force one to bear. OLH can be
    very slow.
    
    	On a related matter. What I am doing is pulling all the details off
    the server into a couple of files which I am then running through a TPU
    routine to turn back into configuration files to be used (for example)
    when the server is physically replaced.
    
    	Some problems.
    
    	The PORT INITIAL SESSION LIMIT attribute does seem to work but it
    can be a bit flaky when on the same command line with other attributes.
    Likewise the INITIAL PREFERRED/DEDICATED SERVICE attributes. I work
    around this with some kludge work in the TPU to drive these onto
    separate command lines. I also have to make sure my command lines don't
    get too long, either.
    
    	As of right now, this seems to work okay.
    
    	TSAM is kind of polite because it has all these "initial"
    attributes so I just use them. Ideally I'd like to do something similar
    with my bridges but the ELM doesn't seem to have "initial" attributes
    so I am looking at having to work it all out myself (work - yuk!). But,
    thinks Andrew, maybe I can whip into the dictionary or some such
    beastie and look at one of those cryptic flags on all the attributes to
    see which ones are setable.
    
    	Can I? If so, what flag do I check?
    
    thanks,
    Andrew
    
    p.s. in my ventures to do these and other tasks i have set MCC running
    in a subprocess so i can do the dirty work in the main process. i use
    this for my routine which secures directives from beingdisplyed on the
    iconic map interface. its kind ofhandy at times. if there is any
    interest i'll bundle it up and ship it out.

The help files you are using are ancient, I didn't get around to updating
them until after the TSAM T1.2.7 update.  If you wish, you can copy the
latest kit form TOOK::TSAM$KITS: it has the same version number, but
new help files and lots of bug-fixes.

It sounds like you are doing manually what the MCC_TS_AM_GETCHAR.EXE utilty
does automatically, RE: cloning server settings.  Again you'll want the
new kit, the old getchar had a zillion bugs.  The getchar is lots slower than
the TSM version, but with carefull editing, you can eliminate lots of
set-up code which you may not be interested in.  If you hadn't heard of
this utility, print out the user's manual, and look in the appendix (B?)
there are several other utilities you might want to try.

If you are truely using the help extensively, you might just be better off
popping into an editor on the file MCC_COMMON:MCC_TS_AM.HELP.  This is
the source for the TSAM online help, and then you could do searches for
likely strings.  The MRM for TSAM (In the upcoming SSB kit) also has all of the
attribute info laid out.

-Dave