OPS/MVS

 View Only
  • 1.  Interesting thing happened

    Posted Nov 02, 2020 10:45 AM
    Hello All,

    Had a weird situation happen this weekend after the IPL's of systems. Not sure if anybody else had this experience, I haven't in probably 20 years working with OPSMVS, but it was a blue moon.  The rule SSMEOM got auto enable got turned off, which of course caused lots of issues later when scheduled down times occurred for tasks.  Does anybody do any automated checking with OPSMVS to make sure the 'Main' rules are enabled and auto-enabled?  or maybe a when a auto-enable is turned off on one of these "major' rules to ask 'are you sure' question pop up?  Just wonder ... 

    Thanks

    ------------------------------
    Randy Knapton
    ------------------------------


  • 2.  RE: Interesting thing happened

    Posted Nov 02, 2020 11:07 AM
    Randy,

    Did you see a msg like this in OPSLOG?  If you display the JOBNAME col, it will show who issued it.  I manually disabled the autoflag in 4.5.1 to get this:
                     OPSS *LOCAL* AOF verb SETAUTO command SETAUTO MSG.SALTESTI
    Also, does the rule have a recent CHANGED date?  If you EDIT the member outside of OPS/MVS 4.5.1 and save it, the AUTOFLAG gets turned off automatically.

    We dont check for individual rules, but once I turned off a whole ruleset because of a SYNTAX error trying to disable just a specific rule.  We now do an ADDRESS "AOF" "LIST" every hour to make sure no entire ruleset is disabled.

    Just a couple of suggestions.
    Sal


  • 3.  RE: Interesting thing happened

    Posted Nov 05, 2020 04:14 AM
    Like many others we also monitor our (production) rules closely.
    Therefor we do NOT just rely on the AE bit being ok: At initialization, we set all AE bits correctly from a separate rdf table holding the correct values, so any inadvertently reset ae bit will always be rectified at ops initialization.
    Furthermore we monitor AOF DISABLE events, and verify against that same table whether or not it is ok to be disabled. If not: bells will go off.

    Regards,

    Marcel van Ek
    Atos NL

    ------------------------------
    Automated Operations Technical Expert
    Atos
    Netherlands
    ------------------------------



  • 4.  RE: Interesting thing happened

    Posted Nov 03, 2020 12:05 PM
    Hi Randy,

    We wrote back in time a TOD rule that is monitoring all rule sets.
    As Sal said, a simpel edit-save outside the OPS rule editor, disables the Auto-Enable flag.
    A rule can also become disabled to due excessive been fired (add OPTIONS "NOFIRELIMIT").
    This TOD can be scheduled at the end of the day, week or in the system shutdown command.
    The rulesets to check or scan can be build in a stem. This in order to leave out or skip some dev rulesets.
    The same can also be done for specific ruleset.rulename to avoid false positives.
    For each ruleset we skip rules who are:
    - Enabled and auto-enabled
    - Disabled and not auto-enabled
    All others are considered as anomaly and can be put into a mail for verification or notification WTO on console.

    Kr,
    Patrick Barrez.