Conference bulova::decw_jan-89_to_nov-90

    
    A reply to obviate the need for the question:
    
    Installing this should not in any way effect the ability for you to
    run "native" DECwindows.  You might want to keep seperate DWS and
    VWS.PAR files, or make everything big enough for both and simply
    change the WINDOW_SYSTEM at boot (you will also need to define/sys
    DECW$IGNORE_AUTOGEN - since for unfathomable reasons DECW$CHECK_PARAMS
    Insists that a couple of parameters be EXACT and these are too small
    for UIS).  An interactive boot, seperate .PAR files and the command
    to SYSBOOT of USE DWS.PAR is what I do to get DECwindows up native.
    
    The ONLY file altered by this kit is DECW$DEVICE.COM which has logic
    added to it to try to start the VMFB server if the window system
    is 2.
    
    _Fred

    
                 <<< BULOVA::DOCD$:[NOTES$LIBRARY]VWS.NOTE;3 >>>
                          -< MicroVAX Workstations  >-
================================================================================
Note 3248.9                    Virtual DECwindows                        9 of 13
STAR::KLEINSORGE "shockwave rider"                  104 lines  31-JAN-1989 16:36
--------------------------------------------------------------------------------
    
    Some pre-emptive replies:
    
    1) Performance
    
    One of the non-goals for the VWS server at present is that it be a
    production environment.  A common view is that anything that
    reduces the urgency to move to DECwindows is not in the companys
    best interest.  And indeed, the target machine is the pVAX.  The
    goal is to provide a DECwindows environment that can serve as a
    temporary development platform for customers who require UIS until
    DECwindows is viable (for instance, until their ECAD application is
    available).
    
    This server represents 98% DECwindows code and a 2% hack that was
    produced in less than 3 weeks by a single individual, and as such
    represents only proof that the idea of a development DECwindows
    environment on UIS is feasible.
    
    2) Color
    
    Not quite ready to tackle this yet.  We first need to finish up
    on some committments that were made to DECwindows regarding the
    migration effort.
    
    3) Detail
    
    This is mostly 'cause I like to ramble on about the details of how
    something was done and how it works...  You can skip it unless you
    want to know the ugly details.
    
    Ok.  DECwindows is based on the X11R2 Server(s) from MIT, but it has
    been optimized and extended.  MIT provides several sample servers,
    and the MI (Machine Independent) server is what is intended that
    developers use as the starting point for developing their own
    device specific server.  Ultimately a MI server develops into
    very specific servers like the MFB (Monochrome Frame Buffer) used
    for QVSS-style hardware.  DEC has even gone beyond this to a AM
    (Abstract Machine) model which is a MI equivalent for hardware
    with sophisticated graphics co-processors.
    
    The problem is that from a cold start and without help from those
    who are very familiar with the existing code, writing a MI or AM
    server isn't a picnic.  You need to first understand how *any* server
    works.  Unable to find a template MI or AM server to use as the
    starting point, and unwilling to dig into the bowels of a very
    complex server like the GPX server - I decided to instead take a
    very big hammer and get something as quickly as I could with as
    little effort as possible - getting something that worked and
    that let me understand how servers work.  The idea occured to me that
    I should play with the Monochrome Frame Buffer code.
    
    The first order was to decouple the server from the hardware.  This
    is a trick because DECwindows Servers need a hardware device.  So
    I created a device driver that looks like a cross between a VS2000
    and VSII driver and does nothing except provide timer services and
    an input queue -- but no input, and all other functions are noops.
    Then to decouple the Server from the frame buffer -- easy enough,
    just a small change in the server initialization and the frame
    buffer code uses VAX memory just like it uses Video memory.
    
    Now I have a server that loads and draws to a memory bitmap but
    nothing else...  Some code to create a UIS window and (on a timer)
    copy the bitmap to the window -- now we have output, but it is a real
    CPU eater.
    
    The next step requires that you understand that everything in X
    is indirect.  And the way drawing actually occurs is CALLS though
    vectors in a graphic context structure (plus some annoying routines
    for window operations that have no GC and who's vectors are somewhere
    else).  By replacing the vectors with vectors to my own routines
    and saving the original vectors in a private server GC structure -
    the drawing calls can now be filtered.  The filter routines do
    the actual routine call, build a clipping rectangle and bump a
    batch counter.  When the batch counter goes to zero, the extents
    changed can be clipped and a UISDC$IMAGE done to update the screen.
    Oh, the final worry - pending updates when the server is finished
    processing can be flushed by providing a routine vector to be called
    before the server hibernates (formerly "Fluff Pillow", love the name).
    
    Now we're cooking.  Slow but useable on a GPX and pVAX.  But no
    input.
    
    Input is a crock.  DECwindows expects that a port driver will supply
    packets into a input queue provided by the common input server.  But
    the UIS driver hasn't been taught this trick (yet) - so... instead
    the server gets normal UIS input AST's and inserts input packets
    into the queue and wakes up the user-mode server.  And since the server
    expects LK201 keycodes, and UIS only supplies SMG-style codes, the input
    code reverse decodes input into LK201 data, including doing key
    down and up as well as lock, shift and control simulation.  I didn't
    bother to try and back-translate 8-bit codes, since this is a temporary
    hack.
    
    Bingo, a simple DECwindows server that is *exactly* what the "real"
    monochrome server would output.  Just slower.
    
    This is just a 3-week hack.  But I was impressed enough in it's
    performance that I figured I'd see how much faster it needs to
    be for useability.  The next step is a true MI server and then
    incrementally replacing MI code with UIS drawing primitives to
    produce a server that is machine independent but UIS specific.
    
    

