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

Conference csc32::consolemanager

Title:	POLYCENTER Console Manager
Notice:	Kits, Scans, Docs on CSC32:: as PCM$KITS:,PCM$DOCS:, PCM$SCANS:
Moderator:	CSC32::BUTTERWORTH

Created:	Thu Aug 06 1992
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	1541
Total number of notes:	6564

600.0. "TCPIP CONSOLE PORT READ ERROR" by KERNEL::ROOMEM () Mon Feb 06 1995 17:47

 Dear all

 My customer is attempting to use PCM 1.5 to monitor a remote node. The 
customer is using UCX 3.1

 Unfortunately, whenever console output is generated on the node being 
monitored, he receives the following messages both in the CONTROLLER_01.log 
file and the PCM event list window. 

   Read error on TCP socket port number 2002
   error 0

 The console then reconnects, during the time between the disconnection and 
reconnection no console messages are produced. It takes approximately
10 seconds from when the console output stops being displayed to the 
time the error message is generated. The error message is not produced 
when there is no console output generated. (so could it be a buffer problem) 

 Now I don't know TCPIP, but I thought the child process is both responsible 
for producing the error message and the reconnection.  To this end I checked 
both the TCP PROBE TIMER and DROP TIMER

               UCX> SHOW PROTOCOL TCP/PARAMETER

 and the poll timer is 75 seconds and the drop timer 600.

 Now this can't be the problem as it takes approximately 10 seconds from 
losing the messages and the error message appearing.

 I'm really struggling to troubleshoot this problem.

 Could it be a buffer problem, but what buffers do I need to check. (You 
don't see any messages in the event window when no console output is produced,
so it could be buffers, but why would the child process drop the connection)

 I'm looking for anyone who may have seen a similar problem, or who knows more
about why the child process drops the console line, so that I can troubleshoot 
further. 

 BTW. LAT is perfectly OK, its just TCPIP that is a problem
  
 Any input, gratefully received.

 Regards

 Martin Roome 
 VMS Specialist
 Basingstoke.

T.R	Title	User	Personal Name	Date	Lines
600.1		OPG::PHILIP	And through the square window...	`Mon Feb 06 1995 18:32`	11
	Martin, What does the terminal server do when you telnet to it, that is... $ TELNET server portnum Does this give you a successful connect and are you able to interact with the server? Cheers, Phil
600.2	Everything is OK	KERNEL::ROOMEM		`Mon Feb 06 1995 20:18`	13
	Phil, Thanks for the response, I should have said in my first message, that this is a DECserver 90TL, and that problem is intermittent, sometimes all console output is handled sucessfully and it will fail at different points (he's running a command procedre that produces a known ammount of console output for testing purposes) I'll certainly get him to try that, but I'm expecting to be able to connect via TELNET. I'll certainly let you know if there are anyother messages produced. Cheers.
600.3	OK when you TELNET	KERNEL::ROOMEM		`Wed Feb 08 1995 21:40`	12
	Phil, Its like I said, when he uses TELNET to connect to the port, and generates his console output, everything is OK. No additional error messages, (even after repeated tries he was unable to get it to fail.) Given the nature of the message could it be an application error, but as I said how do I troubleshoot. Cheers
600.4		CSC32::BUTTERWORTH	Gun Control is a steady hand.	`Wed Feb 08 1995 23:52`	7
	Go into UCX and do a SHO COMM. Check the number of free small buffers. If it's close to 0 then you'll need to increase the number of small buffers. This command varies with the version of UCX thats running. Be sure and check this with PCM running!!!!! regs, Dan
600.5	Still no joy on the UCX front	KERNEL::ROOMEM		`Thu Feb 09 1995 17:00`	24
	Dan, I went into UCX, did a SHOW COM and neither the SMALL BUFFERS, LARGE BUFFERS "free value" came close to 0. (In fact they didn't change at all) We then did a SHOW COM/MEM and the peak values for SMALL BUFFERS, LARGE BUFFERS, SERVICES and DEVICE SOCKETS never got any where near there maximum value (infact the small and large buffers peak useage were 3 and 4, the services and sockets were equally low) Does this now point to the controller process or am I jumping the gun, are there any PCM buffers to check? Thanks again for your input. PS. The customer can't get his DECserver to transmit a break, I thought it was just a case of setting the port on the decserver to BREAK=REMOTE. It works fine with LAT, but not TELNET. Again, any suggestions. Cheers. Martin Roome CSC, Basingstoke.
600.6		OPG::PHILIP	And through the square window...	`Thu Feb 09 1995 17:26`	7
	Martin, Can you post your customers DECserver setup details and we will try and reproduce this problem here. Cheers, Phil
600.7		CSC32::BUTTERWORTH	Gun Control is a steady hand.	`Thu Feb 09 1995 20:32`	11
	Matin, Also do you know what version of the DECServer software Network Access Software the server is running? A SHO SERVER command at the Local> prompt will tell us this. I had a 90TL running in lab I have had no problems with it. I also suspect that the problem with the break is with the server which is the other reason we need to know the software version. We had problem with LAT several years ago where certain baselevels of the decserver software on DS200's failed to generate a break when commanded to do so! Regs, Dan
600.8	I hope this gives you guys some clues	KERNEL::ROOMEM		`Tue Feb 14 1995 16:53`	47
	I hope the following SERVER and PORT information, sheds some light on the problem, the customer is getting a bit desperate. Cheers DECserver 90TL Communications Server V1.1 (BL44-10) - LAT V5.1 (c) Copyright 1992, Digital Equipment Corporation - All Rights Reserved Please type HELP if you need assistance Enter username> A Local> SHOW SERVER DECserver 90TL V1.1 BL44-10 LAT V5.1 ROM 2.0.0 Uptime: 16 05:32:50 Address: 08-00-2B-A3-94-0C Name: DS9001 Number: 0 Identification: Circuit Timer: 80 Password Limit: Console Port: 1 Prompt: Local> Inactivity Timer: 30 Queue Limit: 100 Keepalive Timer: 20 Retransmit Limit: Multicast Timer: 30 Session Limit: 64 Node Limit: 200 Software: MNENG1 Service Groups: 0 Enabled Characteristics: Announcements, Broadcast, Dump, Lock Local> SHOW PORT ALL CHAR Port 7: (Remote) Server: DS9001 Character Size: 8 Input Speed: 9600 Flow Control: XON Output Speed: 9600 Parity: None Signal Control: Disabled Stop Bits: Dynamic Access: Remote Local Switch: None Backwards Switch: None Name: PORT_1 Break: Remote Session Limit: 4 Forwards Switch: None Type: Soft Default Protocol: TELNET Preferred Service: None Authorized Groups: 0 Groups: 0 Enabled Characteristics: Autoprompt, Broadcast, Input Flow Control, Loss Notification, Message Codes, Output Flow Control, Verification
600.9		CSC32::BUTTERWORTH	Gun Control is a steady hand.	`Wed Feb 15 1995 22:54`	8
	You have an older version of the 90TL software. I strongly recommend that you have your customer upgrade the 90TL software. Note that the software for the later decservers is now referred to as Network Access Software. I've not found it on the CONDIST so try the LAT conference. Regs, Dan
600.10	Problem solved ?	ULYSSE::BAUDELLE		`Wed Mar 01 1995 08:50`	13
	Did that solve your problem ? I went through the same problem (TCP console port read error) I have done the same checks within UCX and the problem remain. (added small-buffer and device-socket) The decserver is DS 90 M V1.1 BL55-16 ROM 4.1 , do you think that upgrading the software will make it work ? Thank's Pierre