IV98839: COMMIT, REFRESH, OPEN CHANGE STATUS DIALOG ARE SLOW IN GRAPHICAL SCHEDULER DUE TO SELECT RUNNING SEVERAL TIMES

APAR status

• Closed as program error.

Error description

• When the user does a Commit, a Refresh or opens the Change
  Status dialog box in Graphical Scheduling this SQL select is
  run several times, sometimes we have seen it 5 times in the
  logs:
  
  select count(*) from wplabor wl, skdactivity act where wl.craft
  is not null and act.id = ('WORKORDER_' || wl.wonum || '_' ||
  wl.siteid || '_' || wl.orgid)  and wl.orgid = 'EAGLENA'and
  (act.objectid) in (select workorderid from  workorder  where
  wonum=wl.wonum and workorderid = act.objectid and
  act.skdprojectid =  287 and act.objectname = 'WORKORDER')  and
  wl.wplaboruid not in (select objectid from skdreservation where
  skdprojectid = 287 and objectname = 'WPLABOR')
  
  In one case it took over 10 seconds each time it ran so in the
  end over 30 seconds was spent running this one select.   We
  should change the Scheduler to run it only one time.   We
  should save the results if other parts of the function (Commit,
  Refresh or opening the Change Status dialog) need to use those
  results again.
  
  Steps to reproduce:
  1. Turn on Logging so you can see how often this select is run.
    Usually in the Logging application I set:
   SCHEDULER to Log Level DEBUG
   SCHEDULERSQLto Log Level DEBUG
   'sql' to Log Level INFO
  2. Save your Logging settings and Apply Changes.
  3. Open any Schedule in Graphical Scheduling (GS) or create one.
  4. Click on the Gantt View tab.
  5. Choose either Change Status, Refresh Schedule or Commit
  Changes from the Common Actions menu.
  6. Note the time you did number 5.
  7. When it is done, gather the SystemOut logs and search for
  "from wplabor" and see how many times you find the SELECT COUNT
  (*) FROM WPLABOR in the log.
  
  You will see if several times.   That is the problem, it should
  be in the log only one time.   Or perhaps we do not even need
  to run this select at all.
  
  The was found in 7.6.0.5, reproduced in 7.6.0.6 and development
  says it is in all versions, even 7.6.0.9 being developed now.
  

Local fix

• (none)
  

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  * maximo scheduler users                                       *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  * When the user does a Commit, a Refresh or opens the Change   *
  * Status dialog box in Graphical Scheduling this SQL select is *
  * run several times, sometimes we have seen it 5 times in the  *
  * logs                                                         *
  ****************************************************************
  * RECOMMENDATION:                                              *
  * Apply fixpack  Release 7.6.0.9 of Base Services or request   *
  * an interim fix                                               *
  ****************************************************************
  

Problem conclusion

• Fix has been made to fix....The fix for this APAR is contained
  in the following maintenance package:
  		 | release\fix pack\interim fix for  Release 7.6.0.9 of Base
  Services
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  MAXIMO SCHEDULE

• Fixed component ID

  5724R46SE

Applicable component levels

• R763 PSY

     UP