IV31464: THE CATALOG SCHEDULER DOES NOT GENERATE REPORTS AS EXPECTED

IBM License Metric Tool Interim Fix 7.5.0-TIV-ILMT-IF0008
Tivoli Asset Discovery for Distributed Interim Fix 7.5.0-TIV-TAD4D-IF0008

APAR status

• Closed as program error.

Error description

• ### SCENARIO I ###
  
  Let's assume the following scenario:
  
  On 31.10.2012, the customer has the following reports ready in
  the system:
  
  01.01.2012-19.09.2012
  20.09.2012-19.10.2012
  
  He would like to generate reports on weekly basis, starting from
  01.11.2012.
  
  Using the 'Reporting Options' he schedules reports to initiate
  on 01.11.2012 with frequency of 1 week.
  
  The UI suggests that the following reports will get generated:
  20.10.2012-31.10.2012
  01.11.2012-07.11.2012
  
  This is the expected behaviour.
  ---------------------------------------------------------------
  
  What happens in fact is that the following reports get
  generated:
  
  20.10.2012-26.10.2012
  27.10.2012-02.11.2012
  
  This is the unexpected behaviour. The scheduler ignores the
  initiation date, and simply applies the report frequency period
  regardless of the intended start date.
  
  
  
  
  
  ### SCENARIO II ###
  
  A)
  1. Schedule a three-months report such that the first report
  does not have the duration of three months.
  2. Wait for the target date to come and confirm the report not
  generated.
  
  B)
  1. Schedule a one-week report such that the first report does
  not have the duration of one week.
  2. Wait for the target date to come and confirm the report not
  generated.
  
  
  
  
  
  ### SCENARIO III ###
  
  Tested between 19-23 XI:
  
  1)
  There were 'SIGNED' reports till 23 IX and one 'READY' till 23
  X. Despite the monthly schedule there was no 'RUNNING' report
  from 24 X till 23 XI.
  
  2)
  The 'READY' report was removed, the scheduler frequency setting
  was modified to 1 day and the server was restarted. In result,
  immediately after the server startup and aggregation there were
  multiple 1-day
  reports generated and covering the time window from 24 X till
  the present day (the last report was 'RUNNING'). There was a gap
  left and covering the 24 IX - 23 X period.
  
  3)
  Daily reports were then removed and the reporting frequency was
  modified to 1 month and the server was restarted. No
  effect/change after data aggregation. Only signed reports
  showing.
  
  4)
  Server and DB2 were stopped. The system date was changed forward
  a couple of days to 21 XI. LMT components were started again. No
  effect/change after data aggregation. Only signed reports
  showing.
  
  5)
  The reporting frequecy was modified to 1 month starting from 21
  XI. LMT components were started again. No effect/change after
  data aggregation. No 'RUNNING' report.
  
  6)
  Finally, server and DB2 were stopped again, the system date was
  set much forward to 25 XII 2012. LMT components were started
  again. Reporting schedule was showing 1 month from 21 XI till 20
  XII. Server started to aggregate data (CODBL0004W) but there was
  no running report. When the aggregation warning (CODBL0004W)
  reached and passed the 21 XI (so the reporting schedule) there
  was no 'RUNNING' report. Finally when the aggregation ended,
  server produced a 'Non-coninous' report 21 XI - 20 XII and
  reporting schedule was showing 1 month from 21 XII till 20 I.
  The gap 24 IX - 20 XI was not filled in.
  
  
  
  
  
  The scheduler feature needs to be reworked as giving random
  results depending on many factors.
  

Local fix

• Use manual reports when/if necessary.
  
  Create manual report to fill the gap between the last report and
  the desired initiation date.
  

Problem summary

• ****************************************************************
  * The catalog scheduler does not allow to generate reportes for
  * expected period. Behavior of the scheduler should be the same
  * as it was provided in 7.2.2 FP2
  ****************************************************************
  * RECOMMENDATION: Apply appropriate interim/fixpack when
  * available.
  ****************************************************************
  

Problem conclusion

• The fix for this APAR is contained in the following maintenance
  packages:
   | Interim Fix | 7.5.0-TIV-ILMT-IF0006
   | Interim Fix | 7.5.0-TIV-TAD4D-IF0006
  

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

  LICENSE METRIC

• Fixed component ID

  5724LMT00

Applicable component levels

• R750 PSY

     UP