Agents for Updating Calendar Entries and Resource Reservations for Brazil Daylight Saving Time (DST) 2013

Technote (troubleshooting)


Problem

This document provides details about the steps necessary to prepare Lotus Notes clients and Lotus Domino servers for the change of daylight saving time rules in Brazil in February 2013. In 2013, Brazil will end observing daylight saving time on the third Sunday in February, 17th at Midnight. This is a change from 2012, where DST ended on the last Sunday of February.

Impacted time zones as listed under Microsoft Windows are:

Time Zone Name Windows Time Zone Description
E. South America Standard Time (UTC-03:00) Brasilia
Central Brazilian Standard Time (UTC-04:00) Cuiaba

Resolving the problem

Any existing calendar entry that falls outside the previous DST period will appear one hour off after the operating system has been patched with the updated time zone rules. For a general overview of actions to take, refer to "Steps to prepare Notes/Domino for Brazil Daylight Saving Time Change 2013" (Document #1621784). IBM has prepared a set of LotusScript agents that will update any existing calendar entries, calendar profiles, resource reservations, and resource documents on a mass basis that were created prior to the application of an operating system patch for these time zone changes.

Agent Overview


Two agents have been created to update documents impacted by this DST change:

- An Administrative Calendaring Update Agent (or Admin agent) designed to update all impacted calendar entries in a user's mail file as well as time zone specific calendar profile fields.

- An RnR Update Agent designed to update all impacted reservation documents as well as time zone specific fields contained in Resource documents in a Resource Reservations database.

When a Date/Time field value is composed in Lotus Notes, its value is computed as ticks from GMT. A time zone's offset from GMT changes when it enters and leaves daylight saving time. So when daylight saving time rules change from a previous year's date/time values that fall within the impacted time period need to be updated with the correct GMT value.


The agents operate by recalculating the date/time values of calendar entries and room/resource reservations in the impacted time zones to their correct GMT offset. The agents will act on entries that are scheduled in an impacted time zone regardless of whether the mail file owner is the chair or an invitee. The agents will not act on entries which have been created or are chaired in an unaffected time zone but have attendees which are located in an affected time zone. The agent does not need to process those entries for them to display correctly. The agents will update impacted documents to show the correct time both in the Calendar view and in the open document itself.


Deployment Advice:

1. Assess which of the optional operating modes (described in "Agent Options") are applicable to your environment, being sure to review the advantages and disadvantages of each option.

2. Review the "Best Practices and Warnings".

3. For best performance, run the Calendaring "Admin" agent as a background agent, and run multiple instances to further shorten total runtime. See the "Best Practices and Warnings" section for details.


What does each agent update?

The primary goal of each agent is to update the following individual fields to reflect the new DST rules, within each affected document:

  • StartDateTime
  • EndDateTime
  • StartTimeZone
  • EndTimeZone

The StartDateTime and EndDateTime fields are rebuilt based on the new time zone rules, which are updated in the StartTimeZone and EndTimeZone fields. The Resource Reservation agent also updates the internal fields $Times1 through $Times7 for relative Resource documents.

The StartTimeZone and EndTimeZone fields are structured to contain the following attributes based upon the time zone rules stored on the operating system at the time the document was created:

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 <StartMonth> <StartWeek> <StartDayOfWeek> <EndMonth> <EndWeek> <EndDayOfWeek>.
ZX
Host-specific time zone index. (Optional)
ZN
Time zone name.

The agents check the StartTimeZone or EndTimeZone to see if any entries match the original StartTimeZone/EndTimeZone values and update them to the Updated StartTimeZone/EndTimeZone values. As you can see, the StartTimeZone/EndTimeZone values are based off of the time zone settings of the workstation that composed the impacted calendar entry or resource reservation.

Original Time Zone Name Original Windows Time Zone Description Original StartTimeZone/EndTimeZone Value
E. South America Standard Time (UTC-03:00) Brasilia Z=3$DO=1$DL=10 3 7 2 4 7$ZN=E. South America
Central Brazilian Standard Time (UTC-04:00) Cuiaba Z=4$DO=1$DL=10 3 7 2 4 7$ZN=Central Brazilian

Updated Time Zone Name Updated Windows Time Zone Description Updated StartTimeZone/EndTimeZone Value
E. South America Standard Time (UTC-03:00) Brasilia Z=3$DO=1$DL=10 3 7 2 3 7$ZN=E. South America
Central Brazilian Standard Time (UTC-04:00) Cuiaba Z=4$DO=1$DL=10 3 7 2 3 7$ZN=Central Brazilian

(The terms UTC and GMT are interchangeable in the above tables)

Agent Details

Administrative Calendaring Update Agent

This agent will update all documents that meet the following conditions:

  • Each entry must have fields: StartDate, StartTime, EndDate, EndTime, StartTimeZone, and EndTimeZone.
  • The agents will not act on documents that contain $TimeZoneAgent field, which is used as a flag by the agent to indicate that the document has already been processed.
  • The agents will not act on invitations which have not been accepted, as the entry is not present within the calendar yet. This may mean that an invitation which had not been accepted will still observe the outdated DST rules once it is accepted.
  • The agents will not act on draft entries.
  • For non-repeating documents, the agent will act only on those within the weeks affected by the DST changes.
  • Repeat entries will be rescheduled per instance within the specified weeks, except in cases where reschedule notices are not sent. In this case repeat entries are acted on from the affected instance forward.
  • The agent uses a FOR loop that defaults to run through documents that fall within the DST period from 2013 to 2013 only. This can be modified to add more years as desired.
In addition, this agent will perform the following actions (regardless of whether there are any actual entries that need to be processed):
  • Update a Notes mail user's Calendar time zone setting if previously set. This resets the TimeZone field in the mail file "CalendarProfile" profile document.
  • Update an iNotes user's setting CurrentTimeZone field and AlternateTimeZone field, if previously set. These values are found within the "iNotesprofile" profile document.

Additional agent behavior of note:
  • This agent will execute in a database based on the standard mail template (6.x or later).
  • Tallies of the number of documents acted on, as well as details on any errors that occur, are written to the status bar as well as a log document. The document is a draft memo which is found in the Drafts folder of the database hosting the agent. The "Admin" agent additionally reports which mail files it is acting on, the start time of the main loop, the start time of each mail file it processes, and the end time of the main loop.
  • The agent will skip databases to which the administrator does not have at least Editor access. This database name will be noted to the report. If the database could not be accessed or the administrator had No Access rights the entry will reflect "Unable to process <mail file name>". If the database can be accessed but the access level is below Editor, then the entry will also note "ACL access is lower than Editor." Note: In cases where the agent is run in the background and the user has Full Access Administrator rights, the ACL access rights to a user's mail file is irrelevant.
  • If a repeat entry has a missing or corrupt parent document the agent will add the field $TimeZoneAgent with a value of 0 to the repeat document. In such cases the issue will be noted in the log, noting the document's Universal ID (UNID) with the text "Unable to process document: <UNID> Its parent document was not found." Such entries must be manually recreated.
  • When run in report mode, the agent will still flag orphan repeat entries by creating the field $TIMEZONEAgent with a value of 0.
  • If an unexpected error is returned, the error number, text and relative code line are reported to the log document.
  • The agent only updates documents from the current day forward.

RnR Update Agent

This agent will update all documents that meet the following conditions:
  • The documents must have the StartDate, StartTime, EndDate, EndTime, StartTimeZone, and EndTimeZone fields
  • The agent will not act on documents that contain the $TimeZoneAgent field, which is used as a flag by the agent to indicate that the document has already been processed.
  • The agent uses a FOR loop that defaults to run through documents that fall within the DST period from 2013 to 2013 only. This can be modified to add more years as desired.
  • The TimeZone field of any Resource documents created in an impacted time zone. These are found in the Resources view of a given resource reservations database.

Additional agent details:
  • The agent will run only in databases based on the Resource Reservations template (6.x and later).
  • The agent is designed to be executed from a Notes client.
  • In order for the agent to work correctly the RnRMgr task, if running, must be shut down first.
  • If a repeat entry has a missing or corrupt parent document the agent will add the field $TimeZoneAgent with a value of 0 to the repeat document. In such cases the issue will be noted in the report, noting the repeat document's Universal ID (UNID) with the text "Unable to process document: <UNID> Its parent document was not found." Such entries must be manually recreated.
  • A log recording number of documents acted on, as well as details on any errors that occur, are written to the status bar as well as to a new log document within the database.
  • When run in report mode, the agent will still flag orphan repeat entries (if applicable) by creating the field $TIMEZONEAgent with a value of 0.
  • If an unexpected error is returned the error number, text and relative code line are reported to the log document.
Agent Options

The configuration of important options is discussed further below. Both agents have the ability to operate in a report mode. This mode will count the number of documents that need to be acted on by the agent. By default agents act only on entries within 2013.

Both agents are written in LotusScript. There are options within the agent's Initialize event in the area labeled "USER DEFINABLE VARIABLES". The information below details the options, including which version they are available in, their default behavior, as well as any Pros and Cons related to their usage:

Report Mode

Set the "ReportMode" variable to "True" to run a report which does not update documents, or "False" to update documents. Default is False.
  • Pros:
- Reports the number of documents to be processed. This option is great for administrators to gauge the amount of work the agents will perform.
- The agents tally and report the total documents for all databases that would be processed by the agents.
  • Caveats:
- Report mode may report a similar, but not identical, number of documents that need processing as when the documents are actually updated. This is not unexpected. The report mode should be used as a guide to understand the general number of documents which need to be acted on. If you have doubts whether all necessary documents were processed, you can re-execute the report mode version after running the agent in action mode.
- When run in report mode, the agent will still flag orphan repeat entries by creating the field $TIMEZONEAgent with a value of 0. This ensures better performance and additionally guards against problematic calendar data.

Years of Data to Act on

Agents that do not act on selected documents use a FOR loop to determine the limits for the year(s) of the data acted on. The default for the loop is 2013 to 2013, and will act on documents falling inside of the Brazil DST change period. All calendar entries will be processed from today forward.

Note: The FOR loop can be manipulated by directly editing the code line "For yr=2013 To 2013", which is present in the core section of the Initialize event rather than the section titled "USER DEFINED VARIABLES".

Running Mail File "Admin" Agent as on a Server (Recommended)

Set the "isRunningOnServer" variable to "True". Default is True. You must additionally set the "fileName" variable to the input text file located on the server. The details for this file are discussed further below.
  • Pros: Allows for better performance than manual execution from the actions menu. IBM tests show 65% improvement.
  • Cons: Slightly more difficult to configure.

Mail Rescheduling Notices. Set the "CanNotify" variable to "True" to send rescheduling notices for entries being processed by the agents. Default and recommended setting is False.
  • Pros:
- Not sending reschedule notices minimizes chance of R&R declines.
- Not sending reschedule notices minimizes user confusion by suppressing reschedule notices.
  • Cons:
- Not sending reschedule notices causes non-Notes invitees to not know the meeting time may have changed for them.
- Not sending reschedule notices causes Notes users in a different geographic region to not be aware of time changes for meetings rescheduled by the agent, unless they also have the Admin agent run against their mail file.
  • Known limitation:
- When a user's mail file is processed by the agent, it will also generate a reschedule notification to any rooms or resources reserved through the C&S workflow.
- It is possible for a conflict to occur as the agent is processing C&S entries. For example, User A reserves a room at 1:00 PM and 3:00 PM for separate meetings. User B reserves a room at 2:00 PM. After the operating system patch is applied say User A's meetings will appear at 2:00 PM and 4:00 PM, and User B's meeting will appear at 3:00 PM. If User B's meeting is processed first by the agent it will reschedule the room reservation back to the correct time of 2:00 PM. However, since this slot is already occupied by User A's meeting, it will be rejected by R&R autoprocessing.

Best Practices & Warnings
  • Backup databases before running the agents
  • Test in a non-production environment before running the agents in production. Your testing should also include measuring server load in addition to document throughput reported by the agent.
  • To minimize impact to production servers, it is recommended that you run the "Admin" agent during off peak hours
  • To avoid replication conflicts, do not run the agents on the same mail files on multiple replicas (i.e., two clusters). This is also why we recommend running at non-peak hours, to minimize conflicts in cases where the a user is modifying calendar entries and an agent is acting on a replica (or same) mail file.
  • Shut down extraneous tasks while running the agent to improve performance and have resources dedicated to AMGR. Tasks to shut down specifically during the agent run:
- Router (while running with the option to send reschedule notices)
- RNRMgr (while running the "RnR" agent)
  • When running with "CanNotify=False" to suppress reschedule notices, run the agent on all mail servers worldwide so international invitees calendars are corrected.
  • Turn off encryption when triggering "Admin" agents from a Notes client (File -> Preferences -> User Preferences -> Mail, disable the option: "Encrypt mail that you send").
  • To avoid runtime errors, ensure the agent has been saved/compiled in the same version it is executed from. For example, if running from a Notes 8.5.x client/server, save the agent with a Notes 8.5.x client/designer.
  • If you set up the "Admin" agent to run as scheduled, ensure the "Max LotusScript/Java execution time:" in the Agent Manager section of the Server document is set to a high value to allow agent execution to complete.
  • If you set up multiple "Admin" agents, be sure that each has their own input file, and that each of those has its own unique content. The requirements and details involving the input file are fully discussed in the section that details the agent.
  • Foreign language caveat: To be executed in foreign language templates, the agents must be edited to add the language specific suffix to the referenced libraries in the (Options) event of the relative agent. To determine the correct suffix for your language design, open the database in the Domino Designer client and select Shared Code -> Script Libraries. Locate the relative library and note its suffix.
By default, the agents are coded with the Brazilian template specific suffix "_pt-BR" appended to the referenced libraries. To execute the agents from a different language template, you must edit the agents to add the language specific suffix to the referenced libraries in the (Options) event of the relative agent. To determine the correct suffix for your language design, open the database in the Domino Designer client and select Shared Code -> Script Libraries. Locate the relative library and note its suffix. Note: For English based templates, the suffix "_pt-BR" would need to be removed.

The agents are provided with the library references as noted:

The Calendaring and Scheduling agents use:
Use "TIMEUtilities_pt-BR"
Use "CSEventNotes_pt-BR"

The Resource Reservation agents uses:
Use "CSReservation_pt-BR"
  • It is recommended that you run the agent in report mode first to determine how many documents the agent will process. You can estimate how long it will take the agent to run based on the documents it needs to process. Based on the results below, there are substantial advantages to running the Admin agent with the following recommendations:
1) Running as a background agent versus foreground (31% improvement in our tests).

