Conference bulova::decw_jan-89_to_nov-90

    Do you have any INQUIRE statements in SYLOGIN.COM or LOGIN.COM?
    
    See the Release Notes, Section  2.5.2, FileView Notes. It's the 
    first one listed.
    
    David
    

    
    
    You were right, I had an inquire in my login.com file,  thanks.
    
    				Adele
    

I'm having the same problem: when I want to start Fileview the message
'no condition handler found' appears in my Session Manager window.

I have NO DCL inquire statements in my LOGIN.COM or SYLOGIN.COM
(as stated to be the cause in the Release Notes).

I'm running VMS V5.1-1 on a VS3100 , member of an MI-cluster.

The strange thing is that on another cluster (LAVC, also running on VMS 5.1-1 ,
but with a VS2000) I do have DCL inquire commands in my LOGIN.COM and Fileview 
just works fine.     --


Does anyone have a clue?

thanks,

Eric




    

    
    Here I am with the solution:
    
    It turns out that Fileview executes SYLOGIN and the commandfile
    as specified in the UAF field LGICMD.
                                         
    LGICMD defaults to LOGIN but can be changed, which we did.
    
    We have all our users accessing our system through a menu-interface
    which is started using the commandprocedure as specified in the
    LGICMD field in the user's UAF-entry.
    
    So I have to correct the VMS V5.1 Release notes ... on page 2-3,
    section 2.5.2 'Fileview Notes' with the above info.
    
    My final solution was to add to the beginning of our 'global' LGICMD 
    procedure:
    
    ! Check if process is started through Fileview. If so, exit.
    $!
    $       term = f$getdvi("sys$output","trm")
    $       if .not. term then exit
    
    
    Eric.                               
          
    

    Eric's solution is close -- but some of us (who go back to VMS V1.6...)
    have different setups.  Speicifcally, the logical SYS$SYLOGIN is
    defined and LGICMD is blank.  Under these conditions, VMS executes the
    SYS$SYLOGIN file, then SYS$LOGIN:LOGIN.COM (if present).  After messing
    with Eric's procedure and experimenting (for about three hours!), I
    came up with this procedure for those of you with SYS$SYLOGIN,
    SYLOGIN.COM, and LOGIN.COMs:
    
    1. Get rid of SYS$SYLOGIN:
    
    	$ DEASSIGN/SYSTEM/EXEC SYS$SYLOGIN
    
       Make sure it's removed from any system boot command files also!
    
    2. Modify the user account to point to the system manager file.  My
       example assumes you have a file SYS$MANAGER:SYLOGIN.COM, accessed
       by everyone, and you use SECURPACK:
    
    	MCR AUTHORIZE
    	UAF> MOD */LGICMD=SYS$MANAGER:SYLOGIN.COM
    	UAF> MOD DECNET/LGICMD=SECPACK_FILES:SECPACK_DECNET_LOGIN.COM
    
       Change the "*" to the specific user account above, if you don't
       want this procedure to go to everyone.
    
    3. Modify SYS$MANAGER:SYLOGIN.COM as follows:
    
       � Make Eric's command the first command.  I made it a one-liner
         as follows:
    
    	    $ IF .NOT. "''F$GETDVI("SYS$OUTPUT","TRM")'" THEN EXIT
    
       � Add the following line somewhere toward the end of the file,
         to make sure the user's LOGIN file is executed:
    
    	    $ IF "''F$SEARCH("LOGIN.COM")'" .NES. "" THEN @LOGIN
    
    I have tried all of the above and they work on my system.

re .4, .5

If you don't mind me saying so, this setup seems to be a crock.
VMS provides two "slots" for the execution of a login command 
procedure; one slot is system-wide (defined by SYS$SYLOGIN)
and the other slot is per-user (defined by LGICMD in the UAF).

Given the existence and definition of these two slots, any other
usage (such as putting a system-wide file in the LGICMD slot)
is just perverse.   You'll never replicate exactly the
range of function that VMS gives you; your system will "work
funny" and sooner or later you'll get bitten by it.

For example, if you have SYS$SYLOGIN doing "@LOGIN", then 
this means that the /NOCOMMAND qualifier no longer has the
original semantics.  Either /NOCOMMAND prevents the system-wide
file from being executed, or it has no effect, depending on
other login flags.

Why try hard to do things in a non-obvious manner?
V1.6 has been obsolete for a couple of months now!  :-)

P.S.   Your suggestions in .5 would mean that a user's LOGIN.COM
       doesn't get executed for non-interactive logins.  I'd be
       most upset if I used this system.

    My solution was intended as a workaround--I don't like it either
    because it violates the LOGINOUT standard procedures.  If anyone has a
    better method, please post it here.

    The situation was this: the FileView problem was caused by
    executing some kind of menu application in inappropriate
    circumstances.  
    
    This menu application happens to start up through the LGICMD field.
    That part isn't really anything to do with the FileView problem.
    It seems wrong-headed to usurp the per-user login command
    file with a system-wide procedure such as this.  How would I
    do it?  Easy.  I'd do the appropriate setup in the system-wide
    procedure, and I'd tell all my users that if they wanted to
    use the menu system, then they should put (e.g.) "$ STARTMENU"
    as the last line in their own LOGIN.COM files.   Maybe I'd give 
    new users a template LOGIN.COM with that command already in place.
    If I didn't want to give my users the choice of doing that, then
    I'd put the menu-system-startup in SYS$SYLOGIN:.
    
    Now, back to the FileView problem.  In general, if you put
    statements in a login procedure for someone else, you should
    accept the responsibility of verifying that those statements work 
    in all contexts.  In particular, for interactive marvels, make sure 
    that the process mode is interactive AND that the job's controlling 
    terminal [F$GETJPI(0,"TERMINAL") -- not SYS$anything] is a terminal
    and maybe that SYS$INPUT and SYS$OUTPUT are terminals too.