COPYRIGHT (C) 1984-2021 MERRILL CONSULTANTS DALLAS TEXAS USA
MXG NEWSLETTER SIXTY-ONE
***********************NEWSLETTER SIXTY-ONE*****************************
MXG NEWSLETTER NUMBER SIXTY-ONE, JANUARY 21, 2013
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, aka z/OS, Technical Notes
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VI.A. WPS Technical Notes.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. z/VM Technical Notes.
X. Email notes.
XI. Incompatibilities and Installation of MXG.
See member CHANGES and member INSTALL.
XII. Online Documentation of MXG Software.
See member DOCUMENT.
XIII. Changes Log
Alphabetical list of important changes
Highlights of Changes - See Member CHANGES.
COPYRIGHT (C) 1984,2013 MERRILL CONSULTANTS DALLAS TEXAS USA
I. The 2012 Annual Version MXG 29.29 was dated Jan 23, 2012.
1. The current version is MXG 30.30, dated Jan 21, 2013.
You can always use this form
http://www.mxg.com/Software_Download_Request
to request the ftp download instructions for the current version.
See CHANGES member of MXG Source, or http://www.mxg.com/changes.
II. MXG Technical Notes
1. Compressed CICS or DB2 data should be decompressed on z/OS before
it is read on ASCII platforms with MXG.
On ASCII, MXG internal SAS code that decompresses CICS SMF 110s took
over TWO HOURS to read a 652 MB compressed CICS SMF file that needed
only TWO MINUTES for PGM=DFH$MOLS to decompress on z/OS, and then
only NINE MINUTES for MXG to process the 2354 MB CICS file on ASCII.
(MXG does print a NOTE when this internal code is executed.)
The below results STRONGLY RECOMMEND that compressed CICS ID=110
subtype 1 records should be decompressed with PGM=DFH$MOLS on z/OS
and that data read from the ASCII platform. Unfortunately, DFM$MOLS
will only write SMF 110 subtype 1 records; it does NOT pass other
SMF records into its output, so you will need to split the 110-1's,
run them thru DFH$MOLS, and concatenate with the other SMF data.
Also, you must use a new CICS version's DFH$MOLS program to read
a new CICS version's records; you cannot use the CICS 4.2 DFH$MOLS
to uncompress CICS 5.1 data (USER ABEND 106). See member DFH$MOLS.
The same algorithm is used for DB2 compressed SMF records, so I also
STRONGLY RECOMMMED that DB2 ID=101 compressed records should also be
first decompressed on z/OS by PGM=DSNTSMFD and then the decompressed
records are read by MXG on ASCII. DSNTSMFD does write all other SMF
records in its input to its output. See member DSNTSMFD.
Newsletter FIFTY-SEVEN compared processing CICS data on ASCII, but
didn't use the ftp access method, and its example was not dense CICS
compressed data. This new measurement's SMF file is 110-only, with
85900 records, 78620 of which are compressed subtype 1 records; the
SMF file is 652 MB, of which 562 MB are compressed subtype 1s, which
uncompress to 2354 MB.
a. Use DFH$MOLS first to uncompress the file and read UNCOMPRESSED.
c. Use MXG's internal SAS algorithm to read COMPRESSED NO EXIT.
Elapsed User CPU SYS CPU Size
a. DFH$MOLS on z/OS 00:02:00 00:00:05 652/2354MB
UNCOMPRESSED on ASCII 00:09:36 00:08:57 00:00:05 2354 MB
total 00:11:36
c. INTERNAL SAS on ASCII 02:19:24 02:13:04 00:00:29 2354 MB
The uncompressed file requires z/OS disk space, 2354 MB, but ONLY
for eleven minutes, and it is a temporary file.
And, for reasons I do NOT (yet) understand, DFH$MOLS program SORTs
the input SMF file. The DFH$MOLS log statistics show:
Records Read 85,900 ( 652MB)
Records Written 78,260 (2354MB)
Sortwork Tracks 10,419 ( 549MB)
III. MVS, a/k/a z/OS, Technical Notes.
5. APAR PM79239 for HTTP Server for z/OS 5.3 reports a remote
attacker could execute arbitrary commands on the system, with
a base CVSS Score of 10, which, I presume, is the reason the
APAR is a FLASH(ALERT), and why IBM reps are calling customers.
APAR OA41000 or OA41031 for z/OS, and APAR OA41059/60/61 for
Tivoli Netview are also a part of the Security Vulnerability.
4. APAR PM74888, PTF UK90705 12/21/2012, corrects wrong data is
in SMF 101 records for QWACZIIP_ELIGIBLE, only for DB2 utilities.
This is MXG variable QWACZIEL in DB2ACCT, T102S148 or T102S369.
APAR DESCRIPTION: Value QWACZIIP_ELIGIBLE in an IFCID accounting
record can be incorrect. When an agent executes a utility, a call
to record the stop of accounting time executing that utility will
not correctly obtain the zIIP time of the CPU. This incorrect value
will then be used in a calculation of QWACZIIP_ELIGIBLE for the
subsequent accounting record, resulting in incorrect values for
QWACZIIP_ELIGIBLE field. This error could appear in any of these
records: IFCID3, IFCID148 and IFCID369. One instance in one record
had over 14,576 HOURS in QWACZIEL without the PTF.
3. APAR OA39058 makes changes to the ID=99 SUBTYPE=14 records, to
consolidate the current two-records-per-interval into a single
record. See Change 30.259.
2. APAR OA40532 reports SMF 21 read/write counts in SMF21BR, SMF21BW,
SMF21BRN and SMF21BWN can be zero when data was transferred; the
APAR cites only device type 3592 Model E07 as having the error.
1. APAR OA40596 reports CPU time fields in TYPE 42 subtype 19 are not
correct, but did not identify if both SMF42JNE and SMF42JNF are
wrong, and the APAR reports that RMF III RLSLRU CPU times are taken
from the 42-19 and is also wrong. The APAR is OPEN, but it has a
circumvention(divide by 4096*10**6) but MXG has already divided by
4096*10**3 so it's unclear if dividing current by 1000 is correct.
Additionally, APAR OA40653 identifies these ID=42 variables are all
incorrect (all fields in the SMF2AJPY array): SMF2AJPZ SMF2AJQA
SMF2AJQB SMF2AJQ6 SMF2AJQC SMF2AJQD SMF2AJQF SMF2AJQ7
IV. DB2 Technical Notes.
1. Text
V. IMS Technical Notes.
1. Text
VI. SAS Technical Notes.
3. ITSV Sites using %CPSTART with an MXG Program HARDCODED with "PDB."
will fail when MXG writes to //PDB, which has DISP=SHR in ITSV.
The hardcoded value is the cause of the error, and the MXG program
corrected; ever since Change 15.320, the macro variable &PDBMXG has
been the correct syntax.
The ITSV "PDB" is a logical grouping of data libraries, with
different summarization levels.
In MXG, PDB is the default LIBNAME to which most programs write
their output SAS datasets.
But, to document how this interface between ITSV and MXG works, you
could use that MXG program with hardcoded PDB. after %CPSTART, by
invoking %VMXGINIT after %CPSTART to change the MXG default to WORK:
//SYSIN DD *
%CPSTART(MODE= . . . . );
%VMXGINIT(DEFAULT=WORK);
%INCLUDE SOURCLIB(ANALZIPC);
RUN;
Then, all of the datasets that would have been written to //PDB are
in the //WORK data library, and all reports were produced. If you
also want to KEEP those "//PDB" datasets created by the MXG program,
you can add this LIBNAME statement in your JCL
//REALPDB DD DSN=YOUR.REAL.OUTPUT.PDB,DISP=(NEW,CATLG),
// UNIT=SYSDA,SPACE=(CYL,(500,500))
and add this SAS statement after the %INCLUDE in the SYSIN program.
PROC COPY IN=WORK OUT=REALPDB MT=DATA;
Note that when %CPPROCES/%CMPROCES are used to create an MXG "PDB"
library, they replace the BUILDPDB functionality, with a %VMXGINIT
to change the default to WORK, and then execute a constructed DATA
step of _VARxxxx and _CDExxxx tokens for the MXG datasets you want,
which are then copied from WORK to DETAIL, where they are renamed
to their ITSV names. But %CxPROCES also defines VIEWs for datasets
in their DETAIL library that, when you use the PDB LIBNAME, return
the original MXG dataset and variable names, so you can %INCLUDE
MXG programs that expect their data in the PDB data library and they
work just fine "as-is" after you use %CxPROCES.
2. SAS Version 9.2 on z/OS ABEND 0C4 in SASVM occurred in DAILYDSN job
with MXG 30.04 but ran fine with MXG 29.05. Customer compared MXG
options with their CONFIG options and found MPRINT in their CONFIG
that was NOT in MXG's default, and removing the MPRINT from CONFIG
eliminated the error, even though OPTIONS MPRINT is very OFTEN used
by MXG support for diagnostics. SAS Technical Support confirmed the
actual error is Problem Note 39533 for 0C4 in SASVM, SASXAL, SASXA1
and that error is corrected in SAS V9.3, but the 9.2 circumvention
is to use OPTIONS NOCARDIMAGE. Yes, removing an option sometimes
did circumvent this error, but NOCARDIMAGE is the 9.2 culprit.
In SAS 9.4 the z/OS default will become NOCARDIMAGE, which is the
current default on ASCII platforms.
1. TRACEBACK ERROR with SAS 9.1.3 SP 4 on z/OS.
-TRACEBACK errors can be due to insufficient region size, although
some cases in 9.1.3 were actual compiler errors that were corrected.
A site testing MXG 30.04 with no REGION specified on the JOB card,
but with 250M specified on the STEP card, failed during the compile
of PROC SQL inside the _SDB2 macro (i.e., after the "big DATA step"
had successfully read the SMF data), with a "TRACEBACK ERROR" (and
NO other clue).
-My first guess, memory:
While the SAS 'initialized' message reported 250MB was available,
the IBM step terminate IEF032A message showed the SYS+EXT was ONLY
93MB+11MB, and the last SAS memory note reported the above-the-line
virtual storage was 93MB (but only 672K below!), so both suggested
that the job's region had been limited to about 100MB. In z/OS,
when there is no REGION parameter on the JOB card, it is the site's
IEFUSI exit that limits the allocated region size, and, sure enough,
this site had a 101MB limit specified in their IEFUSI exit. The
site changed IEFUSI to 250M and reran, but encountered the same
error at the same place, so this may NOT have been memory-related,
in spite of the preceding guess. Fortunately, the site was able
to (WISELY!) upgrade to SAS Version 9.3 to eliminate the error.
-The answer from SAS Technical Support:
With SAS Version 9.1.3 there were known (and now fixed) issues with
PROC SQL when OPTIONS THREADS was enabled, and changing to use the
OPTIONS NOTHREADS would have been their recommendation.
They think the memory numbers were an artifact and not the cause.
VI.A. WPS Technical Notes.
1. Text
VII. CICS Technical Notes.
1. Text
VIII. Windows NT Technical Notes.
1. Text
IX. z/VM Technical Notes.
1. Text
X. Email notes.
1. Text
XI. Incompatibilities and Installation of MXG vv.yy.
1. Incompatibilities introduced in MXG 30.30 (since MXG 29.29):
See CHANGES.
2. Installation and re-installation procedures are described in detail
in member INSTALL (separate sections for each platform, z/OS, WIN,
or *nix), with examples of common Errors/Warnings messages a new MXG
user might encounter, and in member JCLINSTT for SAS V9.2 or member
JCLINSTW for WPS. INSTALL also shows how to read SMF data on PCs/nix
using the FTP ACCESS METHOD.
XII. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
XIIV. 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 VV.RR in MXG VV.RR+1:
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 30.yyy thru 30.001 are contained in member CHANGES.