Conference bulova::decw_jan-89_to_nov-90

Exactly what version of VMS and DECwindows are we talking about here?

    
    The version of vms is 5.3 so I think that the version of decw is 2.0 .

Re: .2

No, that's still DECwindows "V1"

		Steve

RE: .3

	You sure about that Steve? 

							mike

    VMS V5.3 is DECwindows V2.0.  That's why my product can't use any VMS
    but 5.3 or above.
    
    Irene

No, I suppose not.....  Sigh.

	Steve

Well, if the customer is running VMS V5.3, then he should not have to
put the start up of DECwindows in SYSTARTUP_V5.COM (or anything it calls).

Check to see if the SYSGEN parameter WINDOW_STYLE is equal to 1.

    Now that you are all sure of the decw version with vms 5.3, does anyone
    have some other ideas ?
    
    RE 7: I think you ment WINDOW_SYSTEM, that is equal to 1.
    
    Thanks,
    Gea.
    

Oops, yes, of course I meant WINDOW_SYSTEM.  Thanks.

Well, now we know the customer is running VMS V5.3, and that
WINDOW_SYSTEM is equal to 1.  The next step is figuring out how
far DECwindows is getting before things hang up.

Have the customer remove the startup of DECwindows from the
command procedure called by SYSTARTUP_V5.COM.  This definitely
shouldn't be there.  Next, delete all the old SYS$MANAGER:
DECW$SERVER_0_ERROR.LOG files.  Reboot the system.  Now,
does the DECW$SERVER_0 process get started?  If so, please
post the entire contents of DECW$SERVER_0_ERROR.LOG.

If the server gets started, but you don't get the Start Session
dialog box, then a common problem is too low a value for the
SYSGEN parameters GBLSECTIONS and GBLPAGES.  These resources
are easy to consume if you have lots of layered products.
Let us know what the values are, and how many are in use.

    I tried what you suggested here is the response:
    
    1) The startup of the decw was removed from the systartup_v5.com
    2) the process decw$server_0 is not created
    3) The file DECW$SERVER_0_ERROE.LOG wasn't created
    4) In sysgen the parameters are :
    		GBLPAGES 30.000
    		GBLSECTION 400
    5) I chacked in install :
    		gblsection used 217
    		gblpages used 16620/13380
    
    6) The 3100 is in a cluster ad has vax sim installed
    
    Is this usefull, I hope so
    Thanks,
    Gea.

Well, this is certainly an interesting puzzler.  Since the server
process is not getting started at all, I can understand why you're
not getting anything on the screen!

I've not seen this problem before.  Maybe others have, and can suggest
specific things to try.  In the meanwhile, I can suggest two approaches:
the step-by-step debugging technique, or the big hammer technique.

The big hammer technique is based on the theory that something in the
customer's installation is wrong, but we don't bother to find out what.
We just scratch it, and start all over.  This means running DECW$TAILOR
to first remove DECwindows from the system, and then running it again
to add DECWindows back to the system.  If there was a corrupted or
missing file, this should fix the problem.

The step-by-step technique is to do things like add REPLY commands to
the DECW$STARTUP.COM and DECW$STARTSERVER.COM files to see exactly
how far DECwindows startup gets before going haywire.  I would suggest
at the minimum putting statements at the front of each of those two
files, and one before and after the RUN/DETACHED command of the
server image itself.

    I have some news the customer with "I don't get anything on the video"
    ment that the decw doesn't start and the video acts like a common
    vt200.
    
    It seams that the window_system i equal to 0.
    I check for the tenth time, but window_system is equal to 1.
    
    Any more idea ?
    Thanks,
    Gea.

Ok, so you have checked that WINDOW_SYSTEM is one.  Did you do the stuff Peter
suggested in .-2?  If you get something, you can hopefully narrow down the cause
of the failure.  If you get nothing, see if the logical name
DECW$IGNORE_DECWINDOWS is defined.  It should not be.  If it is, search through
the command files in SYS$MANAGER and see if any of your customer's startup files
define it for some reason.

Another thing to check is to see whether the device drivers have been loaded.
What kind of system is this?  A monochrome or color, and if color and SPX?
In any case, the following devices should exist and be on line depending on the
hardware:

Color non-SPX	  GAA0
Monochrome only:  GCA0
Color /SPX	  GEA0

If none of these are here, it is a real indication that WINDOW_SYSTEM is wrong.

Another thing you can do is run DECW$STARTUP by hand from the system account
and watch what happens.  Turn verify on, although that will give you a lot
of stuff on the screen.

Burns

You mention that the customer can use the screen as a normal terminal.
This could mean that the user is using the operator console window to
login to the system, which is an unusual thing to do.  This is normally
only done when the SYSGEN parameter SYSTARTUP_P1 is set to "MIN".  In that
case, you would not only not get DECwindows, you wouldn't get all the
other VMS stuff such as DECnet and batch queues, etc.

Even if SYSTARTUP_P1 is equal to " ", there is still a race condition
during startup, where the customer can hit carriage return and get
a LOGIN: prompt in the console window.  This happens because the
DECwindows server process has not yet got the screen device assigned.
If the customer then logs in, that process gets the screen, and the
server can never start.  The solution is to log out of the process
on the console, and let the server get the screen.

You have to be a little patient for the server to startup, but if
nothing happens after a couple of minutes, then you can assume the
server isn't going to start.  In that case, try what I said in .11.

    I checked the device GCA0: is present, but is off line
    
    Gea.