Conference azur::mcc

2667.0. "MCC V1.1 & VMS 5.5 - more problems?" by ANOSWS::COMFORT (Spent a little time on the hill) Tue Mar 31 1992 14:59

    
    Hi,
    
    I have encountered the previously mentioned VMS V5.5 and MCC V1.1
    alarms problems and have applied all available patches (hence the
    meaningless item message is no longer present).  However, I have come
    across a new wrinkle on 5.5 systems.  I have modified a batch procedure
    to do some checking for area outages.  I run this particular alarm on a
    VMS 5.4-3 system and on a VMS 5.5 system.  Everything else is identical
    (at least as far as I have personally setthe two systems up).  The
    alarm works great on the VMS 5.4-3 system, but I am getting file access
    failures on the 5.5 system.  At first I did have one privilege not set
    on the 5.5 system and was experiencing difficulty accessing the alarm
    command procedure file, so I changed the privileges so that they are
    identical and now when an .COM is submitted via job controller calls, I
    get this: 
    
    $  dcl_str = "man/ent show node4 phx25 area " +  area_num + " state"
    $  dcl_str = dcl_str + ", to file " + tmp_file
    $  man/ent show node4 phx25 area 21 state, to file
    SYS$SCRATCH:MCC_ALARMS_DATA_17120936.tmp
    DECmcc (V1.1.0)
    
    %MCC-F-PARTABOPEN, error opening parse table file:
    MCC_SYSTEM:MCC_PTB_PARSER.BPT
    %RMS-E-PRV, insufficient privilege or file protection violation
    %MCC-F-PTBINACC, parse tables inaccessible, unable to initialize
    FCL PM
    %MCC-F-TRM_FAILURE, PM unable to continue
    
    If I submit the same alarms procedure to batch from DCL, with the
    alarm data file included as parameter P8, everything is fine.
    
    As a temporary measure, I have given full privileges to the account
    under which this is being run.  I do not have any alarm data as
    of yet to see if this works around the problem.
    
    The normal privileges of the account, COMMSYS are as follows:
    
      CMKRNL SYSNAM DIAGNOSE LOG_IO SETPRV TMPMBX WORLD OPER NETMBX
      PHY_IO SYSPRV
    
    The file and directories are all owned by SYSTEM.
    
    
    Any information will be greatly appreciated.
    
    
    Regards,
    
    Dave Comfort
    
    

    I suspect you have a quota problem on the V5.5 system.
    I am guessing that V5.5 subtracts from quotas differently than V5.4
    did.
    
    Run the most recent version of the MCC_AUDIT on the V5.5 system and
    see what it finds.
    	NETS::USER$NETS:[MCC011.S-KIT]MCC_AUDIT.COM
    
    s/rob

    
    The solution to this problem was that upon parse table rebuild, the BPT
    is receiving a world no access protection.  I was not seeing this under
    5.4-3 due to the account having a privileged uic of [2,1]. On the 5.5
    system the uic was [30,1].  When MCC_ALARMS_SECURITY is executed, it
    strips the batch process of all privs except tmp and net.  So even
    placing a set proc/priv=all in the login.com after having granted full
    privileges in the user account under 5.5 was not producing the desired
    results. Couple this with uncontrolled set noverifys in various command
    procedures during login, and I was never seeing the fact that
    MCC_ALARMS_SECURITY was even being executed.  I now formally question
    the advisablility of stripping the privileges during this procedure. In
    my opinion, user privilege options should be left to the discretion of
    the system/MCC managers. So, basically my problem was due to an
    inconsistency in world wide account management on the part of
    SmithKline.  However it does pose some interesting issues, such as why
    did the parse table receive a different protection. 
    
    Dave Comfort

RE: .2

  > However it does pose some interesting issues, such as why
  > did the parse table receive a different protection.

  This problem has been fixed.  Now, a new parse table will use the
  same protection as the old file.  If the parse table is completly
  new, it will use default protections.

  Hope this helps (and sorry for the late reply)...

                                                                - Jerry