I still have a few questions that I am unclear on regarding the technical
bulletin...

We are on 6.0.3 patch 20...

- Do we still need to set the TZ setting on the Client (Windows XP OS) even
though our server is HP-UX?
- Do our client PCs need the MSVCRT.DLL hotfix or is that a Windows server
only fix?

Thanks!
Mike

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Easter, David
Sent: Friday, March 09, 2007 8:55 AM
To: arslist@ARSLIST.ORG
Subject: Re: Additional information about DST event and how it affects AR
System

If you use TZ -and- load the hot fix from Microsoft for MSVCRT.DLL, then
the historical data issue will not occur.

If you just use TZ, you will see the historical data issue.

Thanks, 

-David J. Easter
Sr. Product Manager, Service Management Business Unit
BMC Software, Inc.
 
The opinions, statements, and/or suggested courses of action expressed
in this E-mail do not necessarily reflect those of BMC Software, Inc.
My voluntary participation in this forum is not intended to convey a
role as a spokesperson, liaison or public relations representative for
BMC Software, Inc.


-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Kyle Whitley
Sent: Friday, March 09, 2007 5:44 AM
To: arslist@ARSLIST.ORG
Subject: Re: Additional information about DST event and how it affects
AR System

>
> For AR System 6.03 or 6.0.1: "If your client and/or server needs to be

> set to use a United States time zone, you will need to load a hot fix 
> from Microsoft and set the TZ variable at your client or server.
> Failure to do this will cause some displayed and submitted historical 
> dates to be off by one hour."
David,

Does this mean if we are setting our clients with a TZ that these issues
should not occur?

Thanks

Kyle

Easter, David wrote:
> Hi All,
>  
>    As mentioned on this list, we've discovered another consequence of 
> the start/end date shift in DST for the US/Canada that is caused by a 
> deficiency in the Microsoft Operating System.  Due to the heightened 
> sensitivity to DST related issues has worked directly with Microsoft 
> to provide a solution to our customers.  BMC has updated the technical

> bulletins for DST found on Support Central to reflect this new 
> information and document the potential solution available from BMC and

> Microsoft.
>
> Because of the complexity of the situation, the technical bulletins 
> have now been broken up into three versions - representing the three 
> supported versions of AR System currently available (i.e. 6.0.1, 6.03,

> 7.0.01).  AR System 5.1.2 customers should read the 6.0.1 technical 
> bulletin as 5.1.2 and 6.0.1 will exhibit nearly the same symptoms.
> Please read the bulletins carefully - information within the bulletin 
> varies by version, so answers for one version may not apply to another

> version. The bulletins are posted at 
> http://www.bmc.com/support/hou_Support_AZ_List/#R under AR System and 
> the appropriate version.  [Due to a back-office glitch, some bulletins

> may not be available until after 9pm CST on 3/8/07 or later...]
>
> The short summary of the additional information in the technical 
> bulletin is this:
>
> For AR System 7.0.01: "If your client and/or server needs to be set to

> use a United States time zone, you will need to load a hot fix from 
> BMC (or patch 002) and set the TZ variable at your client or server.
> Failure to do this will cause some displayed and submitted historical 
> dates to be off by one hour."
>  
> For AR System 6.03 or 6.0.1: "If your client and/or server needs to be

> set to use a United States time zone, you will need to load a hot fix 
> from Microsoft and set the TZ variable at your client or server.
> Failure to do this will cause some displayed and submitted historical 
> dates to be off by one hour."
>
> The more detailed explanation is as follows:
>
> Windows Update distributes Windows operating system fixes that will 
> make sure clocks are adjusted correctly moving forward. However, this 
> Microsoft-supplied operating system patch resolves only the DST issue 
> for 2007 and itself introduces an additional DST-related defect. After

