Topic
  • 3 replies
  • Latest Post - ‏2013-06-25T20:31:31Z by krmilligan
S1AW_Gene_Schumacher
2 Posts

Pinned topic QSQSRVR RUNPTY and TIMESLICE

‏2013-05-20T16:04:23Z |

Hello Kent,

We are just migrating to a new version of Oracle OneWorld and IBMi V7R1 so I am getting my first exposure to QSQSRVR jobs, my limited understanding of the job is that they handle the DB2 workload for "parent" jobs.  I'm an old school system 38 guy so my guess is that this throws a wrench in work management tracking of CPU cycles among other things.  I have just reading your 2010 article "Tracking DB2 QSQSRVR Job Usage Just Got a Lot Easier", a very good article but I have a follow-up question.

 

For purpose of discussion my job running in QBATCH has the standard batch attributes of RUNPTY(50) and TIMESLICE(5000), now the job starts DB2 work which is handed off to a QSQSRVR job, that job prestarted with class QSYSCLS20 with RUNPTY(20) and TIMESLICE(2000), so now my batch job is running with an interactive timeslice and affecting the interactive workload, which is mostly QZDASOINIT JDBC.  This seems to be contradictory to  separating workloads.

 

My question is;  Is there a way to make the QSQSRVR job adopt the RUNPTY and TIMESLICE of the parent job?

 

Thanks very much for your consideration.

  • krmilligan
    krmilligan
    450 Posts

    Re: QSQSRVR RUNPTY and TIMESLICE

    ‏2013-05-20T16:14:54Z  

    The easiest way would be to run the QSQSRVR jobs in the same subsystem as the parent jobs.

    http://www.mcpressonline.com/tips-techniques/database/techtip-grab-control-of-the-db2-qsqsrvr-jobs.html

     

    If the user profile that establishes the QSQSRVR connection has *JOBCTL user special authority, DB2 will inherit the run priority from the application job and use that value for the life of the connection in the QSQSRVR job.  DB2 does not inherit the timeslice.

     

  • S1AW_Gene_Schumacher
    2 Posts

    Re: QSQSRVR RUNPTY and TIMESLICE

    ‏2013-06-25T17:58:54Z  

    The easiest way would be to run the QSQSRVR jobs in the same subsystem as the parent jobs.

    http://www.mcpressonline.com/tips-techniques/database/techtip-grab-control-of-the-db2-qsqsrvr-jobs.html

     

    If the user profile that establishes the QSQSRVR connection has *JOBCTL user special authority, DB2 will inherit the run priority from the application job and use that value for the life of the connection in the QSQSRVR job.  DB2 does not inherit the timeslice.

     

    Thanks for the reply Kent although it seems like that is only half of the solution.  I used to be able to tune the system by putting the QUSRWRK subsystem in it's own *SHRPOOL but this seems like a much more complex option if it can be done at all.  I'm wondering if;

    • I could move these prestart jobs to QUSRWRK?
    • There would be a way to separate the JDBC(QUSRWRK) workload from the QBATCH workload?  Putting QBATCH in it's own *SHRPOOL will no longer get it done as both of these job types will use the same QSQSRVR for DB activity.

    Thanks for your consideration.

    Gene

  • krmilligan
    krmilligan
    450 Posts

    Re: QSQSRVR RUNPTY and TIMESLICE

    ‏2013-06-25T20:31:31Z  

    Thanks for the reply Kent although it seems like that is only half of the solution.  I used to be able to tune the system by putting the QUSRWRK subsystem in it's own *SHRPOOL but this seems like a much more complex option if it can be done at all.  I'm wondering if;

    • I could move these prestart jobs to QUSRWRK?
    • There would be a way to separate the JDBC(QUSRWRK) workload from the QBATCH workload?  Putting QBATCH in it's own *SHRPOOL will no longer get it done as both of these job types will use the same QSQSRVR for DB activity.

    Thanks for your consideration.

    Gene

    Not sure how QUSRWRK made it into the conversation, but there's a lot of flexibility in 7.1 to move the QSQSRVR jobs to different subsystems:

    https://ibm.biz/BdxQ3z