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

Conference wrksys::mikasa

Title:AlphaServer 1000 (aka Mikasa)
Moderator:WRKSYS::HESCHG
Created:Mon Nov 14 1994
Last Modified:Thu Jun 05 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:917
Total number of notes:3293

840.0. "Problem with 4/266 and console port locking up" by JALOPY::CUTLER () Thu Feb 13 1997 09:59

I've got a customer who recently purchased 24 4/266's. Before the purchase we
had provided them with a evaluation system that was an earlier version of the
Mikasa (4/200). Well bottom line is that now, since they've received the 4/266's
and have started deploying them in a production environment (these are engine
test cells), the console port is locking up whenever their operators hold down 
the arrow or backspace keys (rapid sucession of repeating a particular key). 

This problem does not happen on the older machine (4/200) and did not happen on
the MVAX II's that are being replaced. I went out there yesterday with a
protocol analyzer and saw the following.

  - Saw the operator keystrokes and corresponding application responses that was
   running on the ALPHA.

  - Kept seeing keystrokes from terminal and more responses from ALPHA
application, then all of a sudden saw only ALPHA responses coming across, 
when they appeared to be completed, then got a blast of keystrokes from the
operator console, then there is no response from the application. I then
did a $SHOW PROCESS/CONT/ID=PID to look at the application, it said that it
was in a LEF state. I was hoping to see it in some type of RW state but it 
appeared normal. 


   Here is the configuration:

	OPERATOR CONSOLE IS AN HP TERMINAL EMULATOR WINDOW CONNECTED TO THE 
	MIKASA CONSOLE PORT. BAUD RATE IS 9600. I might note that nothing has
	been changed with these. This the same console connection that has been
	in use for the last 5-6 years.


	SYSTEM(s) that exhibits the problem

	     OPENVMS 6.2-1H2
	     PAL 5.56-4
	     SRM V4.6-218

	SYSTEM that does not exhibit the problem

	     OPENVMS 6.2-1H2
	     PAL V5.53-5
	     SRM V3.1-2


	Application uses FMS for screen interface. One comment is that they 
	did share with me, is that sometimes it appears that "EVENTUALLY" the
	application does appear to come back to life (ie. after about 10-15     
        minutes the console appears to unlock itself)?

	


Any ideas as to what is going on or what I should look at next?

Rick C.
Ford Sales Support
Detroit, Michigan


T.RTitleUserPersonal
Name
DateLines
840.1Well still no progress at DynoJALOPY::CUTLERFri Feb 14 1997 16:0213
Well I called the CSC, the person on the other end and I agreed that it was 
a flow control problem between the two systems. He suggested that I lower the 
baud rate down on the console to 4800 or 2400 baud. I tried, but it kept locking
up on me. I couldn't even log in as a VMS user. I'm so frustrated right now,
does anyone know what is going on? What am I doing wrong, any suggestions. By
monday I'm going to need an engineer on line with me, while I'm at the customer
site. But, I'm hoping that it's not going to have to go that far, if someone can
give me some other suggestions of what to try? The customer has now delayed
installing the remaining 15 systems because of this issue, any suggestions/help
would be greatly appreciated.

Rick C.

840.2XON/XOFF to high valueUTOPIE::OETTLhide bug until worst timeFri Feb 14 1997 18:135
You could try to increase the XON/XOFF threshold on the terminal.

This did help me at a site where I installed a Sable and had similar problems.

�tzi
840.3What parameter is that?JALOPY::CUTLERSat Feb 15 1997 05:496
Otzi,

    Are you talking about the (I think this is the name), ALTALARM Sysgen
parameter? 

Rick
840.4UTOPIE::OETTLhide bug until worst timeMon Feb 17 1997 15:209
Hi,

no, I meant the communication setup of the terminal(emulation).

On the VT-series terminals you can change flow control settings in the
communications menu.


�tzi
840.5Not using VT Terminals... Problem fixedJALOPY::CUTLERSun Feb 23 1997 06:4816
Otzi,

   They're not using VT terminals so that was not an option. We finally got the
systems to stop locking up. I ended up having to "downgrade" the firmware to the
version that was on the system that was not locking up (see my original note for
what version that is). I think (not sure) that there was a problem between the
version of the OS they were using (Openvms 6.2-1h2) and the firmware. Systems
orginally shipped to the customer with OpenVMS 6.2-1h3, but the customers
applications had been ported on 6.2-1h2 and for some reason, the customer just
wanted to "duplicate" that disk and distribute on all systems (they're legal,
they purchased all licenses). So, maybe if they had stuck with 6.2-1h3, there
may have been no issues with the console. But, bottom line is we're all set. I
doubt if they will ever upgrade the OS (and therefore may have the need to
upgrade firmware), as these are the type of systems, they put in and let run.

Rick