Conference bulova::decw_jan-89_to_nov-90

    I found my problem...
    
    All local users needed to be defined as just USERNAME (not
    NODE::USERNAME) even if TRANSPORT=DECNET and NODE=NodeName on the
    SET DISPLAY (I went back and double checked...).
    
    Therefore:  NODENAME::USERNAME does not seem to work if NODENAME
    is local.
    
    Thanks,
    
    Brett

    
    
    I had the same situation happen and was able to fix it using the
    suggestions in reply .1.  However, to carry it just one step further.
    I am running an application (ALL-IN-1) that spawns a subprocess
    to the DDIF viewer.  When the subprocess tries to run the DDIF viewer,
    I get the following error:
    
      Xtoolkit Error -can't open display.
      xtoolkit fatal error

    Any suggestions?
    
    Steve
    

    
    Somehow make it execute this command before attempting to use the DDIF
    viewer.
    
$ set display/node=0::/create/transport=local

I thought that if DECW$DISPLAY was defined in the job table, the spawned
process would pick it up.

Jeff

    
    Many thanks for the reply.  Putting the 
    
    set display/node=0::/create/transport=local 
    
    command in the A1 script file worked fine. 
    
    
    Steve
    

Running the latest version of DECdecision field test (EFT3), if I try and run
their IVP from the system account (after doing a set host 0), I get this now
infamous message:

XIO: non-translatable vms error code: 0x2DBA002, vms message:
%decw-e-cnxabort, connection aborted
%XLIB-F-IOERROR, xlib io error

This is from the commands:

$ set display/create/node=drift
$ @sys$test:decision$ivp.com

If I modify the session manager security to allow access from 0::system, this
problem goes away.  But allowing access from DRIFT::SYSTEM fails.  What is the
difference between 0 and the system's node name?

Also, any idea why I get the error message number rather than the text message?

And yes, I did ask in the DECdecision notes file (EPIC_INFORMATION_IFT, note 
277) and was told that it wasn't their error message.

John

    
    For now, it is different.  The access control pieces do not test all
    permutations of node/protocol/address format and these currently test
    differently.
    
    You are getting the text message and the error number.  Being
    implemented in C and living in code shared between VMS and UEG, you're
    witnessing the behaviour of the perror() call when it doesn't see a
    unix error number.  (The text is the cnxabort message.)

I'm unable to upgrade beyond VMS V5.1 for the time being, for the age-old
'third-party product doesn't support current VMS release' excuse.  I want to
fix the 0x2DBA002 problem I'm experiencing.  Reading previous notes hasn't 
filled me with confidence that any of the cures really work.  The one 'cure'
that no-one has poo-poo'd was 'wait for DECwindows V2.0.  Can I install this
on VMS V5.1 to fix my 0x2DBA002 problem?  If not, what are the best cures
available?

Thanks!
tl

Given what we know now, going to DECwindows V2 is the only practical
solution to the 02DBA002 problem.

It's not technically possible to put the DECwindows V2 on a V5.1 system.
The fixes you need are in the transport, and the transport depends upon
system routines only found in VMS V5.2 and later.

Beating the horse just a little deader, upgrading to VMS V5.2 and not V5.3 help
this problem at all?

Thanks!
tl

VMS V5.2 won't help the 0x2DBA002 problem.  The version of DECwindows
distributed with V5.2 is DECwindows V1.0 with bug fixes, but not the
bug fixes you need in the transport.  We had to make very substantial
changes in the transport to work around this problem.  (Note: the
problem hasn't truly been fixed: it's just that the probability of
encountering it has been reduced by and order of magnitude or two.)

    I'm seeing 2DBA002, but in a new way.  I've modified the address of the
    VCB02 subsystem; I'm using on of the secondary addresses for my only
    VCB02, rather than the primary.  This allows me to control the console
    of the workstation through the 9-pin console port, via VCS.
    
    When system reboots, I do see the pointer appear on the workstation
    window.  Later, the pointer 'fills in', then immediately disappears, to
    be replaced by a cursor consisting of two vertical lines; this line
    cursor moves with the movement of the mouse.
    
    I tried to restart DECwindows with '@sys$manager:decw$startup restart':
    
    Restarting DECwindows software, server 0.  Please wait.
    %RUN-0S-PROC_ID, . . .
    
    Message number 02DBA002
    
    
    Is using the secondary address, with no primary, now, under VMS
    V5.3.DECwindows V2.0, illegal?
    
    Thanks!
    tl

What is decw$server_screens logical defined to be? Is your GPX unit
GAB0 when you swap it's csr address?
						Bill

    >What is decw$server_screens logical defined to be?
    This logical name is undefined.
    
    >Is your GPX unit GAB0 when you swap it's csr address?
    Nope.  I have GAA0, GAA1 and GAA2.
    
    I set my VCB02 to the 'first' secondary address, 777402; sure enough, a
    SYSGEN SHOW/CONFIG shows that to be the CSR address of device GAA.
    
    Thanks for the suggestion.  What next?
    tl

Can you post the contents of sys$manager:decw$server_0_error.log? - Bill

>decw$server_0_error.log<
12-JAN-1990 15:44:06.6 Hello, this is the X server
Dixmain address=13074
Now attach all known txport images
%DECW-I-ATTACHED, transport DECNET attached to its network
in SetFontPath
Connection 99700 is accepted by Txport
out SetFontPath
GPX color/monochrome support loaded
gpx$InitOutput address=12a210
Connection Prefix: len == 42
12-JAN-1990 15:45:33.9 Now I call scheduler/dispatcher
12-JAN-1990 15:45:36.7 Connection 99738 is accepted by Txport
12-JAN-1990 15:45:43.3 Connection 99700 is closed by Txport
    
    >show log/table=decw* decw$server*
(DECW$LOGICAL_NAMES)

(DECW$SERVER0_TABLE)

  "DECW$SERVER_DISABLE_CH" = "N"
  "DECW$SERVER_SCREENS" = "GAA0"
  "DECW$SERVER_TRANSPORTS" = "DECNET"
	= "LOCAL"

Though my system passed all ROM diagnostics, it failed the MDM VCB02 test of
the 1st four plane memory upgrade.  Once the cable was correctly seated, all
was well.

Thanks to Bill Matthews for the assist!

tl

    "my system passed all ROM diagnostics" -- if your QDSS is not at the
    primary address, then it is not automatically tested by the ROM
    diagnostics.  If you want to test a QDSS which is not at the primary
    address, type
    
    >>>T 63 n
    
    where "n" is the QDSS index to test (primary = 0, first alternate = 1,
    second alternate = 2, etc.).  Your QDSS index is 1.
    
    stephen