I just ran into this DEFECT myself, and I am somewhat upset. Now that I
understand what the problem is, my conclusion is that IBM has broken ADSM
by doing this, at least in our environment. Here is my analysis.
I tried to use the "dsm" command (the GUI interface) to retrieve some files
that I had previously archived. They all had expiration dates in the next
century (i.e., beyond the year 1999). When using the GUI interface, I was
not able to locate any of these files. This is because the GUI interface
insists on specifying a date selection range for the expiration date of
files. I am unable to specify a date range that exceeds 12/31/99. I have
tried everything, and still ADSM cannot find my files, or it complains that
the range I have used is invalid. Prior to this change, the GUI defaults
were reasonable (they would look for files having an expiration date between
1990 and 9999). Now the default is to look between 1990 and 1999.
I can find these files just fine using the CLI (dsmc) because it does not
insist on me specifying a date range for the expiration date of the files
that I want to list/retrieve. So, I KNOW that the files are really there.
Ok, so I'm just a little upset about this, but I figure I will dig out the
mailfile describing how to update my "locale" to use 4-digit years. Rather
than being an option for me, this operation has now become a pre-requisite
to my continuing to be able to use the "dsm" command.
Next, I find out that the instructions in the mailfile are incorrect for
the version of AIX that I am using (4.1.4). I decide to plow forward anyway,
making what I think are reasonable changes in the instructions for the
version of AIX I am running (i.e., my language is "en_US", not "En_US", etc.
Then I get stopped cold by the requirement that I have the C compiler
installed on my system to be able to do this. I do not have C. Having
C should not be a pre-requisite for being able to use ADSM's dsm command!
Now I am very upset (can you tell? ;-))
This could all have been avoided by some foresight by the developers, or
whoever decided to "fix" this problem.
If you want to follow the standard, you should have done it in a way that
was upward compatible with your product. As you decided to do it, you have
negated the date and time formatting options that you document in your
manuals. These are no longer obeyed! I quote from the README file:
o This client now uses the local XPG4 definition for the format
of dates, times, and numbers. The settings for the ADSM options
DATEFORMAT, TIMEFORMAT, and NUMBERFORMAT options will now be ignored
on this client.
What is worse, you have broken a very important piece of your product
in the process by not understanding the consequences of what you did
before shipping it in the product stream.
What you COULD have done is to add a NEW option (how about DATEFORMAT
XPG4) for date and time formatting that would ALLOW ADSM to follow the
XPG standard, instead of FORCEING it to. This would have been a much
kindler and gentler way to introduce this change into ADSM.
Finally, I am surprised that such a major change was introduced as a fix
rather than being introduced at the next major release change, and that
it was introduced without any documentation on what users should do.
There is a small item in the README file (quoted above) that looks
innocuous, until you realize what the impact is. There are no
instructions at all on how to recover from it.
If it ain't broke, don't try to fix it.
If you document function, keep it around so your product remains upward
compatible.
Now that I think about it, this is APARable.
|
