Conference iosg::all-in-1_v30

3339.0. "job aborting in OA$SCRIPT" by SUOSWS::HAMANN () Wed Sep 29 1993 11:19

    Dear experts!
    
    I get the following error from a job executing in OA$SCRIPT:
    (VMS 5.5, ALL-IN-1 3.0)
    
    %JBC-F-JOBABORT, job aborted during execution
       -JBC-E-SYMDEL, unexpected symbiont process termination
       -SYSTEM-S-NOTALLPRIV, not all requested privileges authorized
         Completed 29-SEP-1993 09:10 on queue OA$SCRIPT_GERMAN
    
    The scenario is as follows:
    
    I have an application that submits batch jobs (always the same script)
    to OA$SCRIPT. These batch jobs run fine as long as only ONE user 
    submits them.
    
    If different users submit batch jobs they run fine if the queue is empty
    at the time of submission or if the last entry in the queue is from the
    same user.
    
    If the queue contains pending jobs from different users the first job
    from a different user will fail consistently with the above error.
    
    I don't understand where the privilege problem comes from. The job
    does not request elevated privileges and runs fine if submitted into an
    empty queue.
    
    Some details to the job:
    
    The job is submitted via the OAMAILBOX from the subprocess of an
    interactive session. The command is produced from the following PASCAL
    statement:
    
    STRING1 := 'SUBMIT_SCRIPT (SCRIPT="BGV$COMMAND:FORMATDOC.SCP",P1="' +
                  AKTKZ + LFDNR + LFDSF + GEBNRK + DRUCKEN + RETCOD + FLRNAM +
                  FORMTYPE + DEV + DOCNAM + COPIES_S1 + COPIES_S2 + JOBNR_E +
                  JOBNR_D + VSEITE + BSEITE + '",' +
      	    'TRACE_FILE="BGV$TMP:' + AKTKZ + '_' + LFDNR + '",' +
      	    'JOB_NAME="' + aktkz + '/' + lfdnr +'")';
    
    
     The values of AKTKZ and LFDNR are unique for each job, so there is no
    access conflict on the logfile.
    
    However a logfile is not created for the failing job.
    
    The submitted script looks as follows:
    
     ! formatdoc.scp , batch script zur Dokumenterstellung
     GET #AKTKZ = OA$SMB_PARAMETER_1:8:0
     GET #LFDNR = OA$SMB_PARAMETER_1:3:8
     GET #LOGFILE= "$1$DUA5:[BGV]TRACE_" #AKTKZ "_" #LFDNR ".LOG"
     !set_trace (all,io,mess,dcl,function,command,log=#LOGFILE)
     get oa$function='.function command $1$dua5:[bgv.19.com]formatdoc.com "'-
     oa$smb_parameter_1 '"'
     .exit
    
    If the set_trace is activated a the logfile will not be created 
    for a failing job, there is no indication, that this script 
    has ever been started.
    
    I guess, that the script symbiont works differently when preparing for
    a new queue entry depending on the startup condition, either fetching
    the next entry from the queue or getting awakend for a new entry on an
    idle queue.
    
    Any insight, workarounds?
    
    Klaus
     
    

    Andrew,
    
    this might be the same error as in 3248, however I got a bit further
    in excluding causes.
    
    1. My jobs ALWAYS succeed when submitted from only ONE user out of many.
    
    2. The images are installed as required, otherwise my jobs would NEVER
       run, right?
    
    3. The error CONSISTENTLY raises when the next job to start is from a
       DIFFERENT user, regardless of the user. 
    
    4. It is always the same script.
    
    I am sure, ALL-IN-1 is failing to impersonate ONLY if the offending job
    is frome a DIFFERENT user and this job pas pending prior to the termination
    of its predecessor.
    
    I can smell this coding error and I am sure, I would find it within an
    hour if I could look at the listing. If the queue is idle at the time
    of submission the impersonation works, if the queue is busy 
    the impersonation for the next job is left out or fails and 
    the personality of the previous job is used.
    
    That would explain all my observations and the submittor of 3248 is
    kindly asked to check his observations against this hypothesis.
    
    Klaus

    
    
    ... and one more observation...
    
    I checked the failure syndrom with a different trivial script, that
    does nearly nothing. Then I did not get an error. So the problem might
    have to do with what the last terminated job had done.
    
    The real job uses a subprocess and the OAMAILBOX. This could make a
    difference.
    
    However the problem is in a very early stage of job activation because
    I never get a logfile for the real job if it fails.
    
    Still hacking around in distress...
    
    Klaus