This issue was reported in September 2013. The finalizing steps of a rename request in AdminP are run on all servers and at the same time (Sun 01:00). Here is the tekst of the original.
| LO77203: "RENAME PERSON IN CALENDAR ENTRIES AND PROFILES IN MAIL FILE EXTENDED" CARRIED OUT IN BOTH MAIL FILE AND IN SECOND SERVER |
Ask the IBM Support Agent Tool
APAR status
REOP
Error description
Rename Person in Calendar Entries
and Profiles in Mail File
Extended" carried out in both mail file and in every
server that contains a replica of the user's mail file
Customer is getting replication save conflicts when renaming
users to a new certifier.
After users are recertified and accepted the name change the
users experience replication conflicts in their Calendar.
After investigating issue it was identified
The adminp task "Rename Person in Calendar Entries and Profiles
in Mail File Extended" is running on every server in which the
mail file has a replica copy even when the other servers are not
being indicated in the ACL> Advanced> As administrator servers
of the mail file.
Documentation explains the way it should work the adminP
request type:
"Rename Person in Calendar Entries and Profiles in Mail File
Extended"
http://www-12.lotus.com/ldd/doc/domino_notes/9.0/help9_admin.nsf
/f4b82fbb75e942a6852566ac0037f284/0f541322a4371dfc85257b19005b50
d7?OpenDocument
Rename person in calendar entries and profiles in mail file
extended
Triggered by: Completion of the "Rename person in Free Time
Database" request.
Carried out on: The person's home server.
Carried out: Immediately
Note: This request eliminates the need for client users to
enable the Modify All Names Fields ACL setting in order to
manage name changes properly in the calendar. That ACL setting
is no longer necessary and any changes to it by users are
ignored.
The behaviour explained above is not working as documented.
The request is carried out on : Every server that has a replica
of the mail file
The request is carries out: Delayed.
STEPS to reproduce:
- Set up 2 domino servers 853FP3
- Register a couple of organization units to play with for
renaming
OU=Ireland/O=September
OU=France/O=September
- Register a couple of test users " Test
User01/Ireland/September" Test User02/Ireland/September" "Test
User03/September" and make sure that the user's mail files have
a replica on each node of the cluster ( servers
dubxpcvm1141/September & dubxpcvm1142/September)
- Log as the Test Users and create some meetings in the
calendar, and mail delegations to update the calendar
profiles with the name of other users to be renamed... using the
test users registered before
- Rename the user from "Test User01/Ireland/September " to "
Test User01/France/September "
"Test User02/Ireland/September " to " Test
User02/France/September "
"Test User03/September " to " Test User02/Ireland/September "
- In admin4.nsf the request type "Rename Person in Calendar
Entries and Profiles in Mail File Extended" will be carried out
when the Delayed request for adminP are run instead of
immediate.
- For this scenario to be reproduced you need to replicate the
admin4.nsf requests generated during the rename of the user
to all the servers in which the user's
mail file is located.
You will notice that when the adminp delayed request
is run on the other servers, in which the user's mail file
has a replica of the user, the request type "Rename Person in
Calendar Entries and Profiles in Mail File Delayed "
is carried out also by these other servers instead of
just being carried out by the person's home server.
Screen shot of the results included
Local fix
Problem summary
Problem conclusion
Temporary fix
Comments
This APAR is associated with SPR# BBSZ9BXGU3.
APAR Information
APAR number
LO77203
Reported component name
DOMINO SERVER
Reported component ID
5724E6200
Reported release
853
Status
REOP
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2013-09-27
Closed date
Last modified date
2017-11-18
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Applicable component levels
|
Is this still an issue (for just the iSeries?), any why would they fix this for Domino R8.5.3 which went End of Support on 30/09/2018?