Fred,\
	Did you look into modifying or adding a new driver that could switch
between UIS and DECWindows on the fly. That is suspend one windowing system
and switch the hardware interrupts to the other windowing systems drivers and
resume the new windowing system. You would also have to save the state of all
of video memory and template ram and dac but it seems plausible.
						Bill

    It's "on the list" to be looked at.
    
    Problem is, that nobody on this side of the wall knows enough about
    both drivers to take a stab at it.  The person who has been doing the
    UIS drivers is leaving the group in a couple months - and so we will
    be back to square one just on our side.  I certainly have avoided
    knowing the internals of our video drivers.
    
    Now that V1 of DECwindows has shipped, if one of you guys upstairs who
    *do* know a little about both want to make a stab at it... we will
    certainly take the result of the effort.= and give you whatever help
    we can.
    
    I'm not convinced at this point that something can be done that will
    work 90% of the time.  And so I am unsure about how supportable it
    would be.  To get something that worked all the time might require
    changes to both sets of drivers to allow them to be stopped and
    restarted.
    
    _Fred

                     <<< BULOVA::DOCD$:[NOTES$LIBRARY]VWS.NOTE;3 >>>
                          -< MicroVAX Workstations  >-
================================================================================
Note 3248.14                   Virtual DECwindows                       14 of 14
STAR::KLEINSORGE "Toys 'R' Us"                       13 lines   2-FEB-1989 16:40
                                  -< Update >-
