Conference humane::scheduler

    Logical name NSCHED$  on the remote system does not point to
    the directory where the scheduler database files reside, or it didn't
    at the time the scheduler remote agent was started.
    
    POWDML is a cluster, only one node might be messed up.  The solution is
    to make sure NSCHED$ is defined correctly there, and then restart the
    remote listener on that node.

    Still continuing with this problem....NSCHED$ is defined the same
    on all nodes:
        "NSCHED$" [exec] = "POWDML_SYS01:[NSCHED]" (LNM$SYSTEM_TABLE)
    
    This is the correct location.  I also stopped and restarted the
    remote agent just in case it was looking at the wrong spot.
    Also, it works when I proxy into a privileged account (SYSTEM) but
    not when I proxy into a non-priv'd account.  All the files in NSCHED$
    have been set to W:RE.
    
    Any ideas?

    Unless the code was changed from how I remember it, the message means
    that the program can't open the database file(s).
    Either the pointer (NSCHED$ logical) is wrong, or there is a privilege
    problem. I Think NSCHED$ only gets translated when the remote agent
    has to do its first access, if the access succeeds it sets a flag and
    keeps the file open. Apparently it didin't succeed, so it will try
    again each time.  Let me see... you say you can access the data base
    from a priv'd proxy account, and then when you try it a few moments
    later using a non-prived proxy it doesn't work ?
    
    How about when you run the user interface directly on that node
    (like in $sched show jobs) - does that work ? 
    
    In general, the files in NSCHED$ should NOT all be W:RE
    (The scheduler server should have enough privs to access the stuff it
    needs, and the UI is installed with SYSPRV - it is a security problem
    to allow world write access to the database !

    Well maybe there is a protection problem here.  Maybe the remote
    scheduler looks at some different files than are used when just 
    invoking Scheduler interactively?
    
    The SCHED command does work fine interactively for both the
    privileged (SYSTEM) and non-privileged (CIS_SAT) account.
    Here is what I typed from the non-priv'd account:
    
    WITNES $ sched
    POLYCENTER Scheduler V2.1
    (c) Digital Equipment Corp.  1990, 1993.  All rights reserved.
    
    SCHEDULE>sh job */br
    
     Job Name             Entry    User_name    State      Next Run Time
     --------             -----    ---------    -----      -------------
     CISB010              16       CIS_SAT      Scheduled  23-DEC-1996
     CISB020              17       CIS_SAT      Scheduled  23-DEC-1996
     CISB_SYSUAF_OWNER    176      CIS_SAT      Scheduled  24-DEC-1996
    SCHEDULE>exit
    
    Here is the proxy on WITNES (POWDML) that works fine otherwise:
    
    Witnes_System>> auth
    UAF> sh/proxy ics::bonvallat
    
     Default proxies are flagged with (D)
    
    ICS::BONVALLAT
         CIS_SAT (D)
    UAF>
    
    Here is the same SCHED command that was being done interactively now 
    being done from the ICS::BONVALLAT account remotely:
    
    ICS$
    SCHEDULE>sh job */br/server=witnes
    Connecting..Connected to WITNES
    %NSCHED-F-NODATABASE, Scheduler database not found
    SCHEDULE>exit
    
    This command would work if I were to change my proxy on WITNES to
    default to the SYSTEM account rather than the non-priv'd CIS_SAT
    account.
    
    Thanks again!    - Jeff
    

    Besides the job database (NSCHED$:*.dat) It also looks at NETPROXY.DAT
    (pointed to by exec mode logical NETPROXY, I think)  - Its supposed to
    be installed with SYSPRV, I think, so it should have no problem looking
    at that file (and I didn't think it would make that error if it
    couldn't read it)
    
    
    Check the privileges the SCHED_REMOTE (or what ever its called now-a-days)
    process is installed with.

    Found it!  For some reason (I think probably because of the way certain
    questions were answered when installing NSCHED), the SCHEDULER$STARTUP
    file on POWDML does not install the NSCHED$:SCHED_DECNET.EXE file -
    as is done on our other V2.1 systems.
    I installed NSCHED$:SCHED_DECNET.EXE with the proper privileges and 
    voila - it works.
    
    Thanks for helping to point me in the right direction.   - Jeff