I have a customer for which I am migrating their DOORS 8.0 database server instances to DOORS 9.3. As part of the data verification process after migrating each project's database, I've had to export each projects' modules to CSV for both versions and compare. Most of the diffs I've analyzed appear to show character encoding differences for tab, line-feed, carriage return, bullet, elongated hyphen, and other special characters. Visual inspection of the data in these cases shows no difference of consequence.
After migrating all their project instances and comparing outputs for hundreds of modules, I came across a difference I had not observed until the last two project databases I migrated.
The difference involves what happens when a module has the DXL attribute "DXL for All Changes For Suspect In-links (all modules)." When I use the DOORS 8.1.0.0 client to export the module to CSV, this attribute is processed for links from deleted objects and text like the following is in the output:
/Path to Object: Object ID
There have been 9 changes made since suspicion was last cleared on 11/18/2010 17:51:12.
1. Modification to ABC attribute on 1/17/2011 12:23:58.
2. Modification to DEF attribute on 1/17/2011 15:52:35.
3. Modification to GHI attribute on 1/17/2011 15:52:35.
4. Modification to JKL attribute on 1/17/2011 19:35:04.
5. Modification to MNO attribute on 3/16/2011 15:14:49.
When I use the DOORS 9.3.0.4 client to export the module to CSV, the attribute is not processed for links from deleted objects. I've executed the exports with View > Show > Deletions both enabled and disabled and the results are the same (also with View > Show Deleted Items enabled and disabled).
I've manually examined the properties of the deleted objects and their history records in both versions using client 8.1.0.0 and client 9.3.0.4 and confirmed the history records are the same. Attempting to track down a possible change in the DXL, I looked at a module view with a layout DXL column of the same name as the attribute DXL:
"All Changes For Suspect In-links (all modules)"
Edit > Columns... > Columns tab > select All Changes For Suspect Out-links (all modules) > Edit... > Browse... > Current
DXL displayed is:
// includes
#include <layout/actual/suspect_in.inc>
fnDisplaySuspectInLinks(true, true)
Unfortunately, I cannot compare the source of this function between versions. Also, when looking at the corresponding DXL attribute:
Edit > Columns... > Attributes tab > select DXL for All Changes For Suspect In-links (all modules) > Edit... > General tab
The DXL attribute checkbox and Browse... button are disabled so I cannot inspect the DXL used. I can only assume the same function is used for the DXL attribute as for the Layout DXL.
I've looked through all the known issues and changes docs that I could find from version 8.0 up to 9.3 and I cannot find a reference to this difference in behavior. Ultimately, the data does not appear to be different between versions; except in the export to CSV output because DOORS 8.1 outputs the history for the linked deleted objects and DOORS 9.3 does not. I am curious if anyone else has observed this behavior or perhaps has an explanation. Is this an undocumented enhancement? A bug? I've only been a DOORS admin for seven months so I am still learning concepts daily. Any insight would be appreciated.
Sincerely,
Jay
P.S. I'm new to the forums so please advise if I should post this elsewhere.
jay.long - Sat Jan 07 13:42:48 EST 2012 |
Re: Suspect In-link DXL attribute export diff between DOORS 8.1 and DOORS 9.3
llandale - Mon Jan 09 19:14:44 EST 2012
I believe you have no recourse here.
IBM took it upon themselves in v9200 to downgrade the status of "deleted object" from the previous "invisible" to "worthless" by refusing to allow attr changes and link changes. This was quite inconsistent with the notion of backward compatibility, denying customers the ability to use "deleted objects" to mean something other than "pre-purged".
v9200 and v9201 had the unfortunate feature that attr-DXL could not display the value for deleted objects, getting some sort of "cannot change attr-value of deleted object" message repeatedly. Attr-DXL then had to include "if (isDeleted(obj)) halt". They fixed it in v9202.
I therefore suspect that function fnDisplaySuspectInLinks() has that line of code in it and they never bothered to take it out. If it were me, I'd replace that file temporarily with the one from v82 and see if it works.
I wonder about your deleted objects retaining their links. What does it mean?
In any event IBM may reply to your complaints that the new DOORS is not backward compatible when it comes to deleted objects, because they fixed the long standing 12-year-old bug that deleted objects could be modified and have links and refusing to let their suspect-link code display values of deleted objects is consistent with their enforced notion.
|
Re: Suspect In-link DXL attribute export diff between DOORS 8.1 and DOORS 9.3
jay.long - Tue Jan 10 17:08:07 EST 2012 llandale - Mon Jan 09 19:14:44 EST 2012
I believe you have no recourse here.
IBM took it upon themselves in v9200 to downgrade the status of "deleted object" from the previous "invisible" to "worthless" by refusing to allow attr changes and link changes. This was quite inconsistent with the notion of backward compatibility, denying customers the ability to use "deleted objects" to mean something other than "pre-purged".
v9200 and v9201 had the unfortunate feature that attr-DXL could not display the value for deleted objects, getting some sort of "cannot change attr-value of deleted object" message repeatedly. Attr-DXL then had to include "if (isDeleted(obj)) halt". They fixed it in v9202.
I therefore suspect that function fnDisplaySuspectInLinks() has that line of code in it and they never bothered to take it out. If it were me, I'd replace that file temporarily with the one from v82 and see if it works.
I wonder about your deleted objects retaining their links. What does it mean?
In any event IBM may reply to your complaints that the new DOORS is not backward compatible when it comes to deleted objects, because they fixed the long standing 12-year-old bug that deleted objects could be modified and have links and refusing to let their suspect-link code display values of deleted objects is consistent with their enforced notion.
As for your question, "I wonder about your deleted objects retaining their links. What does it mean?" I don't know for certain. I assumed this was expected behavior so that the link becomes suspect and can be investigated. I read that is the behavior for objects that are linked to changed objects.
|
Re: Suspect In-link DXL attribute export diff between DOORS 8.1 and DOORS 9.3
llandale - Tue Jan 10 17:57:52 EST 2012 jay.long - Tue Jan 10 17:08:07 EST 2012
Thank you for the reply, Louie. Certainly more information than I had found. Did you glean this knowledge on your own from past experience or did I miss the individual fix pack docs with this information? Regardless, I really appreciate the insight being that I am a new DOORS admin with little DOORS 8 or DOORS 9 experience.
As for your question, "I wonder about your deleted objects retaining their links. What does it mean?" I don't know for certain. I assumed this was expected behavior so that the link becomes suspect and can be investigated. I read that is the behavior for objects that are linked to changed objects.
Suspect Links works fairly well for linked objects; say you change the System requirement and the sloppy process "encourages" the sub-system folks to check it out; or perhaps the test folks.
|