HD85107: CMP/OMF IR-REG FOR LAST_OBJECT_ID NOT UPDATED

APAR status

• Closed as program error.

Error description

• CMP/OMF IR-REG FOR LAST_OBJECT_ID NOT
  UPDATED
  Customer found a problem that seems to be linked to previous cas
  e (23716,660,706) SCENARIO :
  You need to have 2 users connected to the DB on 2
  PCs to reproduce the problem!
  Below the script:
  1- Connect USER1 and USER2 on 2 different
  machines WITH USER1:
  2- Create a Part A, link it to toto.CATPart and let it
  NEW
  3- Disconnect USER1 and reconnect
  4- Create a Part B which references the same file
  as Part A (toto.CATPart)
  => You get an error 00947 because file is already
  referenced by Part A
  5- Cancel creation of Part B
  6- Create a Part C
  WITH USER2:
  7- Create a Part D
  8- Create a Part E
  => YOU GET AN ERROR 00055 (element already
  exists)
  Add Info from customer: Create Part E follows the
  same mecanism as creating a new version of
  object (Check Out).
  On Check Out there are no error message but a
  rollback is performed, so the Check In data
  becomes locked.
  ANALYSIS OF THE PROBLEM BY CUSTOMER:
  Explanation of the bug, step by step:
  2- User1 books a sequence of 20 OBJECT_IDs and
  use the first one (1 -> 20)
  => LAST_OBJECT_ID is updated (21)
  4- Deleting only the file and not the file catalog
  causes the bug described below
  5- When creating PartB, SmarTeam books a new
  sequence of 20 OBJECT_IDs and use the first one
  (21) but doesn't create the object (21 -> 40)
  => LAST_OBJECT_ID is not updated!!!
  6- When creating PartC, SmarTeam uses the next
  OBJECT_ID booked (22)
  7- When User2 creates PartD, he books a sequence
  of OBJECT_ID starting from LAST_OBJECT_ID not
  updated (21) and is able to create the object
  => This OBJECT_ID has not been already used
  because PartB was not created
  8- When User2 creates PartE, he get the next
  OBJECT_ID (22) but object is not created
  => This OBJECT_ID has been already used by
  PartC creation, SmarTeam cannot create twice :
  Err 00055
  The problem is that 2 users can share a same
  sequence if one of them get errors because of
  referenced objects !!!
  This problem is appearing often and is linked to the
  Check Out problem :
  - Michelin Clonage application is generating lots of
  objects which can be already referenced, if user
  doesn't really care
  The check out problem (23716,660,706) is
  linked to this scenario because on check out
  operation OBJECT_ID is attributed in the same way
  CONCLUSION :
  Michelin wants that LAST_OBJECT_ID table to be
  updated even if there are problems on the creation
  of an object.
  Additional information from customer
  ------------------------------------
  - The information about the SmarTeam level V5R19
  SP03 HF010.
  - The customer's workaround information:
  "1. No workaound possible because we cannot
  follow each user.
  2. Delete manually the trace in the database and
  restart the operation."
  - The customer's fix expectation and justification:
  "It is a strong regression from SmarTeam V5R19.
  The bug really alterates the consistency of the new
  SmarTeam version and generates lot of troubles
  for users:
  - X objects creation forbidden because of duplicate
  message (no value)
  - 50 objects locked in 3 weeks
  We want a correction in a HotFix of SmarTeam
  V5R19 SP03."
  WORKAROUD FOUND AND SENT TO CUSTOMER.
  After USER 2 has Error No: 00055
  The item already exists in the system.
  Adding item 'Lad1_CATPRT-780668 a.00' caused a
  duplicate value error in 'CATIA Part'.
  WORKAROUND:
  - He clicks on OK on this error message and has
  returned to the profile card were he was tried to
  add E CATIA Part
  - He CLICKS ONE MORE TIME ON OK ON THE SAME
  PROFILE CARD AND THE E CATIA PART IS
  CREATED and with same ID as ??780668?? that was
  not created before in the first attempt
  - The workaround contents TWO CLICKS
  

Local fix

Problem summary

