A fix is available
APAR status
Closed as program error.
Error description
PE28633-F708 After applying PTF UK28633 you see inconsistent results when displaying resources either from the EUI or the WUI. The inconsistency occurs when you connect to a different CMAS, your request for the same resource may be missing or return a different number of records. Additional Keyword(s) and Symptom(s): The base signature for a resmap is nulls.
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: All CICSPlex SM V3R2M0 Users * **************************************************************** * PROBLEM DESCRIPTION: Operational resources may be missing * * from WUI displays or from API result * * sets, and RTA events may not trigger * * correctly, after applying PTF UK28633 * * for APAR PK49141. * **************************************************************** * RECOMMENDATION: After applying the PTF that resolves this * * APAR, all CMASes must be restarted. Note * * that the restarts do not need to occur at * * the same time. * **************************************************************** CPSM builds Topology resource maps to indicate what resources are installed in a MAS. When an API/WUI/RTA request is made for a specific resource type , the resource maps are queried to determine where to send the request to retrieve the information. The maps are created for each resource type by the connecting CMAS, and sent to joining CMASes, so that all CMASes that help to manage a MAS can determine where to send API/WUI/RTA requests. To cut down on the amount of traffic that is shipped between the connecting and joining CMASes, the maps are written (hardened) to the local data repository (EYUDREP). To ensure that the maps are correct between the connecting and joining CMASes, each resource map has a signature, which indicates the SYSID of the CMAS that created the maps, along with the timestamp of when the maps were created. When a CMAS joins a MAS, it compares the signatures of its hardened maps with the signatures of the connecting CMAS. If the signatures match, the joining CMAS uses its hardened maps. If they do not match, the joining CMAS requests the connecting CMAS's maps be sent during the join process. With UK28633, a connecting CMAS may create a null signature for a specific resource map for a MAS. If this occurs, then the joining CMAS will not create maps for that resource type for that MAS. If an API/WUI/RTA request is made for that resource type for that MAS through the joining CMAS, then no data will be returned for that resource class. If subsequent resources are installed in the MAS for that resource type, the joining CMAS will build and harden an incomplete map for that resource type. This can result in some but not all resources being displayed for the MAS for that resource type.
Problem conclusion
Method EYU0XCRB (XCRB), which retrieves the hardened maps from the EYUDREP, has been updated to correct the logic flaw in UK28633 that can result in a null signature being built in the connecting CMAS. To ensure that any incorrect maps created by the application of UK28633 are fixed, the following changes have been made: - Method EYU0TSSC (TSSC), which is called in the connecting CMAS, will verify that any existing signatures are non-null. If a signature is null, TSSC will update the signature to a valid value. - Method EYU0TSRA (TSRA), which builds the list of map signatures that is passed from the connecting CMAS to the joining CMASes, has been updated to turn on an indicator to inform the joining CMASes that the maps on the connecting CMAS are valid. - Method EYU0TSSJ (TSSJ), which is called in the joining CMAS, has been updated to determine if the connecting CMAS has valid maps. If so, it will indicate to XCRB that the connecting CMAS has valid maps. - In addition to the fix noted above, XCRB has been updated in the joining CMAS to request that the local maps be deleted if TSSJ indicates that the connecting CMAS has valid maps and XCRB determines that the local maps may be invalid. The parameter list for XCRB, EYUZXCRB, has been updated so that TSSJ can indicate that the connecting CMAS has valid MAPs. - Method EYU0TSMH (TSMH), which requests that maps be hardened to the EYUDREP, has been updated to indicate that the maps are valid. TSMH will indicate this if called in the connecting CMAS, or if called in the joining CMAS if the connecting CMAS also has the PTF on that resolves this APAR. - Method EYU0XCRS (XCRS), which hardens the maps to the EYUDREP, has been updated to indicate that the maps are valid if TSMH indicates this. The parameter list for XCRS, EYUZXCRS, has been updated so that TSMH can indicate that the maps are valid.
Temporary fix
********* * HIPER * ********* FIX AVAILABLE BY PTF ONLY
Comments
Operational resources may be missing from WUI displays or from API result sets, and RTA events may not trigger correctly, after applying PTF UK28633 for APAR PK49141. CPSM builds Topology resource maps to indicate what resources are installed in a MAS. When an API/WUI/RTA request is made for a specific resource type , the resource maps are queried to determine where to send the request to retrieve the information. The maps are created for each resource type by the connecting CMAS, and sent to joining CMASes, so that all CMASes that help to manage a MAS can determine where to send API/WUI/RTA requests. To cut down on the amount of traffic that is shipped between the connecting and joining CMASes, the maps are written (hardened) to the local data repository (EYUDREP). To ensure that the maps are correct between the connecting and joining CMASes, each resource map has a signature, which indicates the SYSID of the CMAS that created the maps, along with the timestamp of when the maps were created. When a CMAS joins a MAS, it compares the signatures of its hardened maps with the signatures of the connecting CMAS. If the signatures match, the joining CMAS uses its hardened maps. If they do not match, the joining CMAS requests the connecting CMAS's maps be sent during the join process. With UK28633, a connecting CMAS may create a null signature for a specific resource map for a MAS. If this occurs, then the joining CMAS will not create maps for that resource type for that MAS. If an API/WUI/RTA request is made for that resource type for that MAS through the joining CMAS, then no data will be returned for that resource class. If subsequent resources are installed in the MAS for that resource type, the joining CMAS will build and harden an incomplete map for that resource type. This can result in some but not all resources being displayed for the MAS for that resource type. Method EYU0XCRB (XCRB), which retrieves the hardened maps from the EYUDREP, has been updated to correct the logic flaw in UK28633 that can result in a null signature being built in the connecting CMAS. To ensure that any incorrect maps created by the application of UK28633 are fixed, the following changes have been made: - Method EYU0TSSC (TSSC), which is called in the connecting CMAS, will verify that any existing signatures are non-null. If a signature is null, TSSC will update the signature to a valid value. - Method EYU0TSRA (TSRA), which builds the list of map signatures that is passed from the connecting CMAS to the joining CMASes, has been updated to turn on an indicator to inform the joining CMASes that the maps on the connecting CMAS are valid. - Method EYU0TSSJ (TSSJ), which is called in the joining CMAS, has been updated to determine if the connecting CMAS has valid maps. If so, it will indicate to XCRB that the connecting CMAS has valid maps. - In addition to the fix noted above, XCRB has been updated in the joining CMAS to request that the local maps be deleted if TSSJ indicates that the connecting CMAS has valid maps and XCRB determines that the local maps may be invalid. The parameter list for XCRB, EYUZXCRB, has been updated so that TSSJ can indicate that the connecting CMAS has valid MAPs. - Method EYU0TSMH (TSMH), which requests that maps be hardened to the EYUDREP, has been updated to indicate that the maps are valid. TSMH will indicate this if called in the connecting CMAS, or if called in the joining CMAS if the connecting CMAS also has the PTF on that resolves this APAR. - Method EYU0XCRS (XCRS), which hardens the maps to the EYUDREP, has been updated to indicate that the maps are valid if TSMH indicates this. The parameter list for XCRS, EYUZXCRS, has been updated so that TSMH can indicate that the maps are valid.
APAR Information
APAR number
PK56207
Reported component name
CICSTS V3 Z/OS
Reported component ID
5655M1500
Reported release
50M
Status
CLOSED PER
PE
YesPE
HIPER
YesHIPER
Special Attention
NoSpecatt
Submitted date
2007-11-08
Closed date
2008-01-14
Last modified date
2008-02-02
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UK32867
Modules/Macros
EYUQXCRB EYUQXCRS EYURTISD EYURTRTD EYURXCRB EYURXCRL EYURXCRS EYUTRCHE EYUYXCRB EYUYXCRS EYUZXCRB EYUZXCRS EYU0TSMD EYU0TSMH EYU0TSRA EYU0TSRC EYU0TSSC EYU0TSSJ EYU0XCRB EYU0XCRS EYU9XCPU EYU9XCP3 EYU9XCP4
Fix information
Fixed component name
CICSTS V3 Z/OS
Fixed component ID
5655M1500
Applicable component levels
R50M PSY UK32867
UP08/01/16 P F801 ®
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.
[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSGMGV","label":"CICS Transaction Server"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"3.2","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"3.2","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
02 February 2008