Another DST agent question with repeating calendar entries

Hello,

I have been running the DST agent from my server and it seems to work pretty well. But I do have a problem for some of my users. I’ll run the agent against their mail file. I don’t get any errors on the console, but it says 0 of 24 processed. When I look at the persons calendar entries for the 3 week time period, all the entries are repeating entries. There is a little blurb underneath the type of calendar entry saying " This is a draft placeholder for your repeating meeting. Changes to this note will apply to the enitre set when sent to invitees. Original Meeting invitation. No actions are allowed.

I looked at the StartTimeZone property and it is still set to the old DST standard.

Can anyone tell me why these aren’t updating?

[14E4:000C-0470] 03/02/2007 12:07:27 PM Agent Manager: Agent printing: Starting loop: 3/2/2007 12:07:27 PM

[14E4:000C-0470] 03/02/2007 12:07:27 PM Agent Manager: Agent printing: Started processing: mail\bferrel at: 3/2/2007 12:07:27 PM

[14E4:000C-0470] 03/02/2007 12:07:27 PM Agent Manager: Agent printing: Successfully processed 0 of 24 entries

[14E4:000C-0470] 03/02/2007 12:07:27 PM Agent Manager: Agent printing: Ending loop: 3/2/2007 12:07:27 PM

[14E4:000C-0470] 03/02/2007 12:07:27 PM Agent Manager: Agent printing: Total processing time (in seconds): 0

[14E4:000C-0470] 03/02/2007 12:07:27 PM Agent Manager: Agent printing: Total documents per database:

[14E4:000C-0470] 03/02/2007 12:07:27 PM Agent Manager: Agent printing: mail\bferrel: 24

[14E4:000C-0470] 03/02/2007 12:07:27 PM Agent Manager: Agent printing: Total documents found: 24

[14E4:000C-0470] 03/02/2007 12:07:27 PM Agent Manager: Agent printing: Total R5 documents found: 0

[14E4:000C-0470] 03/02/2007 12:07:27 PM Agent Manager: Agent printing: Time spent per document (in seconds): 0

[14E4:000C-0470] 03/02/2007 12:07:27 PM Agent Manager: Agent printing: Time spent per database (in seconds): 0

[14E4:000C-0470] 03/02/2007 12:07:27 PM AMgr: Agent ‘DSTUpgrade’ in ‘AdminAgent.nsf’ completed execution

Thank you in advance

Subject: Another DST agent question with repeating calendar entries

Thanks guys. As far as I know Jean, I don’t have the $TimeZoneAgent. At least I never created one. The TimeZone properties, start and end, are still at 4 1. They won’t change to 3 2

I have ran the agent again, actully 3 or 4 times. I will have to have the user just reschedule the meeting once. She is the only participant, so it shouldn’t be a big deal.

Thanks for the replies.

Subject: RE: Another DST agent question with repeating calendar entries

Hi Joseph,

the $TImeZoneAgent field is added byt the IBM’s agent. So the problem seems to be that the agent is not able to process the entry (For whatever reasons)

So, if the agent have been able to process the document, the StartTimeZone \endTimeZone field would be DL = 3 2 instead of DL= 4 1

and finally, if you have the version 4.0.2.7 of the agent, you will have a field called $TimeZoneAgentVersion with the value “4.0.2.7”.

From Agents for updating Calendaring and Scheduling entries and Resource Reservation entries for Daylight Saving Time (DST) 2007

The StartTimeZone and EndTimeZone fields are structured to contain the following attributes:

Parameter

Definition

Z

Time zone offset from GMT.

DO

Daylight Saving Time (DST) observed flag. 1 means DST is in effect; 0 means it is not. If equal to 1, a value should be supplied for DL.

DL

DST law identifying the .

ZX

Host-specific time zone index. Note: This parameter is not generated in Domino Web Access-created entries.

ZN

Time zone name.

The agents check the StartTimeZone or EndTimeZone to see if they match any of the values in this list:

“Z=9DO=1DL=4 1 1 10 -1 1ZN=Alaskan”
“Z=8DO=1DL=4 1 1 10 -1 1ZN=Pacific”
“Z=7DO=1DL=4 1 1 10 -1 1ZN=Mountain”
“Z=6DO=1DL=4 1 1 10 -1 1ZN=Central”
“Z=5DO=1DL=4 1 1 10 -1 1ZN=Eastern”
“Z=4DO=1DL=4 1 1 10 -1 1ZN=Atlantic”
“Z=3003DO=1DL=4 1 1 10 -1 1ZN=Newfoundland”

The code checks only the Z, DO, DL, and ZN parameters, as the ZX parameter is not significant in this case for Notes clients, and is unused for Domino Web Access sessions. If the field matches one of the above values, the DL parameter will be updated to contain “DL=3 2 1 11 1 1”, reflecting the new DST rule, and the Z, DO, ZN parameters (and for Notes created entries ZX) will remain unchanged. We then rebuild the StartDateTime and EndDateTime fields, based on the new StartTimeZone and EndTimeZone values. We will also set a new field, $TimeZoneAgent with a value of 1, to track which documents the agent has processed.

JYR

Subject: Another DST agent question with repeating calendar entries

Hi,

Is the StartTimeZOne\EndTimeZOne field correct? You should have DL=3 2 instead of DL=4 1.

Do you have a field called $TimeZoneAgent?

JYR

Subject: Another DST agent question with repeating calendar entries

I’ve had a similar issue where repeating meetings haven’t gotten updated. I was told to a)run the agent again; b) and/or have the chair of the meeting reschedule to the “correct” time.