APAR status
Closed as canceled.
Error description
This apar is to assist the user community to completely apply all maintenance to get the RMF support for surfacing PR/SM LPAR management time. The attached lists are of known apars and their associated PTFs: ************** Release 3.5.0 and 3.5.1 ************************ APAR | R502 | R512 --------|---------|--------- OY36668 | UY61902 | UY61903 OY46899 | UY71709 | UY71710 OY50008 | UY76353 | UY76354 OY51875 | UY77599 | UY77601 OY52512 | UY82168 | UY82169 ** When ordering chain OY57883 | UY85161 | UY85162 specify all PTFs listed OY59427 | UY88702 | UY88703 and IFREQ HRM3502 and OW09990 | UW14475 | UW14501 JRM3512 OY48964 | UY76353 | UY76354 OY53988 | UY82630 | UY82631 OY57833 | UY84976 | UY84977 OY56207 | UY95896 | UY95897 OY65572 | UY96678 | UY96678 OY60913 | UY98363 | UY98409 OY67727 | UW00056 | UW00060 OW00194 | UW00179 | UW00181 ************** Release 4.1.1 and 4.1.2 ************************ APAR | R411 | R41X --------|---------|--------- OY36668 | UY61904 | UY61905 OY46899 | UY71711 | UY71711 OY50008 | UY76355 | UY76356 OY51875 | UY77602 | UY77602 OY52516 | UY82170 | UY82170 ** When ordering list all OY57883 | UY85163 | UY85163 PTFs with PREs and COREQs OY59427 | UY88704 | UY88705 OW09990 | UW14505 | UW14505 OY48964 | UY76355 | UY76356 OY53988 | UY82632 | UY82632 OY57517 | UY84095 | UY84096 OY56207 | UY95898 | UY95899 OY65572 | UY96679 | UY96680 OY60913 | UY98410 | UY98411 OY67727 | UW00065 | UW00097 OW00194 | UW00183 | UW00183 ************** Release 4.2.0, 4.2.1 and 4.2.2 ***************** APAR | R420 | R421 | R422 --------|---------|---------|-------- OY36668 | UY61906 | UY61907 | UY61907 OY46899 | UY71712 | UY71713 | UY71713 OY50008 | UY76357 | UY76358 | UY76358 OY51875 | UY77603 | UY77604 | UY77604 OY52516 | UY82171 | UY82172 | UY82172 OY58993 | | | UY86654 OY57883 | UY85164 | UY85165 | UY85165 OY59427 | UY88706 | UY88708 | UY88709 OW09990 | | UW14515 | UW14517 OY48964 | UY76357 | UY76358 | UY76358 OY56017 | UY83199 | UY83200 | UY83201 OY53988 | UY82633 | UY82634 | UY82634 OY56207 | UY95900 | UY95901 | UY95902 OY65572 | UY96681 | UY96682 | UY96683 OY60913 | UY98487 | UY98488 | UY98489 OY67727 | UW00099 | UW00100 | UW00101 OW01334 | | | UW04705 ************** Release 4.1.1 and 4.1.2 ************************ APAR | R430 --------|--------- OY56207 | UY95903 OY57883 | UY85166 OW09990 | UW14518 OY65572 | UY96684 OY60913 | UY98490 OY67727 | UW00102 OW01334 | UW04707 ================================================================ PE CHAIN APAR descriptions: OY46899: THE RMF PARTITION DATA REPORT SOMETIMES INCORRECTLY REPORTS THE CAPPING INDICATOR FOR A PARTITION. IN ADDITION TO THIS, THE RMF PARTITION DATA REPORT WILL SOMETIMES INCORRECTLY REPORT THE WAIT COMPLETION STATUS, AS WELL AS THE 'WAIT COMPLETION CHANGED DURING THE MEASUREMENT INTERVAL' STATUS. THIS PROBLEM CAN ALSO MANIFEST ITSELF AS AN ABEND0C4 IN ERBMFRCR. MODULE ERBMFRCR WAS USING THE WRONG INDEX VALUE WHEN ACCESSING THE SMF70CAP FIELD OF A LOGICAL PARTITION'S LOGICAL PROCESSOR DATA SECTION. A PROPER INDEX IS NOW BEING USED. THE SAME TYPE OF ERROR WAS OCCURRING WHEN ACCESSING THE SMF70WSA AND SMF70WSC FIELDS OF THE FIRST VALID LOGICAL PROCESSOR DATA SECTION FOR THE FIRST VALID LOGICAL PARTITION. WE ALSO FOUND THE FOLLOWING PROBLEM: WHEN PROCESSING RECORDS GENERATED BY RMF WITH OY36668 APPLIED ON A B1 SECURED LOGICAL PARTITION (NOTE LPSEC FRAME), IT IS POSSIBLE FOR RMF TO REPORT THE CPU BUSY% BASED ON THE TOTAL PARTITION DISPATCH TIME RATHER THEN USING THE EFFECTIVE DISPATCH TIME. AFTER CLOSER STUDY OF THE SMF TYPE 70 RECORDS ON WHICH THE ABEND0C4 OCCURS, ONE WILL NOTE THAT THERE IS NO LOGICAL PARTITION DATA SECTION FOR PARTITION PHYSICAL, AND THE 'PHYSICAL EXISTS INDICATOR BIT' IS OFF. THIS LEADS RMF TO BELIEVE THAT PHYSICAL DOES NOT EXIST AND THAT ALL PARTITIONS' EFFECTIVE DISPATCH TIME IS ALSO NOT AVAILABLE. THIS RULE IS TRUE EXCEPT IF RMF IS RUNNING IN A SECURED PARTITION. WHEN RMF RUNS IN A SECURED PARTITION IT IS UNABLE TO GATHER PARTITION STATISTICS FOR OTHER CONFIGURED PARTITIONS. AN EXCEPTION TO THIS RULE IS NOT MADE WHEN RMF IS TRYING TO COLLECT STATISTICS FOR PARTITION PHYSICAL. RMF THINKS THAT PHYSICAL DOES NOT EXIST. AFTER RMF MAKES THE ASSUMPTION THAT PHYSICAL DOES NOT EXIST THE PARTITION'S TOTAL DISPATCH TIME IS USED TO CALCULATE CPU BUSY TIME PERCENTAGE. THE EFFECTIVE TIMES AND PERCENTAGES ARE INCORRECTLY REPORTED AS ZEROS WHEN IN FACT VALID EFFECTIVE DISPATCH TIMES EXISTS FOR THE PARTITIONS THAT RMF IS ALLOWED TO COLLECT STATISTICS ON. OY48964: RMF MODULE ERBMFRCR WILL ABEND0C9 WHEN CALCULATING THE PHYSICAL PROCESSOR TOTAL UTILIZATION FOR PARTITION PHYSICAL. CLOSER INSPECTION OF THE SMF RECORD FIELDS SMF70EDT FOR PARTITION PHYSICAL REVEALS THAT THE EFFECTIVE DISPATCH TIME CONTAINS ABNORMALLY LARGE TIMES. THIS PROBLEM WILL OCCUR DURING AN INTERVAL THAT A PHYSICAL PROCESSOR IS VARIED ON OR OFFLINE. WHEN RMF COLLECTS PHYSICAL PROCESSOR STATISTICS FOR PARTITION PHYSICAL IT ASSUMES THAT WHEN A PHYSICAL PROCESSOR IS VARIED ON OR OFFLINE THE THAT THE CP THAT CHANGES STATUS IS THE ONE WITH THE HIGHEST PHYSICAL PROCESSOR ADDRESS. THIS IS THE WAY LOGICAL PROCESSOR ADDRESSES ARE HANDLED BY PR/SM. FOR PARTITION PHYSICAL, HOWEVER, LOGICAL PROCESSOR ADDRESSES IN THE LOGICAL PROCESSOR DATA SECTIONS OF THE SMF RECORD CORRESPOND TO THE PHYSICAL PROCESSOR ADDRESSES. BECAUSE OF THIS, RMF WAS IMPROPERLY CALCULATING THE TOTAL DISPATCH TIME FOR A MEASUREMENT INTERVAL FOR PARTITION PHYSICAL DURING INTERVALS THAT VARY ACTIVITY OCCURRED. THIS IS BECAUSE RMF USES THE PROCESSOR ADDRESS AS INDEXES. OY50008: IT IS POSSIBLE THE RMF PARTITION DATA REPORT FIELD FOR LPAR MGMT % TO ALWAYS REPORT A 0.00 VALUE FOR ALL PARTITIONS, EXCEPT FOR *PHYSICAL*. THIS PROBLEM WILL ONLY HAPPEN IF THE PARTITION THAT RMF WAS RUNNING ON DURING DATA COLLECTION WAS A DEDICATED PARTITION. PREVIOUS TO LPAR MGMT TIME APAR OY36668 RMF TREATED DEDICATED PARTITIONS SIMILAR TO MVS SYSTEMS RUNNING IN NATIVE MODE. THIS WAS ESPECIALLY TRUE DURING THE CALCULATION FOR THE BUSY TIME % ON THE PAGE ONE OF THE RMF PARTITION DATA REPORT. A DEDICATED PARTITION THAT WAS NOT WAITING WAS CONSIDERED BUSY. WITH THE LPAR MGMT TIME APAR OY36668 THE BUSY TIME % WAS NOW CALCULATED USING THE EFFECTIVE DISPATCH TIME RATHER THEN THE TOTAL DISPATCH TIME REGARDLESS OF WHETHER THE PARTITION WAS DEDICATED OR NOT. THIS AREA OF CODE WAS NOT CHANGED TO ALSO BE ABLE TO CALCULATE THE LPAR MGMT % WHEN RUNNING ON DEDICATED PARTITIONS. OY56017: Applying UY74658 and UY74659, Customer gets 'NOT SEL' on the 'ELEMENT SUMMARY REPORT' for ERBSMF79, ERBPPCON, and ERBPPCOM. The SMPE states of the MODs and MAC are as follows: MOD/MAC RMID UMID Last Update ======= ======= ======== =========== ERBPPCON JRM4422 JRM4422 HRM4420 ERBPPCOM UY68894 JRM4422 HRM4420 ERBSMF79 JRM4422 JRM4422 HRM4422 JRM4422 only. Refer to apars OY47504 and OY42170 for detail description of problems that will be encountered. OY53988: AFTER THE APPLICATION OF OY48964, THE RMF SUMMARY REPORT CPU BUSY FIELD SHOWS 100% WHEN RUNNING PROCESSORS WITH A DEDICATED PARTITION AND THE WAIT COMPLETION= YES. MODULE ERBMFPSC CALCULATES THE BUSY PERCENTAGE BY SUBTRACTING THE WAIT TIME FROM THE INTERVAL LENGTH AND MULTPLIES THIS BY A SCALE FACTOR. WE HAVE FOUND THAT THE SMF70WAT FIELD THAT IS BUILT BY ERBMFDCP IS ZEROS AFTER OY48964 REGARDLESS OF THE WAIT COMPLETION BEING SET TO YES OR NO. THIS MAKES THE CPU BUSY CALCULATION INCORRECT. OY51875: WHEN REQUESTING CPU ACTIVITY REPORTS THE CPU 'BUSY TIME PERCENTAGE' FIELD WILL CONTAIN CORRECT VALUE IN THE FIRST REPORT BUT ANY SUBSEQUENT REPORTS WILL CONTAIN ZEROES IN THIS FIELD. PROBLEM SURFACES AFTER APPLY OF THE PTFS FOR APAR OY46899. PROBLEM SEEMS TO ONLY OCCUR WHEN REQUESTING 'REPORTS(ALL)', 'REPORTS(CPU,PAGESP)' OR 'REPORTS(CPU,VSTOR)'. FOR EXAMPLE IF REQUESTING 'REPORTS(CPU,CHAN)' THE PROBLEM DOES NOT OCCUR. OY52516: After installing PTF for OY50008, the status field of each logical partition in the 'partition data report section' of 'cpu activity report' contains blanks. OY57833: CPU UTILIZATION IS ZERO IN MON I SUMMARY REPORT AFTER APPLYING OY53988 1. SMF70 (LPAR) LOGICAL CPU ENTRIES CONTAIN X'00' VALUES. 2. CPU ACTIVITY AND SUMMARY REPORTS SHOW ZERO CPU BUSY VALUES AND NEGATIVE VALUES FOR TOTAL AVERAGE. THE CPU ACTIVITY REPORT ALSO SHOW ZERO BUSY PERCENTAGE. OY56207: 1. Abend0c9 in ERBDRHDR after OY11330 PR/SM support applied, and also RMFMON CPU= field in the header of all reports possibly incorrect. Module ERBMFECP makes no check for an lcca of a processor to be online during sampling, and can accumulate incorrect statistics for logical processor wait time which is used to calculate the cpu= time for the header of all rmfmon reports. The lccawtim field is the incorrect field, but it is *not* incorrect for monitor I reports or the smf70wat field. To vary the logical processor offline, the mvs 'cf' command wrong will only accumulate the lccawtim field incorrectly if the logical processor was either dedicated or, in later releases of rmf, if the processor has wait completion enabled for the processor. You may see an incorrect value in cpu= either higher or lower than expected during the timeframe of varying the processor offline. 2. After a processor is varied online to a partition, an ABEND0C9 in ERBGRCS0 may occur in Monitor II or the dispatch times and wait times may be incorrect for that processor, in Monitor I. The problem is that these fields are not reset when the processor is varied online causing these values to be incorrect. All proceeding intervals will be correct and this failure only occurs for that interval when the processor was varied online. OY65572 Following OY56207 abend0c4 received when ERBMFECP addresses a new array within the RMF CPU datatable with the wrong index. It uses the processor address out of the diagnose work area which ranges from 0 to (max-1), bu the array is declared with boundaries 1 to max. This problem doesn't appear if the first processor is offline. OY60913 1.CPU Activity Report is showing 0 busy time after apar OY53988. Customer has logical processors defined in the range 1 to A. RMF is designed to work with definitions in the range of 0-5. In this case, the results are inpredictable because the id is used internally as an index. 2.RMF CPU Report Writer abends after applying APAR OY56207 in RMF 412, RMF 421 and RMF 422 OY67727 RMF Monitor I CPU data cycle gatherer ERBMFECP sets flag for Dedicated Partition instead of Wait Completion. That results in using CCVUTILP to calculate the CPU Util. instead of using the individual Dispatch and Wait times as obtained via Diagnose 204. This data is collected by Monitor I but used only by Monitor II. Monitor II data gatherer modules ERBGRCS0 and ERBDRHDR need to be changed to test for non-dedicated LPARs correctly. OW00194 R305,R512 and R411 only ABEND0C4 IN ERBMFDCP +X'12F8 AFTER APPLYING UY98410 - OY60913. BAD MVCL INSTRUCTION IN ERBMFDCP AT +X'BAA ISSUED WITH INCORRECT LENGTH, DESTROYING ECPUBFDS DSECT ABEND0C9 at offset X'1458' of ERBMFPSC (UY68889) and ABEND0C9 at offset X'6AC' of ERBMFRCR. OW01334 RMF Monitor I Channel Path Activity Report partition utilization. When the Channel Path Busy Time CPMB_CUM_CHP_BUSY wraps, The calculation in module ERBMFDHP STM 278 at 4.2.2 is not correct. As a result, we see a very high Partition Utilization for this interval. This value wraps approximately every 76.36 busy time hours (Seldom). For the next intervals the data are correct until the count wraps again. The corresponding Monitor II module ERBRCHAN works correct (It does not divide by 8).
Local fix
Problem summary
Problem conclusion
Temporary fix
Comments
See submitter text for details on applying maintenance for RMF support for PR/SM LPAR.
APAR Information
APAR number
II06466
Reported component name
V2 LIB INFO ITE
Reported component ID
INFOV2LIB
Reported release
001
Status
CLOSED CAN
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
1992-10-23
Closed date
1993-03-03
Last modified date
1999-09-01
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Applicable component levels
[{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19N","label":"APARs - OS\/390 environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"001","Edition":"","Line of Business":{"code":"","label":""}},{"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":"001","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":null,"label":null},"Product":{"code":"SG19O","label":"APARs - MVS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"001","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SSSN3L","label":"z\/OS Communications Server"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"001","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}}]
Document Information
Modified date:
13 December 2020