New time zone daylight savings rule for 2007

Discussion:

(too old to reply)

Blake, Cheryl A.

2007-02-19 11:47:01 UTC

Hi Richard,

if all we have to do to reset the spring ahead/fall behind is copy the
TIMZONES.DAT to TIMEZONES.LOCAL and modify it then why should we have to
install any MultiNet patches at all?

Especially if we're using MultiNet for nothing except TCPIP?

thanks,

Cheryl Blake

Senior Systems Engineer

Lahey Clinic

Burlington, MA

-----Original Message-----
From: Randy Johnson [mailto:***@sxc.com]
Sent: Friday, February 16, 2007 5:28 PM
To: Richard Whalen; info-***@process.com
Subject: RE: New timezone daylight savings rule for 2007

I am getting ready to test this, but I noticed that both NTP and XNTP

are DISABLED. Will this process help me??

Or should I apply the ECOs for Daylight Savings Time changes??

Or should I install the current version of Multinet??

Randy Johnson

-----Original Message-----

From: Richard Whalen [mailto:***@process.com]

Sent: Thursday, January 11, 2007 9:05 AM

To: Randy Johnson

Subject: RE: New timezone daylight savings rule for 2007

remove them from any ZONE lines that you copy from TIMEZONES.DAT to

TIMEZONES.LOCAL.

You only need to copy the ZONE line for the zone that your system is in.

-----Original Message-----

From: Randy Johnson [mailto:***@sxc.com]

Sent: Thursday, January 11, 2007 11:00 AM

To: Richard Whalen

Subject: RE: New timezone daylight savings rule for 2007

Richard,

Which lines do I remove the "COMPILED_IN" from, or do I remove all of

them??

Randy,

-----Original Message-----

From: Richard Whalen [mailto:***@process.com]

Sent: Wednesday, January 10, 2007 10:37 AM

To: Randy Johnson

Subject: RE: New timezone daylight savings rule for 2007

1. Yes, enter the rule as is, with the ">=" characters.

Sunday >= 8 is how SECOND SUNDAY is specified.

2. Just remove the "COMPILED_IN" portion of the line.

3. The method that we use to test is to set the time on

a test system, restart NTP and check to see if the

MULTINET_TIMEZONE logical has changed.

4. See answer 3.

5. Ask HP. I have seen some discussion on the ITRC forum

so I believe that they have patches for some versions of

VMS. (I can't currently get to the ITRC forums to give

you a pointer.

6. There are no plans for a patch that would accept SECOND,

THIRD, FOURTH or FIFTH. We use standard NTP code and

rules that many other systems use, and I don't believe

that you'll see any of them supporting SECOND.

-----Original Message-----

From: Randy Johnson [mailto:***@sxc.com]

Sent: Wednesday, January 10, 2007 12:19 PM

To: info-***@process.com

Cc: Richard Whalen

Subject: RE: New timezone daylight savings rule for 2007

I have the following questions:

1. Do I enter the rule as is (with the >= characters)?

2. Do I remove ALL "COMPILED_IN" characters or do I delete the whole

line(s)?

3. How can I test my changes to be sure it will work?

4. How can I tell if Multinet is managing the changing of the time for

daylight savings time?

5. Are there any other changes needed for OpenVMS?

6. Will Process be making a change to enter something other than FIRST

or LAST?

Randy Johnson

SXC Health Solutions

-----Original Message-----

From: Richard Whalen [mailto:***@process.com]

Sent: Tuesday, January 02, 2007 7:31 AM

To: info-***@process.com

Subject: Re: New timezone daylight savings rule for 2007

The parser only recognizes "FIRST" and "LAST".

To get second you have to use

Rule US 2007 DST 1:00 Sunday >= 8 March 2:00

First Sunday November 2:00

For those of you that are making this change, your timezones.local file

must

have the Zone lines

as well as the above rule. You'll want to remove the "COMPILED_IN" from

the

timezones.local file when you copy the rules from timezones.dat

This is probably really an enhancement request more than a query.
VMS 7.3-2, MN 4.4A
I copied timezones.dat to timezones.local and inserted a new line that
defined the start and end dates for use in the US beginning this new
year. The start time is specified as the second sunday of March,
so the added line was
Rule US 2007 DST 1:00 Second Sunday March 2:00 Last
Sunday November
but a $Multinet Set/timezone/select=("US/PACIFIC")
PST/file=multinet:timezones.local
returned: "SECOND" is not a day number, Bad DST Starting time.
So I just hard coded it to the 11th of March. So I'm good for this
year.:)
Roger, Harvey Mudd College

Bob Koehler

2007-02-19 14:19:48 UTC

Permalink

Post by Blake, Cheryl A.
Especially if we're using MultiNet for nothing except TCPIP?

What else would you use Multinet for?

Richard Whalen

2007-02-20 14:03:21 UTC

Permalink

Creating TIMEZONES.LOCAL with the necessary information in it is sufficient to manage the new rules.
The patches contain an updated TIMEZONES.DAT with the new rules and updated images for the rules that are compiled in.
Many customers find it easier to apply the patches than to make the changes to TIMEZONES.LOCAL themselves.

Even if you aren't running NTP or XNTP you should apply the patches or create a TIMEZONES.LOCAL with the proper information.
MultiNet maintains a few logicals that encode the time zone information that are used for a variety of purposes. One example is: SMTP uses the time zone information when dealing with messages.

Richard Whalen
Process Software

-----Original Message-----
From: Blake, Cheryl A. [mailto:***@lahey.org]
Sent: Monday, February 19, 2007 6:47 AM
To: info-***@process.com
Subject: RE: New time zone daylight savings rule for 2007

Hi Richard,

if all we have to do to reset the spring ahead/fall behind is copy the TIMZONES.DAT to TIMEZONES.LOCAL and modify it then why should we have to install any MultiNet patches at all?

Especially if we're using MultiNet for nothing except TCPIP?

thanks,

Cheryl Blake

Senior Systems Engineer

Lahey Clinic

Burlington, MA

-----Original Message-----
From: Randy Johnson [mailto:***@sxc.com]
Sent: Friday, February 16, 2007 5:28 PM
To: Richard Whalen; info-***@process.com
Subject: RE: New timezone daylight savings rule for 2007

I am getting ready to test this, but I noticed that both NTP and XNTP

