Conference azur::mcc

6011.0. "MCC_TS_AM_STARTUP Hanging" by CUJO::BROWN (Dave Brown) Mon Jun 06 1994 15:59

	I am having a problem with SYS$STARTUP:MCC_TS_AM_STARTUP.COM hanging.
I have seen this problem on a V5.5-2 system, after it was upgraded to V6.1, 
and now on another customer's V5.5-2 new system build. In the case of the 
former two examples, the problem disappeared with no apparent explanation. In 
the case of the last example, the problem occurs every time the TSAM startup 
procedure is run. We are using TSAM V1.4 with EMS V2.3/BMS V1.3.

	As MCC_TS_AM_STARTUP executes, one can see with verify set that it 
first attempts to shut down any existing TSAM process via the command:

	MCC> DISABLE MCC 0 TERMSERVER_AM ABORT TRUE

	It then installs/reinstalls MCC_TS_AM.EXE Then if the TSAM process is 
still present, it does a STOP/ID on it. Then the procedure jumps back into MCC
and issues the following two commands:

@mcc_common:mcc_enroll_ts_am

%MCC-I-ENRDUPLENTRY,enrollment successful; duplicate entries found and replaced

enable mcc 0 termserver_am

** THIS ** is where the hang occurs. When I bring up another interactive 
session and get into SDA to see what the process that is running the startup 
procedure is doing, it is in LEF state with a busy channel to a mailbox. From 
DCL, I have tried copying something to the mailbox; the process running the 
startup procedure comes out of its hang and the following message is displayed:

MCC 0 TERMSERVER_AM

AT 6-JUN-1994 17:48:21

The requested operation cannot be completed

			VMS Routine Error = 
%NONAME-W-NOMSG, Message number 00000000

The command procedure then continues to completion. This will also occur if I 
type a ^C in the session that is running the startup procedure.

While the process running the startup procedure is hung, a SHOW SYSTEM reveals
that there is a TSAM process running but it disappears as soon as the hang
is aborted. It's almost like the process running the startup procedure is 
expecting the TSAM process to reply to its mailbox once the TSAM process is 
up but this communication doesn't happen.

As indicated earlier, I have another system that this problem used to occur on
but the problem has vanished. The problem vanished as a possible result of 
upgrading VMS to V6.1 of installing V1.4 of TSAM; I don't know which one, if
either, 'fixed' the problem. On this customer's machine which is having the 
problem currently, VMS is V5.5-2 and TSAM is V1.4.

The process quotas don't seem to be a problem. The process quotas in which I 
run the TSAM startup procedure on the customer's machine are:

	Maxjobs:	0  Fillm:	50  Bytlm:        2000000
	Maxacctjobs:	0  Shrfillm:	 0  Pbytlm:		0
	Maxdetach:	0  BIOlm:     4096  JTquota:	     4096
	Prclm:	       30  DIOlm:     4096  WSdef:	    17920
	Prio:		4  ASTlm:     4096  WSquo:	    28160
	Queprio:	0  TQElm:     4096  WSextent:       65536
	CPU:       (none)  Enqlm:     4096  Pgflquo:	   300000

I'd appreciate some help with this problem, I have arrived at wit's end.

	Thanks!

	Dave

    Its a new one to me.... I'd check all of the usual suspects: does the
    account have privs?  I assume the accounts quata's match DECmcc
    requirements
    and whatever might be in the release notes/user doc for TSAM. 
    Re-install
    TSAM, and make sure there are no errors duing the dictionary update
    (except
    the ones the release notes tell you are OK.)
    
    I think they have shut off my old development account, so I can't tell
    you more, try setting the MCC_TS_AM_LOG to FFFF or whatever, and
    see if that displays anything useful.
    
    Other than that, check with the French guys, Dirk jaspie::anteunis
    maybe can help....
    
    -Dave
    

Dave,

You refer to TSAM V1.4 , do you mean V1.0.4 ? If you are using V1.0.4 then 
I don't know what caused your problem. However, if you are using TSAM V1.0.3
then please read note 5371.* .

To find out what version of TSAM :

	mcc> show mcc 0 termserver_am att attr


andrew 

  Reply to .1: What did these ugly people do to good ol' Dave's account ?
               Dirk is not french but belgian
               AZUR::ANTEUNIS is my correct e-mail address



  As far as I know the code (learned from Dave Fonseca) I woudl suspect
  either or both of 2 things: the TSM library on which TSAM is built and
  the version of DECnet

  TSAM uses mailboxes to communicate with a spawed process. The latter
  does the real communication with the Terminal Servers. The parent process
  does all the multi-threading and DECmcc specific stuff.

  If You dont' have a TSM license active on Your system, the subprocess
  will behave "strange", and the mailbox communication might get into
  an eternal wait state where both ends are reading form it. So Andrew
  has probably pinpointed the problem.


  As far as DECnet IV - DECnet/OSI, TSAM uses the DNA4 AM to do things
  like NCP sho node xxx char. This serves to kows what image is downloaded
  if a (older generation) Terminal Server is booting. As far as I know
  this is not present in the current V1.0.4 version of TSAM for DECnet/OSI.
  But You never know we discover a quick fix in the "dead code".


  Dirk

    
    
    	I started growing wary of the quality of the TSAM installation so I
    reinstalled it. After I reinstalled TSAM (V1.0.4), it did not hang on
    startup any more. I suspect it was a problem with the MCC data dictionary 
    which was not properly modified when TSAM was installed on the system 
    originally.
    
    	Thanks for all the quick responses!
    
    	Dave