RE: With the upcoming time change....

[Vern Hamberg <vhamberg@xxxxxxxxxxxxxxxxxxxxxxxxx>]

Dennis

Good points, I think. But I don't think IBM does what it does to
accommodate Help Systems, or most other vendors. Except maybe SAP or
J.D.Edwards. (Don't we wish!)

My boss, who worked in the journaling area at IBM some years ago, suggested
that system functions can be affected, too - like journaling. (Please, I
have no more info than that!)

But I have to wonder just what impact there really is, as we must have to
face the issue when we make manual changes, right? Still, the people
developing this thing are not dumb, and there are usually reasons I am not
privy to when I don't understand why.

Also, AFAIK, UTC offset isn't required for proper operation (except maybe
Domino and other newer things). It IS necessary, if you want times reported
correctly in Management Central monitors, e.g., which is the context where
this issue has arisen before.

Regards

Vern

At 08:50 AM 10/25/02 -0400, you wrote:

> Hi, Vern:
>
> Thanks for your message.  That's fair at first glance.  So we're saying we
> can't improve the operating system because we have vendor Business Partners
> who have special considerations, and it's our duty to protect them, thereby
> ensuring that they don't have opportunity to remove those special
> considerations?  That's an interesting proposal indeed!
>
> What if this was all *planned* and IBM were to state, "From VxRx forward,
> the AS/400 will use GMT as its internal time of reference.  All times
> presented to the user will be *local,* having been adjusted according to
> the user-specified UTC offset *TABLE* which is DST-aware."  (This is not a
> new concept... it's been on *nix systems, for example, for at least thirty
> years.)  Now, if IBM were also to allow (say via API) an application to
> reference GMT (and the table in some fashion), the BP in question would be
> (or at least should be) able to work off of that internal clock, thereby
> eliminating such special operations once and for all.  And what if (wonder
> of wonders) the USER had the choice of specifying a fixed UTC-offset (ala
> Indiana or China or ....), and would therefore be able to operate the tired
> old way if s/he so chose?
>
> As I read it, the thinking is "ApplicationX requires special steps in order
> to accomodate DST.  In order that we don't disrupt things and take away
> ApplicationX's need for those special steps once or twice every year, we
> can't touch the code."  And we can't improve it for those who don't use
> ApplicationX because ... umm ... because ...  Am I missing something?
>
> Now that I've stuck my foot out there to be smashed, I'll have a look at
> the archives and see what the discussion included.  But I'll tell you now
> it'll be very hard to convince me that this sort of change isn't an
> improvement that's well worth the effort.
>
> I know that I'm way past "Everybody else has one, Mom.  Why can't I?" but
> come on, IBM.
>
> Dennis
>
>
>
>
>
>
> Vern Hamberg <vhamberg@centerfieldtechnology.com>@midrange.com on
> 10/25/2002 08:05:58 AM
>
> Please respond to midrange-l@midrange.com
>
> Sent by:    midrange-l-admin@midrange.com
>
>
> To:    midrange-l@midrange.com
> cc:
> Subject:    RE: With the upcoming time change....
>
>
> Dennis
>
> The matter of  "Daylight Savings Time awareness" was much discussed fairly
> recently. I guess se didn't have much to do back in June  ;-)
>
> The main issue, as I understand it, is time-dependent processes. ROBOT, for
> one, should be shut down, then the change made, then restarted, so that you
> don't either miss or double-run something.
>
> Vern
>
> At 07:40 AM 10/25/02 -0400, you wrote:
>
> >This is one of the areas I find amusing about the AS/400 system.  It's
> >amusing only because it's easily overcome and not really in the nuisance
> >category.
> >
> >I am not aware of any other system where both UTC offset and local time
> >must both be specified for proper operation (you only need one of these if
> >the internal time is maintained at GMT)... and also aware of no other
> >system that isn't "Daylight Savings Time aware."  (oh, I take that
> back....
> >IBM mainframes suffer from the same shortsightedness.  And DOS from back
> >when the earth was still cooling.)
> >
> >I keep thinking that one day IBM will wake up and resolve this, but then
> >what would I have to complain about two times every year?   Of course, I
> >could always move back home to Indiana, where they don't bother with such
> >nonsense.... hmmm....  :)
> >
> >Dennis