Conference clt::mms

1384.0. "%MMS-F-EXEDELPROC, HOW TO FIX IT ?" by EDSDS6::GLEASON (Daryl Gleason, DECset Engineering) Tue May 13 1997 09:11

           <<< CLT::DISK$CLT_LIBRARY3:[NOTES$LIBRARY]DECSET.NOTE;1 >>>
                                  -< DECset >-
================================================================================
Note 327.0             %MMS-F-EXEDELPROC, HOW TO FIX IT ?             No replies
GIDDAY::SHCHIU                                       74 lines  12-MAY-1997 22:00
--------------------------------------------------------------------------------
    
    
    I have a customer site with 
    
    VAX/VMS V6.1
    MMS V2.7-03  ( pretty old version )
    
    They have a mms script been running for long time, and suddently found
    problem with %MMS-F-EXEDELPROC. Later it was identify that 
    dcltables.exe was updated after two patches installed on the system
    
    DECRDB060A_ECO6
    RDB070_ECO1
    
    
    user has checked the accounting log, and found the subprocess
    did sucessfully completed , why MMS would reported abnormal 
    termination of the subprocess.
    
    As in some of the note points out could be related DCLTABLES.EXE.
    as in this case, Is there a workaround the problem  other than
    replace the old dcltables.exe.
    
    rgds
    
    
    /stanley 
    . stuff happens
    .
    %MMS-I-GWKWILLEX, MMS will try executing action line to update target
    .FIRST.
    ! set up a default directory for CMS FETCHES executed by MMS which
    %MMS-I-EXEPROCID, PID of created subprocess is %X20403EEB.
    %MMS-I-GWKEXESTS, Status of executed command is %X00010001.
    -RMS-S-NORMAL, normal successful completion
    ! corresponds to the directory in which MMS looks for the sources
    %MMS-I-GWKEXESTS, Status of executed command is %X00010001.
    -RMS-S-NORMAL, normal successful completion
    
    . Stuff happens
    .
    %MMS-I-GWKEXESTS, Status of executed command is %X00010001.
    -RMS-S-NORMAL, normal successful completion
    SET DEFAULT 'INIT_DEF'
    %MMS-I-GWKEXESTS, Status of executed command is %X00030001.
    -CLI-S-NORMAL, normal successful completion
    SHO PROC/ACCO           ! show resources used
    
    28-APR-1997 16:27:35.25   User: LBROWN           Process ID:   20403EEB
                              Node: DEV1             Process name:
    "LBROWN_1"
    
    Accounting information:
     Buffered I/O count:       247  Peak working set size:        665
     Direct I/O count:           5  Peak virtual size:           4669
     Page faults:              502  Mounted volumes:                0
     Images activated:           4
     Elapsed CPU time:          0 00:00:00.24
     Connect time:              0 00:00:01.76
    %MMS-I-GWKEXESTS, Status of executed command is %X10000001.
    ***
    %MMS-F-EXEDELPROC, Subprocess terminated abnormally.
    ***
      LBROWN       job terminated at 28-APR-1997 16:28:07.83
      Accounting information:
      Buffered I/O count:             862         Peak working set size:  
    11174
      Direct I/O count:              1091         Peak page file size:    
    24022
      Page faults:                  13010         Mounted volumes:            
    0
      Charged CPU time:           0 00:00:04.92   Elapsed time:     0
    00:01:09.01
    

    Hi Stanley,
    
    The EXEDELPROC error indicates that the MMS subprocess is terminating
    prematurely, before the MMS exit handler has been invoked as part of
    the normal MMS image rundown.
    
    This kind of thing can happen when some program that MMS runs in an
    action line abnormally (and abruptly) terminates the process, usually
    as a result of an error encountered while in supervisor mode or higher. 
    
    The patches you reported indicate changes to Rdb, which runs largely in
    executive mode. I have seen that kind of behavior with Rdb before, both
    from within MMS and also outside of MMS. I doubt that the changes to
    the DCLTABLES image itself would have any effect on MMS, but changes to
    Rdb might conceivably cause this kind of problem. I can't say for sure
    why the accounting log wouldn't register any errors except to theorize
    that the abnormal process termination might have prevented that. Is the
    customer executing Rdb-related commands in his MMS action lines?
    
    In any event, the best way to check on this is to take the action lines
    that MMS executes and execute them manually outside of MMS. If your
    process crashes, then that's probably what's happening within the MMS
    subprocess as well.
    
    If this turns out not to be the case, then it would be helpful to have
    a look at the full description file and a full log of a failed run.
    
    -- Daryl