PI09207: AFTER TRANSACTION ADDED DURING ONLINE CHANGE (OLC), NPRI IS SET TO ZERO ON XRF ALTERNATE

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• A transaction was added during an Online Change in an XRF
  environment.  On the IMS Active, the Normal Priority (NPRI) is
  set properly.  On the IMS Alternate, NPRI is set to zero.  As
  a result, Current Priority (CPRI) is set to zero as well.  This
  can result in the transaction not being scheduled after a
  takeover.
  .
  The problem is in module DFSCPSM0.  When a transaction is
  added, flag TRAT_VAL2 should be set with the TRAT_NPRIV value
  to indicate NPRI has been set.  Module DFSCPSM0 is setting
  TRAT_VAL1 in error.  This is not the correct flag for NPRI:
  .
           OI    TRAT_VAL1,TRAT_NPRIV INDICATE NPRI VALUE SET
  .
  The correct flag setting should be:
  .
           OI    TRAT_VAL2,TRAT_NPRIV INDICATE NPRI VALUE SET
  .
  Setting TRAT_NPRIV in TRAT_VAL1 would be the same as setting
  the TRAT_CLASSV value.  This indicates the Class value has been
  set.  Probably does not lead to any additional problems when a
  transaction is added.
  .
  TRAT_NPRIV, TRAT_VAL1, and TRAT_VAL2 are stored in the IMS
  LOG2208 MAPBYTE23 record.  While the problem has been seen in
  an XRF environment on the IMS Alternate, the problem could be
  exposed on any IMS system during restart if the log record is
  processed during a restart.
  Additional symptom:
   There is also a problem in DFSCPSM0 where the same bits in
  TRAT_ATTR2 are used to indicate that TRAT_CONVY and
  TRAT_DIRROUTY  and also, TRAT_CONVN and TRAT_DIRROUTN.
  The problem experienced was that after restart a Transaction
  no longer was indicated as being a conversation transaction
  and no spa was available.
  

Local fix

• Assign NPRI to the required value
  /ASSIGN NPRI n to TRAN xxxxxxxx
  (The local fix is only for the problem with
  NPRI)
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All IMS V11 users who do an online change.   *
  ****************************************************************
  * PROBLEM DESCRIPTION: The user had done an online change to   *
  *                      set the normal scheduling priority      *
  *                      (NPRI) for a transaction to 1.  After   *
  *                      a XRF takeover they noticed that the    *
  *                      transaction priority was now 0.         *
  ****************************************************************
  * RECOMMENDATION: INSTALL CORRECTIVE SERVICE FOR APAR/PTF      *
  ****************************************************************
  The user wanted to add a new transaction with the transaction
  normal scheduling priority set to a non zero number.  They added
  this transaction to the staging library which was later copied
  into the inactive modblks dataset.  The customer then did an
  online change to add the new request with a non zero
  normal scheduling priority( NPRI ).
  
  During the commit phase of the online change module
  DFSCPSM0 is called to process the new transactions
  SMB.  As part of this processing the attributes for this
  transaction is logged in a type x'22' log record which
  represents an action generated by a type-2 command.
  One of the things logged in this log record is the NPRI
  value and if it exists a flag bit is set to indicate this.
  This log record will be used after a restart to set up
  the correct attributes for the transaction.  The problem
  is that after a restart the user noticed that transaction
  now had a normal scheduling priority of zero.  The cause of
  this was due to the code in module DFSCPSM0 which loaded
  the NPRI is set bit, into the wrong flag byte.  The flag
  bit TRAT_NPRIV (  X'80' )  is  set in  TRAT_VAL1
  instead of TRAT_VAL2 where this flag resides.  The restart
  module when checking this bit checked TRAT_VAL2 and since it
  did not indicate that NPRI value was set it did not set it up.
  
  This APAR also fixes a similar issue with the TRAT_DIRROUTY
  and TRAT_DIRROUTN flag bits which were set in TRAT_ATTR2
  instead of the actual flag bit TRAT_ATTR3
  

Problem conclusion

• GEN:
  KEYWORDS:
  
  *** END IMS KEYWORDS ***
  
  Code has been changed in the following module to fix the problem
  adressed in this apar.
  
  ************
  * DFSCPSM0 *
  ************
  
  The code will now set the  TRAT_DIRROUTN and TRAT_DIRROUTY flag
  bits in the correct flag byte ( TRAT_ATTR3 )
  
  
  The code will now set the  TRAT_NPRIV flag
  bits in the correct flag byte ( TRAT_VAL2 )
  

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:

  PI17667 PI17668 UI17867

Modules/Macros

• DFSCPSM0
  

Fix information

• Fixed component name

  IMS V11

• Fixed component ID

  5635A0200

Applicable component levels

• R102 PSY UI17867

     UP14/05/14 P F405

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.