The difference in the value of the run priority of some Connect CDC Kernel threads in the Work with Threads display and what is displayed in the WRKSYSACT command is a result of the IBM i system dynamically changing the run priority from time to time (for a short time slice) as a normal result of its management of concurrently running jobs.
Work with Threads Example
WRKSYSACT Display
This is not related to Java threads, and Connect CDC has no direct control over it. The IBM i system control program dynamically changes run priorities to optimize concurrent processing. The actual default assigned run priority is NOT changed as one can see in the Work with Threads display.
Press F1 on the PTY value displayed in the WRKSYSACT command to get a short citation of the behavior. This command lists all the active threads for all active jobs in order of CPU utilization from highest to lowest
The Dynamic Priority Scheduling is a feature of the IBM i and is totally independent of Connect CDC (see the IBM documentation for additional information). Threads that a job spawns run at a priority at or below the job's main thread. The system can dynamically change the priority of a job. This priority is defined as “The priority at which the job or task was running when performance statistics were collected.” It also states, “You may notice a low-priority job having its priority temporarily raised to a higher priority. This occurs when the low priority job has a seize/lock on an object to which a higher priority job needs access. The lower job priority is temporarily increased to release the seize/lock for the other job sooner. The original priority is automatically restored when the seize/lock is released or when a lock wait time-out occurs.”
A seize/lock according to IBM is essentially a wait. From time to time, the system momentarily dispatches a thread at a higher priority to manage locking associated with waiting.
Dynamic Priority Scheduling is the normal IBM default as opposed to fixed priority scheduling. With Dynamic Priority Scheduling, there is no guarantee that the default priority will be fixed throughout the life of the job and the threads that it spawns.
The run priority determines how much processor a job gets. It ranges from zero (highest priority) to 99 (lowest). Zero priority is OS level priority and can cause interactive jobs (20) to be held while it takes over the system.
According to IBM documentation, the assignment of run priority, as opposed to job queue priority and output priority, is normally set to “50” for batch jobs. Generally speaking, when a job starts, the system dispatcher from the class object associated with that job assigns the run priority. There are system classes that would assign that priority by default if the job is running in the default batch subsystems (e.g., QSYSWRK, QBATCH, etc.). Users can “reset” these. However, since Connect CDC has its own subsystem with its own class (OMNIREP *CLS), Connect CDC jobs would get their initial run priority from this class object. By default, this would/should be 50. To determine what the default priority, issue the following command:
DSPCLS CLS(<library>/OMNIREP)This displays what the run priority is set to for the Connect CDC jobs. If you do NOT prefer this default, then issue a “change class” command to change the value in accordance with your run priority policies. Enter the following command at the green screen command prompt:
CHGCLS CLS(<library>/OMNIREP)Press F4 to access command prompt mode
Then set the run priority.
When the OMNIREP subsystem is installed with the OMNIREP class, the installer does NOT create the OMNIREP class with a default run priority. The user can manually change the class in the library where the subsystem was installed. This only needs to be done once.