IV69806: ACM7501 - ASSETTRANS DATEMOVED VALUES BEING RECORDED INCORRECTLY

APAR status

• Closed as suggestion for future release.

Error description

• PROBLEM:
  
  ACM7501 - ASSETTRANS DATEMOVED values being recorded incorrectly
  
  ENVIRONMENT:
  
  App Server IBM WebSphere Application Server 7.0
  Version IBM Maximo Asset Management 7.5.0.2 Build 20120219-2030
  DB Build V7502-00
  IBM Maximo for Transportation 7.5.0.0-20120507-0953 Build
  20110415-1936 DB Build V7500-06 HFDB Build HF7500-02
  Tivoli's process automation engine 7.5.0.2-IFIX20120706-1221
  Build 20120219-2030 DB Build V7502-25
  Mobile 7.5.0.0 Build 20110421-1725 DB Build V7500-07
  Maximo Everyplace 7.5.0.0 Build 20110307-0030 DB Build V7100-01
  IBM Maximo Asset Configuration Manager 7.5.0.1-20121031-0908
  Build BUILD DB Build V7501-09 HFDB Build HF7501-12
  Server OS AIX 6.1
  Server DB Oracle 11.2 (Oracle Database 11g Enterprise Edition
  Release 11.2.0.3.0 - 64bit Production With the Partitioning,
  OLAP, Data Mining and Real Application Testing options)
  (c) Copyright IBM Corp. 2011
  
  STEPS TO REPRODUCE:
  
  Client has been seeing more and more occurrences where mileage
  does not flow down from a parent ?A-Car? to the child ?B-car? or
  to their children at various hierarchical levels.
  The cause of this has consistently been found to be a
  ?hyperspace? in the move history (ASSETRANS table).
  When all is correct, the ?TOPARENT? and ?TOLOC? of one move will
  be the ?FROMPARENT? and ?FROMLOC? of the subsequent move.
  The ASSETTRANS table has two ?times? that get recorded ?
  DATEMOVED and TRANSDATE.
  TRANSDATE is always the actual date and time that a move was
  made.
  DATEMOVED is usually the same as TRANSDATE, but can be
  manipulated to ?backdate? a move (that is, to make it appear as
  if the move took place earlier than when it really did take
  place).
  Maximo ?orders? the ASSETTRANS table by DATEMOVED.
  Sometimes two moves get recorded in ASSETTRANS as having taken
  place at the exact same date/time (down to
  hours/minutes/seconds) ? that is that the DATEMOVED timestamp
  shows two moves happening at the same time, even though
  TRANSDATE shows them happening at different times.
  
  In a recent example observing this happening first-hand, the
  user knows what operations have been carried out, and what order
  was carried them out on.
  One single session of Maximo was open.
  When Maximo sorts ASSETTRANS incorrectly, it determines that
  certain assets are not installed, when they are, or vise-versa.
  It may also be fooled into thinking that an asset is still
  installed in its old position, because it does not see the ?off?
  move.
  It may also be fooled into thinking that an asset is not
  installed because it does not see the ?on? move.
  When Maximo determines that a given asset is parented to car 1,
  it gets the mileage reading that car 1 gets.
  Later, when Maximo is processing mileage for a different car, it
  tries to give a reading to the same asset, but balks at the
  request ? ?You are a bad asset, you already got a reading for
  today!
  What are you doing here trying to get a second reading?
  We?re not only going to punish you, but we?re going to punish
  all your brothers and sisters and parents and not give them a
  reading either!
  
  Prior to when ACM went live , ASSETTRANS was the only means of
  storing move history.
  ACM provides its own table(s) to store move information in and
  seems to take care of them first during any type of moves, then
  attempts to update ASSETRANS as an afterthought.
  On a date, an end-user sent an email stating that asset #12345;
  S/N 23456 (Brake Status Unit) was physically in their repair
  shop SHOP554, but Maximo (ASSETTRANS) said it was in location
  1213 (on parent R3070) as seen below (last line below):
  
  We then used ACM?s install/remove function to remove asset
  #12345 to location ABCD with no parent, and installed asset
  #34567 in its place.  We then did the opposite, removed asset
  #34567 to location SHOP554 with no parent, and installed asset
  #101010.
  This fixed the situation with the asset the end-user was worried
  about, but created a new issue with asset #101010?s move history
  in the ASSETTRANS table.
  
  Both moves were made fairly close together, the first move was
  made at 21 min, 10 sec, and the second less than a minute later
  at 22 min, 41 sec., but Maximo recorded the ?DATEMOVED? as
  having taken place 8 minutes earlier and at the exact same time!
  Maximo ?sorts? the moves by DATEMOVED, and incorrectly gets the
  chronology wrong for those two moves.  The ?hyperspace? that is
  created as a result of this will lead to mileage flowdown issues
  in the future for this asset and whatever car it is mounted on.
  The method we use to correct this type of situation is to
  back-end change the DATEMOVED data for one of the two
  transactions by altering the ?minutes? so that the history will
  sort correctly (chronologically).
  Why is the DATEMOVED value so far from TRANSDATE value?  Why are
  two moves recorded as happening simultaneously which leads to
  many issues?
  

Local fix

• n/a
  

Problem summary

Problem conclusion

Temporary fix

Comments

• In the Assets (CM) application the transaction date does not
  update to the current system date time
  when opening the Install/Remove dialog. A new system property
  mxe.plusa.instremdefaultonow has been introduced.
  If this property is set to true (1) and the As of Date on the
  Asset (CM) View tab has not been modified then the transaction
  date
  will be set to the current system date time when the Install /
  Remove dialog is opened.
  

APAR Information

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

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

Fix information

Applicable component levels