Fixes are available
Rational ClearQuest Fix Pack 2 (9.0.2.2) for 9.0.2
Rational ClearQuest Fix Pack 12 (9.0.1.12) for 9.0.1
Rational ClearQuest Fix Pack 4 (9.0.2.4) for 9.0.2
Rational ClearQuest Fix Pack 10 (9.0.1.10) for 9.0.1
Rational ClearQuest Fix Pack 11 (9.0.1.11) for 9.0.1
Rational ClearQuest Fix Pack 3 (9.0.2.3) for 9.0.2
Rational ClearQuest Fix Pack 5 (9.0.2.5) for 9.0.2
Rational ClearQuest Fix Pack 13 (9.0.1.13) for 9.0.1
APAR status
Closed as program error.
Error description
OSLC queries fetch data in pages, but the design of the pagination is flawed so as to not to always produce a full or correct result. In escalation 139184 we have this logic: 1. OSLC Get some batch of records - in this case there are 391 work items - request 100 at a time (oslc.pageSize=100) 2. The first request gets first 100 records and a URL to get the next 100 (starting at 101) 3. Client calls the "next" URL repetitively until its done fetching results (4 requests, 3 sets of 100 records, the last has 91 records) 4. Sometimes the batches have duplicate entries. Sometimes records are missing once all the data is fetched. The OSLC code does this for each of the 4 batch requests above 1. Get a list of all (391) of the ids of the records - the sql of this get is not sorted and the order of ids cant be predicted 2. Fetch the record data for the ids in the range requested - example start_row:201 end_row:300 will get records 201-300 from the unsorted list of dbids above Since the list of ids is unsorted and its fetched every time an oslc batch request happens, the contents of any one page cant be predicted - The second or third page may contain items already fetched. Fetching all 4 batches may not actually get all of the records. The only thing that's certain is that once all of the pages are traversed 391 records will be retrieved (again some may be missing and some may be duplicated). The key to making this work is having the dbids ordered before calculating the contents of each page. The order may be able to be done in the sql itself or in the list of ids thats in memory.
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: * * ClearQuest OSLC * **************************************************************** * PROBLEM DESCRIPTION: * * When using a ClearQuest OSLC query to fetch data, the result * * is not sorted. * **************************************************************** * RECOMMENDATION: * ****************************************************************
Problem conclusion
A fix is available in ClearQuest 9.0.1.10 and 9.0.2.2. When using a ClearQuest OSLC query to fetch data, the result is now sorted by record dbids in an ascending order.
Temporary fix
Comments
APAR Information
APAR number
PH24473
Reported component name
CLEARQUEST WIN
Reported component ID
5724G3600
Reported release
901
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2020-04-16
Closed date
2020-08-17
Last modified date
2020-08-17
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Fixed component name
CLEARQUEST WIN
Fixed component ID
5724G3600
Applicable component levels
R901 PSY
UP
[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSSH5A","label":"Rational ClearQuest"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"901","Line of Business":{"code":"LOB45","label":"Automation"}}]
Document Information
Modified date:
28 April 2022