Conference bulova::decw_jan-89_to_nov-90

    Try temporarily renaming both the SYLOGIN and their LOGIN files too.
    This sounds like the old problem where something in the login sequence
    is trying to do some I/O with the terminal.  You can't do this with
    DECW V2.

    Also check for SECPACK trying to do any inquiries.

                Dave

    
    Also check for process slots.
    
    

    I have this problem, too, on my stand-alone VS2000 running VMS 5.3, but
    this suggested fix doesn't help.  A few more clues/facts:  
    
    I've renamed both SYLOGIN.COM & LOGIN.COM - no luck.
    
    I can log into the SYSTEM account just fine, but a DEFAULT-type 
    non-priveleged account behaves as follows.  The icon box and session
    manager box display fine, but attempts to start application windows lead 
    to one disk seek & then silence/death for that application.  
    
    I can customize & save the parameters for the session manager & can 
    customize the icon box, but I can't save the icon box parameters.
    
    An almost-identical clustered VS2000 doesn't exhibit any of this
    deviant behavior.  Both SW systems were built last month using V5.3 &
    the two updates.
    
    I'm not an experienced system manager (not that it matters - my site SM
    has the same problem with another client & can't help me either), so 
    please phrase any suggestions in more-or-less clear English - I don't
    have the foggiest notion, for example, what 'check SECPACK trying to do
    any inquiries' means - sounds a lot like a military intelligence
    investigation!
    

    Unfortunately there are no "cookbook" scripts on how to find this kind
    of a problem.  It's just plain tough.  It would help if you could find
    someone with experience is determining why processes won't start, or
    images won't activate or die when they do.  Your system parameters
    should also be reviewed to see if they are set up for what you are
    trying to do with your system.  AUTOGEN is a good place to start.

    SECPACK is an internal security package that must be installed on all
    E-Net nodes.  One of the things that it can do is ask privileged users
    why they are logging into a system.

    Other things to check.  .2's suggestion on process slots is is a
    common problem.  File protections or file and/or directory ownership
    problems can happen.  SYSTARTUP problems are common.

    I wish I could help more, but it this requires good detective work,
    usually coupled with experience.

              Dave

>    I can log into the SYSTEM account just fine, but a DEFAULT-type 
>    non-priveleged account behaves as follows.  The icon box and session
>    manager box display fine, but attempts to start application windows lead 
>    to one disk seek & then silence/death for that application.  
>    
>    I can customize & save the parameters for the session manager & can 
>    customize the icon box, but I can't save the icon box parameters.

	Go into AUTHORIZE and check the DEFAULT DIRECTORY for the account.
	Does it exist?  Can the account SET HOST to the machine and 'see'
	his/her own files?  
>    
>    I'm not an experienced system manager (not that it matters - my site SM
>    has the same problem with another client & can't help me either), so 
>    please phrase any suggestions in more-or-less clear English - I don't
>    have the foggiest notion, for example, what 'check SECPACK trying to do
>    any inquiries' means - sounds a lot like a military intelligence
>    investigation!
>    

	Check ANY command procedures that invoked at account LOGIN time
	for a DCL INQUIRE command or a SET TERM/INQUIRE.  Either of these
	commands can make the DECterms not appear.  SECURE PACK (SECPACK)
	is a package (DEC only) that provides 'moderate' security 
	enhancements.

	Rick Beldin
	

	

    Thanks for both suggestions, Dave & Rick.  Dave's right - it does take
    a lot of good detective work.  I don't quite yet have the problem
    solved, but I do have a good clue now.
    
    I discovered that in the process of tailoring SYLOGIN.COM, the world
    privileges had gotten deleted - probably the result of the default for that
    directory.  Actually there had never been any danger of SYLOGIN.COM doing
    any mischief because it wasn't being executed!  Now...
    
    I strongly suspect that there are one or more other .COM or .EXE files that
    my SYSTEM account can access, that my non-privileged account can't, and 
    that are vital for successful DECwindows login but not necessary for normal
    terminal-mode (SET-HOST) login.  Any suggestions?
    
    What is the root .COM file for account login which eventually leads to
    execution of SYLOGIN.COM, etc?  If I knew this I could probably find
    the culprit(s) myself.  And while I'm at it, where is this documented? 
    I thought it might be in the System Manager's documentation, but I
    can't seem to find it.
                   

>>> I strongly suspect that there are one or more other .COM or .EXE files that
>>> my SYSTEM account can access, that my non-privileged account can't, and 
>>> that are vital for successful DECwindows login but not necessary for normal
>>> terminal-mode (SET-HOST) login.  Any suggestions?

    Verify by changing the default privs on your no=-priv account, and see if
    it fixes everything.

    Kevin

    If you have some way of watching OPCOM messages from that system,
    you might try enabling security alarms for both failed file access
    and for successful file accesses that needed elevated privileges.
    You could log into the nopriv account looking for access failures,
    then give that account some privs and watch for file accesses that
    needed those privs.

              Dave

>   What is the root .COM file for account login which eventually leads to
>   execution of SYLOGIN.COM, etc?  If I knew this I could probably find

    Don't bother looking any further.  SYS$SYLOGIN is executed by the CLI
    automagically.  See Chapter 23 of Internals and Data Structures if you
    want to know more.
    
    Did you try making your tailored SYLOGIN.COM world readable?
    
    The only "special" file for DECwindows is SYS$LOGIN:DECW$LOGIN.COM.
    
    Tim

    Thanks, Tim.  Yes, I fixed the SYLOGIN.COM problem Tuesday by making it
    world readable, although I'm more than mildly surprised that it was even
    necessary.  And yes, I did discover Chapter 23 at 6am this morning and
    concluded that SYLOGIN.COM was probably not invoked by a 'mother' .COM
    file.
    
    You mention DECW$LOGIN.COM - I have a DECW$SYLOGIN.COM on my system,
    but no DECW$LOGIN.COM.  Was this a typo, or should I have both?
    
    I seem to have made trifling progress by discovering that setting
    host to my 'user' account from SYSTEM on the same node I can't run
    MAIL!  Is it possible that this isn't really a DECwindows problem at
    all, but something more generic?  MAIL burps:
    
       	%MAIL-E-NOSUCHUSR,  no such user as !AS                      
    
    As little as I know about VMS, this looks like a logical is failing to
    be set at process creation time.  Which logical and who sets it?
    Anybody familiar with MAIL internals?  F$PROCESS definitely returns the
    correct process name - in my case MICHAEL - and F$USER returns
    [MICHAEL].     
    
    

    DECW$SYLOGIN.COM is the DECwindows equivalent of SYLOGIN.COM; it should
    be present & world readable.  That's the way the installation procedure
    should have left your system.  I don't think you need a DECW$LOGIN.COM
    but if present, it should be readable and not contain things like DCL
    INQUIRE statements.
    
    I think this was said before but you should rename/get rid of the
    account's LOGIN.COM and DECW$LOGIN.COM and replace them with something
    innocuous like a 1-liner "$ EXIT".
    
    Your problem with mail sounds suspicious...I think I've seen that
    message when playing around with username-changing programs.  Check the
    UAF record for the account and make sure it's got a unique UIC and a
    proper identifier, and that the default device and directory are OK.
    
    Tim