The parameter table, which is called BMC_DEBUG_PARAMETER, is read by the BEGINCALL procedure and is used to specify which parameter values (e.g. DEBUG LEVEL) apply to which procedures.
Each parameter value can be specified for an individual package/procedure, a particular session using sid/serial number, all sessions for a named user, or for everything.
As the parameter table is read by BEGINCALL every time an instrumented procedure starts, changes can be made to parameter values while procedures are executing, and the changes will take effect immediately. So, for example, a procedure which is producing incorrect results in a live production system can have its debug messages enabled simply by adding a row to the parameter table, and without the need for code changes or code redeployment.
The parameters values stored in the parameter table will be of one of the following types :-
Each parameter type can have multiple entries in the BMC_DEBUG_PARAMETER table, so different values can be applied to different packages or procedures.
The values in the PACKAGE_NAME, PROCEDURE_NAME, SID, SERIAL#, USERNAME and CALL_INFO_LIKE columns are all used to decide which procedures a particular parameter value applies to. A NULL value in any of these columns means that the column is not considered when matching parameter values to procedures.
When matching a procedures details to the entries in the parameter table, matching always starts with the most specific entries, and works back to the least specific entries until it finds a matching row. The combinations of values are considered in this order :-
To illustrate, lets look at some example parameter table entries for DEBUG LEVEL (with blank values being NULL) :-
SQL> SELECT rownum,param_name,param_value,inherit,package_name,procedure_name,sid,serial#,username,comments
FROM bmc_debug_parameter WHERE param_name = 'DEBUG LEVEL';
R PARAM_NAME PARAM_VALUE INHERIT PACKAGE_NAME PROCEDURE_NAME SID SERIAL# USERNAME COMMENTS
- ------------- ----------- ------- -------------------- --------------------- --- ------- -------- -----------------------------------
1 DEBUG LEVEL 0 Y Default debug level
2 DEBUG LEVEL 4 N SCHEDULED_TASKS CUSTOMER_REPORT
3 DEBUG LEVEL 9 N SCHEDULED_TASKS FRED Log in detail all tasks run by FRED
4 DEBUG LEVEL 2 N SCHEDULED_TASKS
5 DEBUG LEVEL 8 N WEB_SEARCH 407 32665 Trying to find a search bug
6 DEBUG LEVEL 3 N WEB_SEARCH Log search terms
With these rows in the parameter table, the resulting DEBUG LEVEL applied to some example procedure calls would be as follows :-
Every parameter must have a row in the parameter table with PACKAGE_NAME, PROCEDURE_NAME, SID, SERIAL#, USERNAME and CALL_INFO_LIKE all set to NULL, as this gives the default parameter value if no other parameter entries match. Not having a default is invalid and will cause error messages to be written to the log table.
The COMMENTS column is free text and can be populated with a description of the reason for applying a certain parameter value.
It is possible to dynamically apply BMC_DEBUG parameter values to procedures, based on the values of the parameters which are passed into the procedures. This is the purpose of the CALL_INFO_LIKE column, which can hold a string which is matched to the CALL_INFO value which is set by BEGINCALL. For more details, see the Using Dynamic Parameters page.
Another important attribute in the parameter table is the INHERIT column, which contains either Y or N. This allows a procedure to pass a parameter value on to all of the procedures and functions it calls, and they in turn will pass it to the procedures and functions they call.
It is important to note is that when BEGINCALL is assigning parameter values, the INHERIT value from the calling procedure is considered before the parameter table is read. This allows a parameter value to be set at a high level and applied to an entire hierarchy of calls, but this can also lead to situations in which parameter values do not take effect when you think they should.
For example, lets say we have a procedure PROCA which calls another procedure PROCB. With the following entries in the parameter table, which DEBUG LEVEL will PROCB be assigned?
SQL> SELECT rownum,param_name,param_value,inherit,package_name,procedure_name,sid,serial#,comments
FROM bmc_debug_parameter WHERE param_name = 'DEBUG LEVEL';
R PARAM_NAME PARAM_VALUE INHERIT PACKAGE_NAME PROCEDURE_NAME SID SERIAL# COMMENTS
- ------------- ----------- ------- -------------------- ------------------------- --- --------- ---------------------------
1 DEBUG LEVEL 0 N Default debug level
2 DEBUG LEVEL 3 Y PROCEDURE PROCA
3 DEBUG LEVEL 7 N PROCEDURE PROCB
The correct answer is that PROCB will run with DEBUG LEVEL set to 3.
The reason is that despite there being a parameter table entry setting DEBUG LEVEL to 7 for PROCEDURE PROCB, the INHERIT flag is Y for the DEBUG LEVEL of its caller PROCA. So when PROCB calls BEGINCALL, that looks at the call stack to see if its caller's DEBUG LEVEL has INHERIT=Y. It does, so it uses the inherited parameter value, and does not read it from the parameter table.
This allows the same parameter value to be applied to all child calls of a procedure, but you need to bear this in mind when trying to apply different parameter values to procedures which call one another.