> the operating system is patched, historical data might be incorrect.
> Because AR System stores and processes historical data, it is
affected. 
>
> Details: Microsoft Windows 2000, XP, and 2003 store only one set of 
> DST rules for each time zone. If you display or submit a date in the 
> past that falls into the weeks involved in the DST changes, a call is 
> made to the operating system to obtain local time. This call to the 
> operating system applies the new 2007 rules to historical dates and is

> off by one hour. Based on conversations between Microsoft and BMC, 
> Microsoft is looking at a Design Change Request (DCR) for storing 
> multiple DST rules, but this change is not guaranteed and, even if 
> created, is not expected to be available before this summer.
>
> This discrepancy affects historical dates in the years prior to 2007 
> (that is, 2006 and earlier). The range of dates affected varies from 
> year to year as defined by the new DST 2007 rules, which include these
> statements:
>
> - DST will begin on the second Sunday in March instead of the first 
> Sunday in April.
> - DST will end on the first Sunday in November instead of the last 
> Sunday in October.
>
> Thus dates between the second Sunday in March and the first Sunday in 
> April for years prior to 2006 will be affected. In the same way, dates

> between the last Sunday in October and the first Sunday in November 
> will be affected.
>
> Note that this issue will occur independently of the current time and 
> date. Thus the issue can be seen immediately after installing the 
> Microsoft operating system patch and will continue even if the current

> local date is beyond the discrepancy between legacy and new DST dates.
>
> There are pretty pictures in the technical bulletins that show the 
> issue, but simply put the effects are as follows:
>
> For Remedy User; if the time zone is not set through the AR System 
> User Preference form or preference server, the following behavior
occurs:
>
> -  For Standard Time to Daylight Saving Time,  BMC Remedy User will 
> display data as one hour earlier than what is stored in the database 
> for dates between the second Sunday in March and the first Sunday in 
> April in years prior to 2007.  The opposite occurs (i.e. time will be 
> one hour
> later) when the date is in the Daylight Saving Time to Standard Time 
> shift.
>
> - For Standard Time to Daylight Saving Time, the data submitted from 
> BMC Remedy User will be written to the database as one hour later than

> what is in the submitted field for dates between the second Sunday in 
> March and the first Sunday in April in years prior to 2007.  The 
> opposite occurs (i.e. time will be one hour less) when the date is in 
> the Daylight Saving Time to Standard Time shift.
>
> The same thing happens on the AR System server.  If the operating 
> system environment variable TZ is not set, the following behavior
occurs:
>
> - Std to DST: Data written by the server within the server itself (for

> example, through a push field or related workflow) will be one hour 
> later than what is expected for dates between the second Sunday in 
> March and the first Sunday in April in years prior to 2007.  DST to 
> Std is the opposite (time will be one hour earlier).
>
> - Std to DST: Data read from an existing field by the server for use 
> within workflow will be one hour earlier than what is in the field for

> dates between the second Sunday in March and the first Sunday in April

> in years prior to 2007. DST to Std is the opposite (time will be one 
> hour later).
>
> The fix is a replacement of some system DLL's (msvcp71.dll & 
> msvcr71.dll for 7.0.01 and msvcrt.dll for 5.1.2 - 6.03) and the fix 
> requires no code changes to AR System. In other words, the files are 
> MSFT files that can be dropped onto a system without requiring another

> patched version of AR System beyond the already distributed patches. 
> It does, however, require using either the TZ environment variable 
> from the OS or setting the timezone within the user tool preferences
(or a preference server).
>
> As mentioned above, for 7.0.01 you can contact BMC to obtain the 
> corrected msvcp71.dll & msvcr71.dll.  For customers on 6.03 or 
> earlier, you'll have to contact Microsoft.  The KB for obtaining 
> msvcrt.dll is http://support.microsoft.com/?id=932590.
>  
> One gotcha is that Microsoft is only supplying the fix at no cost for 
> Windows XP and Windows 2003 [and Vista - but Vista doesn't have the 
> original problem].  They will offer the fix for $4000 USD for 
> customers running Windows 2000 (Win 2K is out of it's primary support
window).
> They have not indicated to BMC that they'll provide the fix for any 
> other operating systems.  So if a customers is running Windows NT, 
> Windows ME, Windows 98 or other older operating systems, the customer 
> will have to contact Microsoft directly.
>  
> Thanks,
>  
> -David J. Easter
> Sr. Product Manager, Service Management Business Unit BMC Software, 
> Inc.
>  
> The opinions, statements, and/or suggested courses of action expressed

