2 replies Latest Post - ‏2013-04-04T19:31:42Z by tmparker
312 Posts

Pinned topic recolimit bug

‏2013-02-07T20:55:28Z |
The documentation in the Advanced macro guide give the following syntax for the <recolimit> element

<recolimit> element   The <recolimit> element is an optional element that occurs within a <screen> element, at the same level as the <description>, <actions>, and <nextscreens> elements (see Recognition limit).   The <recolimit> element allows you to take action 

if the macro runtime processes the macro screen in which 

this element occurs more than some specified number of times. Attributes   value Required integer. The recognition limit. If the macro runtime recognizes the macro screen 

this many times, then the macro runtime does not process the actions of 

this macro screen but instead performs the specified action.   

goto Optional string (the 

default is 

for the macro runtime to display an error message and terminate the macro). The name of a macro screen that you want the macro runtime to start processing when the recognition limit is reached.   XML samples   Figure 111. Example 

for the <recolimit> element   <recolimit value=
"1" goto=
"RecoveryScreen1" />

However, if I try to use the goto parameter neither the Advanced Editor or the VME recognize it as valid. If I leave it there it throws an an HPS6112 error at runtime.

I really wish to use this option to capture out of control looping. My primary use would be to capture and trace key information that is causing the loop to the system log without running a trace.

This information in in the HOD macro guide and in all HATS documentation since v7.5. I've tried it in HATS v7.5 and v8.5 at their latest levels and it fails everywhere.

On a whim I changed from goto to GoTo and to *Goto*I did not get an error message from either of the editors; however, when I run the macro I get the same HPS6112 error.

Is there some magic to getting this function to work?
Updated on 2013-04-04T19:31:42Z at 2013-04-04T19:31:42Z by tmparker
  • george.baker
    312 Posts

    Re: recolimit bug

    ‏2013-04-04T19:26:38Z  in response to george.baker
    I tried once again to recreate a failing test case only to determine that I had originally inadvertently added the <recolimit> statement within the <actions>.

    The documentation clearly states that it is at the same level as <actions>, so I moved the statement outside the <actions>, specifically just above the </screen> statement.

    It now works perfectly.
    • tmparker
      518 Posts

      Re: recolimit bug

      ‏2013-04-04T19:31:42Z  in response to george.baker
      Hi George,

      You will need to open a PMR for us to get this fixed in an APAR. More than likely this issue would be in the HOD code and a PMR would be the only way HATS would have the ability to change the HOD code.