Possible performance impact on large production plans after JnextPlan

This problem might occur on environments with production plans running around hundred thousand jobs.

Symptom:

After the removal of the production and pre-production plans using the ResetPlan -scratch command and the creation of a new plan using the JnextPlan command, CPU utilization on the database server is high, around 95% or 100%, for as long as the application server logs the following message:
AWSJPU009W The following event "event type" 
for "scheduling object" has been skipped.

During this time, scheduling information about jobs and job streams displayed by the Dynamic Workload Console might not be updated for several minutes, and the actual start time for jobs and job streams might be delayed.

Cause:

The commands for removing a plan (ResetPlan -scratch) and creating a new one (JnextPlan) do not remove events related to the deleted plan from the message queues. Right after the new plan is created, the application server processes all the events related to the previous plan just deleted. For large production plans (in the range of hundred thousand jobs), there might be several thousand events to process, and this processing could take several minutes, some times more than one hour, to complete.

Solution:

Wait for the application server to process all the events related to the deleted plan. The processing is completed when message AWSJPU009W is not logged anymore in application server logs. The duration of this processing is proportional to the number of jobs in the production plan.

If your production plan contains several thousand jobs, consider creating a new plan defining a future start time (using the JnextPlan command with the -from argument) to allow enough time for both the completion of the JnextPlan command and the processing of all the events related to the previous plan. This ensures the information displayed by the Dynamic Workload Console and the start time of jobs and job streams are not affected.