I have
a note from 1996 that reads:
You
should also recycle any service machines that are
time dependent that were logged on during the change,
specifically the VM:Schedule service machine and any
RSCS machine running the event manager (RSCS 3.1.0).
All Shared File System SVMs may need to be restarted.
Check your system for others.
time dependent that were logged on during the change,
specifically the VM:Schedule service machine and any
RSCS machine running the event manager (RSCS 3.1.0).
All Shared File System SVMs may need to be restarted.
Check your system for others.
I do
recall the SFS timestamps being off by an hour. Is someone saying that has
changed in the last ten years?
WAKEUP
used to have the Midnight problem. That has probably been
fixed.
Some user applications may get upset when they
compare timestamps.
-----Original Message-----
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Jim Bohnsack
Sent: Tuesday, March 28, 2006 10:20 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Time Change
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Jim Bohnsack
Sent: Tuesday, March 28, 2006 10:20 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Time Change
The one thing I can think of, besides setting some kind of timer pop in an action routine which is probably a very bad idea, is the PROPCHK statement. It's a timer routine that triggers an "are you there" type of logic. I don't use it, but my predecessor did and it functioned as a really crude timer pop. It could get confused, tho, if it saw a time twice or missed what it expected to be a response for an hour.
Jim
At 08:59 AM 3/28/2006, you wrote:
<snip>
>> individually. We have a wide variety of z/OS, Linux and CMS based apps and
>> only a couple of ancient ones have an issue (PROP gets cranky). Springing
</snip>
Why would PROP get cranky? PROP doesn't wake up on timed events, but on messages. If there is any problem with PROP, it would probably be with the coding of the action routines, or some handoff between the action routines if they kept GLOBALV variables with timestamps. But PROP itself should have no problem with the SET TZ change. Is it more accurately the PROP-based apps that are cranky?
Towers Perrin has run PROP for years and, though Towers Perrin IPLs shortly after the new time is in effect, they do SET TZ before the IPL, and never saw any problem with several PROP machines (though they were recycled with the IPL and hence didn't stay up real long after).
Thanks,
Paul Nieman
EDS
484 997-1080 (work)
888 389-6892 (pager)
NOTICE: This communication may contain confidential, proprietary or legally privileged information. It is intended only for the person(s) to whom it is addressed. If you are not an intended recipient, you may not use, read, retransmit, disseminate or take any action in reliance upon it. Please notify the sender that you have received it in error and immediately delete the entire communication, including any attachments. Although EDS encrypts certain email where appropriate, EDS cannot ensure the confidentiality or integrity of all external e-mail communications and, therefore, cannot be responsible for any unauthorized access, disclosure, use or tampering that may occur during transmission. This communication is not intended to create or modify any obligation, contract or warranty of EDS, unless the firm clearly expresses such an intent.Jim Bohnsack
Cornell Univ.
(607) 255-1760
If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/