> in this E-mail do not necessarily reflect those of BMC Software, Inc.
> My voluntary participation in this forum is not intended to convey a 
> role as a spokesperson, liaison or public relations representative for

> BMC Software, Inc.
>
>
>  
>
>       
>
>  
>
>  
>
>  
>
> ________________________________
>
> From: Easter, David
> Sent: Thursday, February 01, 2007 4:54 PM
> To: Virtual Team - Remedy; Virtual Team - Service Management
> Subject: Additional information about DST event and how it affects AR 
> System
> Importance: High
>
>
> All,
>  
>   I posted this previously, but we're still getting a flood of E-mails

> asking questions answered in the tech bulletin, so I will post it
again.
> PLEASE READ IT!   Not only does it describe the patches needed for AR
> System 6.3 and 7.0.01, the bulletin also contains information about 
> the effects of not patching or upgrading systems. It can be also be 
> found on Support Central in the documentation section for AR System:
>  
> Documentation section for AR System:
> http://www.bmc.com/support/hou_Support_ProdAllVersions/0,3646,19097_19
> 69
> 5_108018_0,00.html
> Specific link to Technical Bulletin:
> http://www.bmc.com/supportu/documents/78/29/67829/67829.pdf
>  
> The most common additional question that comes up is "Can I get the 
> same information for 5.1.2?".  The answer at the moment is that 5.1.2 
> will most likely encounter similar effects as documented for 6.0.1.  
> However, since 5.1.2 is unsupported, BMC has not done any testing 
> specifically on 5.1.2.  5.1.2 customers should review the technical 
> bulletin and review the documented effects of the DST event on 6.0.1.

> Customers may find that they are minimally or not at all affected.
>  
> (For those that didn't know 5.1.2 was unsupported, you can review the 
> support policy for BMC at:
> http://www.bmc.com/info_center_support/overview/0,,19097_4736154_40737
> 59
> 6,00.html)
>  
> The second most common question is "Why aren't we patching 6.0.1 if it

> that release supported?".  The quick answer to this question is: "The 
> affected library in AR System is provided by a 3rd party vendor.  The 
> AR System patches for 6.03 and 7.0.01 are passing the DST updates to 
> that library from that vendor to our user base.  However, the vendor 
> that provides this library is not providing a patch to the version of 
> the library used in 6.0.1.  Thus we cannot provide a fix for 6.0.1.  
> That being said, the use of the affected library was minimal in AR 
> System
> 6.0.1 and the two primary affected areas are web services and 
> import/export.  AR System 6.0.1 customers not using web services or
> import/export may be minimally or not at all affected.   Please review
> the technical bulletin for more details on the documented effects of 
> the DST event on 6.0.1."
>  
> As with anything of this nature, BMC strongly recommends that 
> customers test the effects of the DST 2007 event in their development 
> environment to fully understand what impact the DST event will have on

> their environment.
>  
> Thanks,
>  
> David J. Easter
> Product Line Manager   BMC Software <http://www.bmc.com/>     
> AR System - BMC Service Management Business Unit
> +001 (408) 571-7384
>
>       
>
>  
>
>  
>
>  
>
> ______________________________________________________________________
> _________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org 
> ARSlist:"Where the Answers Are"
>
>   

--
Kyle Whitley
IT System Support Professional
Office of Information and Instructional Technology (OIIT) Board of
Regents of the University System of Georgia

________________________________________________________________________
_______
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where
the Answers Are"

____________________________________________________________________________
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the
Answers Are"

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the 
Answers Are"

Reply via email to