01-04-2008 11:17 AM
Campus Manager Home shows Device Discovery and Data Collection times to be SIX hours ahead of the (correct) Last Updated Time:
Auto Refresh Version : 4.0.9 Last Updated: 04 Jan 2008, 13:06:46 CST
System Status
Operation Last Completion Time Result Status Action
Device Discovery 04 Jan 2008, 19:01:15 CST 46 Devices Idle Start Device Discovery
Data Collection 04 Jan 2008, 19:04:32 CST 46 Devices Idle Start Data Collection
User Tracking Acquisition 04 Jan 2008, 12:39:14 CST 2191 End Hosts
0 IP Phones Idle Start UT Acquisition
No Forum postings or Tech Support items relating to this have been located. (Cannot add as attachment).
01-09-2008 12:26 PM
01-09-2008 12:28 PM
01-09-2008 01:02 PM
Yes, this completes the request, but it does not indicate why the timezone is not being properly read by Java. You should follow back up on your TAC services request as remote access will be needed.
01-09-2008 01:22 PM
Remote access is not possible -- can you please consult with Ken Viola to obtain a different workaround, or to arrange a Remote Access session on his server, or on a test device he may have in his network that might be accessible?
01-09-2008 03:32 PM
Joe: Was the other report of this you saw from an IRS device? Actually, not all of our servers have this issue, apparently, so we may need to perform some more advanced server diagnostics on our own. Thank you for assisting.
01-09-2008 03:37 PM
Yes, it was your service request. While you may have some registry corruption, I would expect to see it in the keys I've requested. As I said, getting Meeting Place access to this server would have to be our next step so we could run some more advanced diagnostics.
You could also rule out a Java problem by running the locale application in the following way:
NMSROOT\MDC\jre\bin\java -Duser.timezone=America/Chicago locale
If that returns the correct CST timezone, the problem lies on the Windows side in the registry.
01-10-2008 02:20 PM
Input and output: did this return the correct CST timezone? A bit at loss for how to tell:
Input:
d:/CSCOpx/MDC/jre/bin
java -Duser.timzone=America/Chicago locale
Output results:
D:\CSCOpx\MDC\JRE\bin>java -Duser.timezone=America/Chicago
locale Locale = en_US Timezone =
D:\CSCOpx\MDC\JRE\bin>java -Duser.timezone=America/Chicago
locale
Locale = en_US Timezone =
java.util.SimpleTimeZone[id=America/Chicago,offset=-2160000
0,dstSavin
gs=3600000,useDaylight=true,startYear=0,startMode=3,startMo
nth=2,startDay=8,star
tDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,en
dMonth=10,endDay=1,en
dDayOfWeek=1,endTime=7200000,endTimeMode=0]
01-10-2008 02:22 PM
Avoiding duplication in the posting, as done, unfortunately, above:
Output results:
D:\CSCOpx\MDC\JRE\bin>java -Duser.timezone=America/Chicago
locale Locale = en_US Timezone =
java.util.SimpleTimeZone[id=America/Chicago,offset=-2160000
0,dstSavin
gs=3600000,useDaylight=true,startYear=0,startMode=3,startMo
nth=2,startDay=8,star
tDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,en
dMonth=10,endDay=1,en
dDayOfWeek=1,endTime=7200000,endTimeMode=0]
01-10-2008 02:45 PM
This is the correct output that I would expect to see without the -Duser.timezone argument. Therefore, the problem lies on the Windows side. Java is unable to map the Windows timezone, Central Standard Time, to the Java timezone, America/Chicago.
01-10-2008 02:48 PM
As a Meeting Place session is not possible (I prefer to keep my job), can you provide us with Registry items to compare between a server that is functioning correctly and one that is not? Thanks for any assistance you can provide. My e-mail is available through Ken Viola, whose contact information you should have.
01-10-2008 02:56 PM
I've already given you all of the registry keys that should be used by Java to obtain the timezone information. All of them check out.
The way it should work is the JVM reads through all of the keys under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\TimeZones until it finds the timezone configured in the TimeZoneInformation key. Once it does, it uses the map value (36,37 in this case) to map that timezone to a Java timezone using the tzmappings file.
Something is not happening properly there, but without deep process inspection, I cannot say what that is.
01-10-2008 03:04 PM
There is one other key that may be of interest. What are the values at HKLM\SYSTEM\Select?
01-11-2008 09:58 AM
Attached are the requested values and also a download message about the most recent Java loaded on the SErver (could that be the problem source?) and sample output from the Java Console (many duplicate messages removed to reduce repetition). Had to remove a screen capture of the Java download verification screen, but details of the most current Java as being loaded on the machine are transcribed.
01-11-2008 02:33 PM
This doesn't shed any new light on the problem. I gave more details to Harold. Follow up with him on your SR.
01-11-2008 02:35 PM
Thanks for your efforts on this, Joe. Will follow up with Harold when I return on Jan. 22nd, meanwhile, will give Harold the e-mail addresses of some of our other specialists, if they have time to pursue this.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide