COPYRIGHT (C) 1984-2007 MERRILL CONSULTANTS DALLAS TEXAS USA
Newsletter FORTY Nine
Last Updated: Feb 5, 2007.
*********************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.
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.
The zIIP CPU times in the RMF Type 72 Service Class/Reporting Class
are compared with zIIP CPU times in the SMF Type 30 Interval Record.
Big Picture:
Total zIIP times match very well, between SMF and RMF, and between
Service Class and Reporting Classes. Total of 8609 seconds in 30s
is slightly larger in SMF than the 8508 seconds in RMF. Service
Class totals match the Reporting Class totals exactly.
C72ZIPTM C72ZIETM C30ZIPTM C30ZIETM
Reporting Classes 8508.93 725.89 8609.19 742.41
Service Classes 8508.93 725.89 8609.19 742.41
However:
The total "Independent Enclave zIIP Qualified" time ("EZQ") is much
greater than the sum of its two components, the "Independent Enclave
Time on zIIP" ("EZI"), plus the "Independent Enclave Time zIIP on
CP" ("EZE"), and the difference happens to be VERY close to the
SMF30CPT (CPU TCB) time, numerically suggesting that the error in
EZQ is that it may include the CPU TCB time when it should not.
Example record had EZQ=491, EZI=267, EZE=2, so that EZQDIFF=221, and
for comparison, CPUTCBTM/SMF30CPU=223. A problem is open at IBM.
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---------|
|--CPUDZITM--|--CPUEZITM--| |--CPUDZETM--|--CPUEZETM--|
(DEP) (IND) (DEP) (IND)
"Qualified - Dependent Enclave"
(Sum of DEP Actual and Eligible)
|-------CPUDZQTM----------|
|--CPUDZITM--|--CPUDZETM--|
"Qualified - Independent Enclave"
(Sum of IND Actual and Eligible)
|-------CPUEZQTM----------|
|--CPUEZITM--|--CPUEZETM--|
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
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. 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 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.
NOTE BENE: OA19257 caused NEGATIVE SERVICE UNITS, and APAR OA19282
is the correction for the original APAR. This APAR also corrects a
case in which RMF 72 reports zAAP activity when no zAAP exists, and
corrects incorrect response time distribution for workloads that
have a response time that is greater than about 1 hour.
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.
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 fiels 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*CMF 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 reaved 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 allcation 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 correctd 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!).
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 was
necessary to get the real error message:
ERROR: THE CHARACTER VARIABLE SYSLTEXT HAS TOO LONG A VALUE FOR THE
PDB LIBRARY.
You must PROC COPY the old V6 library under SAS V9 to create a new
V9 format "PDB" library (also MON/TUE/WED/DAY/WEEK etc), and then
the longer length variables can be written to the data library.
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, and only the MXG code for EREP log processing still uses that
CCHHR= option. 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 avoide 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 24.01):
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.