Subscribe to this APAR
By subscribing, you receive periodic emails alerting you to the status of the APAR, along with a link to the fix after it becomes available. You can track this item individually or track all items by product.
APAR (Authorized Program Analysis Report) |
Abstract
RDARS-ONDCSRV-LOOP WHEN MAX ROWS REACHED IN INDEX TABLE, ARSSEG
RECORD GETS NULL DATE FIELDS, JOB HANGS, QSQSRVR JOB LOOPS
Error Description
ADDRPTOND submitted and after indexing, loading begins and it
reaches the max rows for index table, so new index table should
be generated. ARSSEG file should be updated with record of
first index table showing start and stop dates, and then new
record for next index table. In the original record START_DT
and STOP_DT fields get null values. This results in the ADDRPT
job to hang - no activity, no CPU; a QSQSRVR job will show
taking CPU in apparent loop along with the instance sever job
taking CPU cycles. Search and retrieve can continue - although
customer reported that using some segment date logic in the
search does not provide same results as before those dates in
the ARSSEG record were corrupted. After correction of the
ARSSEG date fields, search function reverts back to the way it
was working before.
The ADDRPT job must be ended and then the QSQSRVR and instance
job usage of CPU goes back to very small or nothing as is
typical.
Problem Summary
****************************************************************
* PROBLEM: (SE60954) Licensed Program = 5770RD1 for i 7.1 and *
* i 7.2 *
* Looping Condition *
****************************************************************
* USERS AFFECTED: All IBM i Content Manager OnDemand operating *
* system users. *
****************************************************************
* RECOMMENDATION: Apply PTF SI55760 for i 7.1. *
* Apply PTF SI55761 for i 7.2. *
****************************************************************
ADDRPTOND submitted and after indexing, loading begins and it
reaches the max rows for index table, so new index table should
be generated. ARSSEG file should be updated with record of first
index table showing start and stop dates, and then new record
for next index table. In the original record START_DT and
STOP_DT fields get null values. This results in the ADDRPT job
to hang - no activity, no CPU; a QSQSRVR job will show taking
CPU in apparent loop along with the instance sever job taking
CPU cycles. Search and retrieve can continue - although customer
reported that using some segment date logic in the search does
not provide same results as before those dates in the ARSSEG
record were corrupted. After correction of the ARSSEG date
fields, search function reverts back to the way it was working
before.
The ADDRPT job must be ended and then the QSQSRVR and instance
job usage of CPU goes back to very small or nothing as is
typical.
Problem Conclusion
This problem only occurs when the load being processed causes
the maximum number of rows for a data table to be exceeded and
the new style dates are being used for the segment field. More
specifically the segment field must have a type of date. An
internal function mishandled a date causing a loop. This problem
is now fixed.
Temporary Fix
*********
* HIPER *
*********
Comments
Circumvention
PTFs Available
Affected Modules
Affected Publications
Summary Information
Status............................................ | CLOSED PER |
HIPER........................................... | Yes |
Component.................................. | 5770RD100 |
Failing Module.......................... | RCHMGR |
Reported Release................... | R710 |
Duplicate Of.............................. |
System i Support
IBM disclaims all warranties, whether express or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. By furnishing this document, IBM grants no licenses to any related patents or copyrights. Copyright © 1996,1997,1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017 IBM Corporation. Any trademarks and product or brand names referenced in this document are the property of their respective owners. Consult the Terms of use link for trademark information
Document Information
Modified date:
30 May 2015