--------------------------------------------------------------------------------
    A new saveset has been put into the directory.  Some "fixes"...
    
    1)	The errors on GVA1: have been fixed.
    
    2)	I accidentally provided a server image that had debugging
    	statements embedded in it and every X11 drawing operation
    	caused at least one line to be written to a error log file
    	(if you want to see something interesting look in the server
    	error log file in sys$manager)... makes things *really* slow
    	as opposed to just slow.
    
    
    

    
    Thanks.  The kit is also available on VWSENG::VWS$KITS:[VWS_TOOLS]
    for those who have trouble getting to VMSKIT::
    
    _Fred

    
    A new version with a couple of fixes is now available on:
    
    	VWSENG::VWS$KITS:[VWS_TOOLS]DECWVMFB000.A;2
    
    This version fixes a AST/User Mode synchronization problem with
    shrinking the DECwindows environment to an icon.
    
    It also will allow use of the COMPOSE key on VWS V4.1 systems (i.e.
    COMPOSE-SPACE now works).
    

    After testing DECWVMFB these last few days, I've found a little
    problem.  The problem is based on the following VS2000 setup:
    
    1. SDC VMS5.1 upgrade
    2. VWS 4.0 windowing - saved to VWS.PAR after system startup
    3. Loaded *full* DECwindows - SDC released
    4. Booted DECwindows - saved to DECW.PAR after system startup. 
    5. Installed RAGS
    6. Installed UTOX
    7. Installed DECwindows Virtual frame buffer
    8. Gen'd the system from VWS.PAR at SYSBOOT>
    9. Invoked RAGS SYS$SYSTEM:GECLOCK.RAGS from SYSTEM account
    10. Received the following errors and returned to DCL:
        XIO: non-translatable vms error code: 0x2DBA002
    
        %decw-e-cnxabort, connection abort
        %xlib-f-ioerror, xlib ioerror
        %trace-f-traceback, symbolic stack dump
            .
            .
            .
    
    Seems unusual!  
    

    
    Look in SYS$MANAGER:DECW$CHECK_PARAMS.COM
    
    Because I have not updated this file to add the dummy device driver
    (GV) it is ignored (and since autogen doesn't understand anyway,
    I just punted).  Look at the MINIMUM values that it needs and make
    sure that you have at least that much.  Leave the ones that want
    a SPECIFIC value alone (they're bogus as far as I'm concerned).
    
    Reboot with that setup and see what happens.  I run this on my V5.1
    VS2000 all the time (it's a tad *slow* but other than that and page
    file fragmentation...).
    
    )Fred

    Fred,
    
    I checked the MINIMUM values in SYS$MANAGER:DECW$CHECK_PARAMS.COM
    and the values looked fine.  I'm still encountering the errors listed
    .9 of this note. 
    
    I did notice that when invoking rags and passing a file to display
    such as GECLOCK.RAGS from a user account, failure to display is
    random.  Most of the same XIO, %decw-e-cnxabort, %xlib-f-ioerror,
    and % trace-f-traceback errors occur.  But sometimes RAGS *will*
    bring the file to display when in the VFB.  One time the system dumped
    and emptied its memory contents to SYSDUMP.DMP, which I still have.
    I understand this program is provided to run "at your own risk",
    I'm just trying to give some feedback relating to testing I'm doing
    with VFB and its potential use in our group.  
    
    Are there specific log files I should by looking at or executables
    I should monitor?  
    
    Are there any serious plans to eventually make this a product?
    
    Jim
    
      

    
    I have to figure that it's some resource problem.  Maybe one of
    the DECwindows develpopers can hazard a guess?  Also make sure that
    you are using the version that isn't logging itself to death (should
    be something like -002 or -003) which is on
    
    		VWSENG::VWS$KITS:[VWS_TOOLS]
    
    The server is such a hack that it only has a very small amount of
    code in addition to the normal monochrome code.  And all of the
    code has to do with writing the bits on the screen or getting the
    input from the KB or mouse into the input queue.
    
    In answer to the other question:  Yes.  pVAX product management
    has asked us to look into providing compatability via an X-Server
    for the short-term.  Think of this as a prototype that proves the
    feasibility of doing it.  This prototype took all of 2-3 weeks of
    work to produce 99% of what you see.  In addition to X servers, we
    are also actively looking at a UIS implementation for X11.
    
    I will install RAGS next week and see if I can reproduce the problem.
    
    _Fred

    .12
    
    After looking around, this looks like the common error that happens
    when the client and server aren't working fast enough together.
    This might well be because of the overhead of UIS.  Check this file
    for some parameters regarding the retry interval and count...

    And again, make sure it's X1.0-002 or -003.  The first kit I put
    out had debugging statements in it and it kept the log file pretty
    busy.
    
        
    _Fred

    What file should I check for retry interval and count parameters?
    What should the parameter values be?
    
    I checked the log file each time there's a symbolic stack dump,
    but nothings in it.  I'm running a VS2000 with the 12 meg memory
    board.  Also, I'm running the DECWVMFB000.A;2 savest version saveset 
    spooled from VMSKIT::SYS$KITS:[VWS_TOOLS].
    
    Are there readable server/client files that can be modified to 
    enhance interactivity?
    

    
    define DECW$SERVER_RETRY_WRITE_MIN 150000/TABLE=DECW$SERVER0_TABLE
    define DECW$SERVER_RETRY_WRITE_MAX 3000000/TABLE=DECW$SERVER0_TABLE
    
    Don't recall offhand what the interval this is in.  It's listed
    in some other note in this conference.  In fact I stole the above
    example from anote that was just put in.
    
        

    The DECwindows error log listed came from DECW$SERVER_0_ERROR.LOG
    while trying to run RAGS from VMFB.  While in the VMFB, I invoked:

        $ RAGS SYS$EXAMPLES:GECLOCK.RAGS  
    
    after defining DECW$SERVER_RETRY_WRITE_MIN 150000 and 
    DECW$SERVER_RETRY_WRITE_WRITE_MAX 3000000 in the server
    table DECW$SERVER0_TABLE. The result was still an XIO non-translatable
    VMS error code 0X2DBA002, followed by connection abort, xlib IO
    error and a symbloic stack dump.  And of course this error log.
    
    -------------------------------------------------------------------
    
