Every ListBox created (or already present by default) in the IBM Rational Change's "ListBox Manager" is supposed to have a default value, commonly called "Any".
This document gives better understanding on the impact of modifying this default value, and gives general guidelines on how to fix your database if this value is missing or inconsistent.
The following situations are clarified below:
- If your Listboxes don't display the value "Any"
- If you have changed your default value but still see "Any" in your Listboxes
- If you see both values ("Any" and your new default value)
- If some of your Listboxes show one of the symptoms above, and some other ListBoxes inconsistently how another one of the symptoms above.
Every value present in a ListBox is read from the file "pt_listbox.cfg", which doesn't get modified if you edit the file "pt.cfg" that contains the default value "Any".
Therefore, your ListBoxes might not necessarily reflect the changes you made to your default value.
Resolving the problem
Please note that the information present in this Technote is not meant to help you customize IBM Rational Change.
This is only a general highlight on Change's default value, meant at helping you fix your ListBoxes (and the underlying database attributes) if you mistakenly damaged them.
This information has been tested with IBM Rational Change 22.214.171.124 patch 07, but most likely applies to the whole 5.x generation.
1. What is the default value?
The "default" value may also be called the "undefined" value.
It is the value that will be displayed and selected in an IBM Rational Change ListBox if the corresponding attribute was actually not given any of the "real" values also present in the ListBox.
2. The default value is mandatory
By default, Rational Change offers the default value "Any". You should see that value in every single ListBox.
When you use Change's ListBox Manager (as an administrator), Change doesn't allow you:
- to remove it
- to duplicate it
3. How does Change identify the default value?
3.1. When you are in the ListBox Manager
Change compares the ListBox entry that you are trying to modify with the default value defined in the file "pt.cfg" (as follows):
If you change that value in the file, and then reload Change's configuration (admin interface --> "General" --> "Load"), then you will witness that Change immediately prevents you from tempering with that new default value in the ListBox Manager.
You will also witness that you are now free to temper with the now-obsolete default value (e.g. "Any"), as it now has no particular meaning.
CAUTION: You might witness a few glitches while you use the ListBox manager, during the transition (as you are not supposed to act this way):
For example, you might witness that all entries of that ListBox get actually deleted when you save them, until Change finds again that your ListBox contains consistent values, especially the default value. Therefore, act carefully if you find yourself in the situation described above.
3.2. When you are in Change (user interface)
We assume the admin has reloaded Change's configuration (admin interface --> "General" --> "Load").
Then Change will display in each ListBox the values it has read from pt_listbox.cfg (which defines every ListBox). (Exception: Dependent listboxes are generated "on the fly", therefore you might immediately observe any change made in either pt_listbox.cfg or pt.cfg).
The default value is considered to be the very first entry of the ListBox, whatever it may be (that is, the entry with id 0).
That is because:
- As explained earlier, a default value is always expected to be present in each ListBox.
- On an HTTP form, a "listbox" is always set to one of the values it contains. It can't be set to "blank".
3.3. In the underlying Synergy/Informix database
For optimisation reasons, Change simply does not save an attribute that has an undefined (that is, "default") value. If you run queries on a CR, you will see that it does not contain any of the undefined attributes.
Symmetrically, an attribute that is expected in a CR but is found not to exist in the database, will be considered by Change as "undefined", and will therefore be rendered with the "default" value.
Note: You might still witness such output in your event.log file, but it's only to make the information more readable. If the attribute is undefined, then it does not exist in the database.
4. What inconsistencies should I be prepared to observe?
4.1. An attribute I know as being set to "default" ("Any") still appears to be set to an actual value
This is a direct consequence of 3.2.
Ask yourself: "Is it the first ListBox entry?" - "Where has my expected default value, that should be the first entry, gone?").
In reality, the attribute actually has no value (i.e. it has the default value), even though the very first ListBox entry seems to be selected.
4.2. Some of my ListBoxes show one default value (e.g. "Any"), and some others show a different default value (e.g. "MyDefaultValue")
See 3.2. for an explanation. Are some of them dependent ListBoxes?
See 4.3 for a solution.
4.3. I have changed my default value in pt.cfg, but not all my ListBoxes offer to select it
That's because the ListBoxes entries are read from "pt_listbox.cfg", which is not necessarily re-generated after you modify "pt.cfg".
You need to force Change to re-generate pt_listbox.cfg, so that every ListBox it contains has a default value matching the one from pt.cfg. Until that becomes true, you will find yourself in a dangerous state of inconsistency (see caution from 3.1).
In order to do so, you can :
a. Manually modify/add/remove some entries in the ListBox manager, as described in 3.1, until you end up with the entries you wish to see AND the new default value (re-read from pt.cfg by Change as you save your ListBox).
As explained in 3.1, you might lose all your ListBox entries at some stage. But provided you remember what they should be, and provided you need change only a few ListBoxes, then this is a rather user-friendly fix.
b. Edit pt_listbox.cfg and update the first entry of each ListBox to match the default value from pt.cfg.
This is the cleanest and safest solution.
4.4. The attributes in the Printer Friendly View don't have the same values as in the CR I'm viewing.
This is a variation of 4.1.
The Printer Friendly view is right.
However the form you're currently watching displays flawed information, for the reason explained in 4.1.