[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:	DECmcc user notes file. Does not replace IPMT.
Notice:	Use IPMT for problems. Newsletter location in note 6187
Moderator:	TAEC::BEROUD

Created:	Mon Aug 21 1989
Last Modified:	Wed Jun 04 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	6497
Total number of notes:	27359

3545.0. "TSAM hangs, plus a question" by ANOSWS::COMFORT (Spent a little time on the hill) Wed Aug 12 1992 12:27

    
    I would like to report strange behaviour of the TS AM detached server
    process.  I have not noticed anything particular in the notes, but have
    not read all entries. 
    
    I now have another customer, Sterling Winthrop, pretty big, where we
    have made a big NIS sales with the flagship being the DECmcc
    workstation for management.  We were running a test bed mini network
    for the customer at the BTO facility during the past two weeks and I
    set up the system like I usually do, with a process running the alarm
    rules in line mode in the "background", and the iconic map for
    notification purposes, ie. no rules running from the map.  By mistake
    during a flurry of activity, I control-y'd the line mode instance of
    MCC and logged out the terminal window (just call me Mr. Thumbs). When
    I restarted the MCC line mode instance, I noticed that the rules for
    terminal server monitoring hung.  Additionally, I could not communicate
    to any terminal server from either the line instance or the IMPM.  I
    found that the only way to get things operating again was to stop/id
    the terminal server process and restart it.  I made this happen at
    least a half a dozen times, even with a logical exit of the MCC
    line instance, ie. control-z. 
    
    Any thoughts?!  Or was this reported already.  
    
    I am also interested, since I have not obtained the docs yet, to learn
    if there is a different way of setting initial (or permanent)
    characteristics of a terminal server that performs better than what
    Sterling asked to do, ie. convert a TSM command script to the
    equivalent NCL/MCC style and run it from MCC.  I did this and it took
    35 minutes to configure one DECserver 700... not acceptable.
    
    Thanks,
    
    Dave

T.R	Title	User	Personal Name	Date	Lines
3545.1	Have observed the same problem, se note 3415.	ANTIK::WESTERBERG	Stefan Westerberg DS Stockholm	`Thu Aug 13 1992 10:17`	4
	I have observed the same problem described in note 3415, but I haven't recived any answer !! /Stefan
3545.2	TSAM still has this problem	TOOK::FONSECA	I heard it through the Grapevine...	`Thu Aug 13 1992 13:52`	30
	Yep, I'm embarassed to say this is still a problem with TSAM. I had thought it had been cleared up after the last field test update, but have been able to duplicate the problem myself since. It is not necessary to stop the detached process the way you have been though. Either execute the sys$startup:mcc_ts_am_startup.com� command file, or from mcc execute the following two commands: MCC> DISABLE MCC 0 TERMSERVER_AM ABORT TRUE MCC> ENABLE MCC 0 TERMSERVER_AM Directives with similar effect are available from the iconic map. RE: DECserver 700 setup times. Although setting up a terminal server from scratch does take quite a bit longer than the corresponding TSM Getchar scripts, I'm still surprised by the 35 minutes you are getting. I'm assuming you are comparing TSM getchar script execution with TSAM getchar script execution? Unless you are using some of the newer internet features on the 700, go in to the command script and eliminate those commands, that should half your time. (If you have not used the TSAM Getchar utility, look in appendix B of the Use manual, it will save you much time with setup.) On the next version of TSAM, I would like to improve the execution times of scripts like this, but for now, there is not much else which you can do. No matter what is done to TSAM in the future, it will never be as fast as TSM, because TSAM is layered on top of TSM. -Dave
3545.3	more hangs...	GIDDAY::DRANSFIELD	Mike Dransfield, Sydney RSSG	`Mon Sep 07 1992 22:03`	33
	re: .2 Is there anything else that can cause TSAM to hang? I have a server that I can access fine from TSM, but TSAM just hangs seemingly forever... MCC> disabl mcc 0 termserver_am abort true MCC 0 TERMSERVER_AM AT 8-SEP-1992 10:12:32 Normal operations terminated. MCC> enable mcc 0 termserver_am MCC 0 TERMSERVER_AM AT 8-SEP-1992 10:12:38 Normal operation has begun. MCC> show term rssg all attr Terminal_Server BUSHIE_NS:.rssg AT 8-SEP-1992 10:12:43 All Attributes Address = 08-00-2B-04-A9-4F Name = BUSHIE_NS:.rssg BUSHIE::DRANSFIELD 11:01:25 MCC_MAIN CPU=00:00:27.82 PF=10317 IO=1449 MEM=7571 !!! it just hangs here This is V1.2 MCC on VMS V5.5-2S7 with DECnet vax extensions. Thanks, Mike
3545.4	reregister fixed it	GIDDAY::DRANSFIELD	Mike Dransfield, Sydney RSSG	`Tue Sep 08 1992 19:46`	6
	re: .3 I think this was a problem with the way it was registered. I had registered two names with the same address and also didn't have log_io and phy_io privilege. Having reregistered it, it now works fine. Mike
3545.5	SERVICE CIRCUIT is important	BERN01::GMUER		`Thu Nov 26 1992 10:41`	113
	We had a lot of problems with an interrupted or hanging TS AM. DECmcc runs on a different node than the load host of the terminal servers. After an evaluation of all possibilities we found that the TSM convert utility generates SERVICE CIRCUIT statements, which may not be correct on the MCC system: -------------------------------------------------------------------------- $ mana/enter DECmcc (V1.2.0) MCC> ! DECmcc procedure generated by MCC_TS_AM_CONVERT utility MCC> ! MCC> REGISTER TERMINAL_SERVER .TS.GBE310 - _MCC> ADDRESS=08-00-2B-1B-E6-8D,- _MCC> TYPE=DS300,- _MCC> MAINTENANCE KEY=%X0000000000000000,- _MCC> LOGIN KEY="ACCESS" Terminal_Server LOCAL_NS:.ts.gbe310 AT 26-NOV-1992 16:18:57 Registration successful. MCC> SET TERMINAL_SERVER .TS.GBE310 - _MCC> DECNET ADDRESS=13.7,- _MCC> IMAGE FILE=SYS$SYSROOT:[DECSERVER]SH1601ENG.SYS,- _MCC> DUMP FILE=SYS$COMMON:[DECSERVER]DS3GBE310.DMP ! ,- _MCC> ! SERVICE CIRCUIT={BNA-0} <-- Coment the critical statement Terminal_Server LOCAL_NS:.ts.gbe310 AT 26-NOV-1992 16:19:16 Characteristics Modification completed successfully. Dump File = SYS$COMMON:[DECSERVER]DS3GBE310.DMP Image File = SYS$SYSROOT:[DECSERVER]SH1601ENG.SYS DECnet Address = 13.7 MCC> SHOW TERMINAL_SERVER .TS.GBE310 ALL STATUS Terminal_Server LOCAL_NS:.ts.gbe310 AT 26-NOV-1992 16:19:56 Status Examination of attributes shows Current Active Ports = 2 High Active Ports = 4 Max Active Ports = 16 Current Active Users = 2 ............ MCC> SET TERMINAL_SERVER .TS.GBE310 - _MCC> SERVICE CIRCUIT={BNA-0} Terminal_Server LOCAL_NS:.ts.gbe310 AT 26-NOV-1992 16:20:08 Characteristics Modification completed successfully. Service Circuits = { "BNA-0" } MCC> SHOW TERMINAL_SERVER .TS.GBE310 ALL STATUS Terminal_Server LOCAL_NS:.ts.gbe310 AT 26-NOV-1992 16:20:19 Status Communication with the target has been interrupted MCC> DISABLE MCC 0 TERM ABORT TRUE MCC 0 TERMSERVER_AM AT 26-NOV-1992 16:20:43 Normal operations terminated. MCC> ENABLE MCC 0 TERM MCC 0 TERMSERVER_AM AT 26-NOV-1992 16:21:30 Normal operation has begun. MCC> SHOW TERMINAL_SERVER .TS.GBE310 ALL STATUS -----------> Here it hangs MCC> SET TERMINAL_SERVER .TS.GBE310 - _MCC> SERVICE CIRCUIT={ISA-0} Terminal_Server LOCAL_NS:.ts.gbe310 AT 26-NOV-1992 16:23:55 Characteristics Modification completed successfully. Service Circuits = { "ISA-0" } MCC> SHOW TERMINAL_SERVER .TS.GBE310 ALL STATUS MCC> DISABLE MCC 0 TERM ABORT TRUE MCC 0 TERMSERVER_AM AT 26-NOV-1992 16:24:19 Normal operations terminated. MCC> ENABLE MCC 0 TERM MCC 0 TERMSERVER_AM AT 26-NOV-1992 16:24:23 Normal operation has begun. MCC> SHOW TERMINAL_SERVER .TS.GBE310 ALL STATUS Terminal_Server LOCAL_NS:.ts.gbe310 AT 26-NOV-1992 16:24:27 Status Examination of attributes shows Current Active Ports = 2 High Active Ports = 4 Max Active Ports = 16 Current Active Users = 2 ........ -------------------------------------------------------------------------- Regards, Edgar
3545.6	QAR#233 in MCC013_INT	CHRISB::BRIENEN	Network Management Applications!	`Mon Nov 30 1992 09:25`	1
	The previous note has been added to the MCC013_INT database as QAR#233.
3545.7		TOOK::FONSECA	I heard it through the Grapevine...	`Mon Nov 30 1992 10:40`	26
	From what I can tell, you are describing two seperate problems here: 1. When you use the TSM convert utility, you wish it would somehow magicly put the correct circuit name into the registration script. All the convert utility does is extract the information from the TSM database, and put it in a script ready to be loaded into TSAM. There is no way the conversion program could know what the service circuits will be in the future if the script it generates is copied from one node to another. If the user wishes to run TSAM on a node which has different ethernet devices than the node TSM was run on, they should edit the registration script and do a wild-card replace from BNA-0 to ISA-0 for example. It probably is not documented that you should note this fact, and I will make sure that is added to the documentation if we ever come out with another version. 2. Once you have registered a terminal server with the wrong circuit information, you don't want TSAM to hang when attempting to connect to the terminal server. I can't tell from your note whether you have installed the update to TSAM (V1.0.2) which corrects a hanging problem which may be similar to yours. If you have not installed this kit, I would suggest you do.
3545.8	Re .-1	BERN01::GMUER		`Tue Dec 01 1992 06:04`	6
	Thanks for the fast replies ! Re .-1: I did not expect any magic in the conversion utility. I think a warning message during the run of the utility with an additional hint in the TSAM documentation is enough. The sense of the note was to inform the DECmcc people about a potential trap.