Re: Testing / managing SMP parallel processing degree

Jim Damato wrote:

<<SNIP>>

Does anyone know a way to control the SMP query degree setting at a level that is less granular than job, but more granular than the system? We want to test a number of job streams. Many of these jobs submit dozens of jobs of their own. I don't want to have every job on the system running with an *OPTIMIZE value for query degree, but I can't possibly manage to hit every job or CL job stream I'd need to reach in our test.

Some thoughts.

IMO the application has a problem [in its design\coding] if there is not the ability to ensure finding all work\jobs activated and by what. That issue should probably be pursued irrespective of how the test is eventually worked out. The application program(s) should of course be able to set whatever attributes for its threads\job that it desires, for the length of time it desires. For example, if the submitted jobs are CALL of CL wrappers, the easiest is to modify each of those programs to make the decision for what they run; it could be an application data area that each checks to determine the library name of the QAQQINI file to use. The application program(s) may instead be submitting the jobs of CALL requests directly to various [non-wrappered] query programs, so possibly instead look at job routing.

Routing data and routing program. This is probably ideal, because an application should already be using its own work management; thus simply tweaking the already established JOBQ,SBSD,JOBD,etc. could have just one changed routing program. If not by specific routing data, then even if there is something about the submitted job [e.g. user or job name] could identify which jobs should run with a specific setting, establish a replacement routing program for the current default routing. That routing program would first perform the desired CHGQRYA, according to whatever is the defining characteristic for activating that CHGQRYA, before TFRCTL to QCMD.

Another option [subpar choice IMO] is to use the Query Governor Exit program for QRYTIMLMT [i.e. established by QQRYTIMLMT sysval] forced to zero, to enable a similar decision as a generic routing program might. Ideally all other jobs would be established to increase their time limit to avoid the exit program entirely; obviously more complex, if the query time limit and\or the exit program is already being utilized.

I do not recall if there is a restriction on CHGQRYA JOB(another) for a job that is either on a JOBQ or which is held, but the programs which issue SBMJOB could retrieve the *LAST message and then issue a CHGJOB on the job that was just submitted. Might be possible to HLDJOBQ first, then issue the CHGQRYA before RLSJOBQ, to ensure the CHGQRYA is enabled since the job being routed [like w/ routing program].

I presume, at least hope, that the Database Open Exit program runs before the database open feature actually establishes the QRYDEGREE for the open it is about to perform. If so then another possibility is to use that exit program to make the decision and set the query attributes according either to similar criteria that might be used for the Query Governor, or even with the file name being opened. This exit program is also IMO subpar choice for use.

Regards, Chuck