Hello, this is the X server
Dixmain address=22dfa
Now attach all known txport images
in SetFontPath
out SetFontPath
VIRTUAL Monochrome Frame Buffer support loaded
vmfb$InitOutput address = 176e00
Virtual Frame Buffer Address = 19d818
Height = 640, Width = 960, Size in bytes = 76800
VWS: Init VWS
VWS: Get Defaults
VWS: x pos 0.000000
VWS: y pos 16928.000000
VWS: place 0
VWS: icon number = 0
VWS: C-S-REMOVE enabled
VWS: grab the kb at startup
VWS: enable shrink
VWS: enable delete
VWS: flags = 166
VWS: max_batch = 8
VWS: Create Window
VWS: Create Display
VWS: Setup Colormap
VWS: Screen Width = 960, Screen Height = 640
VWS: Actual Width = 967, Actual Height = 640
VWS: x1 = 0, y1 = 0, x2 = 959, y2 = 639
VWS: Init KB AST's 
VWS: Init Mouse AST's
Connection Prefix: len == 36
Now I call scheduler/dispatcher
Connection aa4e0 is closed by Txport
Connection aa4e0 is closed by Txport
Connection ac4a8 is closed by Txport
Request opcode 2 is ignored due to internal runtime error 14 for client 5(#error = 1)
Exception Call stack dump follows: 
	a351b
	18c6a1
	177283
	2335d
	233c5
	241c2
	2b4ba
	2f35b
	1e1d2
	2195d
	214b9
	230b4
	418
	8018d8b7
	8018d866
********** marking the end of call stack dump **********
********************************************************
Client 5 has made too many runtime errors(2), its connection is marked for termination
Exception Call stack dump follows: 
	a351b
	18c6a1
	177283
	2335d
	233c5
	241c2
	2b4ba
	2f35b
	1e1d2
	2195d
	214b9
	230b4
	418
	8018d8b7
	8018d866
********** marking the end of call stack dump **********
********************************************************
..ddx layer returns bad status(17)
..Dispatcher close down connection 5
Connection ac4a8 is closed by Txport
Connection ac470 is closed by Txport
Connection ac470 is closed by Txport
ScreenClose: Shutting down VWS
VWS: Close Screen
VWS: Stop Mouse
VWS: Stop KB
VIRTUAL Monochrome Frame Buffer support loaded
vmfb$InitOutput address = 176e00
Virtual Frame Buffer Address = 19d818
Height = 640, Width = 960, Size in bytes = 76800
VWS: Init VWS
VWS: Get Defaults
VWS: x pos 0.000000
VWS: y pos 16928.000000
VWS: place 0
VWS: icon number = 0
VWS: C-S-REMOVE enabled
VWS: grab the kb at startup
VWS: enable shrink
VWS: enable delete
VWS: flags = 166
VWS: max_batch = 8
VWS: Create Window
VWS: Create Display
VWS: Setup Colormap
VWS: Screen Width = 960, Screen Height = 640
VWS: Actual Width = 967, Actual Height = 640
VWS: x1 = 0, y1 = 0, x2 = 959, y2 = 639
VWS: Init KB AST's 
VWS: Init Mouse AST's
Now I call scheduler/dispatcher
VWS: Shrink AST
VWS: Shrink Icon
VWS: Delete Display
VWS: Setup Colormap
VWS: Move Icon AST
VWS: Move Icon AST
VWS: Expand Icon AST
VWS: Create Window
VWS: Create Display
VWS: Setup Colormap
VWS: Screen Width = 960, Screen Height = 640
VWS: Actual Width = 967, Actual Height = 640
VWS: x1 = 0, y1 = 0, x2 = 959, y2 = 639
VWS: Init KB AST's 
VWS: Init Mouse AST's
VWS: Window Movement AST
Connection aa4e0 is closed by Txport
Connection aa4e0 is closed by Txport
Connection ad708 is closed by Txport
Request opcode 2 is ignored due to internal runtime error 14 for client 5(#error = 1)
Exception Call stack dump follows: 
	a351b
	18c6a1
	177283
	2335d
	233c5
	241c2
	2b4ba
	2f35b
	1e1d2
	2195d
	214b9
	230b4
	418
	8018d8b7
	8018d866
********** marking the end of call stack dump **********
********************************************************
Client 5 has made too many runtime errors(2), its connection is marked for termination
Exception Call stack dump follows: 
	a351b
	18c6a1
	177283
	2335d
	233c5
	241c2
	2b4ba
	2f35b
	1e1d2
	2195d
	214b9
	230b4
	418
	8018d8b7
	8018d866
********** marking the end of call stack dump **********
********************************************************
..ddx layer returns bad status(17)
..Dispatcher close down connection 5
Request opcode 2 is ignored due to internal runtime error 14 for client 5(#error = 1)
Exception Call stack dump follows: 
	a351b
	18c6a1
	177283
	2335d
	233c5
	241c2
	2b4ba
	2f35b
	1e1d2
	2195d
	214b9
	230b4
	418
	8018d8b7
	8018d866
********** marking the end of call stack dump **********
********************************************************
Client 5 has made too many runtime errors(2), its connection is marked for termination
Exception Call stack dump follows: 
	a351b
	18c6a1
	177283
	2335d
	233c5
	241c2
	2b4ba
	2f35b
	1e1d2
	2195d
	214b9
	230b4
	418
	8018d8b7
	8018d866
********** marking the end of call stack dump **********
********************************************************
..ddx layer returns bad status(17)
..Dispatcher close down connection 5
VWS: Shrink AST
VWS: Shrink Icon
VWS: Delete Display
VWS: Setup Colormap
VWS: Expand Icon AST
VWS: Create Window
VWS: Create Display
VWS: Setup Colormap
VWS: Screen Width = 960, Screen Height = 640
VWS: Actual Width = 967, Actual Height = 640
VWS: x1 = 0, y1 = 0, x2 = 959, y2 = 639
VWS: Init KB AST's 
VWS: Init Mouse AST's
Request opcode 2 is ignored due to internal runtime error 14 for client 5(#error = 1)
Exception Call stack dump follows: 
	a351b
	18c6a1
	177283
	2335d
	233c5
	241c2
	2b4ba
	2f35b
	1e1d2
	2195d
	214b9
	230b4
	418
	8018d8b7
	8018d866
********** marking the end of call stack dump **********
********************************************************

Unrecoverable server internal error found, terminating all connections.
Exception Call stack dump follows: 
	a351b
	18c6a1
	177283
	2335d
	233c5
	236ee
	249f5
	3d189
	214c8
	230b4
********** marking the end of call stack dump **********
********************************************************
** SERVER INTERNAL RUN TIME ERROR EXCEEDED, SERVER HAS JUST CRASHED!! **
************************************************************************
ScreenClose: Shutting down VWS
VWS: Close Screen
VWS: Stop Mouse
VWS: Stop KB

Fatal server bug!
Server runtime error limit exceeded - type @SYS$MANAGER:DECW$STARTUP server to restart, or see your 

    
    A little checking shows that this was from the primary exception
    handler in the DIX layer.  The client was changing window attributes
    and got an ACCVIO (error 14 looks to me like an ACCVIO).  It exceeded
    the maximum number of errors possible (it normally skips the operation
    on an error -- and opcode 2 uses CH_SkipCurrent) and so it killed
    you when it's error count went > 2.
    
    I'll have to look a little closer to see where the accvio was from
    the exception stack.
    
    
    _Fred

    
    Hmmm.  Excuse the lapse of memory, but where is RAGS located?  I
    can't find a keyword here or in the toolshed nor is a notesfile
    listed in easynotes.lis for it.
    
    _Fred

	FLAME ON

	DECW type conferences not being announced in TURRIS::EASYNET_CONFERENCES
	is a pet peave of mine. Why can't some more of these conferences be
	announced so that people can find them? Are people really against
	people using these conferences?

				Alfred

The conference VAXUUM::DOC_GRAPHICS has all that info.

KP-7 to add conference.

	$ t $

    
    Thanks, am reproducing it at will now with RAGS.  I should have
    a handle on the problem soon (I think I decoded what the heck the
    "stack" is that get dumped and have it tracked down).
    
    _Fred

    Thanks for looking into it Fred!  This problem has be kinda inhibiting
    in terms of progression via VMFB...  I appreciate your help!
    
    Jim

    
    A new version of the Virtual DECwindows server is available from:
    
    
    		VWSENG::VWS$KITS:[VWS_TOOLS]VWSDECW000.A
    
    		      (note the new saveset name)
    
    Changes:

    	o New saveset name using VWS as the prefix rather than DECW.
        
    	o Fixed the problem that RAGS was encountering (a bug in the
    	  pointer pattern (hotspot) translation to VWS format).
    
    	o Minor code changes to clean things up.
    
    	o Version is now X1.0-004
    
    	o New KITINSTAL
    
    		- Explict test for an EXACT match V5.1 to avoid
    		  any potential conflicts with changes in V5.2.
    
    		- Autogen is invoked to bump up minimums for DECwindows
    
    		- Optional Reboot
    
    		- Cluster installation
    
    	o VWS Window Title logical name is now shown in the .TEMPLATE file.
    
    	o Device startup now checks to insure that VWS has finished
    	  initialization before starting up the server (temporary).
        

    re:
    
    >A new version of the Virtual DECwindows server is available from:
    >
    >
    >		VWSENG::VWS$KITS:[VWS_TOOLS]VWSDECW000.A
    
    ---------
    it seems to be missing from the directory. Has this been moved? Can
    I steal a copy from someone?
    
    thanks.
    
    jack
    
    
    

    Ah, sorry.  It is now distributed with the VWS kits, look in
    
    		VWSENG::VWS$KITS:[VWS042]VWSDECW010.A, .B, .C
    
    Note that there are now 3 savesets (very small) and it will now run
    on both V5.1 and V5.2 of VMS.
    
    	THIS PRODUCT DOES NOT WORK WITH DECWINDOWS V2.0 -- DON'T EVEN
    	TRY IT.
    
    _Fred

    Fred, I have six of the kodak workstations, and I want to bring
    up these windows. I am running VMS V5.2 and DECWINDOWS V*(not sure).
    so which products do I want to install?
    
    just to go a little deeper I have 2 630q5's (microvax II's) that
    are serving 3 GPX's,and  6 Kodak Workstations.
    
    thanks
    Paul

    You want to:
    
    	A) Make sure you have DECwindows V1.0 (*NOT* a V2 Server)
    
    	B) Install the VWSDECW010.A, .B, .C saveset from
    	   VWSENG::VWS$KITS:[VWS042]
    
    	C) It would also be a good idea to install VWS042 - otherwise
    	   DECwindows won't start up until VWS$DECW_STARTUP (or something
    	   like that) is defined.
    
    	D) Start DECwindows after rebooting.
    
    	E) Do AUTOGEN with FEEDBACK on a regular basis.
    
    The SDC kit had the VK device added to the DECW$STARTUP command file,
    the earlier ones inadertantly did not.  You can edit this in by hand
    if you have a earlier kit.  Just look for the other references to VA
    and VC.
    
    _Fred

    I found out that I have v2 running so I guess I'll have to use VWS4.1 
    
    thanks
    
    Paul

    
    Sorry, I'll get around to looking at V2.0 as soon as I can.
    
    _Fred
    

