Conference bulova::decw_jan-89_to_nov-90

    You could write a captive command procedure for the special shutdown
    account that would make a shutdown command file and submit it to batch
    on the node.  The account has to be privileged, but the captive command
    file should provide protection.  We use something similiar to shut down
    VAXstations in our cluster without actually having to log onto them.
    Not quite what you want, but very similiar.

              Dave

You can't use a captive procedure for logging in via DECwindows.  However,
you probably could put such a beast in the DECW$LOGIN.COM file in the SYS$LOGIN
for the shutdown account.  If you never exit DECW$LOGIN, you never get the
session manager run.  This file is really not supported for "captive account"
purposes...it is not guaranteed secure, it does not have a clear and easy
channel to interact with the user, etc etc.  It might work though.

Burns

    I used to have a special shutdown account for DECwindows workstations
    on my cluster, and I'd be happy to give you details if you want.  But
    I have retired that setup in favor of a slightly different approach:
    
    With DECwindows V2 (VMS 5.3), I now have a menu which is available only
    from the login screen.  This menu executes under the SYSTEM account and
    therefore can be used to do things like shutdown, AutoGen, etc.
    
    Here is the basic configuration:
    
    (SYS$MANAGER:DECW$PRIVATE_SERVER_SETUP.COM)
        $ Define/System/Exec DECW$LOGIN_BACKGROUND SYS$MANAGER:LOGIN_MENU.COM
    
    (SYS$MANAGER:LOGIN_MENU.COM)
        $ Set NoOn
        $!Spawn/NoWait XSetRoot etc... ! to load background image (optional)
        $ Set Process/Name="LoginMenu"
        $ if f$trnlnm("DECW$DISPLAY") .eqs. "" then -
              Set Display/Create/Transport=Local
        $ Define/Process RootMenu SYS$MANAGER:LOGINMENU   ! Special menu definition
        $ Run SYS$MANAGER:ROOTMENU
        $ if f$environment("depth") .eq. 0 then Logout/Brief
        $ Exit
    
    You should be able to find the ROOTMENU program through the DW_EXAMPLES
    conference (on ELKTRA::).

    
    RE: .3
    Please hand me more details for the special shutdown account you
    mentioned in your reply.
    
    My customer is very nervous to get it as soon as possible and this
    is quite nervous for me because he calls me several times a week
    and I can't get rid of her.
    
    So, please, please solve me and send it to me!!!!!!!!!!
    
    Further many thanx in advance
    		<>Armin<>

I haven't tried this, but...

With DECwindows V2, you can use the CREATE/TERM/DETACH/NO_LOG to get a 
DECterm that asks you to log in.

Why not just create a SHUTDOWN account on the workstation that executes the 
command procedure in .0 as its login command procedure and make a DECterm_login
selection available to the users from the Session Manager or FileView menu?
Logging into the SHUTDOWN account from this DECterm would shut down the system.

Would their license support this?

	- Dave

	Burns,

>You can't use a captive procedure for logging in via DECwindows.  However,
>you probably could put such a beast in the DECW$LOGIN.COM file in the SYS$LOGIN
>for the shutdown account.  If you never exit DECW$LOGIN, you never get the
>session manager run.  This file is really not supported for "captive account"
>purposes...it is not guaranteed secure, it does not have a clear and easy
>channel to interact with the user, etc etc.  It might work though.
>

	A customer of mine needs a "captive" account. Actually their request is
to disable various SM options (AutoStart, Applications, etc...). To be exact
their current application uses captive accounts on A/N terminals, and they are
adding some graphics to it. The application will start DECterm with A/N running
there and on demand spawn DECwindows graphics something.

	As captive account won't let one log in via Session Manager and playing
with various customization options may corrupt "normal" flow of things, they are
looking for a valid solution. Not allowing SM to run maybe a good one, but then
the following question rises : "What is SM doing AFTER it finishes DECW$LOGIN?".
Or rather "Is there anything SM does after running DECW$LOGIN that is essential
to normal work?"

	Thanks in advance,
		Alex

You'll have to wait for the session manager guru to answer that, or else submit
a querry qar.  She only has a chance to look at this conference once in a while.
I *think* the answer is that besides the obvious things that you see on the
control panel, the SM may do some customization setup (colors and stuff).
Not really sure how much of that is done before you get to DECW$LOGIN.  It
also (I think) restarts the login procedure when you log out.  You could
run DECW$STARTLOGIN, but that requires privileges.  That is a
problem.  All this goes to show why it is not supported, I'm afraid.