2) Running multiple background agents to get concurrent processing power.

3) Running agent on a powerful server machine (in our tests, this cut the runtime almost in half).

Steps for Running the Administrative Calendaring Update Agent

The "Admin" agent should be created in a database based on the standard mail template on a Domino server where the mail files to be processed also reside. The agent is designed to be run by an administrator who has at least Editor access to the mail files to be acted on. Although the agent can be run from the actions menu in a Notes Client, it is recommended to be run in the background on a Domino server. It is suggested that this agent be run during off-peak hours so as not to disturb usual mail routing performance. The agent requires that the location of a text file (e.g., c:\mailfiles.txt) be entered when prompted. The data in the text file should be formatted like this:

mail\joeuser.nsf
mail\janeuser.nsf

NOTE: Wildcards cannot be used within the input file. If the extension is not specified, then .NSF will be assumed. If you have mail files with another extension, for example ND5 or ND6, then the extension must be specified.

Running the Agents in the Background on a Domino Server

1. On the server where the mail files to be processed reside, create a new database based off of the standard mail template and open it in Designer.

2. Select Create->Design->Agent from the Designer menu.

3. Make sure agent type is set to LotusScript and give the agent a name, like AdminAgent.

4. Under the objects tab the name of the agent will be selected. Select all of the text in the programmer's pane and delete it.