are DISABLED. Will this process help me??

Or should I apply the ECOs for Daylight Savings Time changes??

Or should I install the current version of Multinet??

Randy Johnson

-----Original Message-----

From: Richard Whalen [mailto:***@process.com]

Sent: Thursday, January 11, 2007 9:05 AM

To: Randy Johnson

Subject: RE: New timezone daylight savings rule for 2007

remove them from any ZONE lines that you copy from TIMEZONES.DAT to

TIMEZONES.LOCAL.

You only need to copy the ZONE line for the zone that your system is in.

-----Original Message-----

From: Randy Johnson [mailto:***@sxc.com]

Sent: Thursday, January 11, 2007 11:00 AM

To: Richard Whalen

Subject: RE: New timezone daylight savings rule for 2007

Richard,

Which lines do I remove the "COMPILED_IN" from, or do I remove all of

them??

Randy,

-----Original Message-----

From: Richard Whalen [mailto:***@process.com]

Sent: Wednesday, January 10, 2007 10:37 AM

To: Randy Johnson

Subject: RE: New timezone daylight savings rule for 2007

1. Yes, enter the rule as is, with the ">=" characters.

Sunday >= 8 is how SECOND SUNDAY is specified.

2. Just remove the "COMPILED_IN" portion of the line.

3. The method that we use to test is to set the time on

a test system, restart NTP and check to see if the

MULTINET_TIMEZONE logical has changed.

4. See answer 3.

5. Ask HP. I have seen some discussion on the ITRC forum

so I believe that they have patches for some versions of

