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

Conference bulova::decw_jan-89_to_nov-90

Title:	DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:	See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:	STAR::VATNE

Created:	Mon Oct 30 1989
Last Modified:	Mon Dec 31 1990
Last Successful Update:	Fri Jun 06 1997
Number of topics:	3726
Total number of notes:	19516

2256.0. "Busy System times out remote displays" by WINERY::VILAINMI (More garlic, says the cooking lady...) Mon Feb 12 1990 16:00

    I have a sometimes busy system that drops remote displays that are
    started on it with by users.  I frequently see my remote DECterm
    windows "die" if the system gets to busy (more than 4-5 COM processes)
    on the BANNER display also running on the system.
    
    Is there some DECnet EXEC parameter I can set to increase this timeout?
    
    /MeV/
    Santa Clara
    Software Services

T.R	Title	User	Personal Name	Date	Lines
2256.1		STAR::MFOLEY	Rebel Without a Clue	`Mon Feb 12 1990 23:43`	6
	What version of VMS?? mike
2256.2	remote DECterm dies under V5.3	NORGE::CHAD	Ich glaube Ich t�te Ich h�tte	`Tue Feb 13 1990 10:08`	8
	in a related vein. I'm running V5.3 SSB and have absolutely no problems with DECnet links dropping for applications started remotely and displaying on my workstation except DECterms started through CREATE/TERM. That DECterm hangs around 3-5 minutes and then dies. No other applications have this problem. Chad
2256.3	VMS V5.3 (and earlier)	WINERY::VILAINMI	More garlic, says the cooking lady...	`Tue Feb 13 1990 19:49`	12
	We're running VMS V5.3 SSB on a 785 with 32Mb memory and 7 assorted workstations. The user who sees this is running applications like VUE$MASTER or the DEBUGGER. I've seen it with BANNER. On another note, we frequently have to cycle DECnet circuit's boot service to have NETACP settle down (it page faults heavily while responding to boot requests, even if its working set is 7000!). When we do this, it breaks all links on the system (as would be expected). Has anyone else seen problems with applications dropping away under heavy loads? It could be that the boot service ON/OFF is what is blowing him away.
2256.4	Move boot requestors to area 1	DEMON3::CLEVELAND	Notes - fun or satanic cult?	`Wed Feb 14 1990 10:36`	8
	If you have frequent boot requests from a few known addresses, you can define them in the database as area 1 nodes (currently unused on the E-net) and cut the page-faulting. Even if you don't have a boot file defined for the node, it will find that out quickly rather than searching the entire database. Either that, or turn service off entirely. Tim
2256.5	Area 1 is not empty	BOMBE::MOORE	Eat or be eaten	`Wed Feb 14 1990 19:49`	1
	Um, area 1 is in use on the EasyNet, see node MARVIN (1.51), etc.
2256.6	well, until recently, anyway...	DEMON3::CLEVELAND	Notes - fun or satanic cult?	`Thu Feb 15 1990 10:32`	5
	Oops, I forgot about the phase V stuff... There should still be enough unused numbers in Area 1 to make this work, anyway. Tim
2256.7	Tsk, tsk...	ASD::LOW	Member - American Autobahn Society	`Thu Feb 15 1990 13:57`	9
	You can't just take 'em... you gotta ask for 'em... Imagine somebody else putting a node on the net in area 1 at the same address... Right Tim? :-) Dave
2256.8		BOMBE::MOORE	Eat or be eaten	`Thu Feb 15 1990 21:46`	6
	Well, actually for this purpose it probably doesn't matter whether the DECnet address is in use elsewhere or not. Adding node FOO's load parameters into the database entry for MARVIN (for example) should not create any conflict, as long as node FOO uses its assigned address for normal network traffic. Download parameters affect only the local node's response to boot requests.