Conference bulova::decw_jan-89_to_nov-90

	Use the Security option in the Session Manager Customize 
	pulldown menu to allow yourself access from your big system
	to your workstation.

							mike

    I did that,, 
    
    I have also looked at the defaults file and it is correctly entered.
    Any other Ideas,
    
    	Thanks,
    		Stephen
    

1.  Check the contents of SYS$MANAGER:DECW$SERVER_0_ERROR.LOG.  You
    should see some failed access attempts logged there.  Please post
    the log file here if you can't make any headway.

2.  Is your "main computer" part of a cluster?  If so, then you should
    be aware that you cannot use the cluster alias in the security menu,
    but that you must enter in all of the individual cluster members
    names.

Does your workstation have the big machine in its DECNET database?  In other
words,

Hunger> MC NCP SHOW NODE GYPSC0

should work.

Burns

Thanks for the tips, 

I have looked at the file and it is of null length. I have made some 
progress however, I changed the access to *::'username' and I can now acces 
the display.   This is not a satisfactory solution. I guess that something 
is wrong with my node database. Both nodes see and know each other. If you 
have any clues then I would  appreciate. I think that the problem has moved 
out of this conference. It is now a NCP problem???

Now that I can open a window on my workstation. I would like to save myself 
logging into the main node. 

I start the batch job which sets the display and then childs the proces. If 
I do this interactively then there are no problems. If I submit the job 
remotely from my workstation then It appears for a short while then 
disappears. the log file shows  

	File access was terminated with SCF bit set on close

Any pointers to the manual would be appreciated.

	Regards,

		Stephen 

Try typing sys$manager:decw$server_0_error.log and see if it tells you anything
about what failed.  If it is a security problem, it will tell you who it
thinks was trying to connect.

Burns

If the contents of SYS$MANAGER:DECW$SERVER_0_ERROR.LOG is null, that means
that the server hasn't flushed the file out to disk yet.  The server was
modified in VMS V5.3 (DECwindows V2) to flush out out the error log file
after every write, however I notice you are still running V5.2.  If you
can't upgrade right away, one quick workaround is to generate lots of
error messages (like with failed connections) until the server's file
buffer gets filled and it flushes it to disk.

By the way, you still haven't answered my question as to whether your
"mainframe" is part of a cluster.  This could be the problem if you
have put only the cluster alias name in the security database instead
of the names of the individual cluster members (this is a current
restriction in DECwindows).

>	Do you know where the desktop version of 5.3 is? or does the 
>	'normal' 5.3 work on the 3100? I will take this way out.

	VMS is VMS. DeskTop-VMS is just VMS with a easier system management
	interface. Let's not confuse it with the old Micro-VMS PLEASE.

>The only problem I have now is why does *::user work but not Node::user.

	Maybe the nodename is not in your NCP database?


	FWIW, other than possibly having another ::BINGER out there with
	terribly malicous intents, there's not THAT much of a security
	problem with *::BINGER displaying to you.. (Yea, yea, I know, I
	know, someone could do something to get info off the screen
	but that takes alot more intuitive work than just hacking..)

							mike