VMS. (I can't currently get to the ITRC forums to give

you a pointer.

6. There are no plans for a patch that would accept SECOND,

THIRD, FOURTH or FIFTH. We use standard NTP code and

rules that many other systems use, and I don't believe

that you'll see any of them supporting SECOND.

-----Original Message-----

From: Randy Johnson [mailto:***@sxc.com]

Sent: Wednesday, January 10, 2007 12:19 PM

To: info-***@process.com

Cc: Richard Whalen

Subject: RE: New timezone daylight savings rule for 2007

I have the following questions:

1. Do I enter the rule as is (with the >= characters)?

2. Do I remove ALL "COMPILED_IN" characters or do I delete the whole

line(s)?

3. How can I test my changes to be sure it will work?

4. How can I tell if Multinet is managing the changing of the time for

daylight savings time?

5. Are there any other changes needed for OpenVMS?

6. Will Process be making a change to enter something other than FIRST

or LAST?

Randy Johnson

SXC Health Solutions

-----Original Message-----

From: Richard Whalen [mailto:***@process.com]

Sent: Tuesday, January 02, 2007 7:31 AM

To: info-***@process.com

Subject: Re: New timezone daylight savings rule for 2007

The parser only recognizes "FIRST" and "LAST".

To get second you have to use

Rule US 2007 DST 1:00 Sunday >= 8 March 2:00

First Sunday November 2:00

For those of you that are making this change, your timezones.local file

must

have the Zone lines

as well as the above rule. You'll want to remove the "COMPILED_IN" from

the

timezones.local file when you copy the rules from timezones.dat

Jeremy Begg

2007-02-21 00:19:08 UTC

Permalink

Hi,

Post by Richard Whalen
Creating TIMEZONES.LOCAL with the necessary information in it is sufficient
to manage the new rules.
The patches contain an updated TIMEZONES.DAT with the new rules and updated
images for the rules that are compiled in.
Many customers find it easier to apply the patches than to make the changes
to TIMEZONES.LOCAL themselves.

One thing that's not entirely clear to me: does TIMEZONES.LOCAL *replace*
TIMEZONES.DAT, or does it merely amend it? In other words, if I have a
TIMEZONES.LOCAL file, does MultiNet ignore TIMEZONES.DAT? Or how does it
merge the two?

For example, if I need to set up a new rule because of a DST variation, does
my TIMEZONES.LOCAL have to contain a complete set of the relevant "Rule",
"Zone" and "Country" statements, or can it contain just a new "Rule"
statement (and nothing else)?

(In case you're wondering, the reason this is an issue is that the
Australian state governments tend to proclaim change DST dates on a
relatively frequent basis. The most recent case was Western Australia
where they gave about three weeks' notice to introduce DST for the first
time!)

Thanks,

Jeremy Begg

Richard Whalen

2007-02-21 14:03:29 UTC

Permalink

The code that reads TIMEZONES.LOCAL and TIMEZONES.DAT reads the
file until it has found a matching Country and Zone that the
system is in, keeping track of Rules that it reads as well.
If it reads TIMEZONES.LOCAL and does not find a matching Country
and Zone, then it discards what it has read and starts fresh
with TIMEZONES.DAT. Which is why we recommend copying TIMEZONES.DAT
to TIMEZONES.LOCAL and adding the new rule.

We considered including the recent Western Australia rule changes
in this patch, but because they were only on a trial basis and could
change again in a few years, we decided not to due to the possibility
that it would change again.

-----Original Message-----
From: Jeremy Begg [mailto:***@vsm.com.au]
Sent: Tuesday, February 20, 2007 7:19 PM
To: Richard Whalen
Cc: info-***@process.com
Subject: RE: New time zone daylight savings rule for 2007

Hi,

Ross Smith

2007-02-21 14:27:49 UTC

Permalink

Just curious:

VMS provides timezone information (for which there is a new patch, btw).

Why duplicate system information? Limit TIMEZONES.LOCAL to an
optional file used in the rare case that HP goofed and left something
out?

-Ross-

Post by Richard Whalen
The code that reads TIMEZONES.LOCAL and TIMEZONES.DAT reads the
file until it has found a matching Country and Zone that the
system is in, keeping track of Rules that it reads as well.
If it reads TIMEZONES.LOCAL and does not find a matching Country
and Zone, then it discards what it has read and starts fresh
with TIMEZONES.DAT. Which is why we recommend copying TIMEZONES.DAT
to TIMEZONES.LOCAL and adding the new rule.
We considered including the recent Western Australia rule changes
in this patch, but because they were only on a trial basis and could
change again in a few years, we decided not to due to the possibility
that it would change again.
-----Original Message-----
Sent: Tuesday, February 20, 2007 7:19 PM
To: Richard Whalen
Subject: RE: New time zone daylight savings rule for 2007
Hi,

Post by Richard Whalen
Creating TIMEZONES.LOCAL with the necessary information in it is
sufficient
to manage the new rules.
The patches contain an updated TIMEZONES.DAT with the new rules
and updated
images for the rules that are compiled in.
Many customers find it easier to apply the patches than to make
the changes
to TIMEZONES.LOCAL themselves.

One thing that's not entirely clear to me: does TIMEZONES.LOCAL
*replace*
TIMEZONES.DAT, or does it merely amend it? In other words, if I
have a
TIMEZONES.LOCAL file, does MultiNet ignore TIMEZONES.DAT? Or how
does it
merge the two?
For example, if I need to set up a new rule because of a DST
variation, does
my TIMEZONES.LOCAL have to contain a complete set of the relevant
"Rule",
"Zone" and "Country" statements, or can it contain just a new "Rule"
statement (and nothing else)?
(In case you're wondering, the reason this is an issue is that the
Australian state governments tend to proclaim change DST dates on a
relatively frequent basis. The most recent case was Western Australia
where they gave about three weeks' notice to introduce DST for the
first
time!)
Thanks,
Jeremy Begg

Richard Whalen

2007-02-21 14:37:33 UTC

Permalink

MultiNet is supported on (VAX) VMS V5.5-2. There is no patch for
the time zone information from HP for VMS V5.5-2. We try not to
have our code to different things depending upon the version of VMS.

-----Original Message-----
From: Ross Smith [mailto:***@med.nyu.edu]
Sent: Wednesday, February 21, 2007 9:28 AM
To: info-***@process.com
Subject: Re: New time zone daylight savings rule for 2007

Just curious:

VMS provides timezone information (for which there is a new patch, btw).

Why duplicate system information? Limit TIMEZONES.LOCAL to an
optional file used in the rare case that HP goofed and left something
out?

-Ross-

Post by Richard Whalen
Creating TIMEZONES.LOCAL with the necessary information in it is
sufficient
to manage the new rules.
The patches contain an updated TIMEZONES.DAT with the new rules
and updated
images for the rules that are compiled in.
Many customers find it easier to apply the patches than to make
the changes
to TIMEZONES.LOCAL themselves.

One thing that's not entirely clear to me: does TIMEZONES.LOCAL
*replace*
TIMEZONES.DAT, or does it merely amend it? In other words, if I
have a
TIMEZONES.LOCAL file, does MultiNet ignore TIMEZONES.DAT? Or how
does it
merge the two?
For example, if I need to set up a new rule because of a DST
variation, does
my TIMEZONES.LOCAL have to contain a complete set of the relevant
"Rule",
"Zone" and "Country" statements, or can it contain just a new "Rule"
statement (and nothing else)?
(In case you're wondering, the reason this is an issue is that the
Australian state governments tend to proclaim change DST dates on a
relatively frequent basis. The most recent case was Western Australia
where they gave about three weeks' notice to introduce DST for the
first
time!)
Thanks,
Jeremy Begg

Ken Bridges

2007-02-21 14:45:33 UTC

Permalink

I'm running OpenVMS 7.3-1 for which there does not appear to be a
patch from HP...does applying the appropriate Multinet patch take
care of everything then?

Thanks.

Ken

Post by Richard Whalen
MultiNet is supported on (VAX) VMS V5.5-2. There is no patch for
the time zone information from HP for VMS V5.5-2. We try not to
have our code to different things depending upon the version of VMS.
-----Original Message-----
Sent: Wednesday, February 21, 2007 9:28 AM
Subject: Re: New time zone daylight savings rule for 2007
VMS provides timezone information (for which there is a new patch, btw).
Why duplicate system information? Limit TIMEZONES.LOCAL to an
optional file used in the rare case that HP goofed and left something
out?
-Ross-

Post by Richard Whalen
Creating TIMEZONES.LOCAL with the necessary information in it is
sufficient
to manage the new rules.
The patches contain an updated TIMEZONES.DAT with the new rules
and updated
images for the rules that are compiled in.
Many customers find it easier to apply the patches than to make
the changes
to TIMEZONES.LOCAL themselves.

One thing that's not entirely clear to me: does TIMEZONES.LOCAL
*replace*
TIMEZONES.DAT, or does it merely amend it? In other words, if I
have a
TIMEZONES.LOCAL file, does MultiNet ignore TIMEZONES.DAT? Or how
does it
merge the two?
For example, if I need to set up a new rule because of a DST
variation, does
my TIMEZONES.LOCAL have to contain a complete set of the relevant
"Rule",
"Zone" and "Country" statements, or can it contain just a new "Rule"
statement (and nothing else)?
(In case you're wondering, the reason this is an issue is that the
Australian state governments tend to proclaim change DST dates on a
relatively frequent basis. The most recent case was Western Australia
where they gave about three weeks' notice to introduce DST for the
first
time!)
Thanks,
Jeremy Begg

Bob Koehler

2007-02-22 14:29:54 UTC

Permalink

Post by Ken Bridges
I'm running OpenVMS 7.3-1 for which there does not appear to be a
patch from HP...does applying the appropriate Multinet patch take
care of everything then?

The C and C++ RTLs, and the JRE if you're using one, have time zone
support. The Multinet patch does not take care of these. You need
to look at your applications and see of they are using any of these
features.

Richard Whalen

2007-02-21 15:00:56 UTC

Permalink

The MultiNet patch takes care of the MultiNet logicals.

If you are running MultiNet 5.0 or later and are using NTP,
then you can use the set_vms_logicals keyword in the NTP
configuration file to cause NTP to set the various VMS
time zone logicals as well. This will set the following
VMS logicals:
SYS$TIMEZONE_DAYLIGHT_SAVING
SYS$TIMEZONE_DIFFERENTIAL
SYS$TIMEZONE_NAME

It does NOT set SYS$TIMEZONE_RULE.

-----Original Message-----
From: Ken Bridges [mailto:***@utpb.edu]
Sent: Wednesday, February 21, 2007 9:46 AM
To: info-***@process.com
Subject: RE: New time zone daylight savings rule for 2007

I'm running OpenVMS 7.3-1 for which there does not appear to be a
patch from HP...does applying the appropriate Multinet patch take
care of everything then?

Thanks.

Ken

Post by Richard Whalen
Creating TIMEZONES.LOCAL with the necessary information in it is
sufficient
to manage the new rules.
The patches contain an updated TIMEZONES.DAT with the new rules
and updated
images for the rules that are compiled in.
Many customers find it easier to apply the patches than to make
the changes
to TIMEZONES.LOCAL themselves.

One thing that's not entirely clear to me: does TIMEZONES.LOCAL
*replace*
TIMEZONES.DAT, or does it merely amend it? In other words, if I
have a
TIMEZONES.LOCAL file, does MultiNet ignore TIMEZONES.DAT? Or how
does it
merge the two?
For example, if I need to set up a new rule because of a DST
variation, does
my TIMEZONES.LOCAL have to contain a complete set of the relevant
"Rule",
"Zone" and "Country" statements, or can it contain just a new "Rule"
statement (and nothing else)?
(In case you're wondering, the reason this is an issue is that the
Australian state governments tend to proclaim change DST dates on a
relatively frequent basis. The most recent case was Western Australia
where they gave about three weeks' notice to introduce DST for the
first
time!)
Thanks,
Jeremy Begg

Ross Smith

2007-02-21 15:08:46 UTC

Permalink

Post by Richard Whalen
The MultiNet patch takes care of the MultiNet logicals.
If you are running MultiNet 5.0 or later and are using NTP,
then you can use the set_vms_logicals keyword in the NTP
configuration file to cause NTP to set the various VMS
time zone logicals as well. This will set the following
SYS$TIMEZONE_DAYLIGHT_SAVING
SYS$TIMEZONE_DIFFERENTIAL
SYS$TIMEZONE_NAME
It does NOT set SYS$TIMEZONE_RULE.

I know (I think) that this was discussed some time ago, but - Why
does it not set SYS$TIMEZONE_RULE? This forces you to re-run the UTC
$TIME... command procedure each time the machine reboots - or I've
missed something important again...

-Ross-

Richard Whalen

2007-02-21 15:25:46 UTC

Permalink

SYS$TIMEZONE_RULE generally does not change, so there is no
code to make this one time change.

If you are running NTP on MultiNet 5.0 or later, then you can
include call_dst_proc in NTP.CONF. This will execute
MULTINET:NTPD_DST_PROC.COM at startup and the change into DST.
You can use the command procedure to make sure that the logical
is set correctly. There is a template for NTPD_DST_PROC.COM in
MULTINET:NTPD_DST_PROC_COM.TEMPLATE

-----Original Message-----
From: Ross Smith [mailto:***@med.nyu.edu]
Sent: Wednesday, February 21, 2007 10:09 AM
To: info-***@process.com
Subject: Re: New time zone daylight savings rule for 2007

Grimme, Jon

2007-02-21 15:30:43 UTC

Permalink

You want to use Multinet_timezone_rules if you are using multinet as your
time
zone rule and control. Thank you,

-----Original Message-----
From: Richard Whalen [mailto:***@process.com]
Sent: Wednesday, February 21, 2007 10:26 AM
To: info-***@process.com
Subject: RE: New time zone daylight savings rule for 2007

SYS$TIMEZONE_RULE generally does not change, so there is no
code to make this one time change.

If you are running NTP on MultiNet 5.0 or later, then you can
include call_dst_proc in NTP.CONF. This will execute
MULTINET:NTPD_DST_PROC.COM at startup and the change into DST.
You can use the command procedure to make sure that the logical
is set correctly. There is a template for NTPD_DST_PROC.COM in
MULTINET:NTPD_DST_PROC_COM.TEMPLATE

-----Original Message-----
From: Ross Smith [mailto:***@med.nyu.edu]
Sent: Wednesday, February 21, 2007 10:09 AM
To: info-***@process.com
Subject: Re: New time zone daylight savings rule for 2007

Richard Whalen

2007-02-21 15:37:49 UTC

Permalink

The value of SYS$TIMEZONE_RULE can be used by some C run time library routines when doing conversions from local time to UTC

-----Original Message-----
From: Grimme, Jon [mailto:***@MSA.com]
Sent: Wednesday, February 21, 2007 10:31 AM
To: 'Info-***@process.com'
Subject: RE: New time zone daylight savings rule for 2007

You want to use Multinet_timezone_rules if you are using multinet as your
time
zone rule and control. Thank you,

-----Original Message-----
From: Richard Whalen [mailto:***@process.com]
Sent: Wednesday, February 21, 2007 10:26 AM
To: info-***@process.com
Subject: RE: New time zone daylight savings rule for 2007

SYS$TIMEZONE_RULE generally does not change, so there is no
code to make this one time change.

If you are running NTP on MultiNet 5.0 or later, then you can
include call_dst_proc in NTP.CONF. This will execute
MULTINET:NTPD_DST_PROC.COM at startup and the change into DST.
You can use the command procedure to make sure that the logical
is set correctly. There is a template for NTPD_DST_PROC.COM in
MULTINET:NTPD_DST_PROC_COM.TEMPLATE

-----Original Message-----
From: Ross Smith [mailto:***@med.nyu.edu]
Sent: Wednesday, February 21, 2007 10:09 AM
To: info-***@process.com
Subject: Re: New time zone daylight savings rule for 2007

Patti Knien

2007-02-24 03:45:36 UTC

Permalink

Good day, Richard,
We also, like Cheryl, are only using Multinet for TCP/IP Telnet and NFS
as our software vendor (LANDATA) chose it to support their Escrow system
on VMS. We have not been applying patches and are hoping the DST issue
could be as simple as possible. Is our job scheduling dependent upon
patching or changing Multinet? Or can we bypass the whole conundrum by
changing the system time manually?

VMS 7.3
Multinet V5.4
Thanks,
Patti Knien
Systems Consultant
Pacific Northwest Title

________________________________

From: Blake, Cheryl A. [mailto:***@lahey.org]
Sent: Monday, February 19, 2007 3:47 AM
To: info-***@process.com
Subject: RE: New time zone daylight savings rule for 2007

Hi Richard,

if all we have to do to reset the spring ahead/fall behind is copy the
TIMZONES.DAT to TIMEZONES.LOCAL and modify it then why should we have to
install any MultiNet patches at all?

Especially if we're using MultiNet for nothing except TCPIP?

thanks,

Cheryl Blake

Senior Systems Engineer

Lahey Clinic

Burlington, MA

-----Original Message-----
From: Randy Johnson [mailto:***@sxc.com]
Sent: Friday, February 16, 2007 5:28 PM
To: Richard Whalen; info-***@process.com
Subject: RE: New timezone daylight savings rule for 2007

I am getting ready to test this, but I noticed that both NTP and XNTP

are DISABLED. Will this process help me??

Or should I apply the ECOs for Daylight Savings Time changes??

Or should I install the current version of Multinet??

Randy Johnson

-----Original Message-----

From: Richard Whalen [mailto:***@process.com]

Sent: Thursday, January 11, 2007 9:05 AM

To: Randy Johnson

Subject: RE: New timezone daylight savings rule for 2007

remove them from any ZONE lines that you copy from TIMEZONES.DAT to

TIMEZONES.LOCAL.

You only need to copy the ZONE line for the zone that your system is in.

-----Original Message-----

From: Randy Johnson [mailto:***@sxc.com]

Sent: Thursday, January 11, 2007 11:00 AM

To: Richard Whalen

Subject: RE: New timezone daylight savings rule for 2007

Richard,

Which lines do I remove the "COMPILED_IN" from, or do I remove all of

them??

Randy,

-----Original Message-----

From: Richard Whalen [mailto:***@process.com]

Sent: Wednesday, January 10, 2007 10:37 AM

To: Randy Johnson

Subject: RE: New timezone daylight savings rule for 2007

1. Yes, enter the rule as is, with the ">=" characters.

Sunday >= 8 is how SECOND SUNDAY is specified.

2. Just remove the "COMPILED_IN" portion of the line.

3. The method that we use to test is to set the time on

a test system, restart NTP and check to see if the

MULTINET_TIMEZONE logical has changed.

4. See answer 3.

5. Ask HP. I have seen some discussion on the ITRC forum

so I believe that they have patches for some versions of

VMS. (I can't currently get to the ITRC forums to give

you a pointer.

6. There are no plans for a patch that would accept SECOND,

THIRD, FOURTH or FIFTH. We use standard NTP code and

rules that many other systems use, and I don't believe

that you'll see any of them supporting SECOND.

-----Original Message-----

From: Randy Johnson [mailto:***@sxc.com]

Sent: Wednesday, January 10, 2007 12:19 PM

To: info-***@process.com

Cc: Richard Whalen

Subject: RE: New timezone daylight savings rule for 2007

I have the following questions:

1. Do I enter the rule as is (with the >= characters)?

2. Do I remove ALL "COMPILED_IN" characters or do I delete the whole

line(s)?

3. How can I test my changes to be sure it will work?

4. How can I tell if Multinet is managing the changing of the time for

daylight savings time?

5. Are there any other changes needed for OpenVMS?

6. Will Process be making a change to enter something other than FIRST

or LAST?

Randy Johnson

SXC Health Solutions

-----Original Message-----

From: Richard Whalen [mailto:***@process.com]

Sent: Tuesday, January 02, 2007 7:31 AM

To: info-***@process.com

Subject: Re: New timezone daylight savings rule for 2007

The parser only recognizes "FIRST" and "LAST".

To get second you have to use

Rule US 2007 DST 1:00 Sunday >= 8 March 2:00

First Sunday November 2:00

For those of you that are making this change, your timezones.local file

must

have the Zone lines

as well as the above rule. You'll want to remove the "COMPILED_IN" from

the

timezones.local file when you copy the rules from timezones.dat

n***@metso.com

2007-02-25 00:50:03 UTC

Permalink

Multinet V5.4 ???

Patti Knien <***@PNWT.com>
02/23/2007 10:45 PM
Please respond to
Info-***@process.com

To
info-***@process.com
cc

Subject
RE: New time zone daylight savings rule for 2007

Good day, Richard,
We also, like Cheryl, are only using Multinet for TCP/IP Telnet and NFS as
our software vendor (LANDATA) chose it to support their Escrow system on
VMS. We have not been applying patches and are hoping the DST issue could
be as simple as possible. Is our job scheduling dependent upon patching
or changing Multinet? Or can we bypass the whole conundrum by changing
the system time manually?

VMS 7.3
Multinet V5.4
Thanks,
Patti Knien
Systems Consultant
Pacific Northwest Title

From: Blake, Cheryl A. [mailto:***@lahey.org]
Sent: Monday, February 19, 2007 3:47 AM
To: info-***@process.com
Subject: RE: New time zone daylight savings rule for 2007

Hi Richard,

if all we have to do to reset the spring ahead/fall behind is copy the
TIMZONES.DAT to TIMEZONES.LOCAL and modify it then why should we have to
install any MultiNet patches at all?

Especially if we're using MultiNet for nothing except TCPIP?

thanks,
Cheryl Blake
Senior Systems Engineer
Lahey Clinic
Burlington, MA

-----Original Message-----
From: Randy Johnson [mailto:***@sxc.com]
Sent: Friday, February 16, 2007 5:28 PM
To: Richard Whalen; info-***@process.com
Subject: RE: New timezone daylight savings rule for 2007

I am getting ready to test this, but I noticed that both NTP and XNTP
are DISABLED. Will this process help me??

Or should I apply the ECOs for Daylight Savings Time changes??

Or should I install the current version of Multinet??

Randy Johnson

-----Original Message-----
From: Richard Whalen [mailto:***@process.com]
Sent: Thursday, January 11, 2007 9:05 AM
To: Randy Johnson
Subject: RE: New timezone daylight savings rule for 2007

remove them from any ZONE lines that you copy from TIMEZONES.DAT to
TIMEZONES.LOCAL.
You only need to copy the ZONE line for the zone that your system is in.

-----Original Message-----
From: Randy Johnson [mailto:***@sxc.com]
Sent: Thursday, January 11, 2007 11:00 AM
To: Richard Whalen
Subject: RE: New timezone daylight savings rule for 2007

Richard,

Which lines do I remove the "COMPILED_IN" from, or do I remove all of
them??

Randy,

-----Original Message-----
From: Richard Whalen [mailto:***@process.com]
Sent: Wednesday, January 10, 2007 10:37 AM
To: Randy Johnson
Subject: RE: New timezone daylight savings rule for 2007

1. Yes, enter the rule as is, with the ">=" characters.
Sunday >= 8 is how SECOND SUNDAY is specified.

2. Just remove the "COMPILED_IN" portion of the line.

3. The method that we use to test is to set the time on
a test system, restart NTP and check to see if the
MULTINET_TIMEZONE logical has changed.

4. See answer 3.

5. Ask HP. I have seen some discussion on the ITRC forum
so I believe that they have patches for some versions of
VMS. (I can't currently get to the ITRC forums to give
you a pointer.

6. There are no plans for a patch that would accept SECOND,
THIRD, FOURTH or FIFTH. We use standard NTP code and
rules that many other systems use, and I don't believe
that you'll see any of them supporting SECOND.

-----Original Message-----
From: Randy Johnson [mailto:***@sxc.com]
Sent: Wednesday, January 10, 2007 12:19 PM
To: info-***@process.com
Cc: Richard Whalen
Subject: RE: New timezone daylight savings rule for 2007

I have the following questions:

1. Do I enter the rule as is (with the >= characters)?

2. Do I remove ALL "COMPILED_IN" characters or do I delete the whole
line(s)?

3. How can I test my changes to be sure it will work?

4. How can I tell if Multinet is managing the changing of the time for
daylight savings time?

5. Are there any other changes needed for OpenVMS?

6. Will Process be making a change to enter something other than FIRST
or LAST?

Randy Johnson
SXC Health Solutions

-----Original Message-----
From: Richard Whalen [mailto:***@process.com]
Sent: Tuesday, January 02, 2007 7:31 AM
To: info-***@process.com
Subject: Re: New timezone daylight savings rule for 2007

The parser only recognizes "FIRST" and "LAST".
To get second you have to use

Rule US 2007 DST 1:00 Sunday >= 8 March 2:00
First Sunday November 2:00

For those of you that are making this change, your timezones.local file
must
have the Zone lines
as well as the above rule. You'll want to remove the "COMPILED_IN" from
the
timezones.local file when you copy the rules from timezones.dat

Ken Connelly

2007-02-25 01:09:39 UTC

Permalink

obviously not.

*> *Multinet V5.4* ???*

Richard Whalen

2007-02-26 15:29:19 UTC

Permalink

If you are going to change the time, then things should be ok for you you without the patch.
The patch is need so that NTP can do the time change for you, and so that SMTP can figure out the differential from UTC.

-----Original Message-----
From: Patti Knien [mailto:***@PNWT.com]
Sent: Friday, February 23, 2007 10:46 PM
To: info-***@process.com
Subject: RE: New time zone daylight savings rule for 2007

Good day, Richard,
We also, like Cheryl, are only using Multinet for TCP/IP Telnet and NFS as our software vendor (LANDATA) chose it to support their Escrow system on VMS. We have not been applying patches and are hoping the DST issue could be as simple as possible. Is our job scheduling dependent upon patching or changing Multinet? Or can we bypass the whole conundrum by changing the system time manually?

VMS 7.3
Multinet V5.4
Thanks,
Patti Knien
Systems Consultant
Pacific Northwest Title

_____

From: Blake, Cheryl A. [mailto:***@lahey.org]
Sent: Monday, February 19, 2007 3:47 AM
To: info-***@process.com
Subject: RE: New time zone daylight savings rule for 2007

Hi Richard,

if all we have to do to reset the spring ahead/fall behind is copy the TIMZONES.DAT to TIMEZONES.LOCAL and modify it then why should we have to install any MultiNet patches at all?

Especially if we're using MultiNet for nothing except TCPIP?

thanks,

Cheryl Blake

Senior Systems Engineer

Lahey Clinic

Burlington, MA

-----Original Message-----
From: Randy Johnson [mailto:***@sxc.com]
Sent: Friday, February 16, 2007 5:28 PM
To: Richard Whalen; info-***@process.com
Subject: RE: New timezone daylight savings rule for 2007

I am getting ready to test this, but I noticed that both NTP and XNTP

are DISABLED. Will this process help me??

Or should I apply the ECOs for Daylight Savings Time changes??

Or should I install the current version of Multinet??

Randy Johnson

-----Original Message-----

From: Richard Whalen [mailto:***@process.com]

Sent: Thursday, January 11, 2007 9:05 AM

To: Randy Johnson

Subject: RE: New timezone daylight savings rule for 2007

remove them from any ZONE lines that you copy from TIMEZONES.DAT to

TIMEZONES.LOCAL.

You only need to copy the ZONE line for the zone that your system is in.

-----Original Message-----

From: Randy Johnson [mailto:***@sxc.com]

Sent: Thursday, January 11, 2007 11:00 AM

To: Richard Whalen

Subject: RE: New timezone daylight savings rule for 2007

Richard,

Which lines do I remove the "COMPILED_IN" from, or do I remove all of

them??

Randy,

-----Original Message-----

From: Richard Whalen [mailto:***@process.com]

Sent: Wednesday, January 10, 2007 10:37 AM

To: Randy Johnson

Subject: RE: New timezone daylight savings rule for 2007

1. Yes, enter the rule as is, with the ">=" characters.

Sunday >= 8 is how SECOND SUNDAY is specified.

2. Just remove the "COMPILED_IN" portion of the line.

3. The method that we use to test is to set the time on

a test system, restart NTP and check to see if the

MULTINET_TIMEZONE logical has changed.

4. See answer 3.

5. Ask HP. I have seen some discussion on the ITRC forum

so I believe that they have patches for some versions of

VMS. (I can't currently get to the ITRC forums to give

you a pointer.

6. There are no plans for a patch that would accept SECOND,

THIRD, FOURTH or FIFTH. We use standard NTP code and

rules that many other systems use, and I don't believe

that you'll see any of them supporting SECOND.

-----Original Message-----

From: Randy Johnson [mailto:***@sxc.com]

Sent: Wednesday, January 10, 2007 12:19 PM

To: info-***@process.com

Cc: Richard Whalen

Subject: RE: New timezone daylight savings rule for 2007

I have the following questions:

1. Do I enter the rule as is (with the >= characters)?

2. Do I remove ALL "COMPILED_IN" characters or do I delete the whole

line(s)?

3. How can I test my changes to be sure it will work?

4. How can I tell if Multinet is managing the changing of the time for

daylight savings time?

5. Are there any other changes needed for OpenVMS?

6. Will Process be making a change to enter something other than FIRST

or LAST?

Randy Johnson

SXC Health Solutions

-----Original Message-----

From: Richard Whalen [mailto:***@process.com]

Sent: Tuesday, January 02, 2007 7:31 AM

To: info-***@process.com

Subject: Re: New timezone daylight savings rule for 2007

The parser only recognizes "FIRST" and "LAST".

To get second you have to use

Rule US 2007 DST 1:00 Sunday >= 8 March 2:00

First Sunday November 2:00

For those of you that are making this change, your timezones.local file

must

have the Zone lines

as well as the above rule. You'll want to remove the "COMPILED_IN" from

the

timezones.local file when you copy the rules from timezones.dat

Richard Whalen

2007-02-26 16:22:01 UTC

Permalink

Creating a TIMEZONES.LOCAL with the necessary information in it should be sufficient.

-----Original Message-----
From: Blake, Cheryl A. [mailto:***@lahey.org]
Sent: Monday, February 26, 2007 11:02 AM
To: info-***@process.com
Subject: RE: New time zone daylight savings rule for 2007

Thanks Richard,

just like to clarify this...

if we copy TIMEZONES.DAT to TIMEZONES.LOCAL and edit it as recommended

do any of the patches need to be installed?

Thanks,

Cheryl

-----Original Message-----
From: Richard Whalen [mailto:***@process.com]
Sent: Monday, February 26, 2007 10:29 AM
To: info-***@process.com
Subject: RE: New time zone daylight savings rule for 2007

If you are going to change the time, then things should be ok for you you without the patch.

The patch is need so that NTP can do the time change for you, and so that SMTP can figure out the differential from UTC.

-----Original Message-----

From: Patti Knien [mailto:***@PNWT.com]

Sent: Friday, February 23, 2007 10:46 PM

To: info-***@process.com

Subject: RE: New time zone daylight savings rule for 2007

Good day, Richard,

We also, like Cheryl, are only using Multinet for TCP/IP Telnet and NFS as our software vendor (LANDATA) chose it to support their Escrow system on VMS. We have not been applying patches and are hoping the DST issue could be as simple as possible. Is our job scheduling dependent upon patching or changing Multinet? Or can we bypass the whole conundrum by changing the system time manually?

VMS 7.3

Multinet V5.4

Thanks,

Patti Knien

Systems Consultant

Pacific Northwest Title

_____

From: Blake, Cheryl A. [mailto:***@lahey.org]

Sent: Monday, February 19, 2007 3:47 AM

To: info-***@process.com

Subject: RE: New time zone daylight savings rule for 2007

Hi Richard,

if all we have to do to reset the spring ahead/fall behind is copy the TIMZONES.DAT to TIMEZONES.LOCAL and modify it then why should we have to install any MultiNet patches at all?

Especially if we're using MultiNet for nothing except TCPIP?

thanks,

Cheryl Blake

Senior Systems Engineer

Lahey Clinic

Burlington, MA

-----Original Message-----

From: Randy Johnson [mailto:***@sxc.com]

Sent: Friday, February 16, 2007 5:28 PM

To: Richard Whalen; info-***@process.com

Subject: RE: New timezone daylight savings rule for 2007

I am getting ready to test this, but I noticed that both NTP and XNTP

are DISABLED. Will this process help me??

Or should I apply the ECOs for Daylight Savings Time changes??

Or should I install the current version of Multinet??

Randy Johnson

-----Original Message-----

From: Richard Whalen [mailto:***@process.com]

Sent: Thursday, January 11, 2007 9:05 AM

To: Randy Johnson

Subject: RE: New timezone daylight savings rule for 2007

remove them from any ZONE lines that you copy from TIMEZONES.DAT to

TIMEZONES.LOCAL.

You only need to copy the ZONE line for the zone that your system is in.

-----Original Message-----

From: Randy Johnson [mailto:***@sxc.com]

Sent: Thursday, January 11, 2007 11:00 AM

To: Richard Whalen

Subject: RE: New timezone daylight savings rule for 2007

Richard,

Which lines do I remove the "COMPILED_IN" from, or do I remove all of

them??

Randy,

-----Original Message-----

From: Richard Whalen [mailto:***@process.com]

Sent: Wednesday, January 10, 2007 10:37 AM

To: Randy Johnson

Subject: RE: New timezone daylight savings rule for 2007

1. Yes, enter the rule as is, with the ">=" characters.

Sunday >= 8 is how SECOND SUNDAY is specified.

2. Just remove the "COMPILED_IN" portion of the line.

3. The method that we use to test is to set the time on

a test system, restart NTP and check to see if the

MULTINET_TIMEZONE logical has changed.

4. See answer 3.

5. Ask HP. I have seen some discussion on the ITRC forum

so I believe that they have patches for some versions of

VMS. (I can't currently get to the ITRC forums to give

you a pointer.

6. There are no plans for a patch that would accept SECOND,

THIRD, FOURTH or FIFTH. We use standard NTP code and

rules that many other systems use, and I don't believe

that you'll see any of them supporting SECOND.

-----Original Message-----

From: Randy Johnson [mailto:***@sxc.com]

Sent: Wednesday, January 10, 2007 12:19 PM

To: info-***@process.com

Cc: Richard Whalen

Subject: RE: New timezone daylight savings rule for 2007

I have the following questions:

1. Do I enter the rule as is (with the >= characters)?

2. Do I remove ALL "COMPILED_IN" characters or do I delete the whole

line(s)?

3. How can I test my changes to be sure it will work?

4. How can I tell if Multinet is managing the changing of the time for

daylight savings time?

5. Are there any other changes needed for OpenVMS?

6. Will Process be making a change to enter something other than FIRST

or LAST?

Randy Johnson

SXC Health Solutions

-----Original Message-----

From: Richard Whalen [mailto:***@process.com]

Sent: Tuesday, January 02, 2007 7:31 AM

To: info-***@process.com

Subject: Re: New timezone daylight savings rule for 2007

The parser only recognizes "FIRST" and "LAST".

To get second you have to use

Rule US 2007 DST 1:00 Sunday >= 8 March 2:00

First Sunday November 2:00

For those of you that are making this change, your timezones.local file

must

have the Zone lines

as well as the above rule. You'll want to remove the "COMPILED_IN" from

the

timezones.local file when you copy the rules from timezones.dat

Patti Knien

2007-02-27 08:49:28 UTC

Permalink

Thank you - sorry I got the release wrong. It is such a great system, I
rarely have to touch it! Bill's world needs much more hand holding.
-Patti

-----Original Message-----
From: Richard Whalen [mailto:***@process.com]
Sent: Monday, February 26, 2007 7:29 AM
To: info-***@process.com
Subject: RE: New time zone daylight savings rule for 2007

If you are going to change the time, then things should be ok for you
you without the patch.
The patch is need so that NTP can do the time change for you, and so
that SMTP can figure out the differential from UTC.

-----Original Message-----
From: Patti Knien [mailto:***@PNWT.com]
Sent: Friday, February 23, 2007 10:46 PM
To: info-***@process.com
Subject: RE: New time zone daylight savings rule for 2007

Good day, Richard,
We also, like Cheryl, are only using Multinet for TCP/IP Telnet and NFS
as our software vendor (LANDATA) chose it to support their Escrow system
on VMS. We have not been applying patches and are hoping the DST issue
could be as simple as possible. Is our job scheduling dependent upon
patching or changing Multinet? Or can we bypass the whole conundrum by
changing the system time manually?

VMS 7.3
Multinet V5.4
Thanks,
Patti Knien
Systems Consultant
Pacific Northwest Title

_____

From: Blake, Cheryl A. [mailto:***@lahey.org]
Sent: Monday, February 19, 2007 3:47 AM
To: info-***@process.com
Subject: RE: New time zone daylight savings rule for 2007

Hi Richard,

if all we have to do to reset the spring ahead/fall behind is copy the
TIMZONES.DAT to TIMEZONES.LOCAL and modify it then why should we have to
install any MultiNet patches at all?

Especially if we're using MultiNet for nothing except TCPIP?

thanks,

Cheryl Blake

Senior Systems Engineer

Lahey Clinic

Burlington, MA

-----Original Message-----
From: Randy Johnson [mailto:***@sxc.com]
Sent: Friday, February 16, 2007 5:28 PM
To: Richard Whalen; info-***@process.com
Subject: RE: New timezone daylight savings rule for 2007

I am getting ready to test this, but I noticed that both NTP and XNTP

are DISABLED. Will this process help me??

Or should I apply the ECOs for Daylight Savings Time changes??

Or should I install the current version of Multinet??

Randy Johnson

-----Original Message-----

From: Richard Whalen [mailto:***@process.com]

Sent: Thursday, January 11, 2007 9:05 AM

To: Randy Johnson

Subject: RE: New timezone daylight savings rule for 2007

remove them from any ZONE lines that you copy from TIMEZONES.DAT to

TIMEZONES.LOCAL.

You only need to copy the ZONE line for the zone that your system is in.

-----Original Message-----

From: Randy Johnson [mailto:***@sxc.com]

Sent: Thursday, January 11, 2007 11:00 AM

To: Richard Whalen

Subject: RE: New timezone daylight savings rule for 2007

Richard,

Which lines do I remove the "COMPILED_IN" from, or do I remove all of

them??

Randy,

-----Original Message-----

From: Richard Whalen [mailto:***@process.com]

Sent: Wednesday, January 10, 2007 10:37 AM

To: Randy Johnson

Subject: RE: New timezone daylight savings rule for 2007

1. Yes, enter the rule as is, with the ">=" characters.

Sunday >= 8 is how SECOND SUNDAY is specified.

2. Just remove the "COMPILED_IN" portion of the line.

3. The method that we use to test is to set the time on

a test system, restart NTP and check to see if the

MULTINET_TIMEZONE logical has changed.

4. See answer 3.

5. Ask HP. I have seen some discussion on the ITRC forum

so I believe that they have patches for some versions of

VMS. (I can't currently get to the ITRC forums to give

you a pointer.

6. There are no plans for a patch that would accept SECOND,

THIRD, FOURTH or FIFTH. We use standard NTP code and

rules that many other systems use, and I don't believe

that you'll see any of them supporting SECOND.

-----Original Message-----

From: Randy Johnson [mailto:***@sxc.com]

Sent: Wednesday, January 10, 2007 12:19 PM

To: info-***@process.com

Cc: Richard Whalen

Subject: RE: New timezone daylight savings rule for 2007

I have the following questions:

1. Do I enter the rule as is (with the >= characters)?

2. Do I remove ALL "COMPILED_IN" characters or do I delete the whole

line(s)?

3. How can I test my changes to be sure it will work?

4. How can I tell if Multinet is managing the changing of the time for

daylight savings time?

5. Are there any other changes needed for OpenVMS?

6. Will Process be making a change to enter something other than FIRST

or LAST?

Randy Johnson

SXC Health Solutions

-----Original Message-----

From: Richard Whalen [mailto:***@process.com]

Sent: Tuesday, January 02, 2007 7:31 AM

To: info-***@process.com

Subject: Re: New timezone daylight savings rule for 2007

The parser only recognizes "FIRST" and "LAST".

To get second you have to use

Rule US 2007 DST 1:00 Sunday >= 8 March 2:00

First Sunday November 2:00

For those of you that are making this change, your timezones.local file

must

have the Zone lines

as well as the above rule. You'll want to remove the "COMPILED_IN" from

the

timezones.local file when you copy the rules from timezones.dat

See our web page at http://www.lahey.org for a full directory of Lahey
sites, staff, services and career opportunities.

THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS
ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL
AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the
intended recipient, your use of this message for any purpose is strictly
prohibited. If you have received this communication in error, please
delete the message and notify the sender so that we may correct our
records.

_____

This email is intended solely for the use of the individual to whom it
is addressed. If you are not the intended recipient, be advised that you
have received this email in error and that any use, dissemination,
forwarding, printing, or copying of this email is strictly prohibited.
Although this email has been scanned for the possible presence of
computer viruses prior to dispatch, we cannot be held responsible for
any viruses or other material transmitted with, or as part of, this
email without our knowledge. Thank you.

This email is intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. Although this email has been scanned for the possible presence of computer viruses prior to dispatch, we cannot be held responsible for any viruses or other material transmitted with, or as part of, this email without our knowledge. Thank you.