10-04-2005 05:16 AM
Hi,
It's my understanding that Ciscoworks LMS gets it's clock from the server that it's installed on. This doesn't seem to be the case on our LMS 2.2 installation. Ciscoworks is an hour behind the system clock ? Stopping and starting the services doesn't seem to help.
Regards
J
Solved! Go to Solution.
10-05-2005 02:25 AM
When you search the BugTool on CCO there are some issues with RME and daylight saving time.
And perhaps you are running into
CSCeb45819 Bug Details
Problem:
Using cwconfig to scehedule, for example, NetConfig jobs, will adjust the
specified time +/- one hour if the job is to be run after a daylight savings
time boundary.
Symptom:
If a NetConfig job is scheduled using cwconfig during daylight time, but the
job is scheduled to run during standard time, the job's time will be
scheduled one hour earlier.
Workaround:
When scheduling jobs beyond a daylight savings time boundary, take the offset
into account. That is, if it is currently daylight time, and the job will
be run during standard time, schedule it for one hour later. If it is
currently standard time, and the job is to be run during daylight time,
schedule it for one hour earlier. Alternatively, the NetConfig GUI can be
used to schedule jobs independent of daylight savings changes.
There is also a patch available by calling the TAC.
-- Are you using jobs that have been setup before start of DST? If yes, then I would say you hit the bug anyway if you are using cwconfig or the GUI.
Try to recreate the job, I think this should help.
Martin
10-04-2005 09:12 PM
Hai,
Your understanding is 100% correct. Ciscoworks get its clock from server installed.
Or whther your network is configured for any NTP synchronization???
Please check the time and Timezone on your server.
restart the services.
I dont find any other clue sorry
10-05-2005 01:24 AM
The timezone's correct and we've tried stopping and starting the services. Thanks for your reply.
J
10-04-2005 10:39 PM
In which applications do you see this happen?
If it is Syslog then perhaps you have to set the correct Country Code in the config file Sa.Properties. Look at the following links for details:
HTH,
Martin
10-05-2005 01:28 AM
Marin,
Thanks for your reply. The problem comes when we have to schedule jobs or backups. We're in daylight saving time but Ciscoworks doesn't seem to have picked up the change.
Cheers
J
10-05-2005 02:25 AM
When you search the BugTool on CCO there are some issues with RME and daylight saving time.
And perhaps you are running into
CSCeb45819 Bug Details
Problem:
Using cwconfig to scehedule, for example, NetConfig jobs, will adjust the
specified time +/- one hour if the job is to be run after a daylight savings
time boundary.
Symptom:
If a NetConfig job is scheduled using cwconfig during daylight time, but the
job is scheduled to run during standard time, the job's time will be
scheduled one hour earlier.
Workaround:
When scheduling jobs beyond a daylight savings time boundary, take the offset
into account. That is, if it is currently daylight time, and the job will
be run during standard time, schedule it for one hour later. If it is
currently standard time, and the job is to be run during daylight time,
schedule it for one hour earlier. Alternatively, the NetConfig GUI can be
used to schedule jobs independent of daylight savings changes.
There is also a patch available by calling the TAC.
-- Are you using jobs that have been setup before start of DST? If yes, then I would say you hit the bug anyway if you are using cwconfig or the GUI.
Try to recreate the job, I think this should help.
Martin
10-05-2005 02:37 AM
Martin,
Nice one, I did take a look at the Bug Tools but I missed that solution it looks like this may be the bug that were hitting. I'll contact TAC for the patch.
Regards
J
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