COPYRIGHT (C) 1984-2021 MERRILL CONSULTANTS DALLAS TEXAS USA
MXG NEWSLETTER FIFTY-NINE
***********************NEWSLETTER FIFTY-NINE****************************
MXG NEWSLETTER NUMBER FIFTY-NINE, Jan 17, 2012
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,2011 MERRILL CONSULTANTS DALLAS TEXAS USA
I. The 2012 Annual Version MXG 29.29 is dated Jan 23, 2012.
You can always use this form
http://www.mxg.com/Software_Download_Request
to request the ftp download instructions for the current version.
1. The current version is MXG 29.29, dated Jan 23, 2012.
See CHANGES member of MXG Source, or http://www.mxg.com/changes.
II. MXG Technical Notes
1. TYPE 30 CPU times in MXG variables come directly from IBM fields:
MXG Variable NAME IBM SMF Manual Field NAME
CPISRBTM SMF30ISB
CPITCBTM SMF30ISB
CPUHPTTM SMF30HPT
CPUIIPTM SMF30IIP
CPURCTTM SMF30RCT
CPUSRBTM SMF30CPS
CPUTCBTM SMF30CPT
CPUTM is the SUM of the above seven CP Engine times.
CPUZIPTM SMF30_TIME_ON_ZIIP
CPUZIPTM (zIIP/zAAP Engine CPU time) is NEVER combined with
the CP ENGINE CPU times variables (original CPU variables.)
CPUZIETM SMF30_ELIGIBLE_TIME_ZIIP_ON_CP
CPUZIETM is already included in the CPUTM because it is the
CPU time CONSUMED on the CP engines.
III. MVS, a/k/a z/OS, Technical Notes.
4. APAR PM54994 for SMF 119 record has been opened; the NIIITIME field
contains invalid '0000000F000000000'x and '000000001C000000'X values
in subtype 19 and 21 records.
3. IBM's TRSMAIN program became AMATERSE in z/OS 1.9: "In z/OS Release
1.9 the TRSMAIN program has been added to the BCP element of z/OS,
and it has been redesigned to support large format sequential data
sets. This program has also been rewritten to follow IBM programming
conventions. The new utility is called AMATERSE. TRSMAIN is
shipped as an alias entry point to AMATERSE. When the TRSMAIN entry
point of AMATERSE is invoked, ddnames INFILE and OUTFILE remain as
the defaults, so little or no change to JCL should be required to
take advantage of AMATERSE. The ddnames INFILE and OUTFILE that were
required by the TRSMAIN utility are replaced by SYSUT1 and SYSUT2
respectively when the utility is called as AMATERSE."
All MXG unterse examples use PGM=TRSMAIN and INFILE/OUTFILE DDs, and
since using PGM=TRSMAIN does execute the new rewritten program, the
examples were not changed to use PGM=AMATERSE (I assume you'll find
this technical note if you search for AMATERSE instead of TRSMAIN).
2. APAR OA37002 reports MKCRTIME and MKLCTIME in SMF 42 subtype 22
are on GMT zone when the event creating the record is an ADDVRS
event, but are on local time zone when the event is an DELETEVRS.
No PTF forthcoming, resolution is FIN ("Fixed in Next").
1. APAR PM47067 corrects WebSphere Version 8 SMF 120 Subtype 1 error
that had zero bytes in the SM120SDR, SM120CDR and SM1290EGR fields.
IV. DB2 Technical Notes.
1.
V. IMS Technical Notes.
2. How do you enable creation of the IMS56FA Transaction Record?
IMS logs statistical information about the transactions within a
unit of recovery (work done by an application program between sync
points) in log record X'56FA' for non-message-driven applications,
or when either:
-The keyword MODE=SNGL is specified in the TRANSACT macro
-The CMTMODE(SNGL) parameter is specified on a CREATE TRAN or
UPDATE TRAN command
IMS logs statistical information about the transactions after each
message in log record X'56FA' for message-driven applications when
either:
-The keyword MODE=MULT is specified in the TRANSACT macro
-The CMTMODE(MULT) parameter is specified on a CREATE TRAN or
UPDATE TRAN command
You can enable or disable this logging on a program basis for
non-message driven applications, and on a
transaction-by-transaction basis for message-driven applications.
Use the following commands to enable or disable this logging on a
transaction-by-transaction basis:
-For an existing transaction, issue the UPDATE TRAN or UPDATE
TRANDESC command and specify the new TRANSTAT() parameter.
-For a new transaction, issue the CREATE TRAN or CREATE TRANDESC
command and specify the new TRANSTAT() parameter.
To enable or disable this logging on a program basis:
-For an existing application program, issue the UPDATE PGM or
UPDATE PGMDESC command and specify the new TRANSTAT() parameter.
-For a new application program, issue the CREATE PGM or CREATE
PGMDESC command and specify the new TRANSTAT() parameter.
You can enable or disable this logging globally during system
definition by specifying a new parameter, TRANSTAT= Y or N, in the
Diagnostics Statistics section of the new DFSDFxxx PROCLIB member.
This setting applies to any transactions and application programs
that are created with the system definition process.
Any transactions or application programs that are created after an
IMS cold start using the online change process or the Destination
Creation exit routine (DFSINSX0, formerly called the Output
Creation exit routine) inherit the TRANSTAT= parameter setting that
is specified in the DIAGNOSTICS_STATISTICS section of the DFSDFxxx
PROCLIB member.
To determine whether or not this logging is enabled for a given
transaction or application program, issue one of the following
type-2 commands:
QUERY TRAN
QUERY TRANDESC
QUERY PGM
QUERY PGMDESC
1. IBM IMS log record IMS56FA comparison with BMC's IMF CIMSTRAN.
THIS ANALYSIS MAY BE WRONG BECAUSE IBM NOW SAYS APAR PM33425 CORRECTED
THE IMS56FA CPU TIMES. THIS NOTE WILL BE UPDATED WHEN NEW IMS LOG
DATA IS ANALYZED AFTER THE APAR HAS BEEN INSTALLED. APAR APPLIES TO
BOTH IMS VERSION 10 AND 11.
A. CPU TIME and Transaction Count Comparisons:
BMC IMF created 13,852 transaction records and
IMF created 6 BMP records.
IBM IMS56FA had 13,831 records that had MSG GU (NMSGPROC GT 0)
and IMS56FA had 22,252 BMP records.
The IMS56FA TRAN CPU time was 329.52 in those 13,831 "TRAN"s
and IMS56FA BMP CPU time was 15.61 in those 22,252 "BMP"s
and IMS56FA "MXG" CPU time was 12.00 captured in ACCUM/RESET,
Total IMS56FA CPU TIME time was 357.15 seconds
Total CIMSTRAN IMF TRAN time was 323.53 in those 13852 "TRAN"s
and CIMSTRAN IMF BMP time was 0.02 in those 6 "BMP"s
Total CIMSTRAN CPU TIME time was 323.55.
Here is the source of the IMS56FA "MXG" IMS CPU Time:
If there are Message GET Unique's in a record, NMSGPROC=1 is set as
this is a "real" transaction record and NMSGPROC should be used to
to count transactions. NMSGPROC=0 if there were no MSG GU and this
is a "NOT-TRAN" record. Of the 49,778 records, 13,831 were "TRAN".
Then, 22,256 were BMPs (a "NOT-TRAN", because NMSGPROC=0, TRANSACT
name is blank, and ARRVTIME is not populated; there were the above
15.61 CPU Seconds in the BMP records. The remaining 13,691 56FA
records totaled 297.11 more CPU seconds, but if added to the other
56FA CPU times the 56FA would have captured TWICE the IMF CPU time,
and the IFA CPU Time has always matched the IMS 07 Program CPU Time
so something else is involved.
When all of the 56FA records are sequenced by TPOASN and ARRVTIME,
there were pairs of records for almost every transaction, sometimes
there were more than two records written. The last always has
NMSGPROC=0, a "NOT-TRAN" record, while the first thru penultimate
have NMSGPROC=1 and are "TRAN" records. According to IBM Support
for IMS, these "NOT-TRAN" (second) records:
Can represents the processing done by the application after it
received the STATUSQC call for the GU to the IOPCB, indicating
that there are no further messages and it should terminate.
Though no messages were processed, IMS still reports the
processing done so that you can capture any cleanup processing
done by the application. These "NOT-TRAN" records have values of
TPMGU=0, TPLTERM=blanks, TPINUTC=0, TPINDATE=X'0000000F', and
TPINTIME=X'0000000F', meaning that no input message was processed
during this commit scope, most likely due to QC status on the
last message GU that was issued. In this case, the TPCPTERM bit
would be on in flag byte TPCPFLGS. This would be a 56FA record
written during application termination after the application
terminated upon receiving QC status from its last message GU call
issued. However, this type of 56FA log record should not be
ignored because it still represents processing time performed by
the application. The application could have continued to do some
work after receiving QC status but before terminating and
returning to IMS.
So pairs of IMS56FA records were matched up with their IMF record.
The IMS56FA "TRAN" (first) IMSCPUTM is ALWAYS slightly larger than
the CPUTM in the IMF transaction (typically about 1 millisecond, so
IBM's exit point for their transaction record is later than the IMS
exit that IMF uses!)
By looking at the sequenced transactions records, the "NOT-TRAN"
(second) records come with two different contents:
-Many have IMSCPUTM that is slightly LARGER than the "TRAN" record:
this flags that this record's CPU Time is ACCUMULATED, and so its
CPU Time cannot be used "AS-IS", as it contains (DUPLICATES!) the
CPU time in the preceding "TRAN" record.
-Many have an IMSCPUTM that is much LESS than the time in the first
record: this flags that this record's CPU Time was RESET, so the
CPU Time in these "NOT-TRAN" records are valid.
Here are the three sequenced CPUTM values in three records for five
transactions; 1,4 are RESETs and 2,3,5 are ACCUMULATED:
Transact: 1 2 3 4 5
IMF 0.133260 0.005130 0.011920 0.007720 0.030480
56FA TRAN 0.134220 0.005575 0.013168 0.008525 0.031700
Second 0.004140 0.006284 0.013675 0.000817 0.033420
So, the new ASUM56FA program sorts IMS56FA data, and assumes that
if the NOT-TRAN record's IMSCPUTM was LESS than the TRAN record,
then the CPU clock had been RESET so that value of IMSCPUTM is
valid and OUTPUT, but if the NOT-TRAN record's IMSCPUTM was MORE
than the TRAN record, then that record was ACCUMULATED and so the
delta CPU time from the TRAN (first) record's (stored) IMSCPUTM to
this NOT-TRAN (second) record's IMSCPUTM is calculated and OUTPUT.
The sort order is STIMSID IMSUSID TPOASN ARRVTIME ENDTIME with
each "pair" having the same TPOASN and ARRVTIME values.
The resultant IMSCPUTM CPU time totals in ASUM56FA dataset are:
==NOT-TRAN== ====TRAN==== ====Total====
Records CPU Records CPU Records CPU
T56FATYP:
BMP 22252 15.61 0 22252 15.61
ACCUM 8435 8.73 11 .03 8446 8.77
RESET 5255 3.26 14 .02 5269 3.29
FIRST 0 13690 325.29 13690 325.29
SINGLE 4 .01 116 4.18 121 4.19
CPU Totals 27.61 329.52 357.15
By sorting and sequencing to identify RESET from ACCUMULATED, an
additional 12 seconds of IMS CPU Time was captured; member ASUM56FA
can be included after TYPEIMST to capture this additional CPU time,
but that could be a lot of CPU and I/O time to post process IMS56FA
to capture a few extra seconds.
So, if you can live without that small amount of CPU time from the
RESETs and ACCUMs, you can minimize the MXG resource requirements
for TYPEIMST, using this new EXAMPLE in member TYPEIMST's comments
that will create ONLY the IMS56FA dataset, and only keeps the 56FA
records with NMSGPROG GE 1 OR BMP='Y'.
// EXEC MXGSASV9
//IMSLOG DD DSN=YOUR.IMSLOG.DATA,DISP=SHR
//IMS56FA DD DSN=YOUR.IMS.IMS56FA.PDB,DISP=(,CATLG)....
//SYSIN DD *
%LET MACKEEP=
%QUOTE(
MACRO _IMSVERS 10.1 %
_NIMS
_NIMS_56
MACRO _WIMS56G &WIMS56G..IMS56FA %
MACRO _EIMS56G
IF NMSGPROC GE 1 OR BMP='Y' THEN OUTPUT _WIMS56G;
%
);
%LET WIMS56G=IMS56FA;
%LET MACIMSH=
%QUOTE( IF LCODE=56X AND TPCPSSTY='FA'X; ) ;
%INCLUDE SOURCLIB(TYPEIMST);
B. CALL differences and equalities:
There are exact matches of total call counts between IMF and 56FA
for some Database counters: DELETE, INSERT, REPLACE, PURGE, and for
these Message counters GET NEXT, GET UNIQUE, and INSERT. There are
more buckets for many more call types in 56FA than in IMF, but the
totals show the counts of calls match quite closely:
56FA GET GET GETHOLD 56FA IMF
CALL HOLD PARENT PARENT TOTAL TOTAL
DB GN 125,015 767 225,793 10,417 361,292 363,008
DB GU 234,519 37,101 271,620 273,809
total: 632,912 636,817
C. I/O Reads and Writes:
IMF provides separate counts for Reads/Writes and KEY/NO-KEP while
the 56FA provides total Reads and total Writes, that match:
IMF I/O Counts
Reads Reads Reads Writes Writes Writes
KEY NO-KEY Total KEY NO-KEY Total TOTAL
14,203 43,466 57,669 1,163 19,952 21,015 78,684
IMS 56FA Counts VSAM Reads VSAM Writes
57,629 21,090 78,719
D. Miscellaneous
IMF provides CHARACTER counts transmitted and Virtual Storage used
metrics that are not provided in IMS56FA.
IMF provides 11 components of CPUTM, 56FA has only the one total.
This Log had 260,000 records, 60MB of only FAx and 56x records.
IMF FAx took 15MB, IBM 56FA took 25MB, and there were 20MB of the
other unneeded 56x subtypes (5600: 10MB, 5607: 5MB, 5612: 5MB),
so you should select only LCODE='56FA'x records when you create
the log file that MXG will read, if you only want IMS56FA data.
VI. SAS Technical Notes.
3. To convert a SAS dataset to EXCEL, use the FILE pulldown and then
select EXPORT, which usually works, but not when there are too many
variables for EXCEL to handle. This alternative has worked so far:
ODS HTML BODY='d:\db2acct.html';
PROC PRINT SPLIT='*' DATA=PDB.DB2ACCT;
RUN;
ODS HTML CLOSE;
When the HTML window opens up, right click on the window and one of
the options given is 'EXPORT TO EXCEL'; click on that and you have
an EXCEL spreadsheet.
2. SAS Problem Note 43996: An error occurs when you run Merrill
Consultants' MXG software with SASŪ 9.2 reports error messages
No MKLEs found
ERROR: VM 1319: The PCE address=1C351414 and MEMORY= address=
might occur if a job contain macros that perform only text
substitution (that is, with no conditional logic), such as jobs
that use MXG software, with z/OS SAS.
The circumvention is to NOT use the debugging-only MPRINT option.
1. A confusing quirk of the maximum integer value that can be stored
in SAS variables with stored lengths less than 8 bytes was seen and
resolved as a "feature" when the value is an exact power of two.
The table of maximum integer versus stored length is in Newsletter
TWENTY-EIGHT - Find "3. How can I have 10 digits...." and read that
note if you are not familiar with how SAS stores numeric variables.
I discovered that the value of 34,359,738,368 was not truncated in
ANY length variable, even a variable with length 2 on z/OS or with
length 3 on PC/unix. The reason is that the value is exactly 32GB,
and for values that are 2**X, the SAS floating point representation
PC/unix: 3 bytes, 11-bit exponent, 22-bit mantissa, 1 sign bit
z/OS: 2 bytes, 7-bit exponent, 8-bit mantissa, 1 sign bit
is sufficient for full representation. But, storing a value that
is one less than 32GB, 34,359,738,367, the result is truncated:
length value lost in truncation
8 34,359,738,367 0
7 34,359,738,367 0
6 34,359,738,367 0
5 34,359,738,304 63
4 34,359,721,984 16,383
3 34,359,544,064 194,303
length value lost in truncation
8 34,359,738,367 0
7 34,359,738,367 0
6 34,359,738,367 0
5 34,359,738,352 15
4 34,359,734,272 3,095
3 34,358,689,792 1,048,575
2 34,091,302,912 268,435,455
So, the table of maximum integer value is a "guaranteed" safe table
but there are exceptions noted above.
VI.A. WPS Technical Notes.
1. Text
VII. CICS Technical Notes.
1. APAR PM43494 for CICS Transaction Gateway corrects an error that
wrote multiple statistics records to both the log and the SMF file,
when a normal shutdown of CICS TG was started while there was still
work running in progress. Now, only one record will be written.
VIII. Windows NT Technical Notes.
1. Text
IX. z/VM Technical Notes.
1.
X. Email notes.
1. Text
XI. Incompatibilities and Installation of MXG vv.yy.
1. Incompatibilities introduced in MXG 29.29 (since MXG 28.28):
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 29.yyy thru 29.001 are contained in member CHANGES.