5. Open the lss file attached here, select all, and copy and paste the code into the programmer's pane.

Update_Timezone (admin) - Brazil 2013_2.lssUpdate_Timezone (admin) - Brazil 2013_2.lss

Revision 2 of the Brazil 2013 agent corrects the following issues:
    A. If a user's free time availability preferences spanned more than one time slot, then only the first time slot would be preserved. For example, in the user's mail file, under Preferences->Calendar & To Do->Scheduling the default availability time is 9:00 AM - 12:00 PM, 01:00 PM - 05:00 PM. After the agent was run only 09:00 AM - 12:00 PM would remain. Only the back-end value in the profile document was affected. The display value seen in the user interface would remain the same.

    If you've already run a previous version of the agent, execute it again with updateCalendarProfileOnly=true set and any impacted users will be reprocessed and corrected.

    B. In revision 1 of the Brazil 2013 DST agent the calendar entries scheduled in the Central Brazilian time zone would be skipped by the agent. Running the current version of the agent will process these entries.

    To determine if you ran revision 1 of the agent , search for the string Brazil2013_1 in the agent code which was used. Documents which were processed by the agent (in the E. South America time zone) will also have a value of Brazil2013_1 in the $TimeZoneAgentVersion field.

6. Create an input .txt list file for the agent. The Admin agent requires a list of mail files to run against. This can be either done manually using a text editor (such as Notepad), or you can generate a list of mail files on a server by issuing the following command on your Domino server console:

load convert -l c:\mailfiles.txt

The command will create a file named “mailfiles.txt” in the c:\directory on the Domino server.

Note: The command parameter “-l” is a dash followed by a lowercase "L". If you use this command to create the input list text file and you plan to run the Admin agent manually from a Notes client, then the text file must be moved from the server system to the client system.

Note: Wildcards are not permitted in the input file.

For a clustered server the command "load convert -l..." will produce a list of those mail files belonging to only those users who have the cluster as their primary mail server. This means the list will not contain an entry for each and every mail file on a clustered server. This behavior can actually be beneficial if you are running multiple versions of the agent. One agent could use the list from one cluster, and a second agent could use the list from a second cluster.

Warning: It is important that you do not apply the agent to the same mail files on more than one cluster, as doing so will result in undesired behavior such as replication conflicts and duplicate entries.

7. Set the Agent Options fileName and isRunningOnServer variables (Note: These are set in the User Defined Variables section of the code). For example:
fileName="C:\mailfiles.txt"
isRunningOnServer=True

8. Per the "Agent Options" section configure ReportMode=True to create a report in the Drafts view of the database showing the number of documents that would have been updated by the agent, or set ReportMode=False to update calendar entries and profile documents.

9. In the Basics section, under the properties tab:
- Set the Trigger to Scheduled.
- Set the Schedule to never.
- Set the target to "All documents in database".



