ADSM-L

Re: No dateformat - with Solaris 2.5/2.1.0.6 client

1997-01-10 12:38:02
Subject: Re: No dateformat - with Solaris 2.5/2.1.0.6 client
From: Helmut Richter <Helmut.Richter AT LRZ-MUENCHEN DOT DE>
Date: Fri, 10 Jan 1997 18:38:02 +0100
On Fri, 3 Jan 1997, Sheelagh Treweek wrote:

> I believe that my dsm.opt is being processed (I added another option into
> it and that worked) but my 'dateformat 2' is ignored. Doing dsmc -date=2
> starts dsmc ok but is also ignored. The dsmc query opt command shows
> dateformat as 0 no matter what I do.
>
> This looks remarkably like the loss of dateformat on AIX a while ago - but
> I can't find any hints in the README's etc. Any help gratefully accepted.

This bug was already discussed a month ago, and I am a bit disappointed
that instead of fixing this bug, it is now being introduced into more
clients.

Dateformat is *not* a matter of taste!  Many data are available only via
query commands whose output is then processed by programs. Sheelagh has
pointed that out in her letter as much as I have a month ago.
Should this bug persist, she and I, and probably many others, are forced
to modify the scripts that process query output. That costs our time
which we would rather have liked to spend for something useful. And the
change is by no means trivial.

I include my old letter for reference.

Best wishes,

Helmut Richter

==============================================================
Dr. Helmut Richter                       Leibniz-Rechenzentrum
Tel:   +49-89-289-28785                  Barer Str. 21
Fax:   +49-89-2809460                    D-80333 Muenchen
Email: Helmut.Richter AT lrz-muenchen DOT de    Germany
==============================================================

Date: Wed, 4 Dec 1996 09:56:39 +0100 (MET)
From: Helmut Richter <a282244 AT sunmail.lrz-muenchen DOT de>
Reply to: Helmut Richter <Helmut.Richter AT lrz-muenchen DOT de>
To: Multiple recipients of list ADSM-L <ADSM-L AT VM.MARIST DOT EDU>
Subject: DATEFORMAT option (was: ADSM Year 2000 compliant)

On Tue, 3 Dec 1996, Paul Zarnowski wrote:

> If you use ADSM archive from AIX, beware of the following bug that IBM
> introduced (at fix level 3?).  They changed ADSM to ignore the DATEFORMAT
> option (as well as a couple of others), and instead use the AIX date
> format options.  I think this was done to comply with some unix standard.

This situation is distasteful not only for the reasons Paul mentioned but
for three other reasons as well:

1. The implementation differs from the documentation, and the
   implementations on the different platforms disagree. I am having a hard
   time describing the DATEFORMAT to our users. Up to the introduction of
   this AIX bug, I was able to describe to our users how they could cause
   ADSM to use a legible date. In Europe, including Britain, a date 04/03/97
   is obviously 4th of March 1997, and, in order to prevent misunder-
   standings, it is mandatory to use an unambiguous format, e.g.
   conformant to the ISO 8601 standard.

2. Users have no longer the opportunity to select a dateformat for
   themselves. Instead, they are dependent on the decision of their system
   administrators.

3. There is no way to write a script that would automatically process
   output from ADSM query commands. Instead, these scripts depend on the
   choice of the date format at every single ADSM client and must therefore
   be adopted to all these formats. This is the more important as much
   information is only available this way (e.g. ADSM usage by a single
   user).

The solution, quite obviously, is to make the change upward compatible:

Retain the DATEFORMAT option.

Add a new value DATEFORMAT=0 with the meaning "use DATEFORMAT as
  specified by the rules of the operating system, in particular the rules
  of locale as specified in standard ISO 9945-1".

Even though upward compatibility is somewhat restricted, I see no
  reason why this new value, once implemented on all client platforms and
  properly documented, should not become the default after due
  announcement in release notes.

Helmut Richter
<Prev in Thread] Current Thread [Next in Thread>