PK55814: PIWEBSRV LMQUEUE BACKUP. ONE TASK TRIES TO GET THE LOCK EXCLUSIVE WHILE IT ALREADY HAS IT SHARED.

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• An EXEC CICS PERFORM PIPELINE SCAN is issued to implement
  changes to a WSBIND file while another task is currently
  executing the business logic of a webservice request.  A task
  may get the PIWEBSRV shared, then later try to get it exclusive
  as well.  The task suspends indefinitely, causing an LMQUEUE
  backup on PIWEBSRV
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All CICS Users                               *
  ****************************************************************
  * PROBLEM DESCRIPTION: Web Service tasks can hang when         *
  *                      updating an active Web Service          *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  A Web Service that was currently in use was updated
  and a CEMT PERFORM PIPELINE SCAN command was issued for
  the containing PIPELINE. This command marked the active
  Web Service for updating once it had completed its
  current work. This drives the updating process in
  DFHPIWR once the outstanding work has completed.
  
  At this point a shared lock on the Web Service has
  already been obtained by DFHPIWR as it got one on
  entering DFHPIWR and released it on leaving.
  
  However as part of the updating process in DFHPIWR, it
  called DFHPISC UPDATE_WEBSERVICE. This subsequently
  called back into DFHPIWR for DISCARD_WEBSERVICE before
  reinstalling it. However, as DFHPISC has called back
  into DFHPIWR a second shared lock has been obtained
  by DFHPIWR. When DISCARD_WEBSERVICE attempted
  to swap its shared lock for an exclusive lock it hung
  as it only relinquished one of its two outstanding
  shared locks and so the request for the exclusive lock
  suspended waiting for all the shared locks to first
  be relinquished, which of course never will happen.
  
  DFHPISC's UPDATE_WEBSERVICE also did not free the
  shared lock in all circumstances which could lead to
  the same problem.
  

Problem conclusion

• DFHPIWR has been updated to first relinquish its shared lock
  before calling DFHPISC UPDATE_WEBSERVICE. DFHPISC has also
  been updated to relinquish the shared lock at the end of
  UPDATE_WEBSERVICE processing, in all circumstances.
  

Temporary fix

• FIX AVAILABLE BY PTF ONLY
  

Comments

APAR Information

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

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

  UK34758 UK34759

Modules/Macros

•    DESPISC  DESPIWR  DFHPISC  DFHPISCA DFHPISCM
  DFHPISCT DFHPIWR
  

Fix information

• Fixed component name

  CICSTS V3 Z/OS

• Fixed component ID

  5655M1500

Applicable component levels

• R400 PSY UK34758

     UP08/03/27 P F803

• R500 PSY UK34759

     UP08/03/27 P F803

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.