PM73536: [wi 73620] RAM - policy is executed without following its timer's schedule

Rational Asset Manager Fix Pack 2 (7.5.1.2) for 7.5.1

APAR status

• Closed as program error.

Error description

• When a policy timer is set for 2 days, RAM server will execute
  the timer every day at 10:30 PM EST.
  
  
  
  Steps to reproduce the issue:
  
  Requirement:
  RAM's admin account
  RAM repository MUST connect to a working SMTP server
  
  1. RAM ? Administration ? Master Lifecycles
  2. New Master Lifecycle? ? Select Standard ? Create a new Master
  Lifecycle
  3. Create a new community (i.e 'user's defect')
  4. Create a new asset type (i.e 'defect')
  5. Go to the new community ?  Lifecycles ? New Lifecycle? ?
  Select the new Master Lifecycle
  6. Next ? Select Review state ? Add 2 Default Polices ? Send
  Email
  7. Set one a timer for each of the policies: 1 day and 2 days
  accordingly
  
  (use all default settings - you can add a short description to
  the policy's email body.)
  
  8. Submit an asset using the new asset type and the new
  community
  9. Manually move the asset to the Review state
  
  Result: RAM will trigger the 2 policies each day - see attached
  picture.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  There is a bug in the addTimerPolicies() method in
  AssetLifecycleManager. This is called on every asset's
  lifecycle update or asset update.
  
  The bug is that for every timer policy for the current state
  the metric for the policy is searched for. If not found then
  a metric will be created for x days in the future (as
  defined by the policy configuration). The bug is that if it
  is found it is updated, but it is reset to run that night of
  the update instead of the future.
  
  The addTimerPolicy is called from two different places and
  times in the asset's life. One time is on each asset update,
  the other time is when the asset's lifecycle is updated (not
  the asset itself). (Interesting note here, this is only on a
  direct update of the asset's lifecycle. It is not called if
  the timer policy change had occurred at the community or
  master lifecycle. In this case it won't be processed until
  the next asset update.)
  
  The question is what to do when:
  
  i) Asset update. Options are that on each update the policy
  is set that far in the future, or only on asset entering
  state will it be set that far in the future. If it is just a
  simple update then the metric would be left alone since it
  is already set correctly from the previous state entry. The
  mixed consensus was that most people will think the timer is
  for only state entry and not on each update.
  
  ii) Lifecycle update. This is tricky. If this is a new
  policy for the state due to the update (i.e. no metric)
  found, then presumably the time will be from then since we
  don't know state entry. But what if the metric is already
  set. We don't know if the time was changed in the lifecycle
  update. If it was changed then should the metric be changed.
  If it wasn't changed then definitely the metric should not
  be changed.
  

Problem conclusion

• Duplicate timer policy configurations are now removed on
  save
  

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

  RATL ASSET MGR

• Fixed component ID

  5724R4200

Applicable component levels

• R751 PSN

     UP