10. In the security section, under the properties tab, change agent properties to run with full administration rights:



11. Ensure that the agent signer (last person to save or enable it) is listed in the Full Access Administrators entry in the Server document within the Domino Directory. The entry is found on the Security tab. If the signer is not listed, then they must be added.

12. Manually trigger the agent on the server by issuing the following command on the server console (Note the double quotation marks around the database name and single quotation marks around the agent name):
tell AMGR Run "DST.nsf" 'AdminAgent'

Note: You can configure the agent to run on a specific schedule, but ensure the "Max LotusScript/Java execution time:" in the Agent Manager section of the Server document is set to a high value, so that agent execution to complete.

13. A documents will be created in the Drafts view of the database. View the contents of these document for any errors and for a report of how many documents were processed.
Instructions for Running Multiple Instances of the Agent

1. To run as multiple instances (i.e., four instances), copy/paste the agent that you created using the above steps multiple times in the same database, and change the name to "AdminAgent1", "AdminAgent2", and so on.

2. Ensure you have the server setup to run the desired number of concurrent agents in the Server document in the Domino Directory. The "Max concurrent agents" setting is found on the Server Tasks -> Agent Manager tab. Note: There are separate settings for "Daytime Parameters" and "Nighttime Parameters," make sure that you set each as desired.