• CMP/OMF IR-REG FOR LAST_OBJECT_ID NOT
  UPDATED
  Customer found a problem that seems to be linked to previous
  case (23716,660,706) SCENARIO :
  You need to have 2 users connected to the DB on 2
  PCs to reproduce the problem!
  Below the script:
  1- Connect USER1 and USER2 on 2 different
  machines WITH USER1:
  2- Create a Part A, link it to toto.CATPart and let it
  NEW
  3- Disconnect USER1 and reconnect
  4- Create a Part B which references the same file
  as Part A (toto.CATPart)
  => You get an error 00947 because file is already
  referenced by Part A
  5- Cancel creation of Part B
  6- Create a Part C
  WITH USER2:
  7- Create a Part D
  8- Create a Part E
  => YOU GET AN ERROR 00055 (element already
  exists)
  Add Info from customer: Create Part E follows the
  same mecanism as creating a new version of
  object (Check Out).
  On Check Out there are no error message but a
  rollback is performed, so the Check In data
  becomes locked.
  ANALYSIS OF THE PROBLEM BY CUSTOMER:
  Explanation of the bug, step by step:
  2- User1 books a sequence of 20 OBJECT_IDs and
  use the first one (1 -> 20)
  => LAST_OBJECT_ID is updated (21)
  4- Deleting only the file and not the file catalog
  causes the bug described below
  5- When creating PartB, SmarTeam books a new
  sequence of 20 OBJECT_IDs and use the first one
  (21) but doesn't create the object (21 -> 40)
  => LAST_OBJECT_ID is not updated!!!
  6- When creating PartC, SmarTeam uses the next
  OBJECT_ID booked (22)
  7- When User2 creates PartD, he books a sequence
  of OBJECT_ID starting from LAST_OBJECT_ID not
  updated (21) and is able to create the object
  => This OBJECT_ID has not been already used
  because PartB was not created
  8- When User2 creates PartE, he get the next
  OBJECT_ID (22) but object is not created
  => This OBJECT_ID has been already used by
  PartC creation, SmarTeam cannot create twice :
  Err 00055
  The problem is that 2 users can share a same
  sequence if one of them get errors because of
  referenced objects !!!
  This problem is appearing often and is linked to the
  Check Out problem :
  - Michelin Clonage application is generating lots of
  objects which can be already referenced, if user
  doesn't really care
  The check out problem (23716,660,706) is
  linked to this scenario because on check out
  operation OBJECT_ID is attributed in the same way
  CONCLUSION :
  Michelin wants that LAST_OBJECT_ID table to be
  updated even if there are problems on the creation
  of an object.
  Additional information from customer
  ------------------------------------
  - The information about the SmarTeam level V5R19
  SP03 HF010.
  - The customer's workaround information:
  "1. No workaound possible because we cannot
  follow each user.
  2. Delete manually the trace in the database and
  restart the operation."
  - The customer's fix expectation and justification:
  "It is a strong regression from SmarTeam V5R19.
  The bug really alterates the consistency of the new
  SmarTeam version and generates lot of troubles
  for users:
  - X objects creation forbidden because of duplicate
  message (no value)
  - 50 objects locked in 3 weeks
  We want a correction in a HotFix of SmarTeam
  V5R19 SP03."
  WORKAROUD FOUND AND SENT TO CUSTOMER.
  After USER 2 has Error No: 00055
  The item already exists in the system.
  Adding item 'Lad1_CATPRT-780668 a.00' caused a
  duplicate value error in 'CATIA Part'.
  WORKAROUND:
  - He clicks on OK on this error message and has
  returned to the profile card were he was tried to
  add E CATIA Part
  - He CLICKS ONE MORE TIME ON OK ON THE SAME
  PROFILE CARD AND THE E CATIA PART IS
  CREATED and with same ID as ??780668?? that was
  not created before in the first attempt
  - The workaround contents TWO CLICKS
  

Problem conclusion

• NOTE THAT THIS PROBLEM WILL ALSO BE FIXED ON V5R19 SP5.
  Additional Closure Information:
  THIS PROBLEM WILL BE FIXED ON SMARTEAM
  VERSION 5 RELEASE 19 SP05 LEVEL.
  Additional Closure Information:
  

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

  SMARTEAM NT>XP

• Fixed component ID

  569199970

Applicable component levels

• R519 PSN

     UP