PI12767: INSTALLING WLMGROUP WITH MORE THEN ONE WLMDEF POINTING TO THE SAME TRANGRP FAILS

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• When the same TRANGRP is named in more than one WLMDEF in
  the WLMGROUP we have a problem.  When we go to process the
  second WLMDEF, we get all the WLMATRANs, including the ones
  that were installed when processing the earlier WLMDEF.
  We then look in the input list for each one, and because we
  removed each element from the input DTRINGRP list when we
  processed the earlier WLMDEF, we assume that the DTRINGRPs
  were removed and we DISCARD each of the active transaction,
  including the ones that we just installed.
  

Local fix

• *
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All CICSPlex SM V5R1M0 Users                 *
  ****************************************************************
  * PROBLEM DESCRIPTION:    You have a TRANGRP which is named in *
  *                      more than one WLMDEF to effect workload *
  *                      separation.  All the WLMDEFs are linked *
  *                      to a single WLMGROUP.  You add one or   *
  *                      more new transactions to the TRANGRP,   *
  *                      and then reinstall the WLMGROUP to add  *
  *                      the new transactions to your active     *
  *                      workload.  You notice that all the CICS *
  *                      transactions in the shared TRANGRP are  *
  *                      being routed to the default target      *
  *                      scope named in your WLMSPEC. In the     *
  *                      CMAS joblog, you find the following     *
  *                      message was issued for each transaction *
  *                      in the shared TRANGRP:                  *
  *                                                              *
  *                        EYUWM0443I Dynamic transaction (xxxx) *
  *                             discarded from transaction group *
  *                             (trangrp) in CICSplex (cicsplex) *
  *                             for workload (wlmspec).          *
  *                                                              *
  ****************************************************************
  * RECOMMENDATION: After applying the PTF that resolves this    *
  *                 APAR, all CMASes must be recycled to pick    *
  *                 up the new code.  Note that CMASes do not    *
  *                 need to be brought down and restarted at     *
  *                 the same time.                               *
  ****************************************************************
     When module EYU0WMWI (WMWI - Install WLMDEFs in Active Work-
  load) is called to reinstall a WLMGROUP it is passed a list of
  all WLMDEFs in the WLMGROUP, a list of all TRANGRPs named in the
  WLMDEFs, and a list of all DTRINGRPs for the TRANGRPs.  First we
  look at each WLMDEF to see if it is already active, and if any
  of the attributes which cannot be changed in an active workload,
  have been changed.  If it is not active then we install it.
     Next we rescan the WLMDEF list, retrieve the element from the
  TRANGRP list for the TRANGRP named in the WLMDEF, and see if it
  is already active.  If it is active, we make sure that no attri-
  butes that cannot change, has changed.  If it is not active, we
  add it to the active list.
     Finally, we rescan the list of WLMDEFs again, and retrieve
  all the WLMATRANs (Transaction in an active workload) for the
  TRANGRP named in the WLMDEF.  We check to see if each active
  transaction is in the incoming DTRINGRP list.  If it is, we
  remove it from the incoming list so it won't be reinstalled.  If
  it is not in the DTRINGRP list, we assume that the DTRINGRP was
  removed, so we discard the WLMATRAN.  When we are finished, any
  DTRINGRPs remaining in the input list are new, and we install
  them, removing each DTRINGRP resource from the list as it is
  processed.
     When the same TRANGRP is named in more than one WLMDEF in
  the WLMGROUP, when we go to process the second WLMDEF, we get
  all the WLMATRANs, including the ones that were installed when
  processing the earlier WLMDEF.  We then look in the input list
  for each one, and because we removed each element from the
  input DTRINGRP list when we processed the earlier WLMDEF, we
  assume that the DTRINGRPs were removed and we DISCARD each of
  the active transaction, including the ones that were just
  installed.
  

Problem conclusion

• Because installation of DTRINGRPs into an active workload is
  only required once, module EYU0WMWI was modified to create a
  temporary cache list.  During the third scan of the WLMDEF list,
  as each WLMDEF resource is retrieved, an attempt is made to add
  the name of the TRANGRP for the WLMDEF to the temporary cache
  list.  If the attempt succeeds, processing continues and new
  DTRINGRP resources are installed.  If the TRANGRP is already in
  the list, then that TRANGRP is bypassed because it was processed
  for another WLMDEF.
  

Temporary fix

• *********
              * HIPER *
              *********
  FIX AVAILABLE BY PTF ONLY
  

Comments

APAR Information

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

  PI12704

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

  UI15869

Modules/Macros

• EYU0WMWI
  

Fix information

• Fixed component name

  CICS TS Z/OS V5

• Fixed component ID

  5655Y0400

Applicable component levels

• R80M PSY UI15869

     UP14/03/12 P F403

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.