12 Replies Latest reply on Jan 16, 2012 6:44 AM by Laurent NameToUpdate

    MRL syntaxe question (case XXX in XXX)

      Hey guys,


      I'm trying to use a "case XXX in XXX" state in a Refine rule and can't seem to find the correct syntax.


      I've tried:


      refine TWS_P_UNTIL_APP :
            TWS_EVENT ($EV)
             where [ ($EV.status != CLOSED AND $EV.status != BLACKOUT) ]
              case  $EV.d_TWS_AlertReff in

                     P_DEADLINE_JOBSTREAM )


                            $EV.mc_object_class = ... ;                     

                            concat ([...],$msg);
                            $EV.msg = $msg;

                     P_DEADLINE_JOB )

                            $EV.mc_object_class = ... ;                      ...

                            concat ([...],$msg);
                            $EV.msg = $msg;





      But this doesn't work.

      Can we use a "case" logic in MRL?

      If yes, what's the syntax? I can't find any examples in the existing rules.


      Thanks for your help


        • 1. MRL syntaxe question (case XXX in XXX)

          There is no "case" syntax im MRL.


          You must use if - then - else. In your example:


          if ($EV.d_TWS_Alert == P_DEADLINE_JOBSTREAM) then






            if ($EV.d_TWS_Alert == P_DEADLINE_JOB) then





          • 2. MRL syntaxe question (case XXX in XXX)

            Erf, ok thanks.


            Is it better / more efficient to have?

            - 1 big refine rule containing multiple "if" for all my alet references (10 => 15) or

            - Multiple refine rules (1 per alertref) with the Alert References in the ECF



            • 3. MRL syntaxe question (case XXX in XXX)

              From my experience, having one big rule is better (it's also easier for tracing).

              • 4. Re: MRL syntaxe question (case XXX in XXX)
                Jonathan Coop

                You're stuck with if then else, try splitting into multiple rules for readability. Jon


                Sent from my iPhone

                • 5. MRL syntaxe question (case XXX in XXX)



                  What I would do :


                  Build a DDA that would contain :

                  • d_TWS_Alert criteria
                  • a list of slots that would contain target value
                    • mc_object_class_values
                    • msg_values


                  Build a rule which uses the DDA which does a match using d_TWS_Alert criteria and maps values according to DDA values !


                  Pros :

                  • your not using any if/then/else : if/then/else  statement are VERY inefficient in MRL rules. You should avoid this whenever you can.
                  • in case you have a new value for d_TWS_Alert, you just have to add an entry into the DDA and not modify your code !


                  Cons : none ?


                  Hope this helps.


                  • 6. Re: MRL syntaxe question (case XXX in XXX)
                    Jonathan Coop

                    I would create multiple rules, each with condition as part of the ECF, ok lots of rules but very fast. Jon


                    Sent from my iPhone

                    • 7. Re: MRL syntaxe question (case XXX in XXX)

                      Why are if-the-else statements so inefficient? Could you explain this?


                      Could you show the code to implement DDA for this example?

                      • 8. Re: MRL syntaxe question (case XXX in XXX)



                        I would not be able to explain exactly why... but it is due to the fact that MRL is Prolog based which is not a "procedural" language like C or perl. if/then/else does not exists natively in Prolog and have been implemented in MRL for convienience and should be avoided whenever possible.


                        As Jon suggest, it is more efficient to have several rules with specific ECF.


                        But it means readability / maintenance problems...


                        Here is a little example of DDA usage (not tested... and not even compiled... so there may be, at least, some syntax issues...) based on Laurent's post :


                        #======== DDA Definition
                          MY_DDA ISA DATA DEFINES
                            # Criterias
                            match_d_TWS_Alert: STRING, default='%s'; # %s means any string for match operator

                            # New values
                            val_mc_object_class: STRING;

                        #======= Rule using DDA
                        refine myrule :
                        using {
                          MYDDA ($DDA)
                          where [
                                    # using match rather than equals... a bit slower but quite usefull
                                    $EV.d_TWS_Alert matches $DDA.match_d_TWS_Alert





                              mc_object_class: STRING;
                        • 9. Re: MRL syntaxe question (case XXX in XXX)

                          The fact that MRL is prolog-based doesn't necessarily mean that it hat performance problems with if-then-else... I think, accessing a DDA also wouldn't be an easier action in Prolog than a simpe if-then-else...


                          I've never seen a suggestion "avoid if-then-else whenever possible" in BMC documentation.


                          I have rules with 20 and more nested if-then-else constructs, and they run without problems (and even without any performance impact). So even Prolog may not have a construct like this, there are no problems when using it in MRL.


                          Having 20 rules instead would result in maintenance problems, and in case of program faults, would mean to trace 20 rules instead of one. And AFAIK processing more rules is more expensive than less since all rule's ECF must be re-evaluated for each event.


                          But of course, you're right that there are situations where a DDA is a better choice than a nested if-then-else. However, it's not always a replacement for DDA.

                          • 10. Re: MRL syntaxe question (case XXX in XXX)

                            Hello again,


                            Actually, I strongly beleive that accessing a DDA is more efficient that building a (nested) if-then-else because of the way Prolog is "searching for a solution".


                            There is a quite interresting document here : The specified item was not found.. It gives some interresting performance tips & tricks, including avoiding (when possible / realistic) if-then-else. It is true that this is not documented in "official" documentation... silly, isn't it ?


                            Unfortunately, it seems that this document is not publicly available. You may want to ask BMC if you can get it though.


                            Anyway, it is just the way I would do it ;-)



                            • 11. Re: MRL syntaxe question (case XXX in XXX)
                              Jon Trotter

                              Hi Jean-Sébastien,


                              Thanks for posting this link. Some of the images were not available in the slide presentation, but very good read.  There was only one slide on the if/then/else, simply stating to avoid it, so I'm sorta with others as to the questions about the purported inefficiencies of it. Regardless, hopefully it will lead me to write better MRL.


                              EDIT:  Didn't scroll down far enough to see the PDF download. I can see all the images in the doc.

                              • 12. MRL syntaxe question (case XXX in XXX)

                                Hey Guys,


                                Thank you verry much for all your help.