Setting PDQ inside an SPL - local scope? - shell

Question

In order to fine tune allocation of PDQ resources depending on the time of day that batch jobs run, we have a utility that sets PDQPRIORITY based on some day of week / hour of day rules, eg:
PDQPRIORITY=$(throttle); export PDQPRIORITY
However, this is fixed at the time the script starts, so long running jobs never get throttled up or down as they progress. To rectify this, we've tried the following:
CREATE PROCEDURE informix.set_pdq() RETURNING VARCHAR(50);
DEFINE pdq, dow SMALLINT;
DEFINE hr SMALLINT;
LET dow = WEEKDAY(CURRENT);
LET hr = TO_CHAR(CURRENT, '%H');
IF (dow == 0 OR dow == 6 OR hr < 8 OR hr > 14) THEN
LET pdq = 100;
SET PDQPRIORITY 100; -- SET PDQ does not accept a variable name arg.
ELIF (hr >= 8 AND hr <= 10) THEN
LET pdq = 40;
SET PDQPRIORITY 40;
ELIF (hr >= 11 AND hr <= 12) THEN
LET pdq = 60;
SET PDQPRIORITY 60;
ELIF (hr >= 13 AND hr <= 14) THEN
LET pdq = 80;
SET PDQPRIORITY 80;
END IF;
RETURN "PDQPriority set to " || pdq;
END PROCEDURE;
At various intervals throughout the SQL, we've added:
EXECUTE PROCEDURE set_pdq();
However, although it doesn't fail, the scope of the SET PDQ seems to be local to the SPL. onstat -g mgm doesn't report any change to the original resources allocated. So adding these set_pdq() calls doesn't seem to have had any effect - the resources allocated at the program start remain fixed.
The code is embedded SQL in shell, ie:
dbaccess -e $DBNAME << EOSQL
SELECT .. INTO TEMP ..;
EXECUTE PROCEDURE set_pdq();
SELECT .. INTO TEMP ..;
--etc
EOSQL
So backticks or $( ) interpolation occurs at the start of the script, when the here document gets passed to dbaccess. (That eliminated the obvious: SET PDQPRIORITY $(throttle);)
Wow, that got wordy quickly. Can anyone suggest any way of achieving this that doesn't involve rewriting these batch jobs completely? Breaking the SQL down into smaller pieces is not an option because of the heavy reliance on temp tables.

Answer 1

As you will have deduced from the inordinate delay between the time when you asked the question and the first attempted answer, this is not trivial.
Part of the problem is, I think, that PDQPRIORITY is captured when a stored procedure is created or its statistics are updated. Indeed, that may be all of the problem. Now, temporary tables cause another set of problems with stored procedures - stored procedures often need reoptimizing when temporary tables are involved (unless, possibly, the SP itself creates the temporary table).