Conference bulova::decw_jan-89_to_nov-90

    >  "protocol node user"...
    
    Sorry.  That should be "transport node user"
    
    David
    

    Almost correct.  The bit about the session manager is fine.  The
    server uses these files in the following manner at every server reset:
    
    Destroy Trusted Access List.
    Destroy Allowed Access List.
    If Trusted file is readable Then
    	Create Trusted Access List from file
    Else
    	Assume Default ("* 0 SYSTEM")
    Endif
    If Allowed file is readable Then
    	Create Allowed Access List from file
    Else
    	Copy Trusted Access List to Allowed Access List
    Endif
    
    						- monty

Thanks!  That explains why when I had lines in BOTH files and performed
an XListHosts, that these lines appeared twice in the permission list output.

Thanks again,

David

What is the magical incantation to start a server WITHOUT starting the program
that puts up the logo and login window? I would like to have just a simple
server, with no window manager or any other window up on my display. I plan to
push UTOX screen images to the background display, and so the previous notes
are of interest to me.

Thanks,
-Ken

I run a 4 meg WS with just a server and start the session on the 6220 host.

So on the workstation, my systartup is a couple of lines like so:

	$ @startnet
	$ def decw$ignore_subprocess true  ! Let DECW$startup run inline
	$ @decw$startup server      ! P1 = server = just start the server
	$ submit/queue=boot_queue remote$session.com

Where boot_queue is the queue on the boot node and the session command file
just defines a display and executes DECW$STARTLOGIN.EXE.

The DECW$SERVER_ACCESS_ALLOWED/TRUSTED database contains the boot node and 
 the username.  Works fine.

					Jeff

    If you are wanting to perform everything that DECW$STARTUP.COM normally
    does  (starts server, libs, and apps) except create a display device
    and run DECW$STARTLOGIN.EXE, then place the following command in
    SYSTARTUP_V5.COM:
    
    $ @SYS$MANAGER:DECW$STARTUP "" 0
    
    If P1 is NULL, then DECW$STARTUP goes through DECW$STARTSERVER,
    DECW$STARTLIBS, and DECW$STARTAPPS.
    
    P2 is the server number and currently all VMS workstations will only
    have one server (Supported that is).  DECW$STARTAPPS will stop
    just before performing the SET DISPLAY and RUN DECW$STARTLOGIN if
    P2 is not NULL.
    
    This method is good because it installs all sharable images and defines
    all the necessary logicals on the system.
    
    David
    

Can anyone tell me where these files are officially documented?

	SYS$MANAGER:DECW$SERVER_ACCESS_ALLOWED.DAT
	SYS$MANAGER:DECW$SERVER_ACCESS_TRUSTED.DAT

It is not found as one of the components in the V5.1 installation
guide.

They are not documented.  They are not supported.  They may change.  Note that
we are trying to figure out how to officially support remote session managers.

Burns

    This is sort of related
    I am trying to get sessions started on an Ultrix V3.0 workstation
    from a VMS V5.1 host
    set disp/cre/node=node
    mc decw$startlogin
    
    the login windows appear and I can happily log in
    but what I find is the Window Manager dies in the DECW$SM.Log file
    is messages of the sort
    
    X error event recieved from server BadRequest bad request code
      Failed request major op code 109 X_changehosts
      Failed request minor op code 0 ( if applicable)
      ResourceID )x8006b infailed request (if applicable)
      Serial Number of failed request 45
      Current serial number in output stream 46
    Session error: %NONAME-E-NOMSG, Message Number 02db822A
    
    
    i.e. XLIB-E-ERROREVENT, error event recieved from server
    
    
    
    if I start a window manager on the Ultrix Box then I can quite happily
    start session manager etc... on it.
    
    The only security file I know of is X0.hosts which has the node
    in - ( do you need transport etc in it ?)
    
    just thought I'd ask
    \Tom King TSC Sydney
    

    
    It's probably not going to fly.  Because of the perceived inadequacies
    of the X access control mechanisms, we boosted the VMS server with a
    special protocol type called "FamilyGeneric" used in the ChangeHosts
    request.  This protocol type is what allows us to perform access
    control on transport/node/username triplets instead of the usual
    transport/node pairs as well as change the trusted access list at
    runtime.  I doubt that the ultrix server is prepared to accept
    changehosts requests with this protocol type so, hence, the error.  I
    suppose the session manager should continue from this error trusting
    the remote server to have permitted appropriate access.  You should
    probably QAR this as a suggestion.
    
    						monty