COPYRIGHT (C) 1984-2021 MERRILL CONSULTANTS DALLAS TEXAS USA
MXG NEWSLETTER FORTY-NINE
*********************NEWSLETTER FORTY-NINE******************************
MXG NEWSLETTER NUMBER FORTY-NINE, February 5, 2007.
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
I. MXG Software Version.
II. MXG Technical Notes
III. MVS Technical Notes
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX z/VM Technical Notes.
X. Incompatibilities and Installation of MXG.
See member CHANGES and member INSTALL.
XI. Online Documentation of MXG Software.
See member DOCUMENT.
XII. Changes Log
Alphabetical list of important changes
Highlights of Changes - See Member CHANGES.
COPYRIGHT (C) 2005 MERRILL CONSULTANTS DALLAS TEXAS USA
I. The 2007 Annual Version MXG 24.24 was dated February 5, 2007.
All sites were mailed a letter with the ftp download instructions.
The availability announcement was posted to both MXG-L and ITSV-L.
You can always request the current version using the form at
http://www.mxg.com/ship_current_version.
1. The current version is MXG 24.24, dated Feb 5, 2007.
See CHANGES member of MXG Source, or http://www.mxg.com/changes.
II. MXG Technical Notes
2. Comparison of TRSMAIN and ZIP compression techniques.
We create both Windows Zipped and z/OS Tersed distribution files for
MXG Software, which is a single sequential pure text file, currently
2,119,181 lines of text; the lines are FB 80 on z/OS, but are not
numbered, so the file is smaller as a variable-length ASCII file.
Our current version's stored sizes are:
Size of FB 80 EBCDIC file, z/OS 169,534,800 bytes
Size of PC ASCII variable length 104,353,987 bytes
Zipped PC file 17,589,006 bytes
Tersed FB 80 21,653,504 bytes
Terse reduced the z/OS file by a factor of 7.82.
Zip reduced the ASCII file by a factor of 5.93.
But, the 8-bit z/OS file is 62% larger than the ASCII file; not
only is there the 8-bit EBDCIC vs 7-bit ASCII, but the ASCII
file lines are the actual length of text, while each line of
the z/OS file is 80 bytes long.
But the 169:21 reduction, almost 8:1 reduction of the 80-byte
EBCDIC text to its TERSEd equivalent is very consistent with my
experience with not only text files, but also z/OS customer's SMF
data files.
1. We consistently see that if you are executing MXG on ASCII, using
the SAS ftp access method to directly process the raw data with MXG
is always faster than using ftp to copy the raw data to the local
machine, and then reading that local file with MXG.
This recent comparison with 1.93 GB of z/VM MONWRITE data showed:
ftp download (7m50s) + TYPEVMXA (7m38s) = 15m 28s = 928 sec
ftp access method direct with TYPEVMXA = 12m 41s = 761 sec
which is 17% faster. 26Aor2006
III. MVS Technical Notes.
48. BMC's Mainview GUI can have a CPU Loop in program BBW9IC00 that is
corrected by their APARs BPY9689 and BPY9610.
47. APAR OA23161 reports RMF Monitor I, II, and III stop recording data
on a device after a dynamic activate of an I/O configuration that
removed a sysplex LPAR from the device candidate list. The device
is still available to other sysplex systems, but the device is
missing in all of the RMF Monitor records on other sysplex systems.
46. APAR PK56492 reports massive numbers of SMF 92 subtype 10 or 11
records (for OPEN/CLOSE directories under /var/ibm/tivoli..).
45. APAR OA22492 reports IFASMFDL, the "IFASMFDP SMF Dump Program" when
SMF is recorded to a Logstream, will stop processing other Logstream
datasets when an empty logstream is encountered.
44. APAR OA22791 reports an ABEND 0C1 when Restarting SMF, but with no
fix, and with "the only negative impact being that the user
issuing the request for an SMF service will receive control back
with R15=16 ('10'x) and with the service not performed (e.g., if
the request was to write an SMF record, that record will NOT be
written. IN OTHER WORDS, A LOST SMF RECORD IS NOT AN ERROR TO IBM!
Fortunately, the probability of the condition is very low.
43. APAR OA22768 corrects ABEND 30A-014 when switching back from SMF
Logstream Recording to Dataset Recording.
42. Information APAR II14219 has extensive "support use" information for
DB2 z/OS zIIP exploitation.
41. APAR OA19618 corrects R723CIOC (IOUNITS) very large values.
40. APAR OA19231 reports incorrect CU type in RMF; moving DASD to a Z9
showed the incorrect 3990-6 when it should have been a 3105.
39. APAR OA19546 corrects RMF III CPUG3 zero offset while data is there.
38. APAR PK35466 corrects SMF 116 MQ Client data WSTIDCHL and WTIDCHLC.
37. APAR PK36010 corrects SMF 14, 15 records; missing close events in
the IMS Audit Management Expert reporting.
36. APAR PK37355 corrects MAXQDPTH in SMF 116 statistics records, which
was not being reset across SMF intervals for long running tasks.
35. APAR PK37848 fixes several problems in SMF 119 records for FTP.
34. APAR PK29870 corrects SMF 16 CPU time of 24 hours, which occurs when
DFSORT is called from a program that uses dynamic allocation, due to
yet another conflict when two tasks (DFSORT, DYNALOC) both issue
STIMER.
33. APAR PK32855 eliminates excess CPU time in WebSphere even when SMF
120 records are disabled.
32. APAR OA19739 corrects report output from IFASMFDP for a site that
dumped an entire year's SMF data; the total record count should have
been 1,300,202,341, but the report truncated the leading digit so it
showed only 300,202,341. DUMPED AN ENTIRE YEAR's SMF?????
31. zIIP CPU Time Comparisons between TYPE72GO and TYPE30_V.
A. The zIIP CPU times in the RMF Type 72 Service Class/Reporting Class
are compared with zIIP CPU times in SMF Type 30 Interval Record.
Total zIIP times match very well, between SMF and RMF, and between
Service Class and Reporting Classes. The totals for Service Classes
match totals for Reporting Classes, and many service classes match
both their reporting class data in TYPE72GO and their address space
data in TYPE30_V/SMFINTRV.
But: MANY Service Class pairs do NOT match up, because the Service
Class of the address space can be different than the service
class of the classified transaction, and because of where the
resources are recorded in cross-memory transactions.
There is no error here, just different recording techniques.
Original example:
C72ZIPTM C72ZIETM C30ZIPTM C30ZIETM
Reporting Classes 8508.93 725.89 8609.19 742.41
Service Classes 8508.93 725.89 8609.19 742.41
Comparison of SMF 30 and TYPE 72 ZIP CPU measurements
Report 1 - MATCHED Service/Reporting Classes
Some Service Classes/Reporting Classes entries match almost exactly
between their type 72 and type 30 data. Horizontally, you can see
the match between the 72 and 30 data for each class. In groups,
you can see that the Service Class and Reporting Class totals match
exactly. And you can see that two of the Service Classes (BATWGWK
and BATWLO match exactly their corresponding Reporting Classes
(RTNGGWK and RTCGPG4), but the other four don't pair exactly.
MATCHED ZIP TIMES - TYPE72GO COMPARED WITH TYPE30 INTERVAL
--------------------- SERVICE CLASSES --------------------------
SRVCLASS C72ZIPTM C72ZIETM C30ZIPTM C30ZIETM PCT30MORE
BATWGWK 9.74 0.10 9.85 0.10 101.193
BATWHI 1224.36 62.27 1257.39 66.16 102.870
BATWHIP 8.57 0.14 8.62 0.15 100.628
BATWLO 151.46 2.49 153.52 2.63 101.425
BATWMD 7106.10 660.39 7171.03 672.87 100.997
BATWMDP 8.71 0.50 8.78 0.50 100.854
-------- -------- -------- --------
8508.93 725.89 8609.19 742.41
-------------------- REPORTING CLASSES -------------------------
RPTCLASS C72ZIPTM C72ZIETM C30ZIPTM C30ZIETM PCT30MORE
RTCGPG2 7502.62 691.14 7582.38 706.20 101.157
RTCGPG3 151.46 2.49 153.52 2.63 101.425
RTCGPG4 813.72 31.29 831.67 32.60 102.279
RTNGGWK 9.74 0.10 9.85 0.10 101.193
RTNGHRJ 18.33 0.69 18.63 0.70 101.602
RTNGPG5 13.06 0.18 13.14 0.18 100.605
-------- -------- -------- --------
8508.93 725.89 8609.19 742.41
======== ======== ======== ========
17017.86 1451.79 17218.38 1484.82
Report 2 - UNMATCHED Service/Reporting Classes
The DB2 Service and Reporting Classes DDF and RDDF are for Enclaves
that do not have an SMF 30 address space, but their CPU times are
included in the address space record for DB2PRD Service Class, and
the address space record for RDP1DIST/RDP2DIST Reporting Class.
---------------SERVICE CLASSES -------------------------
SRVCLASS C72ZIPTM C72ZIETM C30ZIPTM C30ZIETM
DB2PRD 0.80 0.00 5623.12 354.17
DDFPRDET 2754.39 141.25 . .
DDFPRDLA 0.03 0.00 . .
DDFPRDLO 2676.61 187.98 . .
DDFPRDMD 80.15 11.14 . .
DDFPSAGT 0.52 0.07 . .
DDFPSSQP 5.06 0.29 . .
-------- -------- -------- --------
5517.56 340.73 5623.12 354.17
--------------REPORTING CLASSES ------------------------
RPTCLASS C72ZIPTM C72ZIETM C30ZIPTM C30ZIETM
RDDFDEF 2676.61 187.98 . .
RDDFPRDM 80.15 11.14 . .
RDDFPRDX 0.03 0.00 . .
RDDFTA 2754.39 141.25 . .
RDDRAPS 0.52 0.07 . .
RDDRCON 5.06 0.29 . .
RDP1DIST 0.26 0.00 2806.69 206.08
RDP2DIST 0.53 0.00 2816.43 148.09
-------- -------- -------- --------
5517.56 340.73 5623.12 354.17
======== ======== ======== ========
11035.12 681.46 11246.24 708.34
Newer example. Report produced by ANALZIPC Zip CPU analysis program:
R72 R72 R30 R30 R30 R72 R30 R72
ZIP ZIE ZIP ZIE TCB TCB SRB SRB
SRVCLASS:
BATDEVHI 0 0 0 0 1 1 0 0
BATDEVMD 0 0 0 0 2907 3417 50 56
BATPRDHI 0 0 0 0 791 3 1 0
BATPRDLO 0 0 0 0 7463 7484 87 82
BATPRDMD 0 7 0 13 25230 20798 1580 1506
CICPRDHI 0 0 0 0 61519 61534 970 971
CICPRDR1 0 0 0 0
CICPRDR2 0 0 0 0
CICPRDR3 0 0 0 0
DDFHI 281 3571 11624 0
DDFHOT 77 1774 5671 0
DDFLO 1363 2606 6889 0
DDFMD 33 611 2338 0
OMVSBAT 0 0 0 0 71 59 8 7
ONLPRDLO 0 0 0 0 30 30 6 6
STCHI 2 0 1763 8631 33147 6290 6791 6793
STCLO 0 0 0 0 4452 4458 455 455
STCMD 0 0 0 0 2307 2649 95 96
SYSOTHER 0 0 0 0
SYSSTC 0 0 0 0 3177 3202 3170 3171
SYSTEM 0 0 0 0 2056 2910 5205 5562
TSOPRDMD 0 0 0 0 4880 5108 65 61
---- ---- ---- ---- ------ ------ ----- -----
1757 8572 1763 8645 148038 144471 18491 18771
B. This note revised March, 2008, then numbers were added to the
schematic in Oct 2011.
Details:
Variables and schematic of zip CPU times recorded in SMF 30
These are the MXG field names and descriptions of the zIIP
variables data created from the SMF type 30 records:
ZIP CPUZIPTM /*SMF30_TIME_ON_ZIIP*/
DZI CPUDZITM /*SMF30_DEP_ENCLAVE_TIME_ON_ZIIP*/
EZI CPUEZITM /*SMF30_IND_ENCLAVE_TIME_ON_ZIIP*/
ZIE CPUZIETM /*SMF30_ELIGIBLE*TIME_ZIIP_ON_CP*/
DZE CPUDZETM /*SMF30_DEP_ENCLAVE_TIME_ZIIP_ON_CP*/
EZE CPUEZETM /*SMF30_IND_ENCLAVE_TIME_ZIIP_ON_CP*/
EZQ CPUEZQTM /*SMF30_IND_ENCLAVE_TIME_ZIIP_QUAL*/
DZQ CPUDZQTM /*SMF30_DEP_ENCLAVE_TIME_ZIIP_QUAL*/
CPU TIME ON ZIIP ENGINES CPU TIME ON CP ENGINES
"Actual" "Eligible"
------------CPUZIPTM------------ ------------CPUZIETM------------
855,964 2,491
-UNCAPTUR---CPUDZITM---CPUEZITM- -UNCAPTUR---CPUDZETM---CPUEZETM-
(DEP) (IND) (DEP) (IND)
4,224 64,875 786,905 24 863 1,604
"QUALIFIED DEPENDENT ENCLAVES" "QUALIFIED INDEPENDENT ENCLAVES"
(Sum of DEP Actual and Eligible) (SUM of IND Actual & Eligible)
(Includes ZIP and CPU TIMES) (Includes ZIP and CPU TIMES)
"Actual" "Eligible"
------------CPUDZQTM------------ ------------CPUEZQTM------------
73,784 1,420,409
-UNCAPTUR---CPUDZITM---CPUDZITM- -UNCAPTUR---CPUEZITM---CPUEZETM-
(DEP) (IND) (DEP) (IND)
53 64,875 862 662,000 756,805 1,604
----IND-PLUS-DEPN-CP---
663,984
--CPUENCTM---CPUDETTM--
(IND) (DEP)
652,655 11,329
The "Independent Enclave zIIP Qualified" time ("EZQ")=1,142,409 is
greater than the SUM of the "Independent Enclave CPU Time on zIIP"
("EZI")=756,805 plus the "Zip-Eligible Independent Enclave CPU Time
on CP" ("EZE")=1,604, by about 662,000 seconds, which happens to be
(coincidentally?) very close to the 663,984 sum of the "ENCLAVE CPU
TIME" ("ENC")=652,655 plus the "DEPENDENT ENCLAVE CPU TIME" ("DET")
of 11,329 seconds.
30. The VTF Mainframe (CopyCross) V2.1.0 product requires PTF BV00340 if
you want to ftp data from a tape device with that product installed.
29. APAR OA19453 reports SMF7NRO (MXG variable LOSTRECS) could be wrong
if the value is over 64K.
28. Very obscure condition, but if you had different values for the TCB
CPUCOEFF than the SRB SRBCOEFF, APAR OA19462 corrects an error; the
CPUCOEFF, instead of the SRBCOEFF, was used to calculate SRBUNITS,
but only in JBB77S9, HBB7772S and HBB7730 levels of z/OS.
27. APAR OA19852 corrects the invalid CPURCTTM, NEGATIVE SERVICE UNITS,
etc that were introduced by OA19257, which had PE APAR OA19282 prior
to the final correction in OA19852, the PTF for which, has now been
validated by MXG users. Text of this change revised 27Feb2007.
OA19257 corrects slight imprecision in calculation of CPU and SRB
Service Units in SRM code that was discarding the remainder of the
division, which could have caused values to be too small; with this
APAR, more CPU time is captured due to the higher precision.
These IBM fields could have been too small
SMF30CSU SMF30SRB R723CCPU R723CSRB RQSVCPU RQSVSRB RCAECPU RCAESRB
They become these MXG variables in these datasets:
Dataset TYPE72GO, RMFINTRV, TRNDRMFI:
CPUUNITS and SRBUNITS
CPUTCBTM, CPUSRBTM, CPUTM
Datasets TYPE30_V,TYPE30_4,TYPE30_5,SMFINTRV,JOBS,STEPS
CPUUNITS and SRBUNITS
SRVTCBTM, SRVSRBTM, TOTCPUTM
But note that the variables CPUTCBTM, CPUSRBTM, and CPUTM in the
datasets TYPE30_V,TYPE30_4,TYPE30_5,SMFINTRV,JOBS,STEPS
are NOT impacted by this APAR, as they are NOT service-unit-based.
26. From an IBM-Main posting as to the contents of Unix Systems Services
Process Identifiers (PIDs): The right two bytes are sequential,
similar to the customary unix PID. The leftmost byte is an attempt
to insure long-term uniqueness. The remaining second from left byte
is reserved for sysplex use; here are some data examples:
PID in decimal PID in hex
83886667 '0500024B'x
590 '0000024E'x
16777806 '0100024E'x
589 '0000024D'x
83886673 '05000251'x
25. APARs OA12857, OA12858, and OA12861 are required to populate the
PDSE cache statistics in the SMF 14 and 15 records.
24. APAR OA17891 corrects SMF 89 fields SMF89UCT, SMF89USR, and SMF 30
fields SMF30UCT, SMF30UCS; these are MXG variables PRODTCB and
PRODSRB in TYPE30MU (Measured Usage) and TYPE89 datasets.
No change was required in MXG code as these were value corrections.
However, APAR OA19852 is needed to correct errors in OA17891 that
impacted the SMF30UCT and SMF89UCT Usage Segment CPU times, as well
as correcting yet another error in the CPURCTTM.
23. APAR PK32078 reports incorrect Websphere CPU time if servlets have
names greater than 128 characters.
22. APAR PK32519 corrects the counts in variable TSIPDSCA which were
incorrectly being included in variable TSIPDSCO.
21. APAR OA14282 reports WLM data fields were missing in JES2 SMF 26
record, if the JOB had no accounting fields; now corrected so
WLM data fields do not depend on the existence of ACCOUNTn data.
20. APAR OA12079 reports JES3 SMF 26 SMF26NAM and SMF26MSG can be
incorrect in purge record for output received back from a JES3
node and processed on a JES3 system.
19. APAR OA17663 reports SMF type 30 subtype 2 records can stop being
written for an address space that takes an ABEND553 (rc4,rc8,rcC)
unless the OPERATOR takes the appropriate corrective action that is
described in the APAR text.
18. APAR OA15461 corrects RMF STARTIME to include "Leap Seconds", the
(currently) 23 second addition to TAI (International Atomic Time)
(old "GMT") that creates UTC (Coordinated Universal Time). Leap
seconds were added to SMFINTRV INTBTIME long ago by OW43279.
There is a circumvention in the APAR: If you use SYNC(RMF,xx)
option in RMF, with xx=00-59, leap seconds ARE considered to
trigger a new RMFINTRV. However, if you instead use SMF interval
synchronization (SYNC(SMF)), SMF signals a new interval and that
time did NOT include leap seconds, so records requested for 15 min
intervals were written at 11:14:37, 11:29:37, etc, prior to this
APAR.
17. Humor. A discussion of comments in IBM programs reminded me of this
from an OS/360 ASM program before code that Branched to ABEND:
"Self-defenestration is preferable to omphaloskepsis."
16. APAR OA17615 reports WLM managed PAV devices may not have an alias
moved (when it should have been), if the device had EVER held a
RESERVE in the past; the PTF switches off the RESERVE bit when there
is no RESERVE indication in the UCB.
15. APAR OA17732 reports very high CPU in RMF address space after an
address space failed in memory termination, but due to damaged
data within the ASID, the memterm processing also failed, which
caused RMF to internally ABEND every scan of this ASID, which was
occurring every 10 seconds, resulting in an IPL being required.
14. APAR PK25614 reports SMF 116 records show wrong Buffer Pool and
Pageset Numbers (MQINQ,MQSET).
13. APAR OA17374 reports HiperBatch stats SMF64HIT,SMF64MIS,SMF64WIS
are all zeros when DLF is setup to read COFXIT00 with VSAM entries
that comply with HiperBatch eligibility rules.
12. APAR OA16949 reports RMF 74 subtype 5 and 8 records may not be
written after an IPL, when 2105, 2107, or 1750 device types are
being configured as 2105s.
11. APAR OA14652 reports loss of type 30 interval records for some tasks
only after APAR OA08702 was installed, and the SYNC SMF option was
in effect. NDM records were the first noted to be not written.
10. MIDAW, IBM's Modify Indirect Addressing Word facility, has no impact
on MXG Software. MIDAW is a new facility for indirect addressing for
FICON Express2 feature on z9-109s, and may reduce channel, director,
and control unit overhead.
9. Measuring SMSVSAM to recognize potential bottlenecks.
This note is an EDITed extract from IBM Item RTA000175395:
In addition to processor resources, memory, and access to I/O
devices SMSVSAM has its own resources that should be monitored to
recognize potential bottlenecks that may be developing. The primary
SMSVSAM resources are:
a. SMSVSAM data space which contains the RLS buffer pool.
b. SMSVSAM cache structures in the coupling facility.
c. SMSVSAM lock structure in the coupling facility.
d. SHCDS data sets.
a. SMSVSAM data space which contains the RLS buffer pool.
Historical:
SMF Type 42 Subtype 19 records are for VSAM RLS Local Buffer
Manager LRU Statistics Summary. This data includes information
information for each system and a sysplex-wide summary.
Fields of interest are:
SMF42JOO Total Buffer size goal (in megabytes) - Low value.
SMF42JOP Average Buffer size goal (in megabytes) - high value
SMF42JOQ Total Buffer size goal (in megabytes) - high value.
SMF42JNI Average number of Buffer Manager LRU where BMF was
over the goal, and normal algorithms were bypassed to
reclaim buffers.
SMF42JNL Total number of times that BMF was called in interval
(across sysplex).
SMF42JUA Average number of buffer manager LRU processed, where
BMF was over the goal accelerated the aging, but did
not go into panic mode (the sysplex).
Real Time:
RMF Mon III can be used to see the current status of the buffer
pool. From the RMF Sysplex Report Selection Menu, you could
select option 10, VSAM RLS activity by storage class, to see what
the current health status of the buffer pool. It will report: LRU
status of local buffers under control of BMF (Buffer Management
Facility).
Good BMF is at or below its goal on all systems.
Accelerated BMF is over the goal on at least one system, and
the buffer aging algorithms were accelerated.
Reclaimed BMF is over the goal on at least one system, and
the buffer aging algorithms were bypassed to
reclaim buffers.
In addition to the buffer information, lock contention is
displayed along with data rates and hit percentages for BMF, CF,
and DASD.
b. SMSVSAM Cache Structures in the Coupling Facility.
The initial and maximum size of the cache structures are defined
in a policy stored in the CFRM data set. There is historical data
and real time data available.
Historical:
The RMF Coupling Facility Usage Summary and Coupling Facility
Structure Activity Post Processor report has performance data
concerning the RLS cache structures. In the Coupling Facility
Usage Report, there is a column for directory reclaims and
directory reclaims for buffer invalidations (XI). What want to
avoid are directory reclaims and directory reclaims for buffer
invalidation. There should be no directory reclaims for buffer
invalidation and preferably no directory reclaims at all. Seeing
reclaims is an indication that the cache structure is not large
enough. To find whether or not there are any false buffer
invalidations, SMF record type 42 subtype 16 field SMF42GCK can
be used. There should be no false invalidations.
In the Coupling Facility Structure Activity report, there is data
concerning the number of synchronous requests, asynchronous
requests, and how many synchronous requests were converted to
asynchronous for each structure. One should also look at the
number of synchronous requests that have been converted to
asynchronous. Conversion could be done because the host is
sending so many requests to the CF and the CF doesn't have the
capacity to handle them or more or faster links are required.
This report also has data concerning delays and the cause of
these delays. There are also SMF Type 42 Subtype 18 records that
contain data for CF cache usage.
Real Time:
To obtain data concerning the number of synchronous,
asynchronous, and the number of synchronous requests changed to
asynchronous can be found in the RMF Mon III Coupling Facility
activity which is option 7 from the RMF Sysplex Report Selection
Menu. To obtain information concerning reclaims for a particular
structure, simply position your cursor on the cache structure
name and hit enter.
c. SMSVSAM Lock Structure in the Coupling Facility.
The initial and maximum size of the IGWLOCK00 lock structure is
defined in a policy stored in the CFRM data set. There is
historical data and real time data available.
HISTORICAL:
SMF Type 42 Subtype 17 records contain data on RLS lock structure
activity. It is recommend to keep all contention for locks below
1% and false contention below 0.5 %.
Real Time:
The D SMS,CFLS command will display the contention rates.
d. SHCDS data sets.
Data concerning the utilization of these resources is provided by
system commands, SMF records (type42 subtypes 15, 16, 17, 18, and
19), and RMF records.
8. APAR OA17065 reports ABEND of the SMF Address Space and RLS takes an
OC4 with >255 Extent Relief. SMSVSAM calculated the size of SMF 64
records based on the number of extents, but didn't protect for the
many more extents with GT 255 Extent Relief, causing it to create an
SMF record that was too large, which overlaid bits that SMF needed
to process the record. This led to SMF abending and in turn RLS
took an 0C4 during the close of the dataset opened to RLS.
7. The TYPE74 DLYCMRTM='INITIAL*COMMAND*RESPONSE*CMR TIME'
is a subset of PEND time.
- PEND starts when the SSCH puts the ORB in an HSA subchannel
- CMR starts when the ORB is selected for processing by a
channel. CMR time will always be less than or equal to
PEND time.
- PEND and CMR end when a CMR is presented to the channel
for the first CCW.
- Essentially, the difference between CMR and PEND is
subchannel queueing. While subchannel queueing is
common under ESCON, it only occurs in FICON when all of
the channels that serve a device have reached their OE
limit, i.e., 32 or 64
- You should use (CMR+DISC+CONN)*SSCH_RATE to get a device's
contribution to channel MPL.
- CMR should never be added to get service time
(i.e., PEND+DISC+CONN) since it is a subset of PEND.
Thanks to Dr. H. Pat Artis.
6. A "memory leak" (known as a PROGRAMMING ERROR to real programmers)
in WebSphere when SMF 120s are created and a send error occurs.
APAR PK24786 associated with SERVICE LEVEL W510234 of WebSphere
Application Server V5.1.0 for z/OS corrects the ERROR.
5. DFSORT SMF type 16 records with exactly 24 hours of CPU Time are
reported in APAR QP72589, which was closed "Fixed In Next", but the
APAR was not available in time for DF Sort Release 1.5. The APAR
text cites dynamic allocation and STIMER as being involved in the
incorrect value in ICECPUT field.
4. APAR II13674 documents data in the RMF MONITOR III CPC REPORT,
showing which fields are populated pre and post z/OS 1.6.
3. APAR OA15360 corrects SMF89IST, which was equal to SMF80IET in the
type 89 subtype 2 record.
2. APAR OA15281 reports the value in SMF71ACA (MXG Variable HIUICAV in
TYPE71 dataset) is smaller than the minimum SMF71LIC/HIUICMN, due
to incorrect accumulation, and affects z/OS 1.2 thru 1.7. 20Apr06.
1. APAR OA15712 reports invalid CPU time in SMF30CPT/CPUTCBTM in SMF
type 30 records due to invalid Enclave CPU time; CPUTCBTM was more
than the 15 minute SMF interval duration, and occurs when an
enclave transaction is restarted, because in that case, the field
ENCB_TIME_ON_CP is never reset to zero. Apr 20, 2006.
IV. DB2 Technical Notes.
6. Two MXG sites with DB2 V8 and zIIP engines have opened a problem
with IBM DB2 Support: field QWACZIS1, the new zIIP CPU Time in the
SMF 101 (DB2ACCT) record, contains a negative value ('FFFFFFnn'x),
which becomes an extremely large value in MXG, as the INPUT is with
PIB (Positive Binary), since only positive values make any sense.
These negative values are the result of incorrect subtraction in
IBM DB2 code, so there will ultimately be an APAR and PTF, and this
note will be updated when that exists. Oct 13, 2006.
5. APAR PK30886 reports SMF 102 IFCID 145 Audit Trace record was not
written for LOCK TABLE statement nor for REFRESH TABLE statement.
4. APAR PK19368 corrects DB2 creation of additional unexpected SMF 102
IFCID 254 records; they were created for each IFCID 230 record.
3. APAR PK18669 discusses why the DB2TCBTM CPU Time in DB2ACCT can
be larger than the TASCPUTM in CICSTRAN, due to under-reporting of
up to 16 microseconds per transaction with the current CICS clock
resolution. The APAR is CLOSED as a FUTURE requirement to use all
8 bytes of STCK versus the current use of only the middle 4 bytes.
The FUTURE is announced in CICS/TS 3.2, with expanded time fields.
2. APAR PK12365 corrected errors with QWHCBSC having missing values
in DB2ACCT records with QWACRINV=3. 18May2006.
1. APAR PK19191 corrects the values in DB2ACCT and DB2STATS variables
QLSTROWS and QLACROWS, which were not properly incremented when
using block fetching for a cursor. The weekly counts dropped from
300 million to 1 million when DB2 V8.1 was installed but this APAR
was not. 4May2006.
V. IMS Technical Notes.
1. APAR OA18996 reports problems with SMF 42 subtype 6 (TYPE42DS) due
to DSSB overlay in IMS in some instances.
VI. SAS Technical Notes.
11. New in SAS Version 9, the PUTLOG statement can be useful debugging
programs which have multiple FILE statements; PUTLOG directs DATA
step output to the SASLOG file, regardless of the current "FILE" in
effect.
10. The V9SEQ sequential engine does NOT honor the GLOBAL option to
COMPRESS=YES, when the output device is a tape drive on z/OS,
because all tape devices have hardware compression, and to also use
SAS Software compression only wastes CPU time for no value. But a
tape dataset can be compressed by using the dataset option instead:
DATA MYSTUFF(COMPRESS=YES); if you ever really need to compress
with SAS software even when writing to a tape device (but I cannot
fathom why you would want to!).
One reason: If you use EMC COPYCROSS to write to tape, you can
disable it's compression, and since SAS V9.1.3+ does NOT compress
when a dataset is written to tape device AND the Global option
COMPRESS=YES is in effect (the MXG default), you may choose to
enable compression for each dataset written to tape, by using the
Dataset Option COMPRESS=YES for each dataset, which can be enabled
by adding a statement
MACRO _Kdddddd COMPRESS=YES %
in your IMACKEEP tailoring member for each dataset to be written
to tape. The mapping of the "dddddd" value for each MXG dataset
can be found in the IMACxxxx member for that product.
9. SAS Note SN-015924 reports that variables with DATETIME formats can
print truncated values (like '02AUG2005:00:00:00.00' instead of the
correct value '02AUG2005:00:23:14.99'). The problem is most severe
when literals are used to create datetime values with more decimal
places than the places in the format (.999 input, .2 place format),
but I have replicated it with artificially created datetime values,
if the decimal value happens to be certain fractional values.
While no MXG site has reported the truncation, it would be wise to
install Service Pack 4, a prerequisite, and this correction.
Changing the DATETIME format in your report to show no decimals, or
to show more decimal places will print the correct date and time.
8. The undocumented xmrlmem options will display the amount of virtual
storage that SAS can use: DATA; X=GETOPTION("xmrlmem"); PUT X=;
7. Using %UTILBLDP as a single create-and-execute under SAS V9.1.2 got
ERROR: Text expression length (-nnn) exceeds maximum length (65534).
This error is discussed in SAS SN-V8+ -01437 which reports it is not
fixed until SAS V9.2; however, it does not fail under SAS V 9.1.3 at
another site, and running %UTILBLDP as a two-step process to create
the SAS code and then separately execute the created code works at
the 9.1.2 site.
6. PROC SYNCSORT (not the SYNCSORT Sort Product, but the SAS add-on)
ERROR:INVALID SEQUENCE OF COMMANDS FOR FILE PDB.xxxxxxxx.DATA
ERROR:WER755A XVPUTE ERROR ENCOUNTERED.FUNCTION CODE=0,RC=8001F8OB
resulted when PROC SYNCSORT was trying to write to a SAS library
that had been created by SAS V6, and the new dataset being written
has a variable longer than 200 bytes.
Disabling PROC SYNCSORT exposed the real SAS error message:
ERROR: THE CHARACTER VARIABLE SYSLTEXT HAS TOO LONG A VALUE FOR THE
PDB LIBRARY.
which has NOTHING to do with SYNCSORT; it says your PDB DSNAME was
created by SAS V6, and the new MXG Version you are testing creates
new long-length character variables that cannot be written to a V6
data library. MXG has required SAS V8 or V9 for these new data for
several years; its only because you've been using a back-level of
MXG that your daily job did not fail earlier!
If the output DDNAME is DISP=NEW, then the problem is that you must
have an out-of-date JCL that points to an old version CONFIGV9, or
you have an old version VMXGINIT (which should never be tailored!).
Instead, you must have a CONFIGV9 for z/OS with SEQENGINE=V9SEQ and
if you MUST tailor VMXGINIT, it must have TAPENGN=V9SEQ.
If, instead, your failing program is overwriting, i.e., reusing an
existing SAS data library, that data library (and any similar "PDB"
data libraries), must be converted from the non-supported-V6 format
to a SAS V9 format data library, by executing PROC COPY under V9
with DISP=NEW for the new data library, renaming the ORIGPDB to
V6OLD, and then renaming the NEWPDB back to the original ORIGPDB
DSNAME:
// EXEC MXGSASV9
//OLDPDB DD DSN=ORIGPDB,DISP=SHR
//NEWPDB DD DSN=NEWPDB,DISP=(,CATLG),SPACE=(CYL,(500,500))
//SYSIN DD *
PROC COPY IN=OLDPDB OUT=NEWPDB MT=DATA;
Then RENAME ORIGPDB to V6PDB
Then RENAME NEWPDB to ORIGPDB
You also need to examine your "day of week" (MON/TUE/WED/DAY/WEEK)
DSNAMES to see if they are also in the old V6 format, by looking
at the SAS Engine in the proc contents output:
PROC CONTENTS DATA=OLDPDB._ALL_ NODS DETAILS;TITLE OLDPDB;
PROC CONTENTS DATA=MON._ALL_ NODS DETAILS;TITLE MON PDB;
If they were created by V7, V8, or V9, they support long lengths.
5. Error message "Restricted options module not in linklist library"
occurs when the SAS installation option OPRESTRICTIONS=XXXXXXXX was
set in the site's config file, but when SAS did its BLDL for that
restricted options module XXXXXXXX, it was not found in a LinkList
library, and for security, SAS does not allow user overrides for a
restricted options module. The default restricted options module
name in V9 is SASOP910, and it is created by the SAS installer
running the BAOPTS2 job in the SAS installation CNTL data set. You
can read PROC OPTIONS DEFINE; output to see which options can be
restricted.
4. A comparison of I/O rates to read/write a SAS tape/disk dataset on
z/OS, using a 180 MegaByte DB2ACCT dataset:
Disk Tape Elapsed Total
EXCP EXCP seconds Description of test MB/Sec
466 0 6.2 Read from disk, no write 29
0 5747 17.5 Read from tape, no write 10
466 5747 25.3 Read from disk, write to tape. 14
Calculated: 19.1 Write to tape, delta case 1-3. 9
The estimated Write-to-Tape time of 19.1 seconds was surprisingly
close to the observed Read-from-Tape time of 17.5 seconds. Long
ago, I observed write costs that were four times the read cost.
Each Tape EXCP count was a block count of 32760 byte blocks.
Each Disk EXCP count was an SSCH/SIO count of 404,016 bytes. The
Disk dataset's pagesize was 55296, so SAS read 7 pagesizes,
or 7 tracks, or 14 half-track-DASD-blocks per EXCP counted.
3. The V9SEQ sequential engine does NOT honor the GLOBAL option to
COMPRESS=YES, when the output device is a tape drive on z/OS,
because all tape devices have hardware compression, and to also
use SAS Software compression only wastes CPU time for no value.
But a tape dataset can be compressed by using the dataset option
instead: DATA MYSTUFF(COMPRESS=YES); if you ever really need to
compress with SAS software even when writing to a tape device.
2. SAS Note SN-013725 reports ABEND 0C4 while attempting to read an
empty file with INFILE statement options such as LRECL=, BLKSIZE=,
and RECFM=, and this ERROR message may be printed:
ERROR: System abend 0C4 occur4red outside of the SAS environment.
or
ERROR: SYSTEM abend 0C4 occurred in module SASXAL function
VXBSM at offset 00582C.
The note then says "To circumvent the problem, remove any
external I/O options specified in the INFILE statement."
However, in my tests, it was only the CCHHR= operand that caused the
error, the only MXG code that still requires CCHHR INFILE option is
TYPEEREP. But more important, SAS Service Pack 2 for 9.1.3 has
fixed the problem. April 20, 2006.
1. In SAS 9.1 and above, new options DMSOUTSIZE and DMSLOGSIZE allow
you to increase the number of lines send to your SAS Output and
SAS Log window, to avoid the "Output window full" condition.
They must be specified in your SASV9.cfg file.
VII. CICS Technical Notes.
1. Threadsafe transactions can save significant CPU time, as was noted
in Newsletter FORTY-ONE's article on Open Transaction Environment,
OTE. CICSTRAN variable DSCHMDCN's count and DSCHMDTM's duration
(in CICS/TS 3.1, replacing the earlier count in CHMODECT) provides
the count/duration of task switches between the QR and L8 TCBs, and
can be used to identify which transactions are most likely to
benefit from being made to be threadsafe.
VIII. Windows NT Technical Notes.
IX. z/VM Technical Notes.
X. Incompatibilities and Installation of MXG vv.yy.
1. Incompatibilities introduced in MXG vv.yy (since MXG 23.23):
See CHANGES.
2. Installation and re-installation procedures are described in detail
in member INSTALL (which also lists common Error/Warning messages a
new user might encounter), and sample JCL is in member JCLINSTL.
XI. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
XII. Changes Log
--------------------------Changes Log---------------------------------
You MUST read each Change description to determine if a Change will
impact your site. All changes have been made in this MXG Library.
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
The CHANGES selection on our homepage at http://www.MXG.com
is always the most current information on MXG Software status,
and is frequently updated.
Important changes are also posted to the MXG-L ListServer, which is
also described by a selection on the homepage. Please subscribe.
The actual code implementation of some changes in MXG SOURCLIB may be
different than described in the change text (which might have printed
only the critical part of the correction that need be made by users).
Scan each source member named in any impacting change for any comments
at the beginning of the member for additional documentation, since the
documentation of new datasets, variables, validation status, and notes,
are often found in comments in the source members.
Alphabetical list of important changes after MXG 24.01 now in MXG 24.02:
Dataset/
Member Change Description
See Member CHANGES or CHANGESS in your MXG Source Library, or
on the homepage www.mxg.com.
Inverse chronological list of all Changes:
Changes 24.yyy thru 24.001 are contained in member CHANGES.