Fred, how can we sue you? - we fired all the lawyers!

	I can't get Virtual Decwindows to run anymore... it was running
several months ago, but those of us who were using it converted to native
decwindows.  Now I have a new batch of users that want to run virtual
decwindows (VD?), but it doesn't come up.

	We are now running VMS V5.2, VWS V4.2 and VD V1.0, we are running
the version of decwindows that came with VMS V5.2.  VD was installed
after VWS, which was installed after VMS.  The problem is happening
on microvax 2's with either VCB01s or VCB02s.

	We are not automatically starting decwindows on the VWS nodes
in the cluster (we are defining DECW$IGNORE_DECWINDOWS TRUE in
SYSTARTUP_V5)

	When I invoke DECW$STARTUP manually after the system has completed
system startup, things appear to be starting normally, but the VD window
never appears.  The DECW$SERVER_0 process show us, along with a WSAn
process.  Eventually both processes disappear, and the system enters
a cycle of alternating processes, one unnamed, the other named WSAn,
which are running LOGINOUT.EXE - neither process runs very long
(probably because the server isn't there to create the login window?),
and the cycle continues, until one of the processes is manually
stopped.

	Only two log files are getting created in SYS$MANAGER;
DECW$SERVER_0_OUTPUT.LOG (which is empty) and DECW$SERVER_0_ERROR.LOG 
which contains:

Hello, this is the X server
Dixmain address=253fa
Now attach all known txport images
in SetFontPath
out SetFontPath

	Any help would be appreciated.

		Joe

    This is wierd.  I haven't had a lot of time to look into it, but
    I guess I'd better make the time.
    
    _Fred (will be looking into it)
    

>        When I invoke DECW$STARTUP manually after the system has completed
>system startup, things appear to be starting normally, but the VD window
>never appears.  The DECW$SERVER_0 process show us, along with a WSAn
>process.  Eventually both processes disappear, and the system enters
>a cycle of alternating processes, one unnamed, the other named WSAn,
>which are running LOGINOUT.EXE - neither process runs very long
>(probably because the server isn't there to create the login window?),
>and the cycle continues, until one of the processes is manually
>stopped.

	I have similar problems except that DECW$STARTUP will not start
	from SYSTARTUP_V5.COM after installing VWS 4.1. It will start
	up manually, however, but it will cycle through unnamed, WSAn
	stuff until you do so...

	I get the following in DECW$SERVER_0_ERROR.LOG in SYS$MANGER:

Hello, this is the X server
Dixmain address=22dfa
Now attach all known txport images
in SetFontPath
out SetFontPath
VWS/DECwindows
VWS: VMFB loaded
vmfb$InitOutput address = 106e00
Virtual Frame Buffer Address = 11ca18
Height = 864, Width = 1024, Size in bytes = 110592
VWS: Enter vmfb$InitVWS
UIS is not installed, exiting the server
	
	VWS 4.1 is installed via SYSMAN as per the documentation. Should
	I do something different about starting VD?

	Rick
	Rick