Since those are not viable options here, we will be forced to remain in production with a product with a known time error. Hopefully the impact of the DST change will be soaked up by the OS and barely visible to the ITSM 5.5 application - it doesn't make very sophisticated use of time as I recall. The BMC web page provides only thin speculation on what the effects might be. I certainly don't have time to test it, or re-purpose hardware assets to upgrade it to an ARS level we haven't tested yet unless I abandon our current effort to implement ITSM 7. <RANT> From what I have seen and experienced with the 7.0/7.0.01 ARS and ITSM installers and code for the last three months, there is no way this thing will be production-ready before March. We never seem to quite get to the point of configuring the applications (which will be a HUGE endeavor with IM, PM, CM, and SLM using multi-tenancy and back-end customer data imports) to where we can seriously test all of the functionality before we uncover yet another fundamental infrastructure problem that takes several more weeks to resolve (Crystal Reports Server integration since the very beginning and still broken; several weeks ago it was the CMDB 2.0.1 installer until I gave up and rebuilt the entire server, then a slew of issues with RKM, and now it's the AREA LDAP integration which is _very_ fundamental). In fact, the lack of working AREA integration to LDAP means that I could not migrate the existing 5.5 application to a 7.0.01 server anyway; it doesn't work, or at least not right now! Some of this may turn out to be on us, or because of our environment or the x64 AR servers, but so far that has seldom been the case except where I strongly objected to running SQL Server authentication for one thing or another that couldn't/wouldn't do Windows authentication. A real time-killer has been that every time support tells me to revert to an earlier db backup to re-try an installation, I lose any configuration data that I have stored while waiting on some sort of resolution, so I have given up on doing that for now. My application administrator keeps experimenting with configuration on a test installation that we know we will have to rebuild from scratch, but it will have to be manually recreated on the dev system I keep rebuilding. At this point I wish that the application code and the application configuration data were stored in separate databases so we that could save or migrate the configuration independent of the code. Eventually we will beat this crap into submission, but at this rate it will not be before March, and probably not with version 7.0.01. </RANT> I certainly do not want to implement ITSM 7 half-baked and full of known problems or limitations - that would just give ammunition to those parties here that already want to switch call-tracking vendors. On the other hand, if there is a serious problem with the 5.5 application on ARS 5.1.2 once March rolls around, we may have to do just that and take the hits. What are the rest of you in similar situations thinking??? Christopher Strauss, Ph.D. Remedy Database Administrator University of North Texas Computing Center http://remedy.unt.edu/
_____ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Easter, David Sent: Wednesday, December 06, 2006 3:37 PM To: [email protected] Subject: Re: Daylight savings time again ** AR System 5.1.2 is unsupported and there are no plans to patch AR System 5.1.2 for DST issues. If you look at the chart, the resolution is: "Install AR system 6.03 with Patch 20, or 7.0.01. Follow instructions for those AR releases." The reason it says 1/15/2007 for the resolution date is because that is when the Patch 20 for AR System 6.03 will be available. Note that, as posted by me earlier, that 7.0.01 will also require patch 001 which should be out by end of this month. The chart will be updated with this information shortly. Thanks, -David J. Easter Sr. Product Manager, Service Management Business Unit BMC Software, Inc. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
