[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference humane::scheduler

Title:SCHEDULER
Notice:Welcome to the Scheduler Conference on node HUMANEril
Moderator:RUMOR::FALEK
Created:Sat Mar 20 1993
Last Modified:Tue Jun 03 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:1240
Total number of notes:5017

1159.0. "BAS-F-NO_ROOUSE on dissapearing NSCHED process." by UTRTSC::WIJKAMP (One day, you won't drink beer, you'll drink GROLSCH) Thu Sep 19 1996 14:31

T.RTitleUserPersonal
Name
DateLines
1159.1RUMOR::FALEKex-TU58 KingThu Sep 19 1996 18:0516
    When NSCHED exits voluntarily (for example, when someone issues a 
    $ SCHED STOP command, or NSCHED encounters a fatal error and decides
    to "kill" itself), it will try to append an entry to its event log before
    exiting.  So either the error is untrappable, NSCHED can't write to the
    log (quota?, i/o error?) or something is doing STOP/ID on the NSCHED
    process.
    
    If you have image accounting enabled ( $ set accounting... ) you should
    always see the time the image exited and the exit status, since VMS is
    very careful about writing accounting records. This will give you the
    exact time and the exit status.  In the case of a STOP/ID, the 
    status won't be that useful - probably either 0 or the completion status
    of the last image executed by the process, but the exact time may give
    a hint.  You might also try giving the account NSCHED runs under
    EXQUOTA as a default privilege (if it doesn't have it already) to
    see if this makes the problem go away.
1159.2p.s.RUMOR::FALEKex-TU58 KingThu Sep 19 1996 18:102
    I once saw a BAS-F-NOROUSE device error happen when someone
    "write locked" a disk. I don't know if that's related to your problem.
1159.3Solved.UTRTSC::WIJKAMPOne day, you won't drink beer, you'll drink GROLSCHThu Sep 26 1996 15:2110