IBM Support

Use PERL_MODE to avoid performance issues caused by the Hide Actions feature

Preventive Service Planning


Abstract

The Hide Actions feature is used to hide record actions from users that do not have permission to execute them. In a complex schema, especially with many base action access control hooks, the overhead of checking action permission can cause performance issues.

Content

A new schema property is available to address this issue for schemas using Perl as the hook language. The schema property is named PERL_MODE. When this schema property is not defined or has a value of "0", the behavior is unchanged and the Hide Actions performance problem may occur. When PERL_MODE has a value of "1", hook execution is faster because the Perl interpreter is configured for all the action hooks at once, which allows the same interpreter to be used for all the action access control hooks that need to be fired. This saves the overhead of setting up the Perl interpreter for every hook that needs to be called.


The PERL_MODE schema property is set with the "packageutil setproperty" command. The current value of this property can be read with the "packageutil showproperties" command. To remove the property, set its value to an empty string. Be sure the schema is not open in the designer when running the "packageutil setproperty" command.

Note: The use of the packageutil command is solely supported for the above described purpose.

For example, to use the packageutil command to set the PERL_MODE property in the DefectTracking schema in the schema repository for the dbset named "Alpha", use the following command:


packageutil setproperty -dbset Alpha admin "" DefectTracking PERL_MODE 1 -nocheckin

This example shows the best-practice of using the "-nocheckin" option. This allows the changed schema to be tested using the Test Work function before it is checked in.

IMPORTANT: There is a side effect on global hooks when the PERL_MODE feature is enabled. A global hook can contain any Perl code, including variables and subroutines. The variables in the global hook section are initialized when a Perl interpreter is first created. When PERL_MODE is enabled, the interpreter is created once and may then be used multiple times to run different hooks. Those global variables will therefore be initialized just once, and the value may still exist when the next hook is called. This will happen for some hook execution cases, but not in every case, since some cases require an entirely new Perl interpreter to be created.

For example, suppose you have global hook code with a global variable and a subroutine as shown below. Each time the GetCurrentDate subroutine is called, the global $counter variable will be incremented and the new value may exist the next time the subroutine is called.


# Start of Global Script GetCurrentDate

my $counter = 0;


sub GetCurrentDate
{
    $counter++;
    $session->OutputDebugString("GetCurrentDate has been called $counter times");

    my ($sec, $min, $hour, $mday, $mon, $year, $wday, $yday, $time) = localtime();
    return sprintf("%4d-%2.2d-%2.2d %2.2d:%2.2d:%2.2d",
              $year + 1900, $mon + 1, $mday, $hour, $min, $sec);
}

# End of Global Script GetCurrentDate

In the example, the purpose of $counter is to count how many times GetCurrentDate is called.



With the default Perl behavior, the value of $counter will start as zero each time any hook is fired, since the Perl interpreter is initialized for each hook. Thus, it will accurately count the number of calls for all the Perl code that executes as a result of firing just one hook.

When PERL_MODE is enabled, the Perl interpreter may be used for more than one hook, without being reinitialized in between. That means the value of any global variable will persist from one hook to the next. As a result, $counter will instead count the number of times GetCurrentDate is called for more than one hook.

Any global hook code that declares a variable outside of a Perl subroutine will be affected by this difference. Whether or not that impacts schema behavior depends on how the schema uses those global variables.

Before enabling PERL_MODE, global hook code should be inspected to see if any global variables are used in a way that would be dependent on this behavior. To properly handle using PERL_MODE, any global variables should be initialized dynamically in a global subroutine or a specific hook function (such as an action initialization hook), not just by an expression that provides an initial value for the global variable. That will guarantee both that the variable is properly initialized for each use and that any value remaining from a previous hook execution is not accidentally reused.

[{"Product":{"code":"SSSH5A","label":"Rational ClearQuest"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"Documentation","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"}],"Version":"8.0.1.8","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
17 June 2018

UID

swg21959389