LO93818: DEVICE MISSING DATA AFTER ANOTHER DEVICE WITH SMALLER FILTER GOES ONLINE-OFFLINE-ONLINE
Closed as program error.
For a single user, if 1. the user has multiple devices (at least two but not limited to just two) 2. at least one of the user's devices is using SMS (Android Verse), GCM (Android Verse) or APNS (iOS Verse) for push 3. all of the user's devices are inactive (no syncs or push connections to the server) for at least 24 hours 4. the server is restarted during the 24 hours since all of the user's devices' last sync times 5. the device without the largest data (mail or calendar) filter is the first device to connect after the 24 hours and before the server is restarted again then data on the device(s) with filters larger than the filter of the device that was the first to connect after 24 hours may be missing. For example, a user has two devices. The first device is an Android Verse device using GCM for push (it could be using SMS or be an iOS Verse device using APNS for push) and a 7 day mail filter. The second device is an IMSMO device (it could be any device not of the first device types) and 30 day mail filter. The IMSMO stops syncing at 5PM on Friday (for example, the laptop was shutdown for the weekend). The Android device stops syncing at 6PM on Friday (for example, ran out of battery or was turned off). The server had routine maintenance run and was restarted at 2AM on Saturday. The Android device syncs again at 7PM on Saturday. At this point, the data older than 7 days is reaped. When the IMSMO device reconnects on Monday at 8AM, all of the mail older than 7 days has disappeared (the mail still exists in the user's mail database and can be seen using Notes/iNotes/Verse Web, but the mail is no longer visible in the IMSMO client).
Don't let the SMS/GCM/APNS device go offline for 24 hours or if it does, make sure the device with the longest filter (IMSMO in the example) is the first to reconnect.
Very rare scenario where a user with two devices with different mail filters may experience both devices using the same mail filter.
The Traveler server has been updated to resolve this issue.
This fix is included in Traveler 10.0.0.0 and all later releases. See the recommended maintenance technote for the lates available Traveler maintenance release: http://www.ibm.com/support/docview.wss?uid=swg24019529
Reported component name
LOTUS NOTES TRA
Reported component ID
NoSpecatt / Xsystem
Last modified date
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fixed component name
LOTUS NOTES TRA
Fixed component ID