Conference bulova::decw_jan-89_to_nov-90

I suspect you may have to do

	set displ/create/perm/transport=local/server=1
			(Or /node=clu/transport=decnet)
rather than

	define decw$display clu::1

The latter will work for most applciations, but DECW$STARTLOGIN passes
a mailbox message to the job controller, which is expecting to see a
device name in it, not a weird logical.  Try it anyway.  I'm not the
expert in this area.

Burns

$ ! This is the command procedure that I use to start DECWINDOWS on my
$ ! system. It starts the primary server on the QDSS devices then starts
$ ! the second server on the QVSS. I normally don't want to start the 
$ ! session manager on the second seat directly from my workstation. Normally
$ ! I run DECW$STARTLOGIN from the cluster to get the second head's session
$ ! manager. However, if you login to SYSTEM (from the console terminal) and
$ ! do the following:
$ !
$ !  CREATE/DISPLAY DECW$DISPLAY/TRANSPORT=LOCAL/NODE=0/SERVER=1/SCREEN=1
$ !  MCR DECW$STARTLOGIN
$ !
$ ! The second screens session manager should come up. I've had some problems
$ ! under FT5.1 and FT2 DECwindows, but SDC appears to work a little better.
$ ! This is an observation, not necessarilly based in knowledge that something
$ ! changed.
$ !
$ ! Have fun...
$ !
$ ! P.S. the symbols of the form "SYSTARTUP_V_xxxx get defined by decoding 
$ ! my USERD1 parameter. If you don't want to use this hack, just define the
$ ! symbols approproiately.
$ !


$ !+++	SYSTARTUP_DECWINDOWS.COM - Batch Procedure for DECwindows Startup
$ !
$ !	SYSTARTUP_DECWINDOWS.COM is used to decrease the amount of time that
$ !	is required to get DECwindows started. DECwindows requires that DECnet
$ !	be started before it can be started. By putting this startup into a 
$ !	separate job, we can get DECwindows started before the full network 
$ !	database is loaded.
$ !
$ !	Written By:
$ !	James T. McCartney III. 01-Feb-1988.
$ !	Copyright 1988. All Rights Reserved. 
$ !
$ !---
$ !
$ ! Decode the USERD1 system parameter.
$ !
$ IF F$SEARCH("SYS$MANAGER:SYSTARTUP_GET_OPTIONS.COM") .NES. "" THEN @SYS$MANAGER:SYSTARTUP_GET_OPTI
$ !
$ ! Wait for DECnet to be started. We will check to see if DECnet is installed
$ ! on the system and if not then just exit. We then poll once every 10 seconds
$ ! looking for NETACP and REMACP. When both are started, we will start the 
$ ! DECwindows package.
$ !
$ SET PROCESS/NAME=SY_DECWINDOWS
$ IF F$SEARCH("SYS$SYSTEM:NETACP.EXE") .EQS. "" THEN GOTO EXIT
$ !
$ ! Check to see if we should start DECwindows.
$ !
$ If F$GETSYI("USERD1") .eq. 0 Then goto EXIT
$ !
$ ! We are running a baselevel later than DECwindows wants to see.
$ ! Tell it we know what we are doing....
$ !
$ !DEFINE/SYSTEM DECW$IGNORE_VERSION 1
$ !
$ ! Make sure NETACP is finished initializing before continuing.
$ ! This DCL fragment was lifted from STARTNET.COM and was modified
$ ! to wait 10 seconds per loop (instead of 1) to reduce busy waiting
$ !
$ WAIT_FOR_NETACP_COUNTER = 0
$WAIT_FOR_NETACP:
$ IF F$GETDVI("_NET0","MNT") THEN GOTO NETACP_INITIALIZED
$ WAIT_FOR_NETACP_COUNTER = WAIT_FOR_NETACP_COUNTER + 1
$ IF WAIT_FOR_NETACP_COUNTER .EQ. 120 THEN GOTO LOADNET_FAILURE
$ WAIT 0:0:10
$ GOTO WAIT_FOR_NETACP
$NETACP_INITIALIZED:
$ !
$ ! We require that SYS$NODE be defined - Wait for it.
$ !
$ WAIT_FOR_NETACP_COUNTER = 0
$WAIT_FOR_SYSNODE:
$ IF F$TRNLNM("SYS$NODE") .NES. "" THEN GOTO SYSNODE_DEFINED
$ WAIT_FOR_NETACP_COUNTER = WAIT_FOR_NETACP_COUNTER + 1
$ IF WAIT_FOR_NETACP_COUNTER .EQ. 120 THEN GOTO LOADNET_FAILURE
$ WAIT 0:0:1
$ GOTO WAIT_FOR_SYSNODE
$SYSNODE_DEFINED:
$ !
$ ! If the TCPIP transport is to be loaded we will wait for that to start as well.
$ !
$ IF SYSTARTUP_V_UCX_BRIDGE .NE. 0
$ THEN 
$  WAIT_FOR_NETACP_COUNTER = 0
$  WAIT_FOR_INET_ACP:
$   IF F$GETDVI("_BG0","MNT") THEN GOTO INET_ACP_INITIALIZED
$   WAIT_FOR_NETACP_COUNTER = WAIT_FOR_NETACP_COUNTER + 1
$   IF WAIT_FOR_NETACP_COUNTER .EQ. 120 THEN GOTO LOADNET_FAILURE
$   WAIT 0:0:10
$   GOTO WAIT_FOR_INET_ACP
$  INET_ACP_INITIALIZED:
$  ! 
$  ! Until we are sure when the INET_ACP gets everything started we will force a 10 second wait.
$  !
$  WAIT 0:0:10
$ ENDIF
$ !
$ ! For now we must start the DECwindows server after DECnet is available.
$ !
$ !
$ ! Start the server on the primary display device. We do all phases of the 
$ ! DECwindows for this device. Sooner or later, they will get around to doing
$ ! multi-seat workstations correctly.
$ !
$ DEFINE DECW$PRIMARY_DEVICE GA
$ If F$Search("SYS$MANAGER:DECW$STARTUP.COM") .NES. "" Then -
	@SYS$MANAGER:DECW$STARTUP.COM
$ !
$ ! We check to see if the second device exists and if it does, we start the
$ ! server on the second display. This is done before the first device so that
$ ! the DECwindows logical names will be correct.
$ !
$ IF SYSTARTUP_V_DECW_SVR_1 .NE. 0
$ THEN
$  SYSGEN := $SYSGEN
$   IF .NOT. F$GETDVI("GCA0","EXISTS")
$   THEN
$    SYSGEN CONNECT GCA0 /ADAP=0 /CSR=%O777300 /VECT=%O130 /NUMV=02 /DRIVER=GCADRIVER
$   ENDIF
$   !
$   DEFINE DECW$PRIMARY_DEVICE GC
$   IF F$SEARCH("SYS$MANAGER:DECW$STARTUP.COM") .NES. "" THEN -
	@SYS$MANAGER:DECW$STARTUP.COM
$ ENDIF
$ !
$ ! Wait until DECwindows gets started and then start the workstation artifacts.
$ !
$ WAIT 0:0:30
$ !
$ ! Start the Decwindows Clock
$ ! 
$ !RUN/PROCESS=DECW$CLOCK/UIC=[SYSTEM] SYS$SYSTEM:DECW$CLOCK.EXE
$ !
$ ! Start other workstation applications here...
$ !
$ Goto EXIT
$ !
$LOADNET_FAILURE:
$ !
$ REPLY/ALL/BELL "DECnet initialization timeout from SYSTARTUP_DECWINDOWS.COM"
$ REPLY/ALL/BELL "DECwindows will not be loaded."
$ !
$ Goto EXIT
$ !
$ ! Decwindows took to long to get started - we give up.
$ !
$ REPLY/ALL/BELL "DECwindows initialization timeout from SYSTARTUP_DECWINDOWS.COM"
$ REPLY/ALL/BELL "DECwindows applications will not be loaded."
$ !
$EXIT:
$ !
$ ! Cleanup a little bit - only keep this log and the last boot's log.
$ !
$ Purge/log SYS$MANAGER:SYSTARTUP_DECWINDOWS.COM/KEEP=2
$ !
$ Exit

