[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

3094.0. "Application hangs SPX server" by VINO::MCARLETON (Reality; what a concept!) Wed Jul 18 1990 17:06

    The DECwindows application that I maintain has major problems running
    on a VAXstation 3100 model 38/SPX.  I can't find any
    description here that seems to match my problem.  The system is
    running VMS 5.3.

    The application starts up ok but soon runs into trouble. After a few
    mouse clicks, the DECW$SERVER process goes into COM state and stays
    there for several minutes.  The server does not seem to respond during
    this time.  The server eventually comes back and completes any
    mouse-ahead actions that were pending while the server was looping.
    Any more interaction with the problem application will soon cause
    the server to loop again for several minutes.  The application works
    fine on any GPX hardware.  We tried the same application after stopping
    the window manager but we got the same results.

    The application also has problems with graphics operations using a
    clip mask. The clip mask is used in the GC for FillRectangle
    operations.  The FillRectangle is completed as if the GC did not
    include a clip mask.  Another GC uses a clip mask with a CopyArea
    operation.  This clip mask also seems to be ignored.

    The only other SPX related server hang I found here seemed to require
    exiting the session manager.  Will CSCPAT_0183 fix these problems
    or do I need to QAR them as new problems?
    
    						Thanks,
    							MJC
T.RTitleUserPersonal
Name
DateLines
3094.1Use V5.3-1 with SPXSTAR::ORGOVANVince OrgovanFri Jul 20 1990 18:375
    VMS DECwindows support of the SPX option started with VMS V5.3-1.
    If you are really running VMS V5.3, you've probably got a field
    test version of DECwindows SPX support and should consider upgrading
    to V5.3-1. None of the CSC patches are applicable the field test
    versions. 
3094.2Pb in 5.3-2 also with ico -dblEVTIS1::MALASPINAI know someone who knows !Mon Sep 10 1990 06:2518
    			Hi !
    
    	I have the same kind of problem but I AM RUNNING VMS 5.3-2.
    
    You can reproduce this using the decw$examples ico with double
    buffering.
    
    Issue the following command and you'll get the problem :
    
    $ MC DECW$EXAMPLES:ICO -dbl.
    
    The DECW$SERVER process then takes about 75 % CPU time and you then
    have trouble with the pointer which does no longer respond "smoothy"
    to a gentle move !
    
    Any Ideas. (VS3100 SPX with 24 MEGA's).
    
    			Thanks a lot !
3094.3Me too!H2SO4::GERSBACHEdwin Gersbach CS SwitzerlandWed Oct 31 1990 11:2225
I was just logged in on a customers cluster with 6 SPX's when he called me 
because one of the stations hung. I've seen the DECW$SERVER_0 process was in COM
state all the time. Using SHOW PROC/CONT I got the following values:

	PC	00132688 / 00132690
	PSL	03C00009
	SP	7FF8E948
	Event	60000001
		80000000

As I could never see any other PC than the two listed above, I guess it hung in
a very tight loop. It did not do any I/O and the peak virtual size was somewhere
between 14000 and 15000 (VIRTUALPAGECNT was at 150000).

The customer says that he encounters such a hang every other day on one of the
6 stations.

Can anyone get some information from these values? What does the server do or
wait for in this loop?

Thanks in advance
			Edwin

P.S.
VMS is V5.3-1
3094.4Cliplist messages in the log?VINO::MCARLETONReality; what a concept!Wed Oct 31 1990 11:478
    Look in the SYS$MANAGER:DECW$SERVER_0_ERROR.LOG file to see if there
    are any lines that have the message "Cliplist did not get into
    Offscreen".  If you do then you have the problem reported in QAR
    1650 in the V54-FT database on TRIFID::.  You might also want to look
    at note 3224.* in this file.

    					MJC
3094.5No error in logfileH2SO4::GERSBACHEdwin Gersbach CS SwitzerlandThu Nov 08 1990 07:567
Sorry, I forgot to mention that I already checked the logfiles. Actualy it was
one of the first things I did, but there was nothing in it but the usual
CONNECTION ACCEPTED/CLOSED messages.

Shall I enter another QAR?

Edwin
3094.6More information neededSTAR::VATNEPeter Vatne, VMS DevelopmentThu Nov 08 1990 17:464
We can't decode the PC without the contents of the server error log.

Go ahead and enter a QAR.  However, if this is holding up a customer,
you should really escalate this...