Db2® HPU uses OMVS threads for any batch
processing. Each Db2 HPU step (EXEC statement)
launches a single OMVS process that is closed when the Db2 HPU step ends. This process is launched on behalf
of the UID associated to the userid of the submitter of the job that includes the Db2 HPU step.
Consequently, the settings of some z/OS Unix parameters have an impact on the Db2 HPU jobs as described below. Take these impacts
into account to choose settings that meet your requirements in terms of Db2 HPU use.
- MAXTHREADTASKS
- This parameter has an impact on the maximum parallelism degree allowed for a single OMVS
process thus for a Db2 HPU step.
- The number of threads needed for an unload strongly depends on the processing mode and is much bigger for the unload processes run in native mode.
- For the native mode, the number of threads needed by Db2 HPU can be computed with the help of following
rules:
- 20 base threads always used per unload statement and,
- for every partition unloaded in parallel
- 2 threads always used
- 1 thread if the data is unloaded from an INLINE image copy
- 2 threads if ZIIP mode is enabled
- 1 thread if a SORT process is involved
- 1 thread for every LOB column to unload
- 4 threads for every XML column to unload
- 1 thread if SPANNED YES is requested
- For example, for an unload, run in native mode, from a partitioned table space with no LOB or XML to be unloaded and partition parallelism set to 50, the number of threads needed is 20 + 50 (2 + 1) = 170 threads.
- The MAXTHREADTASKS parameter should be set to a value greater than or equal to the number
of threads needed for the more demanding of your unload steps in terms of threads. A
rough and very likely oversized (unless you have objects with a large number of LOB or
XML columns) estimate based on the number of partitions of the table space to unload is
given by the following formula: 20 + partitions_number * 12.
- For unload steps with several unload statements and table space parallelism enabled (via the third argument of the PARALLELISM option VUX030/UTLPARAL PARMLIB parameter), the contributions of the table space processed in parallel must be added to compute the number of threads of the step.
- The MAXTHREADS parameter's value has to be equal or higher (preferably higher) than the MAXTHREADTASKS value.
- MAXTHREADS should be set at least 2 times higher than the MAXTHREADTASKS value.
- MAXPROCSYS and MAXPROCUSER
- The number of Db2 HPU steps that can be run
concurrently is limited by the following rules:
- the number of Db2 HPU steps,
regardless of the userid of the submitter of the related job, does not exceed the
value set for MAXPROCSYS
- the number of Db2 HPU steps in jobs
submitted by userids associated with the same z/OS Unix UID does not exceed the
value set for MAXPROCUSER
- The actual limit set by the second rule depends on:
- the way z/OS userids are associated with z/OS Unix UIDs
- the dispatching of jobs submitters
- The limit increases whenever:
- the number of involved UID increases
- the distribution of jobs among UID is flatter
- For a strictly flat distribution, i.e. each UID is associated to the same number of
Db2 HPU jobs, the maximum number of
Db2 HPU steps that can be run
simultaneously is given by the following formula ; min (MAXPROCSYS,
number_of_UID_involved * MAXPROCUSER). The number of jobs that can actually be run in
parallel can be less than this value if other programs use z/OS Unix processes or if the
outage of another shared system resource occurs.