We didn't believe 2 headed VAXstations were possible. Could you explain what the
hardware connections are? Basically, are you using 1 CPU and 2 screens+kbd+mouse?
What are the cable connections ? 

We could use this functionality I think.

Regards, Ric.

Right now a system vs3500 or VAXstation II/GPX with 2 GPX controllers,
2 video cables, 2 monitors, one keyboard, and one mouse will do it.
						Bill

    You can also build dual SEAT systems using a VAXstation CPU with a QVSS
    and QDSS video  controller.    You  get  two  keyboards,  two  mice and
    everything seems to work.    I've  got such a configuration running and
    have not had problems since upgrading to SDC DECwindows (V1.0). 
    
    Very neat stuff. You really need a CVAX-based processor, the MV-II CPU
    just barely has the power  to  push  this  thing and when you get large
    applications like DECwrite running on both,  it really gets klunky.  It
    just plain runs out of CPU.
    
    I've heard tell of a single seat QDSS/QVSS hybrid but I've not actually
    seen one. Does anyone know if that works as well? Also what about dual 
    seat QDSS/QDSS?
    
    James
    
    P.S.  You really have to watch  you  power  consumption  - it's easy to
    overload the power supplies.
    

Dual-head QDSS is what we are testing. 2 QDSS's in a box have been sold
as dual seat for Ultrix in the past. Dual-head QDSS and QVSS should work
too. Dual-head will be supported in V2.
						Bill

It may also be possible to have dual head vaxstar's and pvax's. One head
mono and one color if a cable can be built that passes fcc testing.
						Bill

    And some other things are done, right Bill? :-)
    

