In Warehouse Manager Resource Settings Part 1, you were shown the various options you can select to control the way users can run Query and Report Writer. That article guided you through accessing the resource settings, explained the choices available to you, and then applied them to a user or group profile. This article will focus on the parameters used when running in batch mode. In particular, it will attempt to explain how the use of the job description can control batch mode operations.
Once you have double-clicked on a user or group profile to enter the Resource Settings dialog, you can go to the Query Limits tab to see the first options that can affect batch mode execution. You can limit the profile to run in interactive mode, batch mode, or allow them to select the mode. Regardless of whether you restrict them to batch mode only or allow them to select the mode themselves, the following settings will apply any time batch mode operations are used.
The Batch Limit option allows you to set a time limit that will be checked before a batch query is submitted for execution. The Query Optimizer estimates the time the query is expected to take; and that estimated time is checked against this setting to see if the query should be submitted. In many instances, the estimated time may be inaccurate for a number of reasons. This may prevent some queries from executing that may complete within the time limit. Also, if the estimated time permits a query to start, this batch limit setting is not checked during execution and has no effect on ending a query that may exceed the limit. As you'll see, this type of problem can be addressed by settings in the job description.
The Batch Priority setting controls the priority of the batch query when it is submitted, where a lower number indicates a higher priority. The default value used for batch queries is 50, which is the standard for batch jobs in general. The Batch tab allows you to control whether or not a profile is permitted to save query results to a file on the iSeries. If this is permitted, you can still limit the user to saving results to a specific library only, as well as restrict the authority that other users will have to a table that this user creates. If no selection is made, the user will be able to control the authority for each table he or she creates.
The Batch Job Information section allows you to select a specific job description to be used by this profile. When used together with a routing entry and a class to control the job run attributes, there are several important items that can be effectively controlled by the selection of an appropriate job description. Among these are the job queue selection, the maximum CPU time, and maximum temporary storage the job can use before the job is ended by the system and the job run priority. By default, Query and Report Writer batch jobs use the QDFTJOBD job description, which typically directs the jobs to run on the QBATCH job queue. There may be reasons why you would want to direct these jobs to a different job queue - for example, to prevent possible conflicts with other system batch processing. Also, by default, these jobs will typically pick up run attributes that include unlimited CPU time and temporary storage. You may wish to limit either or both of these attributes. The steps below will show you how to set up a job description, a class, and a routing entry to set the attributes you prefer to use for queries and reports run in batch mode.
The CPUTIME parameter of the Job CLASS is used by OS/400 as the maximum time limit that any executing job is allowed to run. If a job consists of multiple routing steps, then each routing step is allowed to use this amount of CPU time.
Follow these steps to restrict batch query jobs to a maximum amount of CPU processing time.
- Create a new CLASS
CRTCLS CLS(mylib/newcls) RUNPTY(20) TIMESLICE(500) CPUTIME(#######) CRTCLS CLS(mylib/newcls) RUNPTY(50) TIMESLICE(5000) PURGE(*NO) DFTWAIT(120) CPUTIME(#######)
Specify the desired CPUTIME limit in the range of 1 to 9,999,999 milliseconds. Note: Except for the CPUTIME value, the first example will create a class that is a duplicate of the one normally used for query sessions (QGPL/QWCPCSUP). The second will create a class that is a duplicate of the QBATCH class in QSYS.
- Identify a subsystem and job queue where you want the query jobs to run. Ensure that the job queue has a job queue entry in the subsystem.
- DSPSBSD library/sbs description Opt. 6 - Job queue entries.
The SCTCP job queue in the subsystem where Showcase Strategy normally runs may be used. A job queue in the QBATCH subsystem may also be considered since the changes being made are to apply to batch queries only.
- Use ADDJOBQE if necessary to add the job queue to the subsystem description. ADDJOBQE SBSD(mylib/sbsd) JOBQ(mylib/newjobq) MAXACT(*NOMAX) SEQNBR(##)
Ref#: 1479238
