Conference bulova::decw_jan-89_to_nov-90

You're customer is pretty stupid.  You can't do INQUIRE if you don't have
a terminal.  That means DETACHed jobs, BATCH jobs, NETWORK jobs. not just
DECwindows jobs.  If he had any brains he would be able to figure that out.
The help on INQUIRE specifically says that it is interactive.  Why does he
expect it to work in a non-interactive process (the DECterm controller
process).

The INQUIRE should be surrounded by a test for whether this is a terminal.

Dick

Re: .1

I would certainly hope that any communication with the customer was done in
a more positive and respectful tone than your note.

There is nothing "stupid" in the customer's request.  The assumption that
there is some place to acquire user input from during login is natural.


Re: .0

I don't know the details, but what I would suggest is to have the login.com
create a DECterm first and then use READ/PROMPT from the DECterm device
once it is created.  Don't have it just do an INQUIRE.  

				Steve

    Since the customer is rebooting just to switch between DECwindows
    and UIS, I assume you know about UISX (now in field test). It lets
    you run most UIS applications directly on your DECwindows
    system. 

    
    We had many many customers call into the CSC who want to have a
    'captive' shutdown/backup account so normal user accounts don't need privs.
    Although this isn't terribly pretty, the best workaround I've
    come up with is:
    
    1. create the shutdown/backup account with all privs
    2. create a command procedure that would put up a pretty menu with all
       options the user could possibly want to do from this account.
    3. Create DECW$LOGIN.COM and it will have this line (at least):
    
         $CREATE/TERMINAL @command_procedure_created_in_step_2
    
    When the user logs in this account the first thing they'll get is
    a decterm window running this command procedure.  If all you want 
    to do is reboot under VWS, have the procedure change the params and 
    run shutdown detached .... magic. 
    
    There's a couple draw backs to setting up an account this way:
    
    1. Session manager will still start so they can then start any other
       app they want.  A lot of folks don't like this.  They don't want
       sesmgr to start but they want the ability to log off the account
       and get the login screen back.
    
    2. I was able to force sesmgr not to start but this of course 
       gives you no method for logging off and getting back to the login  
       box.  I believe the way I forced sesmgr not to start was by making
       the last line in decw$login  $LOGOUT.  In this case the only way
       to get back to the login box was to run LOGINOUT detached and
       having it execute DECW$STARTUP with the RESTART option.  That takes
       a couple minutes but it works.  I put this line in DECW$LOGIN
       before the logout.
    
    
    What we really need is for engineering to address what the customer's
    view as a big hole in the decwindows design.
    
    Hope this isn't too confusing.  If you have any questions why don't 
    you send email.
    
    Donna

    >What we really need is for engineering to address what the customer's
    >view as a big hole in the decwindows design.
    
    Plus documentation of the entire login process in the DECWindows
    environment and its ramifications (like no interactive devices for
    INQUIRE to talk to).
    
    Barry
    

Steve,

I repeat my assertion that the customer hasn't read even the help on INQUIRE.
READ/PROMPT will have the same problem as INQUIRE so that is no assistance. 
The login.com being described will not work for anything other than logging in
to a terminal (or terminal emulator).

Perhaps more thorough documentation of the fact that DECwindows WILL create
processes without terminals and that the user should see the guide to writing
command procedures for information on writing command procedures for
non-interactive situations.  LOGIN.COM is, after all, just another command
procedure.

Dick

The tone of interaction in this note is disturbing...as others have noted.

Anyway, I don't think that there is a `big hole' in DECwindows; perhaps there
is functionality that is missing that would expand the applications for
workstations and improve ease of use.

What isn't clear to me is what customers really want.  I think I see the
following customer requirements:

	1. Captive accounts - the user can log in but his activities
	   are restricted by the system manager

	2. Login directly to applications

But I'm not sure how this should be implemented.  Would the following solution
meet the customer requirements:

	If the account record is captive, then the session manager would
	invoke DECW$LOGIN but would not create its session manager window.
	When DECW$LOGIN completed, the session manager would exit the
	session.

	The system manager would need to write DECW$LOGIN with the understanding
	that there is no interactive session present and that the command
	procedure could not exit until the session is over.  The command
	procedure could create a terminal window which was running a
	captive procedure, or it could run a DECwindows application.

	One open issue would be whether or not the window manager would be
	started.

If this is a satisfactory solution, then I suggest that you enter it as a
QAR as a suggestion of the type of solution needed.  If this is important
from a sales standpoint, or from the standpoint of support (ie., the CSC is
spending 40 hours per week responding to this complaint, then this information
needs to be given to the DECwindows product management.

If this isn't a good analysis of the problem, then write up a better explanation.
It just isn't very helpful to say that the lack of captive accounts is a major
hole in VMS.  Meanwhile, you must be prepared to deal with this problem in
some other way; the releases of VMS that your customer will be able to use
before the end of the year are already frozen, bundled into kits and are being
tested.  It is not possible to add new functionality without compromising the
quality of the product and we need to increase the quality, not lower it.

    re: .7 "Let's be constructive"
    
    Indeed!  There is a large varity of captive environments that
    customers need.  It ranges from the ablitiy to turn off a few session
    manger options so as to keep users from shooting themselves in the
    foot, and to keep the number of applications and sessions within what
    the machine is intended to handle.  To applications that require
    complete control of the screen, including what is normally handled by
    the window manager, or even the login screen.  Certainly much of this
    range of functionality can be obtained now by resorting to various
    schemes some supported, and some not.
    
    I would like to suggest that we discuss, within this note (or on
    another topic stream, if that is deemed more appropriate), some of the
    captive environments that customers need to implement on our
    workstations and X servers.  Perhaps we can avoid submitting a zillian
    contradicting QAR requests.
    
    Clearly, our customers require methods of controlling what a user is
    able to do at a workstation.  I don't consider it a "hole" that
    accomplishing that control is awkward sometimes.  It is, however,
    contrary to the idea of giving the user complete control of his
    destiny.  I'll follow-up with descriptions of customer requirements
    that I'm familiar with.
    
    Barry

The fact the the lexical f$mode() exists makes the workaround so trivial that
it's hard to believe this is a problem.  Before decwindows, there were numerous
cases where it was important to know whether the process was running batch,
interactive or network....

			Bob Cohen

re: captive account.  This question has come up many many times.  (i.e. the
need to disable portions of the session manager).  I distinctly remember 
the discussion of setting portions of the session manager as not sensitive
with decw$xdefaults attributes.   Very Ugly, but perhaps better than other
solutions offered.

			Bob 

While f$mode is implied here, it actually doesn't do the trick.  This is an
area that could be better documented.  F$mode says that the session manager
and terminal controller processes are "INTERACTIVE".  What you really need
to do is check F$MODE and f$getdvi ("SYS$COMMAND", "TRM").  If sys$command
isn't a terminal, then you don't have anyplace to direct INQUIRE or READ/
PROMPT.

Dick

A reader has requested merging this topic and 2703.  Since this one started out
as a discussion of INQUIRE and stuff in login.com and 2703 started out as a
discussion of captive accounts, I think I'll keep the separate and just ask
that purely captive account stuff go to topic 2703.  I'll also add keywords to
these.

Burns

   
   I knoew that I had it here somewhere.
   
   If you check for  f$getdvi("tt","devclass") .ne. 70 (aka DC$_WORKSTATION).
   then this should match only when the session executing it is the session
   manager session.  Tell you customer to test for this in his login.com
   
   
   q