3. Split the input text file evenly into separate files for each instance of the agent. For example, mailfiles1.txt, mailfiles2.txt, and so on. Each text file should contain its own unique content.

4. Edit each agent, so that the fileName points to a different text file for each agent. For example, in AdminAgent1, fileName should be fileName=c:\mailfiles1.txt, in AdminAgent2, fileName should be fileName=c:\mailfiles2.txt, etc...

5. Simply issue "Tell AMGR Run" for each of the individual copies of the agent:
i.e. for 4 agents it would be the following
Tell AMGR Run "DST.nsf" 'AdminAgent1'
Tell AMGR Run "DST.nsf" 'AdminAgent2'
Tell AMGR Run "DST.nsf" 'AdminAgent3'
Tell AMGR Run "DST.nsf" 'AdminAgent4'

Steps for Running the RnR Update Agent

The RnR Update Agent agent should be placed in the Resource Reservations database (or template, if desired) and run from the Resource Reservations (R&R) databases. The agent should be run by an administrator who has at least Editor access to the database. The agent is executed via the Actions menu and it creates a report document per execution.

Note: These agents require the coding of a variable within the Initialize event of the agents. The string variable strRnRType must be set as described below:
- "R7" if server is running RnRMgr server task on R&R database (Default)
- "R6" if server is NOT running RnRMgr and the R&R database is using a pre-R7 template (Legacy, and should no longer be needed)

1. Shut down the RnRMgr task on the Domino server. This can be done by issuing a 'tell RnRmgr q' command on the Domino server console.

2. Open the RnR database you'd like to process in Designer. These changes can also be made to the resource reservations template, so that they are propagated out to all RnR databases by the design task.

3. Create a form to view the log output from the agent by selecting Create->Design->Form. Name the form DSTAgentErrorLog.

4. Right Click on the blank form and select Create Field. Name the field Subject.

5. Right click on the form and select Create Field. Set the field type to Rich Text. Name the field Body.

6. Save and close the form.

7. Create a view to display the agent log output by selecting Design->Create->View in Designer.

8. Name the view DST Report.

9. In the By formula field, delete the existing formula and replace it with:

Select Form="DSTAgentErrorLog"




10. Save and close the view.

11. Create the DST agent by selecting Create->Design->Agent from the menu. Name the agent RnRAgent and make sure the type of the agent is set to LotusScript.

12. Under the objects tab the name of the agent will be selected. Select all of the text in the programmer's pane and delete it.

13. Open the lss file attached below, select all, and copy and paste the code into the programmer's pane.


Update_Timezone (RnR) - Brazil 2013.lss


14. Under the Properties tab, in the basics section, set the Target to None.




15. Per the "Agent Options" section configure ReportMode=True to create a report in the Drafts view of the database showing the number of documents that would have been updated by the agent, or set ReportMode=False to update calendar entries and profile documents.

16. Save and close the document.

17. Run the agent by navigating to the Reservations by Date view and selecting Actions->RnRAgent.

18. You will be asked if you have quit the RnRMgr task.



If you have quit the task per Step 1, then select OK, then No in the following dialog.



If you have not quit the RnRMgr task select Yes, and quit the task. If not this could load to agent failure and possible damage to reservations.

