OA60027: ABENDC0D RSN01 IOSRMIHP AFTER IOS071I IDLE WITH WORK QUEUED CAN OCCUR USING SDM XRC SINGLE READER WITH HYPERPAV

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Customer was using XRC and HYPERPAV, experienced,
  IOS1071I dddd,cc,ANTAS004,IDLE WITH WORK QUEUED.
  Within the next 1 second, IOSRMIHP found an
  unexpected IOQ chain involving ALIAS which could
  not be started.  Analysis of svdump produced,
  reveals that 2 competing i/O request were in need of an ALIAS
  such that the normal Redrive of the previous IWQ experienced a
  timing window such that the second i/o request took the alias
  from the pool.  Recovery for the redrive was still in progress,
  however when attempting to queue the alias the IOSRMIHP detected
  the improperly queued alias and declared the abendC0D.
  Idle with work queued (IWQ) is a very infrequent event and
  normally a retry is executed without complexity.   In the case
  of SDM/XRC exploitation, hyperpav alias are used to compensate
  for a single reader to achieve parallelism.   Multiple readers
  will provide better parallelism and reduce the complexity of
  HYPERPAV prioritization which can lead  to competition for alias
  between parallel i/o requests.
  
  ADDITIONAL SYMPTOMS:
  Customer experienceed MSGIOS071I IDLE WITH WORK QUEUED while
  using XRC SDM  ANTAS0004.
  The system produced a dump for IOSRMIHP ABENDC0D RSN01.  Further
  examination of the dump and LOGREC MIH RECORDS indicating IOQ
  not found on the UCBIOQ chain.
  -
  In this scenario, the IDLE WITH WORK QUEUED resulted in a
  REDRIVE attempt, however during the redrive, the alias was
  effectively stolen by another competing i/o request experiencing
  a serialization window in the algorithm to rederive the detected
  IDLE condition.   IOS will need to correct the redrive
  processing to avoid this unexpected error.
  IDLE with work queued can occur when there is enough competition
  for ALIAS and will require queueing at the Subsystem level.
  This is very infrequent and is normally a very easy redrive of
  the i/o request.   The use of SINGLE READER environments can
  further complicate the alias competition so it is recommended to
  use multiple readers achieve bettter parallelism and avoid this
  rare window.
  

Local fix

• BYPASS/CIRCUMVENTION:
  Customers running large System Data Mover environments in
  production should use multiple readers.  Single readers are ok
  for migration, however production workloads can stress the
  infrastructure to the point experienced here where requests are
  competing for Alias resouces.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  * Users at HBB77A0 and above.                                  *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  * When an idle with work queued is                             *
  * encountered, MSGIOS071I or MSGIOS1071I                       *
  * is issued by IOS.  IOS will redrive                          *
  * the I/O that encountered the idle with                       *
  * work queued.  If the redrive I/O times                       *
  * out, the alias associated with the                           *
  * redrive I/O can be reassigned to a                           *
  * second, competing, I/O request.                              *
  * IOSRMIHP will issue ABENDC0D RSN01 to                        *
  * indicate the alias for the redrive I/O                       *
  * is improperly queued.                                        *
  *                                                              *
  * IOSRMIHP when issuing the ABENDC0D                           *
  * RSN01 for the improperly queued alias                        *
  * may encounter an ABEND0C4.                                   *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  When an idle with work queue is encountered IOS attempts to
  redrive the I/O to the same alias.  A timing window exists
  where the redrive I/O times out and the alias associated with
  redrive I/O is assigned to second I/O request.  As the recovery
  process for the redrive I/O proceeds, the alias that is
  associated with the redrive (now assigned to a second I/O) is
  queued for the redrive I/O and IOSRMIHP detects that this
  alias is now improperly queued and issues a ABENDC0D RSN01 to
  indicate this condition.  (Idle with work queue is an
  infrequent event and the redrive processing is very simple.)
  
  
  When the ABENDC0D RSN01 in IOSRMIHP is issued (to identify an
  improperly queued alias) a ABEND0C4 in IOSRMIHP may also be
  encountered.
  

Problem conclusion

• Corrected the timing window seen with idle with work queued to
  eliminate the improperly queued alias and corrected the
  ABEND0C4 in IOSRMIHP.
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

  UJ04192 UJ04193 UJ04194

Modules/Macros

• IOSVSSCQ IOSRMIHP IOSVSCHR
  

Fix information

• Fixed component name

  IOS

• Fixed component ID

  5752SC1C3

Applicable component levels

• R7A0 PSY UJ04194

     UP20/10/28 P F010

• R7B0 PSY UJ04192

     UP20/10/28 P F010

• R7C0 PSY UJ04193

     UP20/10/28 P F010

Fix is available

• Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.