1 2 Previous Next 15 Replies Latest reply on Jul 22, 2015 9:09 AM by Sieghart Seith

    MV AlarmMgmt (in CAS): handling versions of used VIEWS

    Sieghart Seith

      I've got following answer about using views in AlarmDef of MainView Alarm Management:

      (we find out that the view used in alarm was very old - much older than in VDEF lib)

       

      <snip>

      In some cases when a view definition changes and you have created alarm based on it in the past you need to re-create the alarm. Normally in this case you get error messages indicating that structure of the view has been changed and some of field elements do not exist in query anymore...

      In this particular case we do not see any error message related to the view definition. However as your alarm use old version of the view we recommend to re-create the alarm anyway.

      <snip>

       

      IMHO this is bad for adminstration of alarms.

      How can I find out that the view is an old version in alarm?

      And why does alarm not use the recent version stored in VDEF?

       

      I guess this is a "trap" for all mainview admins ...

        • 1. Re: MV AlarmMgmt (in CAS): handling versions of used VIEWS
          Sieghart Seith

          add. information:

          How can/should I do "re-create"? Delete and define again????

           

          -Yes, we recommend to delete and created the affected alarm again.

           

          ===> This answer is "amazing". I have to create Alarm AGAIN with ALL parameters???

          • 2. Re: MV AlarmMgmt (in CAS): handling versions of used VIEWS
            Sieghart Seith

            And it looks like that the former (older) Alarm Mgr does this NOT in this way. See answer from bmc support below.

            <quote>

            For the old alarms managed by the Alarm PAS which have been stored in the separate members (BBHTMNxx) of a user parameter library, I believe, a view definition has NOT been included in the alarm definition.

            <end of qoute>

             

            What are the considerations for the recent architecture to do it differently?

            • 3. Re: MV AlarmMgmt (in CAS): handling versions of used VIEWS
              Feli Brachthaeuser

              Hello Sieghardt,

              also in the older MV Alarm Manager (2.1) a view and an element has been the basis for the alarm definition. And they are also in the definition!

               

              The older Alarm manager got the infos (view and element) stored in UBBPARM members beginning with BBHTMnn, whereas the new one has the details in XML structures in USS files.

               

              Probably people tampered with the definitions using ISPF edit. This is not at all recommended.

               

              I don't know any migration mechanism for alarm definitions based on MV alarm management 6.1.

               

              Sorry!

               

              Best regards,

              Feli

              1 of 1 people found this helpful
              • 4. Re: MV AlarmMgmt (in CAS): handling versions of used VIEWS
                Sieghart Seith

                Thanks, Feli.

                 

                But the most important issues (for me as mv admin) are:

                1) How can I realize that there is a mismatch between view-in-alarm and view-in-VDEF (or "outside alarming")?

                (In our case there is NO error msg or any other indication! There is only a hint from support because we missed an alarm firing and the view-in-alarm is shown in dump and they are missing a fix on the view.)

                 

                2) If have a need to "renew" the view in the alarm - how can I do this efficiently?

                 

                We will discuss these issues on next roundtable in Frankfurt ...

                 

                (I've known this issues in context of view customization - and try to avoid these - but NOT in the context of MVALARM yet.)

                • 5. Re: MV AlarmMgmt (in CAS): handling versions of used VIEWS
                  Feli Brachthaeuser

                  Hello Sieghart,

                   

                  ad 1) Difficult, try view DIAGELE which is a cross reference of views and elements.

                  You can launch this view inside any mv product.

                  But it will not include data from private user-specific VDEF libs.

                   

                  ad 2 ) Renew an alarm is needed: when the distrubuted view has changed its name or when the element has been dropped/ changed the name, etc.

                   

                  see you in Frankfurt,

                  Feli

                  • 6. Re: MV AlarmMgmt (in CAS): handling versions of used VIEWS
                    Sieghart Seith

                    To clarify 2)

                    HOW can I do the renew? Only with DELETE+DEFINE - really? Whats about DEPLOY again? Or copy to an new alarm? (I hate to delete the alarm and have to edit ALL parameters again ...)

                    • 7. Re: MV AlarmMgmt (in CAS): handling versions of used VIEWS
                      Feli Brachthaeuser

                      When the view name is still the same, the element can be changed by updating the alarm definition.

                      in case of a changed view name or new view than well you are in trouble...

                       

                      Let's talk to the BMC guys in Frankfurt!

                      take care,

                      Feli

                      1 of 1 people found this helpful
                      • 8. Re: MV AlarmMgmt (in CAS): handling versions of used VIEWS

                        Sieghart,

                         

                        I think you are making a little more out of this than the issue really is.    As Feli points out the events that will cause a MainView Alarm user to have to recreate an existing alarm are the view goes away (very unlikely) or an element name being used is changed or removed.   Again something that we try to avoid, but it does happen (usually in newer MainView products).

                        As far as the new design of Alarm Manager versus the 2.1 version.    It is MUCH better and disconnecting the need for a customized view or a view at all is a superior design.    It allows for the efficiency you see with Alarm Sets that contain different views, but utilize the same underlying records (i.e. elements).   Also the idea of persistance on alarms did not exist in 2.1. 

                        This is a great discussion and we welcome your input.    I hope you are starting to see that this is a very isolated issue for Alarm Manager 5.0 and the pros outweigh the cons when it comes to the new design.   It seems you are having a meeting with BMC in the near future, but I wanted to provide some additional feedback to what Feli had written.

                         

                        Regards,

                        Fred.


                        1 of 1 people found this helpful
                        • 9. Re: MV AlarmMgmt (in CAS): handling versions of used VIEWS
                          Sieghart Seith

                          Very good point, Fred.

                          NOW I understand in what case I have to renew alarms and how unlikely this is.

                          I was misleaded by bmc support because german support argues that I should renew my alarm anyway (there is no clue that element name was changed!).

                          The story is: I opened a issue because an alarm based on view JLOOP does (sometimes?) not work (no firing although conditions were true). Dump of CAS shows that view JLOOP inside alarm-def was older than the one in VDEF - and this could be the cause of no-firing. So, I get the feeling I have to renew ALL alarms with older versions of incorporated views. Now I'm happy that this is not the case ...

                           

                          I DO agree (100%) that new alarm mgr is MUCH better than den old PAS-located alarm mgr. No doubt!

                           

                          So, it was some kind of misunderstanding. But, nevertheless, it was a good learning about alarm mgmt. And I hope that I get HOLD-informations in maintenance process (PTF on views) in the rare cases where we have to look&change at alarm definitions.

                          • 10. Re: MV AlarmMgmt (in CAS): handling versions of used VIEWS
                            Sieghart Seith

                            Here is one example from maintenance process:

                            .....................

                            +HOLD(BQY0504) SYSTEM DATE(14134)

                            FMID(ZMMR31A) REASON(ENH) CLASS(ENH)

                            COMMENT(

                            The JLOOP and JLOOPZ views are updated by this PTF. If any alarms

                            or customization has been done to these views, it should be redone

                            to pick up the changes added by the enhancement.

                            …………………


                            What mean "redone" exactly? Change + save? Or delete + redefine?

                            • 11. Re: MV AlarmMgmt (in CAS): handling versions of used VIEWS


                              So for your hold data example and question on what does "redone" really mean.    Probably best if our developers would word the hold data differently.     "These views are updated by this PTF.   If any alarms or customziation has been done to these views, it should be tested and changes made as needed.    These changes may include a simple change and resave or in some cases deleting and redefining."    Because it would be difficult to say exactly what needs to be done for each customer.    As you have seen it is different depending on the circumstances.          

                              1 of 1 people found this helpful
                              • 12. Re: MV AlarmMgmt (in CAS): handling versions of used VIEWS
                                Sieghart Seith

                                As we discussed at mv roundtable in Frankfurt customers are missing transparency about this. To handle this efficient and secure is difficult. Maybe we do two RFE requests:

                                 

                                1) get better clarity about mismatch alarm/view (and need to renew alarms)

                                (new data dictionary in next MVI version may help!)

                                 

                                2) simpler process to renew alarms (better than delete-and-redefine which makes "troubles" and have more risks)

                                 

                                Discussion with german support goes on ..

                                • 13. Re: MV AlarmMgmt (in CAS): handling versions of used VIEWS
                                  Sieghart Seith

                                  Request for Enhancement QM001882486 is on the way ...

                                  • 14. Re: MV AlarmMgmt (in CAS): handling versions of used VIEWS
                                    Sieghart Seith

                                    RFE is rejected:

                                    The Developer has reviewed the request and determined that we will not be able to implement it in the foreseeable future because:

                                     

                                    There is no way we could ever automate the process of rebuilding of alarm in the unlikely event it is required again. Somehow we are supposed to know to use a different column and a different field name instead of the values in the old Alarm? Although such a change may be obvious to a human because the column headings are the ones you want to use, the same is not true for an automated process.

                                     

                                    Ordinarily, an Alarms do not need to be rebuild because a view changes. However, as we informed you, this is a special case. The field in the view upon which an Alarm would be set to detect a looping address space was incorrectly calculated. As a result, under certain conditions, this Alarm would not go off if a certain type of SRB were looping. MV for z/OS created a new field that is calculated correctly and that can be used for an Alarm. They hid the old field and labeled the new with the old name. You were supposed to rebuild the Alarm to pick up this new field.

                                    1 2 Previous Next