13. A log document will be created in the DST Report view of the database. View the contents of this document for any errors and for a report of how many documents were processed.

14. When you are finished start the RnRMgr task again by issuing a load RnRMgr.

Post Agent Execution Requirements

Users need to:

- See whether they have received any emails noting a "Decline" notification.

- Review their Calendar to see whether the shifting of any entries resulted in a time slot being unexpectedly double booked. Note: Some users may have already had a time slot double booked and in those cases it would be expected that the adjusted entries resulted in an expected double-booking.

Administrators need to:

- Review the output log from the agent. If the agent noted it could not process a mail file due to an ACL rights issue, then take steps to adjust the ACL of the mail files so that the proper access is provided. You may also want to notify users if there are cases where an entry's parent is missing, as the chair may need to re-invite a user and/or recreate the meeting. If any errors are reported, see the "Details on Possible Error Conditions" section below.

- Review the Resource Reservation database for double bookings. Notify the chairs of the double booked resource or room so they can take action to determine who will retain the resource/room, and who will need to reschedule the resource/book a new room.

The tables below document the behavior and actions that will occur if an entry is rescheduled without issue (non-conflict), or if there is a conflict.

Non-conflict
Reschedule Notifications Enabled
Reschedule Notifications Disabled
C&S Entry is rescheduled. Entry is rescheduled.
C&S RR workflow An acceptance email will be sent to the chair. The meeting will we reflected at the correct time. No acceptance email will be sent.
RR direct Entry is rescheduled. Entry is rescheduled.

Conflict
Reschedule Notifications Enabled
Reschedule Notifications Disabled
C&S The time slot will be double booked. The time slot will be double booked.
C&S RR workflow A decline email will be sent to user who does not obtain the reservation. Which ever notice is in the slot with the new time zone rules first, will win. The entry will be double booked.
RR direct The room/resource will be double booked for that time slot. The room/resource will be double booked for that time slot.

Details on Possible Error Conditions

The following details common errors which may be observed in the log documents

"Unable to process document: <UNID> Its parent document was not found."
An agent will report this entry if a repeat meeting entry has a missing or corrupt parent document. Note: If the code did not check for a invalid parent then this condition would report a 4670 error. Notes cannot process orphaned calendar entries. If you are an invitee, the chair must remove and then re-add you to the invitation so you have a new meeting entry to act on. If you are the chair, you must delete the existing meeting and recreate it. Note: Such "orphan" entries are identified by the presence of the field $TIMEZONEAgent, with a value of 0 (zero).

"Error number 4670 (User-defined error) occurred at line <#> while processing UNID <UNID>"
There are different cases that cause this error and different solutions, as follows:

- A reschedule notice cannot find a person in the Domino Directory.
The chair must edit the entry and remove the invitee, save the entry, and then reschedule it.

- The document or its parent (if it is a Repeat) is a Replication/Save conflict.
A common case is if a user accepted and/or declines an invite from a server, a local replica, or mobile device. This will cause a replication conflict at the parent level and usually causes at least one "twin" (the meeting shows up twice in your calendar at a given time before agent processing). The agent will process all "twins" that it can. If one or both of the twins' parent points to a replication conflict, the agent will not process that entry. Users should be aware of this and either attend the meeting at the normal time, or confirm with the chair when the meeting occurs. The twin/duplicate entry should not be deleted as this will generate a Decline. The entry will need to be ignored.

Related information

Steps to prepare Notes/Domino for Brazil Daylight Savin


    Cross reference information
    Segment Product Component Platform Version Edition
    Messaging Applications IBM Domino Calendaring and Scheduling 8.5.3, 8.5.2, 8.5.1, 8.0.2.1

Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

IBM Notes
Calendaring and Scheduling

Software version:

8.0.2.1, 8.5.1, 8.5.2, 8.5.3

Operating system(s):

Windows

Reference #:

1621783

Modified date:

2013-02-06

Translate my page

Machine Translation

Content navigation