Does anyone know for sure whether the 3500 really supports the QVSS, or
vice-versa ?  I could really use a cheap mono second head (not seat) to display
banners from remote systems, etc.

								-Jeff

    Depends on what you mean by "supports".  If you mean, "can we sell it,"
    I'm pretty sure the answer is no.  I think the only thing we can sell
    is a VSII/GPX with two GPX heads.  Maybe a 3500 with two GPX heads. 
    Not sure about that one.
    
    Will it work?  Well probably if you don't care about watching TV in the
    same building.  (Actually, you'd better add up the power
    requirements...I don't know about that part).
    
    Burns
    

    Burns,

    The most recent ROM revisions on the Mayfair do not support the
    QVSS module.... The ROM prints a nice error message and refuses
    to play.

    Steve

    Ok, thanks.  As I should have stated more clearly, the only thing I
    know very much about is the server, but I thought I had seen the mixed
    head work at one point.  Maybe I did on the old rom :-(
    
    Burns

I would suggest a 4 plane qdss as the second head but a qvss would probably
work as a second head which means it would have to be put at a special csr
address so it doesn't overlap the qdss space and I believe the rom will not
recognize the qvss unless it is at the expected csr address.
						Bill

The problem is that I can't get a QDSS.  We have plenty of QVSSs and VR260s.

So if the QVSS has to go at a non-standard address, and the rom won't recognize
it there, how is it possible ?

							-Jeff

I assume you'd have the QDSS at the standard address, so the ROMs think of
your system as a single-head GPX.  Then to have the OS/drivers/etc. recognize
the second head, you'd have to tell SYSGEN about it with /CSR and /VECTOR,
or whatever the qualifiers are.

Did I guess right?

	paul

re:-1 You guessed right. The QDSS would be at the standard address and the rom
would recognize the system as a single-head GPX. A connect command like the
following:

$ SYSGEN :== $SYSGEN
$ SYSGEN CONNECT GCA0/ADAP=0/CSR=%O777300/VECT=%O130/NUMV=2/DRIVER=GCADRIVER

Would load and connect the the QVSS as a second head. Then something like
putting the following in the decw$private_server_setup.com file would let
the server know that the system is multi-head.

$ DECW$DEVICE == "GAA0,GCA0"
$ DECW$COLOR == "T,F"

In DECWindows V2 support has been added to the session manager, window manger,
server, and drivers to better handle multi-head. The session manager controls
multiple screens and allows FileView and Terminal emulators to be created on
multiple screens, and it starts a window manager for each screen. Window
manager, server, and drivers have added support to confine a cursor to a screen
so move and resize outline boxes work. We are also looking at a special cable
for vs2000/gpx and pvax to allow a monochrome monitor to be attached as well
as the color for dual head since the monochrome electronics are in all vs2000
and pvax systems anyway.

						Bill

Thanks. 

With the help of those in this note, I have successfully set up a two seated
workstation.  Here's a little description...

Starting with a standard QVSS (mono) VSII, I obtained a GPX upgrade kit
which included QDSS controller, cables, VR290, keyboard and mouse.  We
installed the QDSS controller in addition to the QVSS already in place.  As
mentioned earlier in this note, the QVSS has to be at a special address.
There are 3 switch packs on the QVSS controller, an 8 DIP pack, a 4 DIP
pack, and a single switch.  The 8 DIP pack goes (in increasing switch order,
1 = closed, 0 = open) 11110100, the 4 DIP pack goes 0001, and the single
switch is toward position C2.

To startup my two-headed VS, my startup goes like this (I don't have all the
kinks out yet):

$ sysgen :== $sysgen
$ sysgen conn gca0/adap=0/csr=%o777300/vect=%o130/numv=2/driver=gcadriver
$ sysgen autoconfig all/sel=GA
$ define decw$ignore_subprocess TRUE
$ @sys$startup:decw$startup "" 0 GAA0: GAA1: GAA2:
$ def/job decw$primary_device GC
$ @sys$startup:decw$startup SERVER 1 GCA0: GCA1: GCA2:
$ set display/create/perm/server=1/trans=local/screen=0 wsa2:
$ define/job decw$display _wsa2:
$ mcr decw$startlogin.exe

This runs two servers, one for each monitor setup.

Other interesting nifties I found out while playing around...

If you have a GPX color head and you define the symbol DECW$COLOR == "F"
before starting its server, it makes the color head think its an intensity
(grey level) display and it displays in grey levels instead of color.

I had limited success in starting up both heads on ONE server.  After GCA0,
GCA1, GCA2, GAA0, GAA1, GAA2 devices were all recognized, I was able to
start both heads from one DECwindows server by using the command

$ @sys$startup:decw$startup "" 0 GCA0:,GAA0: GCA1: GCA2:
$ set display/noperm WSA1:
$ deassign decw$display
$ set display/create/perm/trans=local/server=0/screen=0 WSA2:
$ set display/create/perm/trans=local/server=0/screen=1 WSA3:
$ define/job decw$display WSA2:
$ mcr decw$startlogin

(I unfortunately didn't keep notes of my experimentation, but I know there
were a lot of problems I ran into in starting this up, particularly, in
starting the server.  Another problem I encountered was that sometimes, I
could note get a window to take focus by clicking)

The Two-headed, one seat workstation has one pointer (which rolls off one
screen and onto the other!) and one keyboard.  The login window appears on
the main screen.  I had a problem that once I logged in via the session
manager, it only started the window manager on the main screen.  While
attempting to drag a window from one screen to another, the pointer goes to
the other screen, but the window simply wraps around on the main screen.
(bummer).

If anyone makes progress on two heads - one server, I'd love to hear of it!

Enjoy!
-Mike

I hear that two headed workstations will be supported in DECw V2.  I'm
wondering if I can get some specifics on what I can expect.

I currently have a QVSS/QDSS 2 seat VAXstation running 2 servers.  Will a
mixed color/mono setup be supported?

I've had limited success in running both heads from 1 server, 1 kb, 1 mouse
(see .-1).  Windows will not drag across from one screen to the other.  It
looks like the session manager and window manager only start on the main
screen.  What will be the expected behavior of such a system in V2?

Will the mixed color/mono heads cause a problem on a 1 server setup?

Thanks,
-Mike

    I'm not an engineer nor do I play one on TV, but what it seems you
    want is one coordinate space that applies to two display controllers
    and two displays.  That's simply not part of the X drawing model.
    
    On the other hand, it's a small matter of programming to duplicate
    all the drawing operations to both screens and have the second
    display have a x+1024 offset, that is display 1 is located to the right
    of display 0.

    
    I'm not too sure about that Pat.  I seem to have seen code that
    does just this - one logical device space.
    
    

Each screen has it's own root window and all windows are contained
within their parent window and all windows are decendents of the root
so therefore windows can't cross screens.

Yes a mixed mono/color display will be supported in the software.

One session manager will start that will allow application startup
directed to either head and will put the pause session window over
both(all) screens. There will be one window manager started per screen.

Basically V2 of DECWindows will have an acceptable level of support
for multiple screens. If the market warrants we can make futher
improvements in the support over time.

						Bill

> One session manager will start that will allow application startup
> directed to either head and will put the pause session window over
> both(all) screens. There will be one window manager started per screen.

"Directed to either head" Is that via DEFINE DECW$DISPLAY \ SET DISPLAY?
That's a drag.  (get it? ha!) From a user's standpoint, one would expect to
be able to drag windows across screens in multi-screen support.  I think I
understand the technical difficulties in this, but it would still be nice to
do.  THAT would be the way to make a transparent windowing system.  Couldn't
the window manager re-parent the application window to be on the other
screen and sent it the right notification events when it's being dragged and
the pointer leaves the current screen?

-Mike

Re: .23

What if the user decides to leave the window half on one screen (color) and
hald on the other (monochrome)?

				-- Bob

re: -2

What will happen is that it will prompt for the screen number via a dialog
box (most likely). THis can be turned off and you can "hard wire" it to
one screen or another.

re: -1

And no, all windows are either on one screen, or the other. It can't 
"overlap". 

Jeff

Gee... I seem to recall that the lowly Mac can do all of this dragging,
windows straddling screens, color-nocolor stuff....

Re: .26

>Gee... I seem to recall that the lowly Mac can do all of this dragging,
>windows straddling screens, color-nocolor stuff....

From a marketing standpoint you're right, this could be a problem.  From a
technical standpoint it's completely irrelevant; our software wasn't written to
allow multiple visual types per window or for visual types to change after a
window is created, and it would take a certain amount of effort to make it
work; how much effort, it's hard to say.  I know DECterm would have problems,
especially if it were in the middle of drawing a ReGIS picture, for example.

				-- Bob

The amount of effort it would take to change the software to permit
(e.g.) windows to straddle screens is in one sense irrelevant.  We're
supposed to be a conforming X Windows system.  If I'm not mistaken,
it's X which makes the definitions such as one screen per window, one
visual type per window, etc.   OK, so we could presumably define an
extension to do anything we wanted to do, but standards are presumably
implemented for a reason.

    You are not mistaken Dave,  the X protocol is
    one of the limiting factors.
    
    What happened with MacIntosh?  Are they X or not?

    re .29
    
    Macintosh is not X (except for an implementation under AUX, their
    Un*x implementation, which is not heavily used).  They are extremely
    proprietary.  But they ARE good.  I find programming to the Xtoolkit
    to be much easier than programming to the Mac toolbox.  On the other
    hand, their implementation is brilliant - efficient, compact,
    extensible, powerful, etc.
    
    Which is why it does all those nifty things.  I'd sure like to do
    those things as well, but I'd be happy just to have two screens,
    one mouse, one keyboard (actually, right now I need 300 two screens
    systems with TOUCHscreens!) even with disjoint windows.
    
    Ken B.
    
    Ken B.

Okay, so windows can't straddle a screen, but is it technically possible to
have the window be re-parented to the other screen when the window is being
dragged and the pointer crosses over the border?

    When the pointer crosses the screen borders,  it is also
    crossing root borders, different hardware, and if Im not
    mistaken different driver/driver entry points in use.
    
    RE: reparenting
    
    A newly re-parented window on a different screen is also 
    in a different root then the parent. This opens up a whole
    different set of non-trivial issues for the window manager
    in regard to iconification,  use of XQueryTree at startup,
    locating the icon for a window.  It is not just a reparent.
                                                      
    

When I goosed this topic with my prior barb about the Mac, I already knew that
the---shall I say---deficiency was with X and not DEC.  I would not expect
X to perform some of these tricks until X12 comes along.  It seems that you
could have a display defined by a ``meta-root' window comprising several
root windows, one for each connected screen.  This would, in the general
case, require non-rectangular windows and other magic.  I doubt that trying
to do this with X extensions would be a good idea.

Since I like X, I feel free to poke fun at it!

        WE have played with an application called swimmer from the dectop
        announcement kit, which allows a graphic to run across a virtual
        parent window that spanned multiple screens (not unlike the old
        greyhound demo for X10). I am now toying with the idea of an demo
        which will operate across multiple screens in a 2x2 or 3x3 or 4x4
        matrix behaving as one large virtual screen. Perhaps the SVN
        widget may be able to help in this sort of environment.
        
        q
        

    FYI, the current X protocol requires the new parent to be on the
    same screen as the old parent.
    
    Just for a little justification:  The internal structures which are
    represented by GCs and Windows each have a vector of routines which
    point to the device-dependent code which does either drawing (GC) or
    windowing (window) operations.  It might not be too difficult to change
    the code such that the window routines would be changed when a window
    was moved from one screen device to another.  The harder part would
    be changing GCs.  Since a GC can be used for more than one window (on
    the same screen), you can't just switch the routine pointers.
    
    I understand that it is not necessarily right to say "don't change the
    spec because I'll have to change the code".  However, an efficient
    implementation was on the minds of the X protocol designers, and the
    servers that I know about were written taking advantage of these
    provisions in the spec.
    
    Burns
    

    After reading .30-.35 I'm wondering why can't the two-head design have
    identical applications with two different roots but communicating with
    each other?  Surely there can be update information going between the
    identical applications so each can know what the other is doing. 
    Posting updates may not be the most efficient method of using the
    network bandwidth, but I think it can work.
    
    

    After all that was said, if i install VMS T5.2 as it is available now,
    will it bring up the session manager(s) correctly on my two-head
    system and let me work from both? If not, will i be able to do so with
    the next FT kit?
    
    --svb

    RE: .37
    
    The sound  of  you  note  leads  me  to  believe that you are wanting a
    two-seat  workstation  not    a   two-headed  workstation.    Does  the
    configuration you desire have one or two keyboards/mice? 
    
    James
    

    Re .38, actually i want both but will settle for either. My system has
    one CPU box and two of everything else.
    
    --svb

                    -< 2 seat works! 1 seat/2 head... eh? >-

It looks like some in this note have a working 2 headed GPX.  Field Service & 
others discourage this and tell me I can't be done etc.  I know they won't 
support it but we need to run DECwindows for applications such as DECwriter & 
can't afford 4 new systems.  Can anyone tell me what hardware they used to 
configure their system?

Here is the configuration I have for 2 systems I need to set up:

	VAXstation II GPX, 		MicroVAX II
	8 plane color			BA123 box
	BA123 box			13 mb
	13 mb				2 RD54
	1 RD54
	1 RD53

Any help is appreciated,
Tom

I just looked through all the replies to this note, and I would
like to get an answer to a wrap-up question.
As I understand it up till now :
	* two headed workstations (one mouse,one keyboard,two displays)
	  will be possible from the next version of decwindows in
	  a more supported way
	* on a pvax, there might come cabling support to connect a
	  monochrome screen as a second head
	* mixed color/mono will be supported
	* dual color only on gpx stations with open slots to add
	  graphics controller
	* each display will have a window manager and session mgr (?)
	* dragging application windows from display to display is
  	  difficult because of the limitations of X11
	* communication between applications on two displays is possible
	  using X routines
	* the mouse just rolls from display to display

My question then, when will this new version of decwindows be available,
(which VMS release to get the numbering right) and on what timeframe ?

Please correct me if I am wrong somewhere, I have a customer interested
in a dual headed station for flight simulator applications.

Thanks for any clarifications,

Dominique

I had to make some hacks to DECW$START_APPS.COM to get both seats to have 
a session manager. They were small, not supported, and not for customer 
consumption. The changes were starting at line 77:

$
$ ! If we are not on a workstation, then we are now done.
$ !
$ !IF (decw$device .EQS. "NONE") .OR. (P1 .NES. "")  THEN GOTO apps_done
$ IF (decw$device .EQS. "NONE") THEN GOTO apps_done ! modified JTM 15-Mar-1989
$ IF P1 .EQS. "" THEN P1 := 0
$ 


I don't claim this to be anything more than a hack, but it works for me and
may help you out.

James

    RE: .41 wrap up
    
    The next functional release of VMS DECwindows is only planned to
    support dual-headed GPX configurations. The code has been written
    to offer more flexibility (i.e. more than 2 screens, mixed GPX/mono)
    but these will be traded off to meet schedule if necessary. Each
    display will have a window manager but there will only be one session
    manager for the workstation. Dragging windows from display to display
    will be impossible, because windows cannot cross screen boundaries 
    in X11. 
    
    In any case, I think it's entirely too early to be promising features
    like this to customers. 

Field Service did the 2-head conversion for me.  (Of course, they say you're
on your own as to making it work).  As for the extra hardware, you need the
display cards, cables, monitor, mouse & keyboard.  I gave a short account of
my setup in .18

Word of caution: DECwindows is already kind of slow and a memory pig.
Running *2* servers on the same machine can put a crunch on things.  But I'm
living with it...

-Mike

The most recent replies have been talking about two headed (i.e. one
server controlling two screens, one kb, and one mouse).  That will take
up some extra memory for data structures, extra window manager, etc, but
it should not run two servers!

There IS a configuration which one can talk about where there are two
completely separate servers and users running on the same CPU.   We call
this two-seated, as opposed to two-headed.  It would have the same hardware
configuration (except that the extra keyboard and mouse would be used instead
of sitting around as spares), but it takes different setting up for s/w and
in addition, we are not planning to support it right away last I knew.  (As
you may have heard said before, there is architecture and some code to make
it work, but it may or may not...it has not been tested.)

Burns

In .44, I really meant to say that I'm running a "2-seated" workstation,
not two headed.  And yep, it works fine.

-Mike

I instigated the creation of a very gross kludge that allows my VS2000 to have
both a color and bw monitor attached, but I can't get the bw driver loaded.
Can anyuone explain how to start both the bw and color/gpx drivers on a vax2000?

I've tried the following command file from 282.2.  And tried several hacks 
ie. changing the driver & device name... but have had no luck.  Are there any 
specific parameters I should change?  The original window GAA0 comes up GAB0 
never has.  I have a MicroVAX II with 2 monitors & 16 meg.

Cheers,
Tom

< Note 282.2 by IO::MCCARTNEY "James T. McCartney III - DTN 381-2244 ZK02-2/N24" >
     -< The command file I use. It tends to wait for everything before s >-

$ ! This is the command procedure that I use to start DECWINDOWS on my
$ ! system. It starts the primary server on the QDSS devices then starts
$ ! the second server on the QVSS. I normally don't want to start the 
$ ! session manager on the second seat directly from my workstation. Normally
$ ! I run DECW$STARTLOGIN from the cluster to get the second head's session
$ ! manager. However, if you login to SYSTEM (from the console terminal) and
$ ! do the following:
$ !
$ !  CREATE/DISPLAY DECW$DISPLAY/TRANSPORT=LOCAL/NODE=0/SERVER=1/SCREEN=1
$ !  MCR DECW$STARTLOGIN
$ !
$ ! The second screens session manager should come up. I've had some problems
$ ! under FT5.1 and FT2 DECwindows, but SDC appears to work a little better.
$ ! This is an observation, not necessarilly based in knowledge that something
$ ! changed.
$ !
$ ! Have fun...
$ !
$ ! P.S. the symbols of the form "SYSTARTUP_V_xxxx get defined by decoding 
$ ! my USERD1 parameter. If you don't want to use this hack, just define the
$ ! symbols approproiately.
$ !


$ !+++	SYSTARTUP_DECWINDOWS.COM - Batch Procedure for DECwindows Startup
$ !
$ !	SYSTARTUP_DECWINDOWS.COM is used to decrease the amount of time that
$ !	is required to get DECwindows started. DECwindows requires that DECnet
$ !	be started before it can be started. By putting this startup into a 
$ !	separate job, we can get DECwindows started before the full network 
$ !	database is loaded.
$ !
$ !	Written By:
$ !	James T. McCartney III. 01-Feb-1988.
$ !	Copyright 1988. All Rights Reserved. 
$ !
$ !---
$ !
$ ! Decode the USERD1 system parameter.
$ !
$ IF F$SEARCH("SYS$MANAGER:SYSTARTUP_GET_OPTIONS.COM") .NES. "" THEN @SYS$MANAGER:SYSTARTUP_GET_OPTI
$ !
$ ! Wait for DECnet to be started. We will check to see if DECnet is installed
$ ! on the system and if not then just exit. We then poll once every 10 seconds
$ ! looking for NETACP and REMACP. When both are started, we will start the 
$ ! DECwindows package.
$ !
$ SET PROCESS/NAME=SY_DECWINDOWS
$ IF F$SEARCH("SYS$SYSTEM:NETACP.EXE") .EQS. "" THEN GOTO EXIT
$ !
$ ! Check to see if we should start DECwindows.
$ !
$ If F$GETSYI("USERD1") .eq. 0 Then goto EXIT
$ !
$ ! We are running a baselevel later than DECwindows wants to see.
$ ! Tell it we know what we are doing....
$ !
$ !DEFINE/SYSTEM DECW$IGNORE_VERSION 1
$ !
$ ! Make sure NETACP is finished initializing before continuing.
$ ! This DCL fragment was lifted from STARTNET.COM and was modified
$ ! to wait 10 seconds per loop (instead of 1) to reduce busy waiting
$ !
$ WAIT_FOR_NETACP_COUNTER = 0
$WAIT_FOR_NETACP:
$ IF F$GETDVI("_NET0","MNT") THEN GOTO NETACP_INITIALIZED
$ WAIT_FOR_NETACP_COUNTER = WAIT_FOR_NETACP_COUNTER + 1
$ IF WAIT_FOR_NETACP_COUNTER .EQ. 120 THEN GOTO LOADNET_FAILURE
$ WAIT 0:0:10
$ GOTO WAIT_FOR_NETACP
$NETACP_INITIALIZED:
$ !
$ ! We require that SYS$NODE be defined - Wait for it.
$ !
$ WAIT_FOR_NETACP_COUNTER = 0
$WAIT_FOR_SYSNODE:
$ IF F$TRNLNM("SYS$NODE") .NES. "" THEN GOTO SYSNODE_DEFINED
$ WAIT_FOR_NETACP_COUNTER = WAIT_FOR_NETACP_COUNTER + 1
$ IF WAIT_FOR_NETACP_COUNTER .EQ. 120 THEN GOTO LOADNET_FAILURE
$ WAIT 0:0:1
$ GOTO WAIT_FOR_SYSNODE
$SYSNODE_DEFINED:
$ !
$ ! If the TCPIP transport is to be loaded we will wait for that to start as well.
$ !
$ IF SYSTARTUP_V_UCX_BRIDGE .NE. 0
$ THEN 
$  WAIT_FOR_NETACP_COUNTER = 0
$  WAIT_FOR_INET_ACP:
$   IF F$GETDVI("_BG0","MNT") THEN GOTO INET_ACP_INITIALIZED
$   WAIT_FOR_NETACP_COUNTER = WAIT_FOR_NETACP_COUNTER + 1
$   IF WAIT_FOR_NETACP_COUNTER .EQ. 120 THEN GOTO LOADNET_FAILURE
$   WAIT 0:0:10
$   GOTO WAIT_FOR_INET_ACP
$  INET_ACP_INITIALIZED:
$  ! 
$  ! Until we are sure when the INET_ACP gets everything started we will force a 10 second wait.
$  !
$  WAIT 0:0:10
$ ENDIF
$ !
$ ! For now we must start the DECwindows server after DECnet is available.
$ !
$ !
$ ! Start the server on the primary display device. We do all phases of the 
$ ! DECwindows for this device. Sooner or later, they will get around to doing
$ ! multi-seat workstations correctly.
$ !
$ DEFINE DECW$PRIMARY_DEVICE GA
$ If F$Search("SYS$MANAGER:DECW$STARTUP.COM") .NES. "" Then -
	@SYS$MANAGER:DECW$STARTUP.COM
$ !
$ ! We check to see if the second device exists and if it does, we start the
$ ! server on the second display. This is done before the first device so that
$ ! the DECwindows logical names will be correct.
$ !
$ IF SYSTARTUP_V_DECW_SVR_1 .NE. 0
$ THEN
$  SYSGEN := $SYSGEN
$   IF .NOT. F$GETDVI("GCA0","EXISTS")
$   THEN
$    SYSGEN CONNECT GCA0 /ADAP=0 /CSR=%O777300 /VECT=%O130 /NUMV=02 /DRIVER=GCADRIVER
$   ENDIF
$   !
$   DEFINE DECW$PRIMARY_DEVICE GC
$   IF F$SEARCH("SYS$MANAGER:DECW$STARTUP.COM") .NES. "" THEN -
	@SYS$MANAGER:DECW$STARTUP.COM
$ ENDIF
$ !
$ ! Wait until DECwindows gets started and then start the workstation artifacts.
$ !
$ WAIT 0:0:30
$ !
$ ! Start the Decwindows Clock
$ ! 
$ !RUN/PROCESS=DECW$CLOCK/UIC=[SYSTEM] SYS$SYSTEM:DECW$CLOCK.EXE
$ !
$ ! Start other workstation applications here...
$ !
$ Goto EXIT
$ !
$LOADNET_FAILURE:
$ !
$ REPLY/ALL/BELL "DECnet initialization timeout from SYSTARTUP_DECWINDOWS.COM"
$ REPLY/ALL/BELL "DECwindows will not be loaded."
$ !
$ Goto EXIT
$ !
$ ! Decwindows took to long to get started - we give up.
$ !
$ REPLY/ALL/BELL "DECwindows initialization timeout from SYSTARTUP_DECWINDOWS.COM"
$ REPLY/ALL/BELL "DECwindows applications will not be loaded."
$ !
$EXIT:
$ !
$ ! Cleanup a little bit - only keep this log and the last boot's log.
$ !
$ Purge/log SYS$MANAGER:SYSTARTUP_DECWINDOWS.COM/KEEP=2
$ !
$ Exit

DECwindows V2 (currently in field test) has support for multi-head
workstations.  I'm using it now.  It works pretty well.

-Mike

    My configuration is two QDSS board sets into a VAXstation II/GPX.
    What is the DIP switch configuration for the second QDSS?
    
    (Where would a customer find this out, by the way?)
    
    Thanks

    To answer my own question: (this is my experience, not official
    comment, and I couldn't find the documentation)
    
    The first VCB02/QDSS has 0001 in its DIP switches. If the second QDSS
    is left at 0001 (in its DIP switches), the CPU self-test will fail.
    
    If the second QDSS is set to 0010, the system will boot, and autoconfig
    will recognize it as "GAB".
    
    This command brought up one server with two screens:
    
    @DECW$STARTUP SERVER 0 "GAA0,GAB0" GAA1 GAA2
    
    So now I'm the proud owner of a two-headed monster. 

I suppose this should be in the configuration information for the supported
two-headed configuration which customers can order, although I don't know
for sure.

Burns

    The hardware documentation, which is shipped  with each system we sell,
    has a section on configuring the CSRs  and  VECTORS  for each supported
    hardware device.  By using this information, and  reading a few command
    files (which customers love to do) they can find  out  a  lot  w/o  any
    documentation.
    
    BTW,  what  is  the status of the two-seat configurations?   Supported,
    Unsupported, "It works but...", "It doesn't work."?
    
    James
    

RE: .53

I'd LOVE to find out the status of the two head configurations, both two
seat and two display.  I'm trying to find this out from product managment, 
espcially for configurations that require special hardware.


Right now, I'm running a two-display VAXstation 3100 (one color, one 
mono) and it's great.  This was pretty simple to set up once I got
the prototype cable to make it happen.

Does anyone know if the Ultrix "DECwindows V2" supports this on the
3100 and 2000?


-bill

The intention to provide support for Multi Head workstations is by DECwindows
V2.0 is great news. There are certainly a lot of markets that could use this
capability. I have been asked how we can offer financial trading platforms with
multiple-screen workstations (upto 4) and I can think of many other 
enviornments where one requires a large window (with mapping or CAD drawing 
information) to not be obscured by other windows.

I think the point about performance is very valid and I would think that a 3000
series VAXstation would be required. A CSS engineer told me that he felt a 
little concerned with the Q-BUS bandwidth, is this so?

I have been told by product managment that,currently there are no plans for 
Digital to market a dual headed workstation (?)

Apparently IBM are claming that their PS/2's(don't know which model) supports 
dual head and are telling customers that DEC can't do it...

    re: -1
    
    Contact Bill Jackson in Worksystems base product Marketing. He is
    pushing on Worksystems product management to provide dual screen
    workstations. He can use all the ammunition he can get. It seems that
    some of the Worksystems product management folks don't "understand"
    what dual (or more) screens mean to customers and the corporation.
    
    Bill can be reached at HARBOR::JACKSON or PRAVDA::JACKSON.
    
    
    Jeff
    

    Re .51, i have a similar two-headed GPX configuration on a VS3500 and
    i'm now at the point where i can try a number of things and create a
    lot of `damage'. I need to understand a number of things that i've seen
    before pushing ahead. I tried the command:
    
    	@DECW$STARTUP RESTART 0 "GAA0,GAB0" GAA1 GAA2
    
    after booting up the system the normal way. It seems to startup the
    DECW$SERVER_0 process fine and let me move the mouse pointer spanning
    the two heads. However, there's no login on either screen. How should i
    get this to work?
    
    On another scenario, in trying to create a two-seated system, i entered
    the command:
    
    	@DECW$STARTUP "" 1 GAB0 GAB1 GAB2
    
    after booting up the system normally. DECW$SERVER_1 starts up fine but
    again no login on screen 1. From time to time, this command would also
    crash the workstation (but that's life, so no complaint here).
    
    Any tips would be grateful.
    
    --svb

Put up DECWindows V2 field test and look in
sys$manager:decw$private_server_setup.template
for example code on how to set up multi-head.
				Bill

Is there a way to get the digitizing tablet to work on a two headed system?
The cursor won't move to the 2nd screen. I think this behavior is correct
for a pad, you shouldn't go the the second screen when you go off the pad;
but is there some secret mechanism to tell the server to go to the second
screen - click MB1 when off the pad or something?

By the way, if I plug in a mouse, slide over the the 2nd screen and plug the 
pad back in it works ok; but I'm stuck on the 2nd screen.

Is there a way to control which SCREEN applications "auto start" on in the
session manager? I want some to start on 0 and some on 1.

A hack is to hit cntrl-f3 to enable the keyboard pseudo mouse and use the
arrow keys to hop screens then the tablet will be on the second screen.

You could also write a small app that puts up a window and looks for a
particular button press or key press and does an XWarpPointer call to move the
cursor to the other screen. Actually your app could probably use the root
window if the window manager doesn't get in the way.
						Bill

Another "bug" in the dual-head PVAX system.


When running Calendar, the Icon is different between the screens.  On
Screen 0 (Color) the icon has the date in it.  On Screen 1 (mono) 
the icon is the standard DECwindows icon (cross hatch, window pane)


Weird, really weird.


-bill

Hah.  Sounds like you caught someone using screen 0 explicitly when setting
the wm property rather than DefaultScreenOf.  Naughty naughty!  Submit a
QAR.

Burns

    Re .63 and .64:

> Hah.  Sounds like you caught someone using screen 0 explicitly when setting
> the wm property rather than DefaultScreenOf.  Naughty naughty!  Submit a
> QAR.

    Yes, please submit a QAR against Calendar. But I don't exactly what we
    are doing wrong; it's all pretty straightforward: we use
    XtAppCreateShell, and do a bunch of Set Values on the returned shell
    for XtNiconPixmap, XtNiconifyPixmap, XtNiconName, etc...

    Any idea Burns? 

    Thanks,
    Denis.

QAR entered.


Number 3624 in the DECWindows-IFT database.


-bill

re .-2.  Unfortunately, I don't know much about the toolkit interactions
with this kind of stuff.  Sounds like it may be the toolkit, although I don't
know why it would work correctly with other applications in that case.

Do I remember that you had to do something weird with shells (to fix the
problem where an alarm would not appear when the main calendar body was
iconified)?

Burns

There's also a weird problem with DECwrite, which I have also QARed.


DECwrite on the second screen sets both foregroun and background to the 
same color, thus you can't see a blasted thing.  It runs, reads the 
document (I can tell by the elevator position) but I can't see anything.



-bill
Who is trying to make this a product by the way.  It's GREAT!

RE: .-1

How did you QAR the DECwrite bug? Do they have a real QAR system or do you
just drop a note in their notes file? I'm tired of having my "bug reports"
that go into the notes file dropped on the floor.

I "QAR"ed (put a note in their notes file) this same bug way back at their
Pre-SSB version and they said it was a DECwindows problem, which it
certainly did/does not seem to be.  So it just sat there, and now the bug is
in their SSB version.  How much do you want to bet that they are using
(display,0) in their code instead of (display,screen)?

-Mike

>How did you QAR the DECwrite bug? Do they have a real QAR system or do you
>just drop a note in their notes file? 
    
    The DECwrite notes file IS our QAR system. You were the first person to
    report this bug to us. All bugs reported there are noted and acted upon
    as appropriate. Initially we thought this was a DECwindows problem.
    It's us. I won't go into the details about why this did not get fixed
    in our V1 but it did not.  
    				Pete

RE: .69

I QARed it as a DECwindows bug, and received mail from the QAR people 
saying that it was a DECwrite bug, and thus they forwarded it on to the
DECwrite people.


-bill

    re .18 where one creates a dual head machine with a QVSS & a QDSS. I
    did my thing with the DIPs on the QVSS, booted & promptly crashed when
    DW started. 8sw dip=11110100 (1=close, 0=open, form sw1 to sw 8), 
    4sw DIP=0001, single sw= C2.
    
    oh yeah, CPU found the QVSS for console, rather than QVSS (this tells
    me somtheing is really no right)
    
    QVSS is standard setting (wuz already in box)..
    
    now, the system expects to find the QVSS @ CSR=%o777300 & VECT @%o130
    
    Could someaone be kind enough to tell what are the DIP sw setting must
    be for the QVSS to be found at this address & set online..
    
    Am running with SDC VMS 5.3, 9 MB MVII.
    
    txm
    
    md

    re .-1: Its fixed.. FS flipped the wrong sw in the CSR pack. CSR SW
    PACK should be "11110110" from left to right (1=close, 0=open). other
    setting per .18
    
    md

    I've observed the following behavior and been wondering if it makes
    sense. On a two-headed system, i start a private window manager on
    screen 1 and am able to get the applications running fine there. Later
    on, i log into the system on screen 0 (which normally would start a
    window manager on screen 1 but is not since one - my private - already
    running there, that's OK and i think it ought to work that way).
    Everything is working fine. I proceed to quit the session and both
    window managers are terminated.
    
    I have problem with this behavior, i.e. i'm expecting the private
    window manager to continue on with the set of application windows
    before a user signs on. Is that expectation reasonable?
    
    --svb

    No, it's not reasonable.  When you log out, everything must get trashed
    and the server reset.  That's the way it is designed.  Otherwise you
    have a number of security problems.
    
    Burns
    

    It's been a few weeks now that I've made experiments with my color 
    VAXstation 3100, trying to run it with two screens (dual-headed
    system). I ended up with a `Y' cable, one plug to the box, the two
    others to: a- a color cable, b-a monochrome cable. The mouse and the
    keyboard are directly plugged in the P-VAX box, and the two monitors
    seem to be very happy with each others.
    
    I understood from our local FS engineers that they didn't support it.
    Fine.
    
    Today, FS came to put the 4th color board in my P-VAX. The first one
    was a known video problem (a bad resistor), the second one was
    generating verticals lines, when viewing complex color (i.e. using a
    certain number of colors) pictures (or playing FLIGHT), and the third
    one just blew away yesterday evening (yellow screen video output,
    failure to pass the test during the cold boot).
    
    Since this is not a `supported' hardware modification, I don't want to
    loose my time, FS time, and DEC's money by blowing color boards one
    after the other.
    I am not accusing the little DYI operation, but I would like to
    understand a few things.
    Apparently, this operation is well supported by DECwindows, as it is
    very happy to manage the two boards. The DECW$PRIVATE_SERVER_SETUP.COM
    file explains very well how to configure software-wise the little
    beastie. I really enjoy this feature, and think it's a great piece of
    software (and hardware) engineering,
    But what is the hardware Engineering point of vue ? I understand they
    don't support it officialy, but are there any technical reasons that
    could cause some hardware corruption at some point ?
    
    The third color board ran great during a month. the first and the
    second were badly operating from the start. I'm really doubtful for the
    third. Am just unlucky, and can I go ahead with the new color board ?
    
    Can anybody help me in that area, providing the name of a person of the
    P-VAX H/W Engineering. As well, I would be very interested by knowing
    the exact reasons why it wouldn't work.
    I believe this notesfile is probably not the place to ask this, but I
    am hoping for a few helpful pointers.
    
    Thanx,
    Pierre.

The cable adapter that is required for dual heads on a VS3100, is being
productized by WS continuation engineering. Contact Gim Hom, the product
manager, for more details.

    The prod mgr is Ron Ginger (WRKSYS::GINGER).
    
    

	Can anyone point me to where support for double headed workstations
	is documented? I can't find it mentioned in the VMS V5.3 SPD.

	Also will official support extend two-headed VS3500 based m/c's as
	well as VS3100's? We have both types running and a couple of
	intereseted customers, mostly wanting two colour screens

	Thanks

	Andrew

    m/c?
    
    If it is supported in H/W then it is supported in s/w.
    Lessee...a 3500 is a Mayfair with a GPX in a small (MicroVAX
    I-type) box, right?  I believe a two-headed h/w configuration is
    supported on a 3600 (which is in a big "world box"), but I don't
    remember about a 3500.
    
    
    Burns

    And the VS3100 will only support a color and a mono, not two color
    heads. Plus you need an adapter to make this work. WS engineering is
    working on it now. Contact WS product management for more details.
     

	Re .81 - m/c was my shorthand for "machine"

	 Thanks for the response, but I'm still concerned about support. Surely
	the VMS SPD defines what VMS DECwindows supports and it doesn't seem to
	mention dual screens for anything. It'd also be nice to confirm the h/w
	is supported (and the /GPX dip switch settings) but I don't believe h/w
	support implies s/w support. However, right now I can't show potential
	customers either!

	 BTW a two headed VAXstation 3500 would be based on VAXstation 3500 plus
	a 4 or 8 plane /GPX upgrade (or possibly MicroVAX 3500 or VAXserver 3500
	plus two upgrades). All of these are based on the BA213 box, 12 slot
	Qbus system with front access panel which should have enough slots and
	power for both /GPX subsystems. I thought 3600's were based on 40" high
	H-cab's containing a BA213 chasis (i.e. same thing really).

	Andrew

I believe that the VMS SPD is not updated for each release. It is certainly
not updated for each dash release. I will ask the decwindows product manager
for a status update.
						Bill

	Thanks,

	BTW Have since found a very brief reference to multiscreen support
	in the European Sales Update article for VMS V5.3

    The VMS V5.3 SPD doesn't say that multihead workstations are
    supported because there were no officially supported hardware
    configurations from Digital at the time. For V5.3-1, VMS will
    officially support multihead on the VS3100 systems with the
    new cable. Note that the VMS SPD isn't updated on -n releases,
    so if you need this on paper before VMS V5.4 you'll have to
    get it from the product manager. 

	Re .86: Thanks

	Just one thing, are dual head VS3500 based systems to be officially
	supported?

	Andrew

Is there any possibility of creating a dual headed 3100 SX (Scanproc) ?
If yes - is it color+mono, color+color ?
Does the Scanproc have mono output like the Dragon ?

Is any dual headed, supported configuration planned ?
(a pointer to a product manager will do).

If everything else fails, would it be possible to create a kind of dual headed
setup by using a 3100 and a DWT, one keyboard on the 3100, and one mouse
connected through a Y cable to both ?

The application would manage the output to both servers, use only the 3100
keyboard input, and process mouse events from both.
A selection widget on one of the screens will provide for toggling the
application's focus between the two screens.

Cheers,

Ori

Is there any possibility of creating a dual headed 3100 SX (Scanproc) ?
If yes - is it color+mono, color+color ?
Does the Scanproc have mono output like the Dragon ?
> Yes, scanproc does have dual headed color+mono just like what is there now
> for GPX. The mono is a dumb frame buffer on the mother board that is always
> there. Both GPX and SCANPROC(SPX) are options which can plug into the single
> color option slot in the 3100's.

Is any dual headed, supported configuration planned ?
(a pointer to a product manager will do).
>Yes!

						Bill
P.S. This note is being written from a dual head VAXstation 3100/SPX.

    
    (None of this is obvious from the titles for this topic. I looked,
    honest! :-)
    
    1. Can I put Three /GPX's in a BA123 worldbox?  Will DECW V2 recognize it
    as screen=2?  (There's a little bit of old equipment that I'm allowed
    to try to use before we sell it off...)
    
    
    2. how do I print-portion-of-screen on my "other screen"  (The one
    without the session manager?
    
    	I just realized that I can use UTOX!.
    
    2.a)  What is the Supported method of printing from the other screen.
    
    		-pk.
    
    
    
    	

    (None of this is obvious from the titles for this topic. I looked,
    honest! :-)
    
    1. Can I put Three /GPX's in a BA123 worldbox?  Will DECW V2 recognize it
    as screen=2?  (There's a little bit of old equipment that I'm allowed
    to try to use before we sell it off...)
>
> Yes you can put /GPX's in a world box but they may need to be 4 plane in
> order to not run out of slots or power. You should just have to modify
> the decw$private_server_setup.com to include info about the third head.
> 
    
    2. how do I print-portion-of-screen on my "other screen"  (The one
    without the session manager?
    
> There is a screen number customize option in the session manager customize
> menu that brings up a dialog box that allows printing for alternate heads.

    	I just realized that I can use UTOX!.
    
    2.a)  What is the Supported method of printing from the other screen.
    
    		-pk.
    
    
    
    	

	I was just wondering if there are any widgets available for the 
	multi-headed workstation ??

	-Joe

What kind of widgets? (what context?)

	Jeff, 

		Something like a fish or something thast swims in your backgroud
	from one monitor to the other...things like that...

	-Joe

There is a demo called swimmer that will allow this to happen. Somebody
in W.S. Marketing Tech support wrote it I think.

	Thanks...I will ask around...

		-Joe

    
    A plug for UISX (UIS for DECwindows/X11)...  The UIS model provides a
    virtual display and you create windows which display a portion or all
    of the virtual display on.  UISX currently allows up to 16 server
    connections (with any number of windows per connection) per virtual
    display.  A single output primitive can cause output on any or all of the
    windows and mouse and keyboard input can be recieved from any of the
    displays.  UISX transparently manages the difference in visual types and
    you can mix ANY type of X11 Server hardware within the same virtual display
    including non-Digital servers capable of connecting to a VMS Decwindows
    client.  UISX also provides backing store transparently to the user.
    
    A demo which creates 4 windows each mapped to a quadrant of a virtual
    display and running the QIX demo program is available in the
    distribution directory on the network for UISX.
    
    UISX is in FT1 and can be obtained from VWSENG::UISX$FT1:UISX010.*
    
    A notes conference exists at VWSENG::UISX
    
    _Fred

After having set up my dual head system (QDSS+QVSS) I find there's a little
thing that's really annoying me.

It assumes that screen 0 is to the left of screen 1, and the mouse pointer
moves off the right hand side of screen 0 to the left hand side of screen 
1.  That's fine, but at the moment (until I get the cabling sorted out) I
have screen 1 to the left of screen 0.  It would save lots of frustration 
if the mouse pointer could also move off the left hand side of screen 0 to 
the right hand side of screen 1.

I suppose I could swap around the definition of the two screens, but I 
assume that DECwindows will expect the mouse and keyboard to be connected 
to screen 0, which is not possible with the cables I have.

Any prospect of a solution?

jb

/*
	The following program when run with privs on a VMS DECWindows
	workstation will cause the pointer to wrap around from the
	right edge of the screen to the left edge of the screen for
	both single and dual head systems.
*/
#include <iodef>
#include <ssdef>
#include <descrip>
#include <lnmdef>
#include <lib$routines>
#include <starlet>
typedef struct _itemlist
    {
    short   bufferLen;
    short   itemCode;
    char    *bufferAddress;
    int	    *returnLength;
    } itemlist;
    static $DESCRIPTOR (DEVNAM, "DECW$SERVER_SCREENS");
    static $DESCRIPTOR(SERVER0,"DECW$SERVER0_TABLE");
    static $DESCRIPTOR(first_dev,"xxxx");
    static $DESCRIPTOR(last_dev,"xxxx");
/*                                                                          */
/* DECwindows Driver for SETMODE of ATTACH_SCREEN call.                     */
/*	The following are different parameters allowed by                   */
/*	attach screen. Thus the prefix "DECW_AS_".                          */
/*                                                                          */
#define IO$K_DECW_AS_TO_INPUT 2
#define IO$K_DECW_AS_TO_RIGHT 3
#define IO$K_DECW_AS_TO_LEFT 4
#define IO$K_DECW_AS_TO_TOP 5
#define IO$K_DECW_AS_TO_BOTTOM 6
#define IO$K_LAST 7
/*                                                                          */
/* QIO function codes, modifiers and submodifiers                           */
/*                                                                          */
/*                                                                          */
/* DECwindows Driver SENSEMODE and SETMODE function modifier codes          */
/*                                                                          */
#define IO$K_DECW_CURSOR_ASSOC 2
#define IO$K_DECW_ENABLE_INPUT 3
#define IO$K_DECW_BUTTON_INFO 4
#define IO$K_DECW_CURSOR_COLOR 5
#define IO$K_DECW_CURSOR_PATTERN 6
#define IO$K_DECW_CURSOR_POSITION 7
#define IO$K_DECW_DEVICE_INFO 8
#define IO$K_DECW_KB_INFO 9
#define IO$K_DECW_MOTION_BUFFER 10
#define IO$K_DECW_POINTER_FILTER_BOX 11
#define IO$K_DECW_POINTER_INFO 12
#define IO$K_DECW_OPWIN_KEY 13
#define IO$K_DECW_SCREEN_SAVER 14
#define IO$K_DECW_KB_LED 15
#define IO$K_DECW_RING_BELL 16
#define IO$K_DECW_ATTACH_SCREEN 17
#define IO$K_DECW_PMOUSE_KEY 18
#define IO$K_DECW_PTR_ACCEL 19
#define IO$K_DECW_MOTION_COMP 20
#define IO$K_DECW_MOTION_BUFFER_INIT 21
#define IO$K_DECW_CURSOR_BOUNDRIES 22
#define IO$K_LAST 23
main()
{
    unsigned long int       condValue;		/* VMS condition value */
    unsigned short int      iosb[4];		/* i/o status block */
    unsigned short int	    chan;
    int			    index;
    int			    maxIndex;
    int			    temp,size;
    itemlist crelnm_itemlist[20];
    itemlist trnlnm_itemlist[3];
    itemlist *crelnm_listptr;
    char lognam_buffer[2048];

    trnlnm_itemlist[1].itemCode = LNM$_MAX_INDEX;
    trnlnm_itemlist[1].bufferAddress = &maxIndex;
    trnlnm_itemlist[1].returnLength = &temp;
    trnlnm_itemlist[1].bufferLen = 4;
    trnlnm_itemlist[2].itemCode=trnlnm_itemlist[2].bufferLen=0;
    condValue = sys$trnlnm(0,&SERVER0,&DEVNAM,0,&trnlnm_itemlist[1]);
    if (condValue != SS$_NORMAL)
    {
	PrintF("Couldn't translate logical name\n");
	lib$stop(condValue);
	return;
    }

    /*
    * Get first device
    */
    index = 0;
    trnlnm_itemlist[0].returnLength = &temp;
    trnlnm_itemlist[0].itemCode = LNM$_INDEX;
    trnlnm_itemlist[0].bufferLen = 4;
    trnlnm_itemlist[0].bufferAddress = &index;
    trnlnm_itemlist[1].bufferLen = 4;
    trnlnm_itemlist[1].itemCode = LNM$_STRING;
    trnlnm_itemlist[1].bufferAddress = first_dev.dsc$a_pointer;
    trnlnm_itemlist[1].returnLength = &size;
    trnlnm_itemlist[2].itemCode = trnlnm_itemlist[2].bufferLen = 0;
    condValue = sys$trnlnm(0,&SERVER0,&DEVNAM,0,&trnlnm_itemlist[0]);
    if (condValue != SS$_NORMAL)
    {
	PrintF("Couldn't translate logical name\n");
	lib$stop(condValue);
	return;
    }

    /*
    * Get last device
    */
    index = maxIndex;
    trnlnm_itemlist[0].returnLength = &temp;
    trnlnm_itemlist[0].itemCode = LNM$_INDEX;
    trnlnm_itemlist[0].bufferLen = 4;
    trnlnm_itemlist[0].bufferAddress = &index;
    trnlnm_itemlist[1].bufferLen = 4;
    trnlnm_itemlist[1].itemCode = LNM$_STRING;
    trnlnm_itemlist[1].bufferAddress = last_dev.dsc$a_pointer;
    trnlnm_itemlist[1].returnLength = &size;
    trnlnm_itemlist[2].itemCode = trnlnm_itemlist[2].bufferLen = 0;
    condValue = sys$trnlnm(0,&SERVER0,&DEVNAM,0,&trnlnm_itemlist[0]);
    if (condValue != SS$_NORMAL)
    {
	PrintF("Couldn't translate logical name\n");
	lib$stop(condValue);
	return;
    }

    condValue = sys$assign (&first_dev, &chan, 0, 0);
    if (condValue != SS$_NORMAL)
    {
	PrintF("Couldn't assign channel to DECW$SERVER_SCREENS\n");
	lib$stop(condValue);
	return;
    }
    condValue = sys$qiow (0, chan,         
			IO$_SETMODE,                
			&iosb, 0, 0,                
			IO$K_DECW_ATTACH_SCREEN,    
			IO$K_DECW_AS_TO_RIGHT,      
			&last_dev, 0, 0, 0) ;
    if (condValue != SS$_NORMAL)
    {
	PrintF("\nAttach screen failed %d", condValue) ;
	lib$stop(condValue);
	return;
    }
}

    I believe that the dual-head cable part number is BC09E-06.

RE: .102


Right on Vince.  The part number is in fact BC09E-06



A question:

Is there ANY way to customize the background pattern and things like that
on the second display (ie: screen 1)?

I'm willing to hack up DECW$SM*.DAT to get it.  I can't stand the default
X background pattern!  

I tried putting some stuff from DECW$SM_BW.DAT in my color file, but that
succeeded in changing both screens.  Is there some screen-specific stuff
that isn't documented?


-bill

Bill,

You could always use the Xsetroot program from within your decw$login.com 
file. That might be an easy way to get the background that you want.

James

    I've put together a paper describing my experience building and working
    with a two-headed VAXstation.  It has been submitted to an IFIP
    conference to be held next year.  The paper contains a good number of
    information points shared by numerous people in and out of this
    conference.  I'd like to thank all of them.

    My hope is Digital is going to sell a bunch more of GPX/SPX
    controllers, BC09E cables, and VR2XX monitors once more of our
    customers realize how they can easily build these systems.

    The paper can be copied from VINO::ROSE:[THEOS.PUBLIC]IFIP.PS.

    --svb

re .103

Bill, 

You'll be able to do this in V3.  Specific customization of everything
that makes sense for the second screen (everything but what's in the
security and keyboard dialogs)

Jackie

    I'm trying to create a 2-head VS200, but can't seem to get it
    going. I've followed the instructions in the paper by S. VoBa,
    including building my own BC09E cable (potential problem there
    since it is a hand-made cable, but it seems to work fine. No
    problem on the color monitor alone, and I get a pointer on the B/W
    screen when I connect device GCA0). I'm working on VMS 5.4, have 
    set up the hardware, changed DECW$PRIVATE_SERVER_SETUP,
    and rebooted the workstation. First the arrow pointer appears on
    the B/W screen (I assume this is device GCA0 getting "connect"ed),
    then the pointers on both screens disappear, and the workstation
    hangs (no response from keyboard, both pointers gone).

    A "sho dev" shows GAA0 accessed by the server, but nothing
    happening on GCA0. I've include the "sho dev" and a copy of the
    relevant parts of the server setup file (note that I used the
    "connect" command directly from the .TEMPLATE file. Does that need
    to be changed somehow?). The server log files are empty. Any
    thoughts about what I might be doing wrong are much appreciated.

    Rob

Device GAA0: is online.

    Error count                    0    Operations completed                  3
    Owner process    "DECW$SERVER_0"    Owner UIC                      [SYSTEM]
    Owner process ID        21000035    Dev Prot                S:RWLP,O:,G:,W:
    Reference count                1    Default buffer size                  80

Device GCA0: is online, record-oriented device, carriage control, shareable.

    Error count                    0    Operations completed                  3
    Owner process                 ""    Owner UIC                      [SYSTEM]
    Owner process ID        00000000    Dev Prot                S:RWLP,O:,G:,W:
    Reference count                1    Default buffer size                  80

$ !
$ ! DECW$PRIVATE_SERVER_SETUP.COM - Customize DECwindows server
$ !
$ !****************************************************************************
$ node_list = ""
$ !
$ ! Here is an example list of valid node names:
$ !
$ node_list = "RAD1"
$ !
$ ! The following commands dispatch to the label corresponding to the name
$ ! of the node executing this command file, provided the node name occurs
$ ! in the list of valid node names.  If the node name is not on the list,
$ ! the command file goes to the label "do_default".
$ !
$ if node_list .eqs. "" then goto do_default
$ node_number = 0
$ node_loop:
$   node = f$element(node_number,"/",node_list)
$   if node .eqs. "/" then goto do_default
$   if (node .eqs. f$getsyi("NODENAME"))then goto do_'node
$   node_number =  node_number + 1
$   goto node_loop   
$ !
$ ! This node is not in the node list.  Don't specify any setup options.
$ !
$do_default:
$ exit
$ !-----------------------------------------------------------------------------
$ !
$ !
$ ! A dual headed VS2000 or VS3100 system. This configuration has only one
$ ! keyboard and mouse, and has a single color and a single monochrome
$ ! monitor.
$ !
$do_rad1:
$ run sys$system:sysgen 
connect gca0/adap=0/csr=%X5000/vect=%o400/numv=01/driver=gcbdriver
$ decw$color == "T,F"
$ if f$getdvi("GAA0","EXISTS") then decw$device == "GAA0,GCA0"
$ if f$getdvi("GEA0","EXISTS") then decw$device == "GEA0,GCA0"
$ 
$ exit
$ !

Is the server process still running?  Is anything still running?  If the
processes are active, but not doing anything, what are they waiting on?

    
    The server process is still there, just in LEF. Seems like it's waiting
    for input from something (but what?). There's also a _WSA1 process
    (also in LEF I believe, not positive about that). I was surprised that
    DECW$SERVER_0 wasn't the owner of both devices, figured it must be
    having trouble accessing GCA0.
    
    If I understand correctly, the windows login screen should appear on
    the color terminal (with the B/W just showing a background pattern),
    and then when I log in, DECwindows should start a session manager on
    each screen?
    
    Maybe I'll just try it again and see if I have any luck. Do I need to
    re-boot the workstation entirely. Or, will a DECwindows RESTART be
    sufficient?
    
    
    Rob 

    
    RE: .107
    
    Is it possible (just as a test) to start a second server (and session
    manager?) to the B/W screen while DECwindows is already started to the
    color screen? I thought it might be a more controlled way to test the
    graphics device connection. Can anyone give me explicit directions on
    how to do this? Thanks.
    
    Rob

    
    RE: last few
    
    Well, don't know what I did exactly wrong (before) or right (now), but
    I tried a DECW$STARTUP RESTART and my two-head VS2000 came up like a
    charm. Works great, I'll have a hard time giving back the color monitor
    now 8^). Thanks to all who helped put together the documentation and
    support for these 2-headers.
    
    Rob
    

Is there any way currently to control whether focus from
the window on the first screen is lost when the cursor
moves to the second screen?

If not, will such customization be added for V3?