COPYRIGHT (C) 1984-2023 MERRILL CONSULTANTS DALLAS TEXAS USA
MXG CHANGES 07.07
=========================member=CHANGE07================================
/* Copyright (C) 1984, 1990 Merrill Consultants Dallas Texas USA */
/************************ CHANGES ******************************/
This is the production MXG Version 7.7, dated February 15, 1990.
The Production Version 7.7 of MXG was shipped during the last week of
February, 1990, to all supported MXG sites.
MXG Version 7.7 is dated February 15, 1990, thru Change 7.247).
(Newsletter SIXTEEN dated February 14, 1990, thru Change 7.243).
(PRERELEASE MXG 7.6 dated January 29, 1990, thru Change 7.228).
(PRERELEASE MXG 7.5 dated December 22, 1989, thru Change 7.207).
(PRERELEASE MXG 7.4 dated November 25, 1989, only for an ESP).
(PRERELEASE MXG 7.3 dated November 25, 1989, thru Change 7.190).
(Newsletter FIFTEEN dated November 11, 1989, thru Change 7.165).
(PRERELEASE MXG 7.2 dated October 19, 1989, thru Change 7.161).
(BETA test MXG 7.1 dated September 14, 1989, thru Change 7.140).
(BETA test MXG 7.0 dated May 31, 1989 thru Change 7.098).
(Newsletter FOURTEEN dated April 1, 1989, thru Change 7.035).
Previous Version 6.6 dated January 20, 1989, had 206 changes.
Operating System and Subsystem Version.Releases supported in MXG 7.7:
MVS/ESA thru 3.1.3 and DFP thru 3.2.
CICS thru 2.1.
DB2 thru 2.2.0.
RACF thru 1.9.
VM/370 thru Release 6 and HPO thru Release 5 (no known problems).
VM/XA SP thru 2.1 plus later PTFs.
IMS 2.1 and IMS 2.2 (see special note for 1.3).
New Devices Recognized and/or supported in MXG 7.7:
3490 and 9348 tape drives (cart and reel respectively) recognized.
3480/3490 Tape Compression (IDRC) recognized.
3390 DASD devices recognized and counted in EXCP3390/IOTM3390.
Most important new enhancement in MXG Version 7.7:
MXGTMNT, the long awaited MXG Tape Mount Monitor, captures how long
operators take to mount tapes, and identifies which job mounted what
tape on which tape drive when, with no system modifications. The
monitor wakes up every 2 seconds to scan the UCB chain, and writes
a User SMF record when each tape mount is satisfied.
Alphabetic (by acronym, of course) list of major changes, enhancements,
and new products/versions now included and supported in MXG 7.7:
ACF2 'ARE' data sets captured.
AION Development System SMF record from AION.
VSAM activity included with non-VSAM in ANALDSET I/O analysis by job.
ARBITER SMF records from Tangram product.
CMF and RMF records can now be differentiated.
CPU Serials added to RMFINTRV.
DB2 Audit Class trace type 102 records.
DB2 SQL text ("what he typed in") is captured.
DB2PM-like reporting enhancements for DB2 2.2 in ANALDB2R.
DFP 3.2 TYPE42 SMF record.
DOS/VSE Power 3.1.2.
FILEAID SMF record from COMPUWARE product.
GTF format DB2 trace data supported.
ICF TYPE6156 VOLSER capture and enhancement.
IDRC (Improved Data Recording Compression) for 3480/3490 tapes.
IMS 1.3 transaction processing: see Change 7.075.
IMS 2.0 and IMS 2.1 response measurement corrections.
JES2 mods to capture SYSOUT release timestamp in type 6 SMF record.
MDFTRACK SMF record from Amdahl MDF environment.
MVS/ESA 3.1.3 SMF and RMF records.
MVS/ESA CPU timings in step records.
NAF SMF record from Candle's Network Accounting Facility.
NETSPY Release 3.2 SMF record.
NETVIEW TYPE37 Release 2 Hardware Monitor External Log Record.
NETVIEW TYPE39 Release 2 Session Monitor External Log Record.
OMEGAMON Command Audit SMF record from Candle.
PDB.STEPS contains STEP accounting fields (if any).
PDSMAN/XP Release 6 SMF record.
RACF 1.9 (based on SMF 3.1.3 manual) SMF records.
RMF Monitor II Type 79 SMF record (fourteen subtypes).
RMF Monitor III VSAM data set records and TYPE72MN enhancement.
ROSCOE 5.6 support for variable number of complexity levels.
STOPX37 Release 3.3 SMF record from Empact product.
STX Release 1.0+ supported.
TLMS (Tape Library Management System) catalog records.
TMON/MVS data records (non-SMF) from Landmark's Monitor for MVS.
TMS (Tape Management System) catalog records.
TPX Release 2.0.0 SMF supported.
TREND data base validation and enhanced report examples.
TSO/MON Version 5.2 SMF record from Legent product.
VM/XA SP 2.1 plus PTFs, and protection for VCOLLECT environment.
VMXGVTOC enhanced for VSAM with 128 extents and DASD VTOC data.
VSAM TYPE64 PTF to add important data for Hiperbatch aid.
Validation and cleanup of all reported MXG 6.6 errors.
Pre-release by pre-release delta of changes (for testers, thanks!):
Significant changes added in 7.7 that were not in 7.6:
Support for Release 3.3 of Empact's STOPX37 product.
IMS 2.2 algorithm enhancements improve IMS log response captured.
ANALDB2R updated for DB2 2.2 (most reports, except DDF).
Lots of final cleanup from pre-release testing.
Significant changes added in 7.6 that were not in 7.5:
Support for all 14 subtypes of the type 79 RMF Monitor II record.
Support for VM/XA SP 2.1 plus new PTFs, and integrity enhancements.
Enhanced decoding of TYPE6156 ICF Catalog record to add VOLSER(s).
Support for Candle's Network Accounting Facility SMF records.
Support for Legent's TSO/MON Version 5.2 added.
Support for Landmark's TMON/MVS product.
Significant changes added in 7.5 that were not in 7.3:
Support for MVS/ESA 3.1.3, including the major enhancements in type
6 SMF record and a new type 42 DFP and 83 RACF SMF records.
Support for the VSAM PTF changing SMF 64 record (for Hiperbatch Aid)
Support for DB2 Release 2.2.0 changes to 100, 101, and 102 records.
Support for Netspy Release 3.2.
Support for PDSMAN/XP Release 6.
Validation of NETVIEW type 37 SMF record modem section.
Correction of JES3 type 6 (prerelease only) error.
Significant changes added in 7.3 that were not in 7.2 or Newsletter 15
DB2 I/O, Locking, and Record Trace reports added to ANALDB2R.
MVS/XA & ESA Pathing configuration and activity report in ANALPATH.
3390 DASD device support is official (support is already in 7.2).
RMDS pagecounts are fixed.
D3330DRV (mountable drive count) eliminated from 30s and PDB.
GTF format DB2 type 102 trace data now correct.
VMXGVTOC cleanup (deletes to clean WORK, last track counting, etc.)
TPX Release 2.0.0 new release supported,
STX Release 1.0+ new product supported.
Prior changes added in 7.2 and earlier are listed in Newsletter 15.
Documentation of enhancements in MXG Version 7.7.
Details on enhancements, and their impact will usually be found in the
text of the actual Change description itself.
While Changes can and should be read in the printed Newsletter, it is
very helpful to use SPF BROWSE/EDIT to scan the online documentation
available in member CHANGES of the MXG Source Library interactively.
Member CHANGES contains the current MXG version status and changes that
have been installed in that software. Member(s) CHANGEnn are copies of
member CHANGES as it stood when MXG version nn was created.
In addition, the Change Number lists the member(s) affected by that
change. Browse those members, especially the ANAL...., IMAC...., and
VMAC.... members for further documentation and usage notes.
Member NEWSLTRS contains the text of all newsletters (including the
newsletter that accompanied that MXG release). You can usually search
on product name or acronym to find the MXG acronym and member names
that document, support, and process that product's data records.
Member DOCVER07 contains abbreviated Chapter FORTY style documentation
of just those variables and datasets that were added by MXG Version 7.7
since MXG Version 6.6, the "delta-documentation". For example, you
could browsing DOCVER07 for the TYPE70 thru TYPE79 (RMF) dataset
descriptions, to learn what new information IBM has added to RMF data
records. There is a DOCVERnn member in the library for each version.
Penultimately, member DOCVER contains abbreviated Chapter FORTY format
documentation of ALL 22,277 variables from the 679 MXG data sets that
can be created by MXG Software Version 7.7 (alphabetically by data set
name and variable name).
Finally, MXG is a source distributed system, so you can often find your
answer by BROWSE/EDIT of the source member, especially the VMAC...'s
that actually create the data set, or ANAL....'s that create the MXG
report. In many instance, the MXG Variable is the IBM or Vendor's
documented field name. In other cases, the IBM field name is carried
as a comment beside the MXG variable that contains that information.
In looking thru MXG library members online, try these SPF techniques:
Make a COPY of member CHANGES (don't use the actual member, because
you will use an EDIT command, which can delete/change data
accidentally).
For example:
EDIT a non-existent new member and COPY in (for example) CHANGES.
On the command line, enter EXCLUDE ALL.
On the command line, enter FIND "VM/XA" ALL , for example.
which will result in your display containing only those
lines that contain VM/XA.
You can then un-exclude the lines before and after each occurrence
by typing L5 or F3 on the line number of the excluded lines to now
display or un-exclude the Last 5 or First 3 lines.
When done, CANCEL from the command line and nothing will be written.
The use of SPF commands EXCLUDE ALL and FIND ALL is a major tool in
creating and maintaining MXG software. It's especially useful is
scanning through a large number of lines of text, like MXG CHANGES
and NEWSLTRS members. Unfortunately, it is only available as a
subcommand of EDIT; you cannot EXCLUDE under BROWSE.
2. Installation sizing and instructions for MXG 7.7.
The MXG Installation instructions are found in Chapter 32 of the MXG
Supplement for version replacement as well as new install.
The MXG tape still is distributed as a Non-Labelled (NL) tape with a
single file, DCB=RECFM=FB,LRECL=80,BLKSIZE=6160, containing an
unloaded Partitioned Data Set containing 1100 members (and about
220,000 lines of source) in IEBUPDTE format. Under CMS/SAS this format
is known to the TAPPDS command instead of the MVS IEBUPDTE program.
At 303 feet of 6250BPI tape, MXG no longer fits on those little
half-full minireels with 300 feet of tape. (They were only $6.50 each
when a full 600 foot reel was $11.75, and in 1984 MXG Version 1 was
only 99 feet long.) Now, for those of you who are still in those dark
ages and require MXG on 3420 tape reels, MXG arrives on that same 7
inch mini reel, but now it's full (and 600 feet now costs $6.50!).
If you received a mini-reel instead of a 3480 cartridge, please
let us know as soon as you can accept 3480 tape cartridges.
We can create about 250-300 cartridges per hour, but only about 100
of the reels per hour, and they have more errors! And cartridges
are only $5.75!
Judy still holds the world land speed record of 11 seconds per 3420
tape mount building MXG Version 4.
The MXG Version 7.7 SOURCLIB requires SPACE=(CYL,(30,1,199)) with
a DCB attribute of DCB=RECFM=FB,LRECL=80,BLKSIZE=23440.
The MXG Version 7.7 SASLIB format library (built by the first step
of JCLTEST) requires SPACE=(CYL,(2,1,99)) and the blocksize is
set when JCLTEST's first step is run.
See the comments below in the Changes log for compatibility issues
with installation tailoring IMAC.... members.
Pre-releases of MXG 7.7 have been installed by over 400 sites this
year, and no real problems in installation have been encountered.
The major portions of all the important code have been running in a
production status at many sites for months. MXG 7.7 has been better
tested than any of the preceding 28 releases, but as it must always
be, it's up to you to validate with your own data.
III. CHANGE LOG
==========================Changes Log=================================
You MUST read each Change description below to determine if a Change
will impact your installation. All of these changes have been made
to this MXG Source Library.
Member CHANGES of the MXG SOURCLIB will always be more accurate than
the printed changes in a Newsletter, because the software is created
after the newsletter is sent to the printer!
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
The actual code implementation of some changes in MXG SOURCLIB may be
different that described in the printed NEWSLETTER (which might have
printed only the easily installed, critical part of the correction).
Always read the comments at the beginning of each source member named
under the Change Number when you receive a new Version of MXG.
Documentation of new datasets and variables, validation status, notes,
etc., are usually in comments in the source members.
If you have to install printed changes from an MXG Newsletter, you
could copy the affected member(s) from MXG.SOURCLIB into your existing
USERID.SOURCLIB and then make these changes therein.
Or alternately, you might create a new PDS, named MXG.CHANGLIB, and put
these in-between-version changes in that PDS, concatenating it between
USERID.SOURCLIB and MXG.SOURCLIB until you get the next MXG version.
When you do, you then delete this MXG.CHANGLIB library, as the changes
will have been installed for you in the new MXG version. It is wise to
record your changes in a member named CHANGES in the installation's
USERID.SOURCLIB as a permanent log of tailoring, etc.
Whenever you install changes or test a new version of MXG (or even for
your own reports), be extra careful to look on the SAS log for any real
error conditions. Search for all occurrences of "ERROR:" "ERROR :"
"UNINITIALIZED" "NOT CATLGD", as they usually indicate a serious error.
PROC PRINT and PROC MEANS of each new MXG-built SAS dataset will go
a long way in explaining their contents, and can be examined to detect
unusually large, negative, or suspicious values.
Summary of critical actions to be taken in installing new version:
a. All IMAC.... members in your USERID.SOURCLIB must be compared
with the new IMAC.... members, and if there is a difference,
you MUST start with this version's IMAC and retrofit your
installation changes. This is especially critical for IMACPDB
and IMAC30IO which were changed by several changes.
b. It is always wisest to PROC PRINT the first 50 observations of
critical datasets created with the new version. A visual scan
will easily confirm if there were unexpected changes. This is
especially important for PDB.JOBS, which can be affected by
user tailoring in IMACPDB.
Completed changes which have been installed and tested in this library:
NEXTCHANGE: Version 7
Change 07.247 Amdahl MDF record fields DOMMIN,MAX,TGT,ATGT,DUTIL,NORM,
VMACMDF SUTIL,UTIL should have been input as PD4.2 instead of
Feb 15, 1990 PIB4., and now they are.
Thanks to Vince Loeffler, G. D. Searle, USA.
Change 07.246 QA runs uncovered TMON/MVS variables JISTART and STARTIME
VMACTMVS that should have been set to LENGTH 8 (because they are
Feb 15, 1990 datetime stamps). Now they are, and ZDATE is now kept.
Change 07.245 TSO/MON will capture member names of PDS data sets that
VMACTSOM TSO users access, but MXG kept only the first eight names
Feb 15, 1990 in MEMBER1-MEMBER8 (and also did not re-initialize). Now,
multiple observations are created when necessary so that
all member names referenced are in TSOMDSNS dataset.
Thanks to Pete Shepard, Ashland Oil, USA.
Change 07.244 DASD/MON support did not keep two variables, RSRCNT and
VMACDMON RFTCNT in the DMON.... data sets, but now it does.
Feb 15, 1990
Thanks to Greg Scriba, First National Bank of Chicago, USA.
===========Changes thru Change 7.243 comprised MXG Version 7.7=========
-Newsletter SIXTEEN accompanied MXG Version 7.7 to Merrill's customers-
Change 07.243 Alpha testing of TSO/MON release found that USRTHKTM had
VMACTSOM been INPUTed with TU4. format but then was inadvertently
Feb 12, 1990 also divided by 38400. (Before TU4. format existed, you
had to INPUT PIB4. and then divide that by 38400 to get
a TU4. data field into a SAS Time/Timestamp variable).
I probably should change all the old "PIB4./38400" fields
to TU4. and delete all of the /38400 lines, but that is
too risky a fix (and totally unnecessary in execution)
this close to production shipment, so I chose to change
the TU4. back to PIB4. At a later time I will make
and test the mostly-cosmetic change from "PIB4./38400"
to TU4.!
Thanks to Pete Shepard, Ashland Oil, USA.
Change 07.242 PDB logic and user tailoring are controlled by IMACPDB,
IMACPDB (which must always be from the same version of MXG as is
Feb 8, 1990 the BUILDPDB/BUILPD3 member being executed). Two changes
were made:
-The new _SUMPRN macro allows users to name additional
variables in TYPE6/PDB.PRINT data sets that are to be
summed in that job's observation in PDB.JOBS. Not likely
needed at most sites (but requested by a few), it should
have been there along to be consistent with the other
standard PDB-build data sets.
-The archaic PROTECT= option was externalized in MXG 6.4
into macro _PROTECT so sites could disable protection.
SAS Version 6.06 does not have a PROTECT= option, and
when you execute under SAS 6.06 with PROTECT= specified,
you get a NOTE: that the option is no longer supported,
and a condition code of 04 is set by SAS 6.06! This part
of this change creates a temporary new style %macro
%VMXGPRO which detects SAS version and does not supply
the option when you finally execute under SAS Version 6!
The comments have been revised in this important member
for user's wishing to tailor MXG PDB data sets:
Installation exit IMACPDB to control the Performance Data Base.
This member externalizes macros critical to building your PDB.
Most sites should not have to change this member, unless they
want to tailor the contents of the standard MXG PDB data sets.
If you tailor member IMACPDB, you must ALWAYS update that old
tailoring starting with the new IMACPDB member in a new version
of MXG. IMACPDB and BUILDPDB/3 must be at the same MXG version!
These following macros are defined here in IMACPDB and referenced in
either BUILDPDB or BUILDPD3. Please read comments carefully before
changing the contents of these macro definitions, and scan CHANGES.
Macro Purpose/Description
_PDB6 List of variables kept from TYPE6 in PDB.PRINT.
_PDB26J2 List of variables kept from TYPE26J2 (JES2) in BUILDPDB.
_PDB26J3 List of variables kept from TYPE26J3 (JES3) in BUILDPD3.
_PDB30_1 List of variables kept from TYPE30_1 in PDB.
_PDB30_4 List of variables kept from TYPE30_4 in PDB.
_PDB30_5 List of variables kept from TYPE30_5 in PDB.
_SUMPRN Subset of _PDB6 variables to be summed into PDB.PRINT.
_MAXSTP Subset of _PDB30_4 variables to be MAXed into PDB.STEPS.
_MINSTP Subset of _PDB30_4 variables to be MINed into PDB.STEPS.
_SUMSTP Subset of _PDB30_4 variables to be summed into PDB.STEPS.
_PDBADD2 List of PDB.JOBS variables back-merged into PDB.STEPS JES2
_PDBADD3 List of PDB.JOBS variables back-merged into PDB.STEPS JES3
_PDBSUMS Externalized logic of MXG summing algorithms, should only
be changed if _MAXSTP or _MINSTP are changed. Careful!
_NODUP Archaic, needed before SAS 5.16 to disable NODUP option.
Since 5.16 is dead, default now enables NODUP option for
all PDB datasets that are SORTed in BUILDPDB. The CICS
datasets from type 110 are not sorted by BUILDPDB.
_PROTECT Archaic default enables PROTECT=ZZZZZ for most PDB data
sets. The PROTECT option goes away in SAS 6.06, and MXG
will recognize execution under 6.06 and will not supply
the option (thereby avoiding an otherwise unavoidable
SAS NOTE: on your log, and a condition code 04!).
Change 07.241 VM/Monitor USER records do not indicate if a LOGON event
VMACVMON occurred. MXG attempted to detect a LOGON in processing
Feb 8, 1990 User interval records by testing the deaccumulated value
of each variable. If a LOGON occurred, its interval data
values should be less than the accumulated resources in
the preceding record from this user. However, two of the
user fields used in LOGON detection are only two byte
counters, which can wrap/overflow inside VM/Monitor, and
when either DRPCANUS or DRPPOPUS overflowed at the wrong
time, MXG falsely detected a logon event, and this caused
incorrect TTIME, VTIME, etc. values. Now, MXG's algorithm
for LOGON detection no longer uses the DRPCANUS/DRPPOPUS
two byte counters.
Thanks to Rob Owens, SAS Institute Europe, GERMANY.
Change 07.240 TSO/MON Release 5.2 shipped in January 1990 will require
VMACTSOM Legent's maintenance tape TSM9002 to correct problems in
Feb 8, 1990 their capture of service units. TSO/MON Release 5.2 that
is accompanied by a Ship Letter Dated Feb 5, 1990 or
later already contains TSM9002 (which corrects errors MXG
found testing a Legent-supplied early beta test tape).
The support for TSO/MON 5.2 required an additional MXG
change, which could impact the existing MXG variables
SWAPHIGH SWAPSIZE TSMPSIMX TSMPSISZ TSMPSOMX
TSMPSOSZ TSMSIMAX TSMSISIZ TSMSOMAX TSMSOSIZ
which contain the swap sizes and maximum swap sizes
in both TSOMCALL and TSOMSYST data sets. Prior to 5.2
TSO/MON recorded the number of 2K blocks, but now TSO/MON
TSO/MON records the number of 4K pages. Since all of the
swap sizes and high water marks are actually
measures of storage (bytes, frames, pages, KB, MB, etc.)
which can be printed accurately and uniformly with MXG's
MGBYTES format, all of these old variables are now
converted
into bytes and formatted with MGBYTES. Unless you test
the value of those variables or calculate other report
variables, the only impact will be that the size will be
printed 396K instead of 99 pages (5.2+) or instead of 198
2K blocks (5.1 and earlier). This fix also preserved old
variables SWAPSIZE, SWAPHIGH, NRSWAPS to protect reports,
but now swaps are split into two variables each for
In/Out.
I firmly believe presenting KB, MB, GigaBytes, and their
rates per second is far more communicative than using
units of pages, frames, slots, etc., for both the swap
size of a single user (which might be 200K, 400K, etc.),
and for the total swapping load (which might be 9000G
for a 15 minute interval, or 10 MB/sec to/from if 100
100K users are swapped once per second). By expressing
these transfers of data between memories in MB/sec or
similar consistent units, comparisons with channel speed,
memory speeds, etc. become clearer, not just in TSO but
in all subsystems in all operating systems.
Thanks to Pete Shepard, Ashland Oil, USA.
Change 07.239 Change 7.142 for PR/SM environment corrected CPUWAITM if
VMAC7072 the number of LPARS was greater than the number of real
Feb 8, 1990 processors. That fix also corrects an error in CPUWAITM
when CPUs are varied ONLINE or OFFLINE under PR/SM.
In verifying that the fix solved both problems, it was
noted that the fix was made only to PR/SM SHARED,WAIT=NO
environment (the normal, expected use of PR/SM). Although
no one has ever (nor likely will ever) specified WAIT=YES
for their PR/SM partition, the fix of 7.142 was applied
to lines 136200-141000.
Thanks to Lou DeRosa, Commercial Union, USA.
Thanks to Igor Polevoy, Commercial Union, USA.
Change 07.238 Several collected changes to various things.
ANALAUDT 1.ANALAUDT line 01500001 should be RACFQUAL=107 instead of
Feb 7, 1990 RACFEVNT=107.
2.Misspelled SMF6LN3 now correct in text of Change 7.105.
3.VMAC37 variables BRFMODEL and BRFTYPE removed from keep
list, as they did not exist.
4.VMAC102 variables QW0080CK,QW0082CK and QW0082F1 are now
formatted $HEX2. for printing.
Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
Change 07.237 -NETVIEW NPM Type 28 records occasionally produce MXG note
VMAC28 "nonzero AOF segment for NPMSUBTY F1 (NPM End)". In the
Feb 7, 1990 two dumps viewed, the AOF triplet does point to a data
segment, but it contains trashy data (like an uncleared
buffer?). There is no AOF segment documented for the F1
subtype (and none expected; this is the stopping of the
NPM monitor). It sure looks like an IBM coding error in
NETVIEW/NPM, but since it's only impact is the note on
the MXG log, and because this is not important, no one
has gone thru the tedious process of several calls to the
support center Level I and Level II until they find that
no reported problem exists and IBM then issues an APAR,
(Authorized Problem Activity Report), which is IBM's
acceptance of the problem, and then they wait for the IBM
Product Change Team to produce the PTF (Program Temporary
Fix), that now must be installed (a change, with its
exposure to breaking something that was already fixed).
Hoping it eventually goes away or gets reported, you can
ignore the note for the F1 subtype.
-Variable BASTIME does not exist in subtype 51x and 61x,
causing INVALID ARGUMENT FOR INPUT FUNCTION. INFO/SYS
entry E337883 confirms these values are zero for those
subtypes. MXG now causes BASTIME to be missing for those
subtypes. Update Nov 2001: See Change 19.221.
Thanks to H. Beer, Hessische Landesbank, GERMANY.
Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 07.236 Support for Empact's STOPX37 Product Release 3.3 added
VMACX37 new variables STEPNAME,PROCSTEP,VMEXTS,VSCLUST,VSCOMP,
Feb 7, 1990 VSTYPE, and VSDTYPE and corrected the length of SELECTBK,
ACTIONBK, and ACTION37. The Empact supplied SAS code for
3.3 is incorrect for at least one field, and this support
has not yet been tested with actual 3.3 records.
Thanks to Duane Reaugh, Empact Software, USA.
Change 07.235 DB2 discoveries and enhancements support DB2 2.2.0:
ANALDB2R 1.DB2STAT0 and DB2STAT1 records have slightly different
VMACDB2 values for QWHSSTCK (time stamp). To associte the two
VMAC102 records from the same interval, MXG carries the subtype
Feb 6, 1990 0 QWHSSTCK into the subtype 1, unless the absolute time
Feb 8, 1990 delta between the 0 and 1 subtypes was greater than one
second (to detect when the previous 0 is the last from
one SMF file and the new subtype 1 is the first from this
system). I assumed one second delta would be enough, but
it is not! One site sent these data for adjacent SMF
type 100 records:
Subtype SMFTIME (SMF) QWHSSTCK (DB2)
0 33:42.55 33:42.4624
1 33:43.69 33:43.6992
a. DB2 STCK to SMF buffer delta time is 90 millisecs.
This possibly represents the elapsed time for DB2
to collect and pass the subtype 0 to SMF.
b. Delta from STCK of 0 to 1 is 1.25 seconds between
DB2 time stamps AND delta from SMFTIME is 1.14
seconds suggest a momentary glitch delayed DB2.
As a result, the THISSTCK check in VMACDB2 now tests for
a delta of 60 seconds between subtype 0 and 1 before a
mis-match is declared. (No records are lost).
2.The DB2ACCT, DB2STAT0, and DB2STAT1 data sets now contain
the 16-byte DDF variable QWHSLOCN (This Location Name) if
this DB2 is part of a Distributed Data Facility network.
3.QWHSLOCN was also added to all T102Snnn trace datasets.
In the trace record, for DDF, there is a new header with
several new DDF fields (including QWHDRQNM, the location
name of the Requestor/Server DB2), which is decoded, but
kept only in the T102S106 dataset. Location names are
$CHAR16. fields (though in the pre-release, QWHDRQNM was
incorrectly $CHAR8.).
4.Type 102 trace subtype 106 T102S106 variables QWP9....,
for DDF are now created and decoded.
5.Variable QXNSMIAP in VMACDB2 is now spellec QXMSMIAP.
6.The CPU time of the 4th address space (DDF) is created
in QWS4EJST and QWS4SRBT and is added to DB2CPUTM.
7.New member XDB2HDR is a debugging aid that decodes the
type 102 record header(s). Hopefully you won't need it!
8.DDF may create multiple segments in type 100 and 101
records (NRQTXA and/or NRQLST greater than 0), but MXG
currently only processes the first segment. Once we have
real DDF data in hand, we'll decide what to do (i.e.,do
we create multiple variables, or multiple observations?).
9.EDM pool reports from variables QB1TCBA-QB4TCBA and
QISEPAGE,CT,FREE,DBD, and SKCT were incorrect (only the
ANALDB2R report was wrong; the values were correct in
the DB2STAT0 data set), and have been fixed.
10.ANALDB2R (DB2PM-like reporting) has been updated thru DB2
Release 2.2.0. The status of all DB2 reporting is in the
comments in member ANALDB2R. Only the SQL TRACE and the
Transit Trace reports were not completed in MXG 7.7. The
reports are generally updated for DDF fields, but we have
had no test DDF data. In all trace reports from DB2PM in
DDF environment, QWHDRQNM, (DDF location) is printed in
the header, but not all MXG trace reports have this one
field (although the system parameter report and other
important reports have been updated.
Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 07.234 MXG Algorithms to process IMS log records into IMSTRAN
IMACIMS observations now are further enhanced. Variables MODNAME,
TYPEIMS NODENAME, MSGSIZIN, MSGSIZOU, ODEST, and DTOKEN should no
VMACIMS longer be occasionally missing; incorrect KEEP/DROP logic
Feb 5, 1990 in VMACIMS was changed. A new macro, _IMSVTAM, is now
defined in IMACIMS to indicate if VTAM is your IMS access
method (default _IMSVTAM is yes). For IMS 2.2 or later,
VTAMNODE will be captured. Output queue time was missing
sometimes because CLINENR was set to LINENR/TERMNR but in
VTAM environment NODENAME/VTAMNODE should have been used;
now CLINENR is set appropriately. The response times for
WFI and multiple transactions per program schedule were
sometimes missing, because only one observation was
created for type 35 events, but a type 35 could be both
the end of one transaction and the start of a second;
MXG now creates multiple observations when appropriate,
and this new logic seems to have closed that loophole.
I keep hoping each IMS iteration will be the last, yet
I know it never will be. This one, though, was a cleanup
of many small problems which have existed since Pete
re-vamped the original MXG algorithms in 1988! These
changes have been well tested on IMS 2.2 and tested on
2.1 data, but not yet on IMS/ESA 3.1 data records.
A new debugging macro _IMSDBUG that provides a decoded
trace of each IMS log record used in MXG logic is also
defined and described in VMACIMS.
Thanks to Pete Shepard, Ashland Oil, USA.
Thanks to Ervin Claxon, Ashland Oil, USA.
Change 07.233 VM/370 Monitor MXG dataset VMONPERF variables Q1LOGDRP
VMACVMON and Q1LOGDRP were documented in the MXG Supplement p 551f
Feb 5, 1990 as being renames of MN002Q1B/MN002Q2Bm but the change was
not made in VMACVMON until now.
Thanks to Bob Small, Grumman Data Systems, USA.
Change 07.232 Landmark's MONITASK record for TRANSACT='OVHD' does not
TYPEMONI contain User segments, and the second fix in Change 7.108
Feb 5, 1990 is now added permanently to prevent STOPOVER when reading
Landmark-created summary files. Note that OVHD transact
do not exist in the "raw" (normal) Landmark records.
Change 07.231 The new-style macro %GRAFRMF was both defined in this
GRAFRMFI member, and automatically invoked as the last line of
Feb 2, 1990 the member, preventing you from passing/changing any of
the macro arguments for RMF reports from RMFINTRV. Now,
the member only defines the macro, and no longer invokes
it for you.
Change 07.230 The variables kept in PDB.STEPS did not include the nine
IMACPDB variables documented on page 278 of the MXG Supplement:
Feb 2, 1990 JOBCLASS,LSQSZHI/LOW,PVTSZHI/LOW,RDRDEVT,REGREQST, and
USRSZHI/USRSZLOW that were supposed to have been added
back in Version 5! Now they have been added to the list
(in the MACRO definition for _PDB30_4 list in IMACPDB).
Thanks to Elliot Weitzman, Oryx Energy Company, USA.
Change 07.229 TYPE70PR (PR/SM only) variable PRSMSLIC (dispatch time
VMAC7072 slice duration) and flag variables DIAG204F, NRPRCHGD,
Jan 30, 1990 and SLICCHGD (X'204' failure, number of processors were
changed, or time slice was changed respectively) were not
kept, labelled, and the last two were not even created,
and PRSMSLIC should have been PIB2.3 instead of PIB3.
Fortunately, that it took until now for this to be seen
suggests they are not of critical import, but due to
detailed debugging by this user, they are now valid.
Thanks to Diane Eppestine, Southwestern Bell Telephone, USA.
===========Changes thru Change 7.228 comprised Prerelease 7.6==========
Change 07.228 NETSPY 3.2 Appendix B did not agree with actual DSECT of
VMACNSPY the T and U records, causing LUUID and LUGTRGT1-4 to be
Jan 29, 1990 missing (but no ABEND nor ERROR, because the Appendix
said to expect 116 bytes, but there were only 108, so the
conditional INPUT was never executed).Change the test
IF NSPYENTL GE 116 to GE 108 and change the subsequent
four occurrences of PIB4.6 to PIB2. (for the LUGTRGT1-4
variables), and delete the four lines where LUGTRGT1-4
are multiplied by 65536,
Thanks to Brian Cooper, Wyeth-Ayerst Labs, USA.
Change 07.227 The alpha test site for Change 7.219 found it deficient
VMACVMXA in two places. The calculation of SKIPTHIS was changed
Jan 29, 1990 to SKIPTHIS=LENGTH-COL-1; and the ELSE INPUT was changed
to just INPUT to properly skip over VM/XA spanned
records.
Thanks to S. Rolin Hymans, Comparex Belgilux, BELGIUM.
Change 07.226 VM/XA changes only in pre-releases 7.2+ caused DELTATM
VMACVMXA in VMXAINTV to be picked up inadvertently from VXSUMIOD,
Jan 29, 1990 where it was inadvertently summed. (DELTATM is the delta
between interval records of the same type, and is used
to calculate rates. In VXDEVTOT, DELTATM is appropriately
summed, because it aggregates device activity across the
day by device address. In VXSUMIOD, however, the interval
is the aggregate, and DELTATM is now taken from the first
occurrence within the interval device records. Note that
DELTATM between device records in an interval will not be
exactly the same as the DELTATM between other interval
records, because all records are not written at the same
time.) The fix: removed DELTATM from the _VSUMIOD macro
definition, added DELTATM explicitly after the references
to _VSUMIOD in building the VXDEVTOT, added ID DELTATM;
to the subsequent PROC MEANS for VXSUMIOD, and added
(DROP=DELTATM) after the VXSUMIOD reference in the MERGE
that builds VXBYTIME. MXG MACRO _TESTINT, which will
process only the interval VM/XA data records, was also
updated to properly handle the I/O interval records.
A brief benchmark of VM/XA processing costs for 30
intervals with 1000 Logged on VM machines shows total
MONWRITE output was 37,735,588 (35MB), written as
1372 4KB control records interspersed with the 3290
data blocks which varied from 4KB to 28KB but averaged
16K. That's about one Megabyte per Logged On user for
30 intervals (at 15 min intervals, thats 7.5 hours, or
one prime shift). MXG _TESTMW took 70.99 TCB 3090-200
seconds for the data step and totalled 117.20 TCB and
46,146 EXCP to create all possible data sets and sample
VM/XA reports, in 14 elapsed minutes of execution. The
_TESTINT macro (keeps only interval records and not all)
took only 9 minutes elapsed with 40.37 TCB in the data
step and 77.33 total TCB with only 31,464 EXCPs.
Thanks to Rob Owens, SAS Institute Europe, GERMANY.
Thanks to Margaret Curtis, Rutherford Appleton Laboratories, ENGLAND.
Thanks to Yam Tan, British Airways, ENGLAND.
Change 07.225 This update to DB2PM-like reports enhances more of the
ANALDB2R reports to support DB2 2.2.0 reports, although not all
Jan 28, 1990 of the new information (especially the DDF Distributed
Data Facility information) has been added to all of
the existing reporting. See the table in the comments
of the member to identify if the report tolerates or
exploits the new data fields. Member was renumbered.
Change 07.224 Typos crept into XMAC71 change 7.038 (to circumvent the
XMAC71 SAS Error 344 condition) that could cause variable type
Jan 26, 1990 conflict for variable FRAMES in TYPE71. Line 0318 XMAC71
that was IF FRAMES=. THEN FRAMES=.;
must be IF FRAMES=' ' THEN FRAMES=' ';
(to initialize FRAMES, which is non-existent if MVS/XA).
Thanks to Bruce Widlund, Texas Utilities, USA.
Change 07.223 Typos crept into ANALPATH, added in MXG 7.3. Line 105
ANALPATH should have been HEX4.; vice HEX4; and Line 222 should be
Jan 26, 1990 PDB.TYPE73 vice DB.TYPE73.
Thanks to Christophe Faure, SAS Institute, FRANCE.
Change 07.222 Preliminary support for type 79 SMF record written by RMF
EXTY791 Monitor II session to the SMF file. This support used an
EXTY792 SMF Manual from MVS/ESA 3.1.3 and an MVS/XA 2.2 DSECT in
EXTY793 ERBSMF79. If I am lucky, it should support all MVS/ESAs
EXTY794 and MVS/XAs 2.2 and later. If I should be really lucky,
EXTY795 some of the MVS/370 subtypes and MVS/XA before 2.2 may
EXTY796 also be processed without error, but caveat user.
EXTY797
EXTY798 Added in MXG 7.6, the code has yet to read a 79 record.
EXTY799
EXTY79A For subtypes 1 thru 12, exact IBM field names are used as
EXTY79B variable names, and one observation is OUTPUT for each of
EXTY79C the segments in each subtype into the twelve MXG-built
EXTY79D TYPE791-TYPE999 + TYPE79A-TYPE79C datasets.
EXTY79DF
EXTY79E For subtypes 13 and 14, because they so parallel the type
EXTY79EF 78 SMF record, their dataset names and variable names are
FORMATS taken from the existing TYPE78, TYPE78CF, and TYPE78CU
TYPE79 MXG datasets to create these four new data sets:
VMAC79
Jan 25, 1990 TYPE79D,TYPE79DF,TYPE79E,TYPE79EU
where Ds (13X) are non-3090s and Es(14X) are 3090 plus.
The implementation for this subtyped SMF record creates a
_VAR... and _CDE... MXG macro for each subtype, allowing
you to construct programs for selected subtypes, if your
really need to.
If you have turned on the right monitoring in RMF Monitor
II, you should have only subtypes of interest, and the
standard MXG program for processing an SMF record:
%INCLUDE SOURCLIB(TYPE79); RUN;
will create all 16 of the possible TYPE79.. datasets that
can be created, and for those of the 14 subtypes that
are found in your SMF file, non-zero observations will
appear in the associated MXG-built dataset.
Alternatively, as an example of this new MXG design for
SMF records with subtypes, you could create/execute the
following MXG program:
%INCLUDE SOURCLIB(EXTY79);
DATA _VAR791 _VAR792 _SMF _CDE79S _CDE791 _CDE792 ;RUN;
to create only the TYPE791 and TYPE792 MXG datasets from
the subtype 1 and subtype 2 SMF type 79 records. If you
do create your own subtype-specific program, note the new
required _CDE79S reference to process the RMF 79 header
and product section. (It's already in member TYPE79).
Future enhancements might include an "ANAL79" to merge
some subtypes together, and might include an "IMAC79" for
session selectivity, etc. Let me know what you need.
Thanks to Ervin Claxon, Ashland Oil, USA.
Thanks to Tom Skasa, General Electric Medical Systems, USA.
Thanks to Sterling Green, General Electric Capital, USA.
Thanks to Bob Rutledge, Sherwin Williams Paint, USA.
Change 07.221 Change 7.189 (only in MXG 7.3 and 7.5) was incorrect.
ASUMCICS While intended to transparently use either Landmark or
Jan 24, 1990 IBM CICS transaction data, it failed miserably if either
source was missing (but it worked great, when both were
present!). Now it self-detects what kind of CICS data
you want summarized from the detail transaction data to
the PDB.CICS (Trending, summarized) CICS data set. Sorry
for not testing all possible alternatives on this one!
Change 07.220 Line 002000 contained a truncated line, and should be
XSYSLOG deleted. (Variable EVENTIME was already calculated just
Jan 20, 1990 a few lines above).
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 07.219 This change is a series of enhancements to VM/XA Monitor
VMACVMXA support.
Jan 15, 1990 1.VM/XA MONWRITE can span logical records across physical
blocks, but VM does not support a "VBS" format, and the
2-byte field that could be used for "spanning" flag is
a reserved field in VM/XA! As long as the spanned record
happened to split on a field boundary, MXG'S Change 7.086
(which removed STOPOVER), and the robustness of SAS, made
spanning "supported"! Now, however, we find 1.13 records
split in the middle of the 8-byte MRHDRTOD field! (This
occurred at a site that named 240 specific devices to be
monitored, causing a 1.14 record that did not leave space
enough in that page for the 1.13 record to fit!)
This circumvention detects a spanned logical record and
and notes the encounter on the log, deleting the bad data
record, and IBM has been notified of their design error.
It may be that this is the only exposure, as in most of
the other records in which there can be multiple segments
the individual segments are actually separate logical
records and may (accidentally) be protected. How could
IBM overlook this design oversight? Because if you are
thinking about "data pages in memory" rather than the
resultant "physical block on external storage device",
and are simply moving addresses across virtual storage,
the operating system takes care of "page spanning" for
you!
2.If no Monitor START event precedes each package of VM/XA
MONWRITE data, numerous problems result. First, since
there is no 1.4 record, the GMT offset delta is unknown,
causing all timestamps to be of unknown time zone! All
of the records found before an end-of-interval have to
be deleted, because BEGINMTR and ENDTIME are unknown.
Furthermore, since MONWRITE records contain accumulated
data (instead of the actual data for the interval), the
first interval will ultimately also be thrown away, as it
is valid only to initialize values for de-accumulation.
Still further, no Monitor START event record means that
there is no MTRDEV Configuration record, which is needed
to map the static device information (such as device type
class, path, etc.) to the device activity records. All of
those variables will be blank in the IOD... datasets.
MXG now will process VM/XA data that is not precedeed by
a Monitor START record correctly, but even MXG cannot do
anything about the missing data.
How can there be no START event? This problem came about
at a site using Candle's VCOLLECT product that creates a
new MONWRITE file each day with its End-of-Day routine.
The second and subsequent files are incomplete. The only
safe solution seems to require Candle to STOP/START the
monitor as the initial records written to each new day"s
MONWRITE file.
This is not a problem with IBM's MONWRITE-created files,
since their ONLY way to dump VM/XA data requires you to
STOP and then START the monitor!
The real culprit here is the IBM design in which monitor
data records are created that are not self-described and
contain no independent information without the prior time
interval. VM/XA should have looked at RMF design!
3.Since no startup records can be guaranteed, the MXG logic
that attempted to capture VMDTTIME,VMDVTIME and VMDCTIME
in the first interval has been eliminated. Until IBM adds
a flag in the USER data record itself, it is impossible
to unambiguously and safely capture these CPU times from
USER logon to the first interval. The remainder of the
MXG algorithm to detect subsequent logon events (done by
setting variable LOGON) has not been altered.
4.VM/XA SP Release 2.1 did not alter the contents of any
data records, but several VM/XA APARs have changed many
MXG data sets by creating additional variables. As is
always the case, member DOCVER07 in the MXG SOURCLIB
library provides the delta-documentation of the datasets
and variables added. These support of these IBM changes
required these sources of documentation:
I. CP Programming Services, Release 2.1 SC23-0370-2.
Appendix B, Monitor Records, which is now the
basic source of documentation of VM/XA records.
II. VM/XA System Product Release 2.1 Program Directory
for VMSUP Level: 8905 for VM36583 and VM37852.
III. INFO/SYS Entry E343842 for VM35968.
IV. INFO/SYS Entry E337409 for VM35962.
V. INFO/SYS Entry E336950 for VM35321.
a. Variable VMDCPUAD has been added to three MXG datasets
for schedule domain, VXSCLADL,VXSCLDDL and VXSCLAEL by
VM35321 (supported in MXG 7.0 and later).
b. Variable RDEVCUIV flags if Control Unit information is
available in the VXIODATD, VXIODVON, and VXMTRDEV MXG
data sets, and RDEVOFFL in VXMTRDEV identifys if the
device was OFFLINE/ONLINE at Monitor START by VM35962.
c. VM35968 adds information on I/O activity (variables
RDEVSKCT,RDEVSKSM,RDEVWRCT,RDEVRDCT containing Seek
counts and cylinders ('passed over while the arm is
passing over uninteresting data', according to Siebo),
and separate counts of Read or Write channel programs
to VXIODDEV at the device level. Variables IORDWRIT,
IORPOSCT,IORPOSSM, CALECYL,CALUSER,and RDEVDEV were
added to the VXSEKSEK seek trace record that IBM had
previously reported as in error and unusable. This is
thought to mean that seek data is now usable.
d. VM36583 and VM37852 add 27 new fields to the interval
VXSYTXSG dataset extending ESTORE (or XSTORE if you
must, even though MVS' used ESTORE long before VM was
able to use "XSTORE") efficiency measurements.
Thanks to Phil Strange, BP International, ENGLAND.
Thanks to Martyn Stevens, Barclays Bank London, ENGLAND.
Thanks to Rob Owens, SAS Institute Europe, GERMANY.
Change 07.218 VM/370 Monitor data variable STGUTIL could be missing as
VMACVMON it was not in the RETAIN statement. Now it is.
Jan 15, 1990
Thanks to Rob Owens, SAS Institute Europe, GERMANY.
Change 07.217 TYPE76 RMF Trace variables INTRVAVG and AVG were slightly
VMAC76 wrong if the last sample set did not have complete sample
Jan 15, 1990 count. The calculations were corrected to use NSAMPLE for
NRSETS*SAMP_SET for INTRVAVG, and SAMP_LST instead of
SAMP_SET for AVG if _I_=NRSETS (i.e., for last set).
Thanks to Steve Cavill, SAS Institute, AUSTRALIA.
Change 07.216 TYPE60 VVR variables are now labeled.
VMAC60
Jan 12, 1990
Change 07.215 TYPE6156 ICF Catalog Activity records have been enhanced
FORMATS to extract volume serial numbers from the catalog section
VMAC6156 at the end of the record, if a volume segment exists. Up
Jan 12, 1990 to five volumes (VOLSER1-VOLSER5) will be contained in
each observation and multiple observations (sequenced in
variable MULT6156) are created if the entry has more than
five volumes. Catalog records consist of a sequence of
catalog cell records, identified by a hex "cell type".
Not all TYPE6156 records contain a 04 Volume record; to
examine the structure of the catalog segments, variable
CATCELLS contains the first 16 cell types encountered.
Expected sequences of ICF catalog cells are:
C1 01 03 04 Non-VSAM dataset
C2 01 05 GDG Base subrecord
C2 01 05 C8 01 03 04 GDS subrecord
C3 01 02 03 06 Cluster component
C4 01 02 04 Data component
C7 01 03 AIX component
C7 01 C4 01 04 C9 01 04 AIX subrecord
C9 01 02 04 Index component
D8 23 Secondary VVR
D9 01 02 03 Path record
E3 03 Truename record
E4 01 03 04 User catalog connector
E7 03 Alias
E9 21 60 23 Primary VVR
Multiple occurrences of 02 03 can occur. Multiple
04 (volume) occur for multi-volume entries.
There are cases with no 04 volume cell in the record.
Variable ACTION shows DEFINE action for non-VSAM files
files with no 04 cell, and have found SCRATCH action
for GDS G0002V00 but there was no C8 entry for that
gen! (The catalog record for a GDS consists of the
base GDG entry followed by a C8 01 03 04 for each
generation; MXG parses the GooVoo in the entry name
and finds its C8 entry in the catalog record to extract
the VOLSER(s) of that generation). We have also found
catalog records containing only the E3 03 (Truename)
entry, and a GDS with only the base GDG C2 01 05 entry.
Format $MG060ID now decodes the possible values of the
ENTTYPID entry type id field, although we still have
found three data values that IBM level 2 could not
explain (although they did offer to build a slip trap
we were unwilling to install!). Thus far, we have found:
A - non-VSAM ("Alien") N - undocumented
B - GDG Base P - Pagespace
C - Cluster R - Path
D - Data S - undocumented
F - Free T - Truename
G - Alternate Index U - User Catalog
H - GDG V - Volume
I - Index X - Alias Name
K - VSAM VVR Y - Upgrade
M - Master Catalog 00 - undocumented
Perhaps ENTTYPID will assist in explaining why an ICF
entry was changed, but does not have a volume record.
For VSAM entries, the catalog record typically contains
04 volume records for the cluster, the index component
and the data component. In this implementation of MXG,
ALL volume records are extracted and stored in VOLSERn
variables, in the sequence found in the catalog record.
Thanks to Connie Lee, Morgan Stanley, USA.
Change 07.214 Sample RMF Monitor III report programs variable DYDELAY
ZRBRPT1 should have been spelled DVDELAY.
ZRBRPT2
Jan 9, 1990
Thanks to Brian Redmond, Home Savings, USA.
Change 07.213 Support for Candle's Network Accounting Facility (NAF)
EXNAFENT SMF records (written by Candle Products CL/SUPERSESSION,
EXNAFGLI CL/GATEWAY, and VTAMPLUS) have been added by this user
EXNAFGOF contribution. Data sets NAFSTART, NAFSHUTD, NAFENTVA,
EXNAFGON NAFLOGON, NAFLOGOF, NAFVOGON, NAFVOGOF, NAFGOGON,
EXNAFGPA NAFGOGOF, NAFGPASS, NAFGLIMT, NAFGPSTR, NAFGPSTO
EXNAFGPO are created from subtypes of these network records.
EXNAFGPR This support includes NAF thru Version 145 of Candle's
EXNAFLOF CL product line.
EXNAFLON
EXNAFSHU
EXNAFSTA
EXNAFVOF
EXNAFVON
IMACNAF
TYPENAF
VMACNAF
Jan 9, 1990
Thanks to Gene Quinn, Blue Cross of Rhode Island, USA.
Change 07.212 Support for TSO/MON Version 5.2 has been added. This
VMACTSOM version adds a number of resource fields (swaps, paging,
Jan 8, 1990 service units, I/O connect time) to the TSOMSYST and
TSOMCALL datasets. MXG 7.6 or later is required for
TSO/MON Version 5.2 if TSO/MON options ACCOUNTING=YES
or DSNAMES=nnn were specified (because TSO/MON inserted
data before the accounting/dsname sections, and because
MXG did not use the offsets to those sections until MXG
7.6+).
Thanks to Ken Dove, Legent, USA.
Change 07.211 Duplicate records were not deleted by the NODUP option
BUILDPDB in the PROC SORT of DATA=TYPE70PR because the BY list
BUILDPD3 was insufficient to guarantee that duplicate observations
Jan 5, 1990 ended up physically adjacent. The variable LCPUADDR had
to be added to the end of the BY list in BUILDPDB/3.
Thanks to Earl Ryan, Life Insurance Company of Georgia, USA.
Change 07.210 The OUTPUT statements in _ANALMON deaccumulation macro
TYPEMONI are now includes of EXMONSYS, and the first definition
Jan 5, 1990 (unused) of _ANALMON deaccumulaton macro was removed.
Thanks to Glenn Thompson, Comalco, AUSTRALIA.
Change 07.209 -Further ANALDB2R report validation fixed Accounting
ANALDB2R trace long (max page locks) and total lock suspends,
GRAFTMNT corrected ABEND in IOS report if PDB did not contain
ASUMVMON IOS trace data, and eliminated uninitialized variable
GRAFVMON message if nondefault sort parameters are used.
Jan 5, 1990 -GRAFTMNT did not properly handle tape mount reporting
if multiple systems were used, now it does.
-ASUMVMON spelled PFAULT incorrectly as PFAULTT.
-GRAFVMON had trailing ./ IEBUPDTE command.
Thanks to Robert Olah, Dun and Bradstreet, USA.
Change 07.208 Support for Landmark's TMON/MVS product ("TMV or TMVS").
EXTMVEL Twelve data sets: TMVSEL,TMVSIC,TMVSIOL,TMVSIOD,TMVSIV,
EXTMVIC TMVSJI,TMVSJIST,TMVSNQ,TMVSPS,TMVSSYS,TMVSYSSW,TMVSYSUI
EXTMVIOL are currently created, though there may be more later.
EXTMVIOD Landmark cooperated extensively in the development and
EXTMVIV testing/validation of this support. Most variable names
EXTMVJI are Landmark field names, except for "standard" MXG names
EXTMVJIS like STARTIME,ENDTIME,DURATM,SYSTEM, etc.
EXTMVNQ Release 1.12 of TMON/MVS must be installed (as record
EXTMVPS formats have been changed from earlier releases).
EXTMVSYS Unfortunately TMON/MVS does not create SMF records, which
EXTMVSW will necessitate a separate jobstream to read their data
EXTMVUI from the MXG-required DDNAME of TMVSIN.
FORMATS The TMON/MVS monitor data can be created in compressed
TYPETMVS format (as is Landmark's Monitor for CICS data), and
VMACTMVS the MXG-provided "SAS Infile Exit" named TMON (created
Jan 5, 1990 by member EXITMONI as described therein and in the
CICS chapter in the MXG Supplement) can be used to allow
MXG to directly decode their compressed format data.
After the "TMON" exit has been installed by EXITMONI
change "INFILE TMVSIN" to "INFILE TMVSIN TMON" to invoke
that exit which will handle either un-compressed or the
compressed data automatically.
Thanks to George Greenacre, Landmark Systems, USA.
Note added Oct 24, 1990. Landmark renamed Release 1.12 to
Release 1.1 (went from 1.11 to 1.1!).
===========Changes thru Change 7.207 comprised Prerelease 7.5==========
Change 07.207 IBM added nine new fields to the type 64 SMF record for
VMAC64 VSAM activity. Added to support IBM's marketing aid for
Dec 22, 1989 Hiperbatch analysis, these new fields (ACBSTRNO,BUFDRNO,
ACBBUFSP,ACBBUFND,ACBBUFNI,JFCBDSN,PLHCNT,ACBMACR1-3)
may prove useful in normal VSAM analysis, as the data
now indicates concurrent strings, buffer counts, and
read/write sequential/indexed flags as well.
PTF UY40839 (APAR OY23661) added the data to the type
64 record, but failed to update the IDAEXTWA macro to
document the order of the new fields! APAR OY26396
contains the actual DSECT of the new fields.
Thanks to Lawrence Jermyn, Fidelity Systems, USA.
Thanks to Diane Eppestine, Southwestern Bell Telephone, USA.
Change 07.206 NETVIEW type 37 record's LPDA (Modem report) section was
VMAC37 off by a few bytes, and some fields were not formatted to
Dec 22, 1989 display in hex. The quick fix is to change BRFLSL from
$1. to $2. and insert +3 after BRFADDR to align MXG with
the apparently undocumented changes in this record!
Thanks to Bruce Widlund, Texas Utilities, USA.
Change 07.205 DB2 2.1 writes an SMF type 100 record with SUBTYPE='80'x
VMACDB2 instead of the expected value of 0 or 1. When or why is
Dec 21, 1989 not known at this moment, but it appears the field that
was originally documented as subtype is now a reserved
field. This change uses the product section IFCID value
to set SUBTYPE when the expected subtype value of 0 or 1
was not originally found. I'm still pursuing this one.
Find the lines:
@21+OFFSMF DB2BUF $CHAR4.
@;
and insert this new logic following that @; :
IF ID=100 AND SUBTYPE NE 0 AND SUBTYPE NE 1 THEN DO;
INPUT @25+OFFSMF OFFPROD PIB4. @;
LOC=OFFPROD-3+OFFSMF+4;
INPUT @LOC QWHSSIID PIB2. @;
IF QWHSSIID=1 THEN SUBTYPE=0;
IF QWHSSIID=2 THEN SUBTYPE=1;
END;
Thanks to Elliot Weitzman, Oryx Energy Company, USA.
Change 07.204 This is a "protective" change to protect you from your
VMAC6 own system programmers. A JES2 system programmer at one
VMAC26 site made incompatible changes to their type 6 and 26
Dec 20, 1989 SMF records when the site added support for 99,999 JES
numbers! This change eliminates the "NOTE: INVALID DATA
FOR JESNR IN LINE nnn bytes bb-ee. linenr : col " if
these incompatible records are processed by MXG.
What did the system programmer do? The 4-byte EBCDIC
field JESNR (which could contain only 0001-9999 in its
original EBCDIC format) was changed to a 4-byte packed
decimal (SAS PD4.) format! Programs expecting a 4-byte
EBCDIC format raised a data exception when they found
illegal EBCDIC numeric values in what was now a valid
packed decimal field. What did IBM do? As described in
the SMF manual, IBM stores EBCDIC value 0000 (which was
never a valid job number), and tells you instead to skip
3 bytes and read the 5-byte EBCDIC job number from the
previously-existing JCTJOBID field. What did MXG do?
The TYPE6 data set was okay, but the above "NOTE:" was
printed; MXG captured the 5-digit field correctly even
with their modfication. However, the TYPE26J2 dataset
had blank value for JESNR, and this caused BUILDPDB to
put all these jobs into SPIN rather than the PDB. The
simple fixes to MXG were: a) in both VMAC6 and VMAC26J2
change JESNR 4. to JESNR ?? 4. - this suppresses the
NOTE: and the Error condition when invalid data found,
and b) in both VMAC6 and VMAC26 change IF JESNR NE 0 to
IF JESNR GT 0 and c) insert new line in VMAC6 after the
line IF JESNR GT 0 THEN INPUT .. JESNR ?? 4. @; reading:
IF JESNR EQ . THEN INPUT @65+OFFSMF JESNR ?? PD4. @;
The site had made its own mods to JES mods before IBM!
Now MXG is robust enough to support this mod.
Thanks to Robert Manalo, EDS, USA.
Change 07.203 Change 7.061 was not applied to XMAC74 (which is only
XMAC74 used to circumvent a SAS limitation in large shops),
Dec 20, 1989 causing AVGPNCHA, AVGPNCUB and AVGPNDEV to be seconds
instead of milliseconds. Applied the changed.
Thanks to Bruce Widlund, Texas Utilities, USA.
Change 07.202 Prerelease-only correction. VMAC6 corrections to handle
VMAC6 the SYSOUT release time (Change 7.137, added in MXG 7.1)
Dec 19, 1989 did not handle JES3 print record variables DATAERR,
OUTPRTY, SUPGROUP correctly, and could cause STOPOVER.
The INPUT statement after SUBSYS='JES3' OR SUBSYS='SAR'
should not have the offsets (OFFTONXT, OFFTONXT+nn).
Remove the offset from before variables DATAERR, OUTPRTY
SUPGROUP, SMF6RVSJ, and SMF6RSVU.
Thanks to MP Welch, Sisters of Charity of the Incarnate Word, USA.
Change 07.201 Variable SUBSYS6 has been created, equal to SUBSYS, to
IMACPDB identify the Subsystem (JES2,JES3,EXTW,PSF,SAR,EXD,CADI)
VMAC6 which created the print record. While SUBSYS already is
Dec 19, 1989 in TYPE6, BUILDPDB already uses SUBSYS from the TYPE30_4
(probably not a wise choice now!) Rather than changing a
meaning of an existing variable, adding SUBSYS6 here and
in IMACPDB (to the _PDB6 macro list of kept variables)
avoids a compatibility exposure. Why do you need SUBSYS?
Some sites want to recover CPU time spent by printing
subsystems (read PSF) by surcharging that subsystem's
PRINT charges. Unfortunately, additional CPU time caused
by PSF has been shown to occur primarily when a non-PSF
data stream is converted, and it is not possible to know
if data-stream-conversion occurred from a type 6 record.
record. (Call XEROX at 213-333-2068 for a free copy of
publication number 720P60340 "Benchmark Report JES2 vs
PSF in Text Oriented Printing" by Tom Bell and Chuck
Hopf. IBM should capture the CPU time for print events
and store it in the type 6, or at least a flag bit should
be set if PSF did convert the data stream. One comparison
shows if PSF takes 7 CPU seconds for Line Mode JES2 Dump
convert and print, a JES2 controlled 3800 Model 3 in Mod
1 emulation mode would take 1 sec. But conversion cost
may be only half the cost. A DCF prepared PSF data
stream of same size took 3 seconds. Sustained print rates
of 200 pages per minute are seen feasible for 3800 Model
3. The type 6 record does record PAGEDEFS FORMDEFS
FONT.... activity for PSF; nonzero counts here does
guarantee only that those PSF functions were invoked.
Change 07.200 NETSPY Release 3.2 added fields to the LU and APPL data
VMACNSPY sets, and is now supported.
Dec 15, 1989
Thanks to David W. Anderson, Chase Lincoln First Bank, USA.
Change 07.199 TPX Version 2 causes STOPOVER because the length of the
VMACTPX subtype 5 is incorrect. Their fix number TGB308A fixes
Dec 12, 1989 their problem. MXG failed to recognize the redefinition
of TPXM1SP0 over its two preceding fields (TPXPESIZ &
TPXPECD8) in a subtype 1 record, also causing STOPOVER.
This is corrected by inserting a new statement M4=-4;
after the @; after TPXMSMRT $CHAR8. and before the IF,
and then putting +M4 just before (TPXM1SP0-TPXM1SP9
Thanks to Larry Doub, RJR, USA.
Change 07.198 Goal Systems PDSMAN/XP Release 6 added five new fields
VMACPDSM (incompatibly, in the middle of the existing data!) which
Dec 12, 1989 are now supported by this change. LGJOB, LGMGEN, LGLMM,
LGNMM and LGRMGEN were added.
Thanks to Lesley Woolston, Manufacturers Hanover, ENGLAND.
Change 07.197 MVS/ESA 3.1.3 added numerous new data fields to SMF data.
EXTY42AU 1.TYPE6 data now identifies the Step which caused the print
EXTY42CU activity, and added security related information in these
EXTY42SC new PRINT variables:
EXTY42TO BIN1USED BIN2USED BIN3USED BIN4USED DIASLIG DIADPLWS
EXTY42VL DIAJHWP DIAUPAWS DPAGELBL ERROVRUN ERRSECOV INTEGRTY
EXTY83 PRSUCCES SMF6NSOL SMF6NSFO SMF6NPS SMF6FDNM SMF6PDNM
IMACPDB SMF6PTDV SMF6STNM SMF6PRNM SMF6DDNM SMF6USID SMF6SECS
TYPE42 SPAGELBL STDUPLEX SYSAREA TMBUPLEX
TYPE83 The variables SMF6STNM (stepname), SMF6PRNM (procstep)
VMAC6 and SMF6DDNM (ddname of print file) have been added
VMAC1415 to the default list of TYPE6 variables that will be
VMAC42 automatically carried into PDB.PRINT in MXG's BUILDPDB.
VMAC80 2.TYPE1415 data variables PDSE, TRUNC, and NULLSEG added,
VMAC83 and several fields documented as zero if PDSE-managed
VMAC90 (BLKCNT, TTRN, UCBSTAB, DSSEQCNT, DSSEQNR). The EXCPCNT
Dec 11, 1989 variable for PDSE-managed datasets counts pages read or
written. Before MVS 3.1.1, PDSE was referred to ILIB.
3.TYPE80 additional bit added to $MG080AU for BYPASS, new
character variable RACFVRMN (version, release, mod level)
replaces numeric RACFVERS, and new RACFTOSK (security
label) added by RACF 1.9.0.
4.New type 42 SMF DFP 3.2 record provides SMS statistics
configuration, and audits changes in five data sets
built from this record. Interval buffer statistics for
3990 cache controlers (total and by storage class) are
in TYPE42TO and TYPE42SC. Control Unit configuration and
delta statistics are in TYPE42CU (and SMS managed volumes
behind that control unit are in TYPE42VL). TYPE42AU
audits operator VARY SMS commands, ACTIVATEs in ISMF
or SETSMS, or ENF occurred because operator issued a
vary command to an SMS-managed volume. This is a new,
and significant source of information for management of
System Managed Storage, as well as 3990 statistics.
4.New type 83 SMF RACF Audit Record (For RACF Datasets
whose security label was changed by ADDSD, ALTDSD,
or DELDSD) is now supported in MXG dataset TYPE83.
5.Two new SMF options were introduced in MVS/ESA 3.1.3 that
allow the installation to never loose SMF data. LASTDS
and NOBUFFS can specify MSG (console message and continue
processing with loss of SMF data) or HALT (puts MVS in a
restartable wait state) whenever either no buffers or no
SMF data set is available to SMF. These options are now
contained in MXG TYPE90 dataset.
Change 07.196 DB2 2.2.0 changed SMF 102 SMF values in 21,30,31,44,62,
FORMATS and 140 IFCIDs, affecting formats $MGD044D, $MGD062S,
IMAC102 $MGD062O, $MGD140P, and creating $MGD063O. IFCID'S 63 and
VMAC102 106 were changed incompatibly, although only 106 has new
Dec 9, 1989 variables. The new Distributed Header is decoded, and now
all header variables are output in T102S106. Twelve new
IFCIDs (with many new variables) were added by DB2 2.2.0,
and these IFCIDS (plus the seven DB2 2.1 IFCIDS that had
not been previously decoded) are now supported by MXG.
With this change, ALL data produced by DB2 is now thought
to be supported by MXG. (There may be additional formats
added to MXG for a few of these new variables). The list
of IFCIDs within class has been updated in IMAC102. There
are also eight new "trace class" macro definitions that
are necessary in MXG (but only until SAS Version 6.06 is
universally available; the MXG use of the _DB2TCn macros
is necessary only because of an internal SAS limit on the
number of iterative DO statements, which has effectively
been eliminated in SAS Version 6.06). A later change will
be made to ANALDB2R to provide reports on these new DB2
DB2 elements. Initially, though, the changes primarily
support Distributed Data Facility, and the addition of
the Monitor Class data records (which contain the same
data already available in the DB2ACCT & DB2STAT datasets
from the 100/102 records!).
For the record, these new IFCIDs were added by this
change: TC1 (153), TC6 (156), TC7 (164,165,166,167),
TC8 (125,168), new TC14 (67), new TC15 (154), new TC16
(157,158,159,160,161,162,163), new Monitor Class MC1
(124,147,148,149,150), new MC4 (155), new AC7 (169),
new AC9 (146), new Accounting Class ACT4 (151), and a
new Statistics Class ST2 (152)! Whew!
Summary of this change: many hours to decode many record
segments which are unlikely ever to be needed by any
rational performance analyst!!!!!!!
Change 07.195 MXG assigned COMNDTYP of blank for command from a CCB,
FORMATS but blank is a CLIST from an FCB. This is corrected by:
VMACTSOM Add '40'X to $MGTSOCD format in FORMATS
Dec 7, 1989 Insert after 033700: RETAIN COMNDTYP ' ';
Insert after 042200: COMNDTYP='00'X;
Delete 042800.
Variable COMND may contain an 8-byte name or a 2-byte
command abbreviation padded with nulls instead of blanks,
which makes testing difficult. The translate function is
now used to convert nulls to blanks. In addition, the
date part of ENDTIME is wrong if the interval crossed
midnight. Correct by insert after line 037000:
IF TIMEPART(SMFTIME) LT STRTTIME THEN
ENDTIME=ENDTIME-86400;
Thanks to Pete Shepard, Ashland Oil, USA.
Thanks to Steve Cavill, SAS Institute, AUSTRALIA.
Change 07.194 ACF2 variables ACTMFCBT (buffer text) and ACTMFKEY
VMACACF2 (record key) were not labeled and not kept, but now they
Dec 7, 1989 are.
Thanks to Ken Williams, ANZ Bank, AUSTRALIA.
Thanks to Raymond Wallace, NRMA, AUSTRALIA.
Change 07.193 Support for DB2 Version 2 Release 2 has been added for
VMACDB2 the DB2ACCT, DB2STAT0, and DB2STAT1 data sets built from
Dec 6, 1989 SMF type 100 and 101 records. IBM changes appear to be
compatible. DB2 2.2 added five QX..... variables for the
MIAP (Multiple Index Access Path) and Create/Drop Alias,
and 21 QLAC.... variables for DDF (Distributed Data
Facility) accounting to DB2ACCT. DB2STAT0 was also
enhanced with 18 QLST.... variables identical to their
QLAC.... counterparts for DDF statistics, and new Q3ST
and Q9ST DDF counters. DB2STAT1 was enhanced with the
same five QX..... variables for MIAP and QTAUCCH. Note
that DDF elapsed and CPU times are captured only in the
DB2ACCT data set (and not in DB2STAT0).
DB2ACCT variable DB2TCBTM is now calculated only if both
QWACBJST and QWACEJST are both non-zero, as IBM now does
document that zero value for either field means that no
CPU timing was available. An additional IBM note says
that QWACEJST is invalid for END OF MEMORY (RINV=24 or
28 decimal), QWACBSRB, QWACESRB, and QWACASRB are invalid
for DB Access Agents, but it is not clear how to identify
that situation. A final note in the PL/S DSECT says that
QWACEJST may be invalid when QWACRINV > 20 while the ASM
DSECT says it is invalid for EOM condition. I am still
checking with IBM:
IFCID 0003 (Type 101 SMF, DB2 Accounting record):
1. When "may" QWACEJST be invalid when QWACRINV > 20 ?
2. Is QWACRINV of 24 or 28 only values for EOM which
cause EJST to be invalid?
3. How does one know this record is for DB Access Agents?
4. When data is invalid, is it non-zero or zero?
5. What are units of QLACCPUL, QLACCPUR, and QLACDBAT?
Change 07.192 Continued validation of STX found the test in line 017500
VMACSTX should test for '02'X, '03'X (instead of '02X' and '03')!
Nov 24, 1989 and '12'X and '13'X should have been added, and corrected
labels for Application connect timestamps, swlu and lu.
Thanks to Larry Doub, RJR, USA.
Change 07.191 VM/SP Monitor channels 17-32 were not input due to bad
VMACVMON logic. Remove the ELSE in three lines 272000, 272400 and
Nov 24, 1989 272800.
Thanks to Bob Small, Grumman Data Systems, USA.
===========Prerelease 7.4 was for special ESP customer support=========
===========Changes thru Change 7.190 comprised Prerelease 7.3==========
Change 07.190 The DASDMON interval start date could be the wrong date.
ANALDMON The Start date in the record is not the interval start,
Nov 24, 1989 but rather the date when DASDMON initiated! The program
now uses the SMF record Date to correctly calculate the
interval start and end dates.
Thanks to Danny High, Blue Cross Blue Shield Texas, USA.
Change 07.189 The ASUMCICS trend program uses detail transaction data
ASUMCICS to create PDB.CICS with response distributions (pct in 2
ASUMDBDS sec) for reports and input to TRNDCICS. Now the program
Nov 24, 1989 will read either data source transparently; you no longer
have to remove comment blocks to use Landmark data.
The new ASUMDBDS program similarly sums the MONIDBDS
detail data into PDB.MONIDBD which matches PDB.CICS.
Thanks to Chuck Hopf, Hopf Consulting, USA.
Change 07.188 New DB2 Reports were added. I/O Reports (PMIOS01-05), the
ANALDB2R Locking Reports (PMLOK01-03), and Record Trace Reports
IMACDB2 (PMTRC01-01) are completed. The Correlation Name and
VMAC102 Correlation Number are decoded differently for IMS, CICS
NOv 25, 1989 and other by the new _DB2CORR macro defined in IMACDB2.
However, detection of IMS, CICS, etc. in IMACDB2 can be
based only on job name (unless you can find a better
test), and you may need to modify those names if you
are concerned with CORRNAME and CORRNUM values. New
DATASET and PAGESET selection was added for I/O reports.
Preparation of the Record Trace report uncovered several
obscure type 102 variables that were spelled wrong or
left out of the KEEP= list.
How much storage does MXG need for DB2 data sets?
A site with 10000 DB2 plans executed per day will need
122 tracks of 3380 DASD for storage of the DB2ACCT data
set, and the DB2STAT0/DB2STAT1 data sets will need 8
tracks each (at 15 minute intervals), for a total of
only 138 tracks (9 cyl, or only 6 megabytes per day!)
Thanks to Chuck Hopf, Hopf Consulting, USA.
Change 07.187 SAR variable SARSW should be @165 vice @164 and @164 is
XMACSAR GCRMODFT $CHAR1.
VMACROSC
Nov 24, 1989
Thanks to Dee Ramon, Mutual of America, USA.
Change 07.186 Reading SMF type 71 records and ROSCOE data directly from
VMAC71 VSAM SMF file needed help. Line 066400 in VMAC71 needed a
VMACROSC +OFFSMF at the end, and line 114600 in VMACROSC should
Nov 24, 1989 have tested for LENGTH > 428+OFFSMF .
Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
Change 07.185 Contributed report for MVS/XA and MVS/ESA I/O pathing
ANALPATH configuration and activity, using TYPE73, TYPE74, TYPE78
Nov 24, 1989 and TYPE78CF datasets from a PDB. Self-describing.
Thanks to Cindy Batson, Hewitt Associates, USA.
Thanks to Dan Kaberon, Hewitt Associates, USA.
Change 07.184 Logic expected subtype of zero, but non-zero value was
VMAC110 not protected. Now it is.
Nov 24, 1989
Change 07.183 SAS 5.18 accepted LENGTH DEFAULT=4 4; syntax, but Version
VMACVMXA 6.06 testing detected the incorrect syntax, which is now
Nov 21, 1989 corrected in line 456800.
Thanks to Dan Squillace, SAS Institute Cary, USA.
Change 07.182 Change 7.151 fixed IMS, but part of the change was not on
TYPEIMS MXG 7.2. The two PROC SORTs (lines 107610 to 107670) were
Nov 21, 1989 to have been deleted, but were not. NOT SORTED error.
Thanks to Lynn Delacourt, Volvo GM Heavy Truck Corporation, USA.
Change 07.181 Change 7.035 discussed potential problems if you tried to
IMAC30IO eliminate D3330DRV variable. This change eliminates that
IMACPDB variable from the default I/O KEEP= list (in IMAC30IO)
BUILDPDB and the MAX/MIN/SUM logic was redesigned (in IMACPDB).
BUILDPD3 If you have not modified either IMAC30IO or IMACPDB, this
Nov 21, 1989 change is not impacting. HOWEVER, if IMACPDB or IMAC30IO
have been changed by your site, YOU MUST retrofit your
tailoring, using the new members in this MXG Version.
I'm still working on a way to fix this once and for all
sites without impact. An additional change was made in
IMACPDB that should not be impacting. The NODUP option
is now always used in BUILDPDB, and the _NODUP macro is
no longer referenced in BUILDPDB/3. (For compatibility,
though, the macro is still defined in IMACPDB).
Thanks to Elliot Weitzman, Oryx Energy Company, USA.
Change 07.180 RMDS page counts for one class of data was stored as PD4.
TYPERMDS while all other counts were PIB4.! Change line 035600 to
Nov 21, 1989 PD4. from PIB4. There is no change in the SMF record for
RMDS Release 4.0, so we therefore now support RMDS 4.0!
(Documentation for the SMF record is in SC30-3442-1,
Installing and Customizing RMDS Release 4).
Thanks to Sim Fleisher, Depository Trust, USA.
Change 07.179 3390 DASD Devices are supported. EXCP3390 and IOTM3390
VMACEXC2 variables are created in TYPE30, PDB.STEPS and PDB.JOBS
VMACUCB data sets, and variable DEVICE (TYPE1415, TYPE74, etc.)
Nov 14, 1989 will recognize 3390. This change is in MXG 7.2.
Change 07.178 CICS UOWTIME is now set missing if there actually is not
VMAC110 a timestamp in UOWID. This is a further enhancement found
Nov 14, 1989 when verifying Change 7.170.
Change 07.177 Additional DB2 reporting has uncovered inconsistence in
VMAC102 variable names and some re-definitions of the same field
Nov 14, 1989 as two variables.
1.QW0021RP $CHAR8. is redefined over QW0021KD thru K2.
2.QW0044RP $CHAR8. is redefined over QW0044KD thru K2.
3.DBID and OBID variables were inconsistent. Most were
$CHAR2. formatted $HEX2. but some were PIB2. numerics.
Now all are $CHAR2., formatted $HEX4. and labels are
consistent. Note this affects the variables suffixed
with DB for DBID, but IBM uses PS and OB for PAGESET and
RECORD OBID, and also KP for PAGESET. This inconsistency
in different names for the same logical entity will not
be corrected in the MXG built T102Snnn datasets, but the
MXG MENU macro variable names used in reporting will be
DATABASE and PAGESET, no matter which IFCID variable name
contains the information.
Thanks to Chuck Hopf, Hopf Consulting, USA.
Change 07.176 GTF format DB2 Trace Data was still not quite correct,
VMAC102 even after Change 7.122. The GTF header inserts 12
Nov 14, 1989 bytes before the triplets but the offsets themselves are
relative to byte 1. MXG used OFFSMF=12 (set in _GTF) to
flag the difference, but failed to use it properly!
The logic at lines 085900 thru 08500 now reads:
IF OFFSMF=12 THEN DO;
INPUT @29 SM102SSI $CHAR4. @;
OFFPROD=QWT02PSO-3;
END:
ELSE OFFPROD=OFFSMF-3+QWT02PSO;
The reset IF OFFSMF=12 THEN OFFSMF=0 after the triplets
have been INPUT is still correct.
Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
Change 07.175 Support for STX Release 1.0+ has been coded and syntax
EXSTX... tested (no error first execution with SMF DD DUMMY!) but
IMACSTX real data has not been yet processed.
TYPESTX Five data sets (STXSTART, STXLOGON, STXLOGOF, STXCONON,
VMACSTX and STXCONOF are created.
Nov 11, 1989
Thanks to Larry Doub, RJR, USA.
Change 07.174 Support for Release 2.0.0 of TPX has been added to decode
VMACTPX the new format records as well as the prior releases. The
Nov 11, 1989 2.0.0 record is incompatible with prior TPX records, and
does require MXG 7.3. TPX 2.0.0 writes a wrong value for
length field MONO5LEN, (it's x28, but there are x30 bytes
in the segment based on MONO6LEN and MONO6ID) that MXG
detects and circumvents. New variables were added to the
TPXSTART, TPXAPLOF and TPXTRMOF datasets by TPX 2.0.0.
Thanks to ???, Swan Hunter Shipbuilders, ENGLAND.
Thanks to Larry Doub, RJR, USA
for excellent dumps and documentation.
Change 07.173 MXG VTOC processing had further validation:
VMXGVTOC a.Change 7.164 was misspelled. The Delete list should have
Nov 9, 1989 listed datasets EXTENT EXTENTS in place of EXTEND.
b.Line 128 example should be NEW=INFO vice NEW=MAP.
c.EQ MXTRACK should be EQ MXTRACK-1 in lines 649, 667.
d.LAST=MXTRACK should be LAST=MXTRACK-1 lines 652, 670.
e.VOLSER should be added to the KEEP= for INFO line 245.
f.Labels added for VTOCINFO new variables NTPC, DEVCYL,
DEVTRK, TOTRACKS, FCYL, FTRK, LCYL, and LTRK.
Thanks to Phil Henninge, Timken Company, USA.
Change 07.172 CA/DISPATCH variables are created in TYPE6 dataset by the
VMAC6 enablement of their decoding in MXG member IMACCADI. The
Nov 9, 1989 variable CADIRCIP was incorrectly spelled as CADIRCVR in
the KEEP= list in member VMAC6, causing CADIRCIP to not
exist.
A note on this MXG technique. SAS does not validate that
variables in a KEEP= list actually exist. If a variable
name appears only in the KEEP= list, that variable will
not be created. All of the CADI.... variables are in the
TYPE6 KEEP= list, but they will not exist in your TYPE6
dataset unless you modify IMACCADI, as all of the code
that creates the CADI variables (LABEL, FORMAT, INPUT)
is inside a comment block in IMACCADI. Removing that
comment block is all that is necessary to cause the
variables to be created AND kept. This technique works
for KEEP= list, but not for the KEEP statement; SAS does
validate the existence of all variables in KEEP statemen
Thanks to Carol Arnold, K-Mart Apparel, USA.
Change 07.171 CICS UOWTIME changes discussed in 7.170 are all true, but
TYPEMONI there was one other error (only in MXG's Landmark code)
Nov 6, 1989 that actually precipitated the discoverys in 7.171.
Line 060700 (ENDTIME=DHMS(ENDDATE,0,0,ENDTIME); must be
moved to new line 014710 (immediately before the line
BASETIME=FRSTBASE + FFFFF*(FLOOR(ENDTIME-FRST....
so that ENDTIME is converted into a datetimestamp first,
before it is used in the UOWTIME decode algorithm!
Thanks to Terry Baker, Royal Insurance, USA.
====FLASH 7.2 (accompanied 7.2 shipment starting in November, 1989)====
================printed Changes 7.170 to 7.162=========================
Change 07.170 CICS UOWTIME can be between 01JAN60 and 22JUL60, or can
TYPEMONI have right date and wrong time, or both may be wrong.
VMAC110 IBM stores times in two different non-unique formats:
Nov 3, 1989 - a 6-byte STCK value in sixteenths of a microsecond,
which wraps every 204 days and which therefore
requires logic to decide in which 204-day interval
since Jan 1, 1900 this UOWTIME occurred, or
- a 6-byte HHMMSS in EBCDIC characters.
Unfortunately, there is no sure way to identify which
format was used. HHMMSS only applies to DL/I batch
originators, but there is not yet an unambiguous test
to identify DL/I session. The 6-byte EBCDIC HHMMSS
field can contain hex F0F0F0F0F0F0x thru F2F3F5F9F5F9x,
all of which are also valid STCK values (on days 192 to
195 on the 204-day clock)! MXG always preserved the
value in UOWTIME, but its datetime value was sometimes
quite far off. Since NETSNAME and UOWTIME are used
to match up the TOR, AOR, and FOR transaction record
for an MRO event, and MXGs algorithm did support that
merge without error. MXG expected NETSNAME would end
with 12 nulls if not from DL/I, but actually NETSNAME
can contain when the originating terminal is
netname local terminal, from TCT
networkid.LUname VTAM ISC LUTYPE6.2 or IRC link
newtorkid.generic_applid non-VTAM or ISC LUTYPE6.1
jobname.stepname.procname DL/I batch session
and non-nulls caused MXG to fail to add BASETIME (real
start datetime of the present 204-day interval) to the
204-day value in UOWTIME. Then adding UOWTIME to the SAS
base date of 01JAN60 created the 1960 datetimes!
Further, MXG logic tested for a HHMMSS format first; a
real STCK value of 15:15:51 on day 192 of the 204-day
clock was changed to 00:00:00 HHMMSS!. Until DL/I can
be uniquely identified, MXG now always presumes the more
likely STCK format. At a specific site with knowledge of
specific newtworkid values in NETSNAME, one should be
able to recognize DL/I and convert back to HHMMSS, but
a generic solution is not obvious at present. UOWTIMEs
value itself may not be very important; as long as it is
constant across MRO regions, it serves its purpose.
In the interim, a quick circumvention happens to be to
change IF SUBSTR(NETSNAME,9,12)='0000...00'X THEN
to IF 1=1 THEN
to always cause the addition of BASETIME to UOWTIME and
to thereby bypass the ELSE DO logic testing for HHMMSS
or HH.MM.SS values at present. I hope it does turn out
that the actual UOWTIME value is useful enough for this!
Thanks to Terry Baker, Royal Insurance, USA.
Change 07.169 The length of variable CHARACTS needs to be 8 to keep the
VMACSYNC full resolution of total bytes sorted (just to make sure
Nov 2, 1989 comparisons are exact). With length 4, no significant
digits were lost, but low order truncation occurred.
Thanks to Glen Farmer, Hallmark Cards, USA.
Change 07.168 The format name MG080IA. was incorrectly spelled MG080AI.
ANALAUDT
Nov 2, 1989
Thanks to Richard Stevens, US Trust, USA.
Change 07.167 This utility which iteratively invokes VMXGVTOC to read
VMXGVTOR all online VTOCs used DO variable I in the outer loop but
Nov 2, 1989 changes to VMXGVTOC also used I. While VMXGVTOC was the
culprit, changing the "DO I=" in VMXGVTOR to "DO IVOR="
was simpler and safer.
Thanks to Don Wensel, Philip Morris, USA.
Change 07.166 Change 7.098 was correct in its text, but the spelling in
MONTHBLD the member should be DDNAME= instead of LIBNAME= in both
Nov 2, 1989 PROC DATASETS.
-----Changes thru Change 7.165 were published in NEWSLETTER FIFTEEN-----
Change 07.165 A comma was lost when re-writing comments in this example
EXITMONI JCL to create the TMON infile exit. Line 048500 needed a
Oct 30, 1989 comma at its end.
Change 07.164 MXG DASD VTOC processing did not clean up the WORK file
VMXGVTOC if multiple DASD Volumes are processed. After line 068200
Oct 30, 1989 insert:
PROC DATASETS DDNAME=WORK MT=DATA NOLIST;
DELETE VTOC1 DSNAMES EXTENT EXTENTS OKEXTENT;
MXG's 3090-200 CPU time to read 206 triple density 3380
DASD volumes is about 20 minutes per day.
Thanks to Phil Henninge, Timken Company, USA.
Change 07.163 TYPE71 variable EXTREADS (Pages Read from ESTORE) is only
VMAC71 valid if you have MVS/ESA (RMF 4.1+), but MXG created a
Oct 30, 1989 value even with RMF 3.5. Now it will be missing if you
are not yet on RMF 4.1+.
Thanks to George Scott, Rockwell International Corporation, USA.
Change 07.162 Format libraries in SAS Version 6.06 will be in a SAS
FORMATS data library, and must be created/referenced with the
Oct 21, 1989 DDNAME of LIBRARY, while SASLIB can still be used for
SAS Version 5.18 Format libraries (i.e., MXG.SASLIB).
This incompatibliity between SAS Version 5.18 and 6.06
will be disussed in Newsletter SIXTEEN. This change uses
the SAS Version under which MXG is executing to decide
if MXG Formats are to be created in the LIBRARY (6.06+)
or the SASLIB (5.18-) DDNAMES.
========Changes thru 7.161 comprised the pre=release of MXG 7.2=========
========Changes thru 7.161 comprised the pre=release of MXG 7.2=========
Change 07.161 This change is documentation of the procedures used in
Oct 19, 1989 the final testing of this prerelease of MXG 7.2.
It may help you in structuring validation of your own SAS
based systems, and will let you see MXG's test plan.
This process accomplishes these goals:
A. Syntax check and execution (no data actually read) of
all MXG code to build all possible MXG datasets.
B. Detection of conflicting definitions of same variable
in different MXG datasets (CHAR/NUM type, length and
format.
C. Detection of known coding errors, such as variables
without labels, DATETIME formatted variables with a
length other than 8, etc.
D. Automatic generation of DOCVER documentation of the
contents of all variables in all MXG 7.2 datasets.
E. Automatic generation of DOCVER07 delta-documentation
of all changes in contents between MXG Verion 6.6 and
this prerelease.
1.UTILXREF creates all possible MXG datasets and uses PROC
CONTENTS to create a SAS dataset of all variables in MXG
which is then analyzed for these known conditions:
-type conflicts (char and num in different datasets),
-missing label for variables,
-DATETIME formatted variable not length=8.
The SYSOUT is also examined for SAS ERROR: messages and
for UNINITIALIZED variable messages and any NOT CATLGD
JCL messages are located.
Change 07.160 Support for the ACF2 ARE data was added to the ACF2JR
VMACACF2 dataset created from the ACSMFREC='L' ACF2 SMF record.
Oct 19, 1989
Thanks to Raymond Wallace, NRMA, Sydney, AUSTRALIA.
Change 07.159 DB2 Trace dataset T102S063 contained only the first 200
IMAC102 bytes of the SQL text for each BIND, but the actual size
IMAC102A of the SQL text can be more than 200 characters. The SQL
IMAC102B text can be useful in understanding why a particular DB2
VMAC102 inquiry consumes large resources (DB2ACCT is used to find
Oct 19, 1989 the expensive executions, and their SQL inquiry text in
T102S063 is then examined to see why). Now, MXG will
create multiple observations in T102S063 for each 200
bytes of SQL text (new variable SEG10263 counts 200-byte
segment number).
Thanks to Robert Olah, Dun and Bradstreet, USA.
Change 07.158 This is not a change, but rather an observation that the
TYPEMONI byte-count on Landmark's own reports defaults to average
Oct 18, 1989 number of bytes per screen (PRIOUCHR/TCOUPRCN) but MXG
PRIOUCHR variable is total bytes for the transaction and
TCOUPRCN is the total number of screen. Landmark reports
will match MXG totals if "T" is added after the Landmark
field number on their report control statements.
Thanks to Tim Follen, Blue Cross of Ohio, USA.
Change 07.157 Preliminary support for Sterling Software's DMS/OS DASD
TYPEDMS management product's VTOC reading utility. Their utility
Oct 17, 1989 will read all VTOCs somewhat faster than MXG's VMXGVTOC
utility, and their utility's output is then used by this
member to create the DMSLIST dataset, similar to the
VTOCLIST dataset creatable by VMXGVTOC. However this
member does not create the VTOCMAP nor VTOCINFO datasets
created when MXG actually reads VTOCs with VMXGVTOC.
Thanks to Chuck Hopf, Hopf Consulting, USA.
Change 07.156 Trend Data Base implementation of MXG Tape Mount Monitor
ASUMTMNT datasets includes a daily TAPEMNTS dataset and also a
GRAFTMNT TREND.TAPEMNTS. GRAFTMNT builds graphics catalog TAPEMNTS
TRNDTMNT from data either in PDB or TREND database.
Oct 17, 1989
Thanks to Chuck Hopf, Hopf Consulting, USA.
Change 07.155 Variable TMNTMTPY in line 004900 should have been spelled
VMACTMNT TMNTMTYP. In MXG 7.1 Beta only.
Oct 17, 1989
Change 07.154 This change eliminates a compatibility exposure between
BUILDPDB MXG 6.6 and 7. The SPIN6 dataset built by MXG 6.6 may not
BUILDPD3 be in order expected by MXG 7 (it depends on whether the
Oct 17, 1989 site added PRENTIME to the BY list in BUILDPDB/3 in its
implementation of MXG 6.6). This change inserts a PROC
SORT of the SPIN6 dataset before combining it with the
new TYPE6 dataset to avoid the possibility of the "out
of sort order" condition.
Change 07.153 In what is believed to be the final revision for VTOC
VMXGVTOC measurement, VMXGVTOC was again INCOMPATIBLY changed.
Oct 16, 1989 Previous users will need to change their reporting.
The MXG VTOC-reading facility now creates three datasets:
VTOCLIST - one obs per dataset, tracks allocated, tracks
used, creation, expiration dates, etc. This
was previously named VMXGVTOC.
VTOCMAP - one obs per extent/free space. A map of the
DASD volume. Previously named VMXGFREE.
VTOCINFO - one obs per volume, from the DSCB4. Size of
the volume, and VTOC flags such as Indexed
VTOC, Available DSCB0s, Available tracks,
System Managed Storage status, etc. New.
The description of this VTOC facility for DASD space
management and accounting is contained in extensive
comments at the beginning of the member itself.
Thanks to Don Wensel, Philip Morris, USA.
Change 07.152 IMS log processing variable MSGLEN (message length) may
VMACIMS be wrong. The LOC=MSGPRFLL in MXG 6.6 was changed in
Oct 16, 1989 MXG 7.0 to LOC=MSGPRFLL+1 to locate where MSGLEN is to
be INPUTed. It appears this change in 7.0 was wrong and
the MXG 6.6 logic is restored. Please look at the value
of variable MSGLEN for message size of a known IMS tran
and confirm if this LOC= logic is correct for your site.
Thanks to Pete Shepard, Ashland Oil, USA.
Change 07.151 IMS log processing logic which merges datasets PRG and
TYPEIMS INOUT was incorrectly changed in MXG 7.0. The PROC SORTs
Oct 16, 1989 of PRG and INOUT just before the MERGE (lines 107610 to
107670) were deleted, and the BY variable of TRANSACT
for the merge was changed to the original DTOKEN. This
merge was more robust than the initial 7.0 change. All
other logic changes in 7.0 appear to be correct. A nit
was also noted: the format for ARRVTIME should be 19.2
for consistency with other DATETIME formats.
Thanks to Pete Shepard, Ashland Oil, USA.
Change 07.150 -EXPLORE/VM variable SERIAL should be input as $CHAR4.
TYPEVMXP and formatted as $HEX8. in member VMACVMXP.
VMACVMXP -The %INCLUDE SOURCLIB(IMACVMXP) in member VMACVMXP
Oct 16, 1989 was moved to member TYPEVMXP.
Thanks to Pete Shepard, Ashland Oil, USA.
Change 07.149 Variable OTH0CPU was not in the KEEP= list for dataset
GRAFTRND ALLCPU.
Oct 16, 1989
Thanks to Pete Shepard, Ashland Oil, USA.
Change 07.148 VM/XA Monitor dataset VXIODDEV variables AVGCONMS,
VMACVMXA AVGDISMS and AVGPNDMS are 1000 times to large. The 1000*
Oct 12, 1989 in lines 686900-687100 was removed. This dataset is not
typically kept, and all three values are correct in the
VXDEVDET, VXDEVTOT, VXSUMIOD datasets that are used in
MXG VM/XA report examples (because these averages were
recalculated correctly in building those datasets).
Thanks to Jeff Goodfellow, GTE Services, USA.
Change 07.147 Numerous discoveries during testing 7.1 Beta DB2 reports.
ANALDB2R All but subpart 4 apply only to ANALDB2R reporting and
VMACDB2 only to the STATISTICS reports.
Oct 12, 1989
-All QSDCKPT changed to QWSDCKPT.
-Second WRITE OUTPUT LOG BUFFERS lines 945200-945300 are
replaced by semicolon and line 944600 should be QJSTBFWR.
-After DB2 COMMANDS, lines containing @ 85 PUOR 'N/A'
should contain only @85 'N/A'.
-The Buffer Pool variables DB2ACCT QBnC... and DB2STAT1
QBnT... (where n is 1, 2, 3, 4) now correctly contain the
data corresponding with buffer pool id values 0, 1, 2, 80
for BP0, BP1, BP2, and BP32. Previously, n=1 variables
contained whatever BP was in the first segment. No data
was lost, but now the variable name n=1 to 4 does match
the contents correctly. (This was the VMACDB2 part).
The Buffer Pool reporting now uses a DO loop instead of
repetitive code, and only prints reports for pools with
activity. (This was the ANALDB2R part).
-QWHSSTCK (time stamp) in the DB2STAT1 dataset might not
be exactly the same ast QWHSSTCK in the DB2STAT0 dataset,
but DB2 reporting requires MERGE of those separate data.
Now, QWHSSTCK will be retained from subtype 0 to subtype
1 of the DB2 Type 100 SMF record so that the MERGE will
not fail. This change also compares the STCK value in a
subtype 1 with the previously retained STCK from the 0,
and PUTs error if out of sequence data is encountered.
-Variables QISEPAGE, QISECTS, QISEFREE, QISESKCT, QTDSOPN,
QISEDBD, QB1TCBA, QB2TCBA, QB3TCBA and QB4TCBA values are
end-of-interval values, but MXG summed their values. Now,
the MXG summarization calculates the average value of the
end-of interval data values for the interval.
-CORRNMBR and CORRNUM were redundantly named, and were not
parsed correctly for IMS connections. Now, CORRNUM is the
only variable used in ANALDB2R, and the values of the
QWHCCN (=:IMS,=:CICS, all else) is used to decide how to
parse CORRNAME and CORRNUM from QWHCCV.
-Second occurrence of DATABASE SERVICES in summary CPU
report (QJS3 variables) are actually for the IRLM, and
now the heading is correct.
-Macro variables were defined both in the ANALDB2R macro
definition, and in the macros called by ANALDB2R. This
redundant code added unnecessary lines and required care
in making redundant changes. Now, all macro variables are
defined only in the ANALDB2R definition and are no longer
explicitly defined in the actual report macro.
-QJST.... variables IDEN,CTHD,SIGN,TERM,ABRT,PREP,COMM,
INDT,RIUR,SYNC,CTHW should have been Q3ST in ANALDB2R.
Thanks to Jan van Lent, Fokker, NETHERLANDS.
Change 07.146 Variables QBnTPFDC, QBnTWKPD, QBnTWMAX, added by Change
DIFFDB2 7.130 to DB2STAT1 dataset were not deaccumulated. Now the
Oct 12, 1989 dozen variables are DIF()'d. Only MXG 7.1 Beta.
Thanks to Robert Olah, Dun and Bradstreet, USA.
Change 07.145 Line 942200 should be ARCHIVE LOG instead of ACTIVE LOG,
ANALDB2R Line 459300 NODUPKEY (PC syntax) should be NODUP for the
Oct 12, 1989 mainframe syntax. Only MXG 7.1 Beta.
Thanks to Pete Galaveri, Readers Digest, USA.
Change 07.144 Change 7.137 new line 012301 mistyped SMF6LN1 as SMFLN1,
VMAC6 causing "UNINITIALIZED" message and missing values. This
Oct 12, 1989 only affected the 7.1 Beta code.
Thanks to Chuck Hopf, Hopf Consulting, USA.
Change 07.143 Line inserted by Change 7.008 after line 23610 did not
BUILDPDB agree with Change. Line 023610 should be IF LAST.JESNR as
Oct 12, 1989 stated in the Change, replacing FIRST.JPURTIME in code.
Thanks to Debby Blackey, Marshalls, USA.
Change 07.142 PR/SM environment TYPE70 CPUWAITM and PCTCPUBY were wrong
VMAC7072 if the number of logical processors was greater than the
Oct 11, 1989 number of real processors. An MVS 3090-400 was given six
logical processors by PR/SM. The type 70 record shows MVS
NRCPUS is four, shows CPUs1-4 are online (CAI1-CAI4 are
'01'B, online-for-entire-interval), shows CPUSER1-CPUSER4
with the real serial numbers, and shows other CAIn and
CPUSERn values are blank. For the PARTISHN in which this
MXG is executing, there are six Logical Processor Data
Sections, creating six TYPE70PR observations, but the
only four that have non-zero LCPUPDTM PR/SM Dispatch also
have LCPUADDR values 1-4 matching the online CAIn values!
MXG correctly calculated individual CPU percent busy and
CPU wait in PCTCPBY0-8 and CPUWAIT0-8 variables using the
duration minus dispatch DURATM-LCPUPDTM, but MXG did not
correctly calculate CPUWAITM and PCTCPUBY in TYPE70 when
6 PR/SM Logical Processors are assigned to a 4-CPU MVS!
MXG summed wait time for all 6 LPARS, causing actual CPU
busy to be much lower than accurate. This change precedes
each of the nine CPUWAIT=CPUWAIT+CPUWAITM; statements in
lines 141300 to 146800 (logic for SHARED, WAIT=NO) with
IF CAIn EQ '......01'B THEN CPUWAIT=CPUWAIT+CPUWAITM;
and then changed n in CAIn to 0 thru 8 respectively.
IBM RMF reporting was also wrong with this data. Their
RMF Summary Report CPU BUSY reported an average 54% busy
(they used CPU0-3) instead of the true 65% busy from CPU
1-4 values. The CPU ACTIVITY report was also wrong with
CPU1s printed value taken from CPU0 (of 0%) and with the
2-4 CPU values taken incorrectly from CPU1-3 fields to
incorrectly report 61.4% busy when 78.5% was correct.
Thanks to O. V. Hanger, A. C. Nielsen Co., USA.
Thanks to Tim Klevar, General Electric Plastics, USA.
Change 07.141 Change 7.070 (only in MXG 7.0 BETA) was incorrect. The
ANALDSET lines of code after DATA DSETOPEN.DSETOPEN; from "IF" to
Oct 11, 1989 "DROP" must be moved to after TYPETASK=TYPETASZ;
Thanks to Debby Blackey, Marshalls, USA.
========Changes thru 7.140 were on the 7.1 Beta Tape===================
Change 07.140 IBM's Cache DASD RMF Reporter created SMF records do not
VMACACHE agree with documentation. GSLEN is 40, but the SD1IDCU is
Sep 14, 1989 in SD2ID instead of SD1ID. I am still researching when
this change occurred (this user is at CRR 1.3). The fix
is at line 028200-28300: change SD1ID=SD1IDCU to
(SD1ID=SD1IDCU OR SD2ID=SD1IDCU)
Thanks to Tom Healy, Chemnet, USA.
Change 07.139 SYNCSORT SMF record SIRECFM/SORECFM were decoded wrong,
VMACSYNC because SIRFM and SORFM were input as PIB1. but they are
Sep 14, 1989 actually EBCDIC numerics and should have been inputted
as 1. instead of PIB1. The CPUTCBTM in the SYNCSORT
record is sometimes wrong; values of 15 hrs 32 minutes
have been found by two different sites on SYNCSORT 3.2
and 3.3 (one site found one record per day, the second
found 50 such records in a month's SMF data). SYNCSORT
says this can happen if a SORT EXIT routine issues the
STIMER macro, but one site thinks the problem still
exists even when exits were not used. Still open.
Thanks to Sam Sheinfeld, Kraft General Foods, USA.
Thanks to Russ Berlin, Time-Life, USA.
Thanks to Sal Fazzino, General Electric Capital, USA.
who reported this first, but who was not listed in Newsletter 15!
Change 07.138 This user contribution creates a SAS Function, FMXGSID,
FMXGSID which can be invoked from a SAS program and returns the
Sep 13, 1989 character variable of the SMF System Id (SMCASID, MXG's
variable SYSTEM) on which the job executed. This was
used to add SYSTEM to MXG VTOC datasets.
Thanks to Gerald Baxter, British Telecom (Red Lion Square), ENGLAND.
Change 07.137 This two-line JES2 system modification stores in a batch
ASMsysmod job's SMF type 6 record the time that that print file was
VMAC6 released to print. This permits direct measurement of the
Sep 18, 1989 printer queue duration for help print jobs. The mod was
originally coded by Carol Toll, Sun Company, and then it
was re-designed by Dean Tesar of Hewitt, who reduced it
to the following system modification:
In macro IFASMFR
after field SMF6RET
and before field SMF6END2.
add new line:
SMF6JTME DS BL4 JOE CREATE TIME
In source HASPPRPU (near label PPSMFBLD)
after MVC SMF6OWC,JOECURCL-JOE(R2)
and just before USING DCT,R2
add new line:
MVC SMF6JTME,JOECRTME-JOE(R2)
As with all system modifications, you accept liability
for all testing and validation of this enhancement to
your SMF data records. VMAC6 was modified to use the
type 6 length fields and will create RLSETIME if it
exists in your type 6 record.
Thanks to Dan Kaberon, Hewitt Associates, USA.
Change 07.136 Variables CPUSER0-CPUSER9, CPU Serial Number from TYPE70,
RMFINTRV have been added to RMFINTRV, as they may be useful to
Sep 13, 1989 know which operating system was on which hardware when.
Thanks to Dave Clarke, British Airways, ENGLAND.
Change 07.135 NETSPY Versions earlier than 3.1 miscounted transactions
VMACNSPY because missing value of character variable (hex 40) just
Sep 13, 1989 happened to be the bit that 3.1 started using. Insert a
new line 038010 ELSE X2='00'X;
in case your NETSPY is an old version.
Thanks to Maria Clarke, Telecom Australia, AUSTRALIA.
Change 07.134 NETVIEW NPM Type 28 record subtype 41x (DRN Command, in
VMAC28 MXG dataset NPMCMDNC) are not structured as documented by
Sep 13, 1989 IBM. There is no TOF segment, and the AOF pointers point
to a PMC segment! This required relocation of the tests
for NPMSUBTY EQ 41X, and copying the present PMC handler
to before AOFTYPE='SAA' processing, and changing TOF to
AOF in that new PMC handler.
Thanks to Anthony P. Lobley, EDS, ENGLAND.
Change 07.133 IDMS 10.2 Monitor dataset IDMSTAS variables TASBFLD1-3
VMACIDMS should have been TASUFLD. The Batch Account Codes will be
Sep 13, 1989 decoded in the next MXG. See unfinished changes, above.
Thanks to Dick Whiting, Precision Castparts, USA.
Change 07.132 The new 3480-IDRC "Improved Data Recording Capability"
VMAC1415 mode should be decodable from TYPE1415 variable TRTCH.
Sep 13, 1989 This change creates a new variable IDRC='Y' or 'N' for
tape data sets to indicate if IDRC was in effect. This
has not been verified. The new logic is:
IF TRTCH=08X THEN IDRC='Y';
ELSE IF TRTCH=04X THEN IDRC='N';
Thanks to Gene Tolini, IBM Vendor Support, USA.
Change 07.131 NETVIEW "Pseudo-SMF" records can be written to a journal
TYPE39J log file instead of SMF. These pseudo-SMF records do not
VMACSMF have legitimate VBS architecture, and do not have the
Sep 13, 1989 data in the standard SMF header (MVSXA, SMFTIME, SYSTEM).
This change adds a new macro named _NETVLOG which is used
in TYPE39J (J for Journal Log) in place of the _SMF macro
normally used. For a quick fix, make a copy of _SMF macro
and name it _NETVLOG. Therein, 1) Change RECFM on the
INFILE statement from VBS to U, and add BLKSIZE=32760.
2) Insert just before the INPUT statement a new line:
OFFSMF=4;
to align the rest of the record with normal SMF format.
3) Create TYPE39J from TYPE39, but replace _SMF with
_NETVLOG.
The actual fix is more extensive, as unnecessary code in
SMF was removed. Better still, put NETVIEW data in SMF!
Thanks to Gary Korkowski, The St. Paul Companies, USA.
Change 07.130 The DB2 DSECTS for DB2 Dated 11/17/88, which were used to
VMACDB2 add support for DB2 Version 2.1 (and which were supplied
Sep 13, 1989 by IBM) have been changed! There were three additional
fields in the buffer manager statistics (DB2STAT1) which
MXG did not know about, and which caused subsequent data
about buffers to be wrong. MXG added three new variables
QBnTPFDC, QBnTWKPD, and QBnTWMAX (where "n" is 1 thru 4,
for each of the four buffer pools), by adding logic for
LENBUFM GE 116, just like the LENBUFM GE 104 logic took
care of the last IBM change. The support for DB2 2.2
will add protection (with +SKIP logic) to eliminate this
exposure in the future.
Thanks to Robert Olah, Dun and Bradstreet, USA.
Change 07.129 Additional summarization routines for the DOS/VSE POWER
ASUMDOS and VM/370 Monitor data, a daily sample job for DOS/VSE
ASUMVDEV CICS journal and VM/Monitor processing, upgrading of the
ASUMVMON GRAF.... members to use PROC PLOT instead of PROC GPLOT
ASUMVMON if you do not have SAS/GRAF, additonal REXX examples for
DALY110J MXG under CMS version of SAS, Trending for DOS POWER, VM
DALYVMON Device data and VM/370 Monitor. These are preliminary
GRAFREGR examples and are subject to change.
GRAFTRND
GRAFVMON
REXXDALZ
REXXDOS
REXXWKLY
TRNDDOS
TRNDVDEV
TRNDVMON
WKLYVMON
Sep 12, 1989
Thanks to Chuck Hopf, Hopf Consulting, USA.
Change 07.128 The validation of 7.0 Beta uncovered many opportunities:
FORMATS 1.VMACVMON, line 256000 set LENDV2=2 for RELEASVM EQ '05'.
VMACIDMS 2.TYPERTEJ, added MISSOVER on INFILE statement because IDMS
VMACRTE 10.1 writes short records.
VMACVMON 3.VMACRTE (IDMS 10.1 only) line 1301 added colon to now
TYPERTEJ read DBKFILE : $CHAR16. to protect for occasional short
Sep 12, 1989 IDMS record.
4.VMACIDMS: all PIB4.4 inputted variables are now formatted
TIME14.4 (180+ variables!). Variable SMFHDCVN was labeled
'DC SYSTEM*VERSION*NUMBER' and added to all KEEP= lists.
INSTIMSY and INSTIMUS changed from PIB4. to PIB4.4 and
added to TIME14.4 format list. DELTATM formatted TIME12.2
and variables PGMTYPE, TASPTYPE, TASTTYPE are now format
$MGIDMPP., $MGRTEPT., and $MGIDMTT. respectively.
5.FORMATS: values 6420 and 0A420 added to $MGVM6TY with
formatted value of 3380. (Appeared in VM HPO 5.0). New
formats $MGIDMPP and $MGIDMTT added.
Thanks to Dick Whiting, Precision Castparts, USA.
Change 07.127 The validation of 7.0 Beta DB2 processing uncovered more
VMACDB2 cleanup. Labels for QWHCOPID and QXSETSQL were corrected,
Sep 11, 1989 the order in which QWHCOPID and QWHCPREV are INPUT was
reversed, DB2ACCT CPU times are now validated and set to
missing if Begin is greater than End, or if the End time
is missing (see INFO/MVS E321145), and the second INPUT
of QTXANPL was deleted, correcting subsequent QTXA....
Thanks to Stan Majka, Virginia Power, USA.
Change 07.126 The 7.0 Beta changes to the Audit report from RACF TYPE80
ANALAUDT had minor glitches. Line 168 should be OUTPUT SUF and not
Sep 11, 1989 INSUF, and lines 77-79 were replicated and INSUF changed
to SUF (to create SUF with same variables as INSUF).
Thanks to Raymond Zieverink, Belk Stores Services, USA.
Change 07.125 This major contribution supports the ARBITER product from
ANALARB Tangram Systems which creates eleven different SMF record
EXARB... types with a total of thirty datasets created from the
IMACARB many subtypes.
TYPEARB
EXARBamm
Sep 10, 1989
Thanks to J-P Tonnieau, GMF System Team SARAN, FRANCE.
Change 07.124 MVS/370 CACHE DASD analysis report was updated for XA &
ANALCACH MVS/ESA. (MVS/370 TYPE74 variables LCHAN and DEVBUSY are
Sep 10, 1989 logically LCU and PCTDVUSE in MVS/XA and MVS/ESA). You
you still have to tailor this report as described in the
comments therein. The report combines RMF TYPE74 device
statistics with RMF Cache DASD Reporter TYPECACH data.
Thanks to Bruce L. Green, Medical Information Bureau, USA.
Change 07.123 DB2 APAR PL29461 PTF UL34399 added new data to a segment
FORMATS of the IFCID 0001 (Subtype 0, Type 100 SMF record) which
VMACDB2 MXG did not compatibly handle ("+SKIP" logic was missing
VMAC102 for this particular data segment in MXG code). This made
Sep 8, 1989 CPU variables for the 2nd and 3rd Address Space to be
wrong: QWS2PROC,EJST,SRBT and QWS3PROC,EJST,SRBT, and the
sum of all 3 address spaces cpu, CPUTM, when the above
PTF is installed on your DB2 Version 2.1 Systems. The PTF
new variables QWSnASID and QWSnASCB, the ASID and ASCB
respectively, are now added to the DB2STAT0 dataset, new
values for format MGD140P in member FORMATS were added,
and labels for trace variables QW0083QD,QW0087QD,QW0140SC
and QW140TC were changed based on IBM comment changes.
Only the change to member VMACDB2 is critical: You must
make the following change in member VMACDB2 if you have
the above PTF installed on any of your DB2 systems:
Find the line:
IF 0 LT OFFASID LT LENGTH AND NRASID GT 0 THEN DO;
Insert a new line following that line, containing:
SKIP=LENASID-20;
Find the next three occurrences of a line containing only
"@;". Insert the following new line after each of these
"trailing at-signs" (only three times, not four):
IF SKIP GT 0 THEN INPUT +SKIP @;
Thanks to Chun-Heng Liu, Brooklyn Union Gas, USA.
Change 07.122 DB2 trace records read from GTF (instead of SMF) do not
VMAC102 create observations because the reset was mislocated; in
Sep 8, 1989 addition, SMF102SSI was incorrect.
Find the present line:
IF OFFSMF=12 THEN OFFSMF=0;
Change that line so that it reads:
IF OFFSMF=12 THEN INPUT @29 SM102SSI $CHAR4. @;
Immediately before the present line containing:
OUTPUT SUBTYPES;
Insert this new line:
IF OFFSMF=12 THEN OFFSMF=0;
Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
Change 07.121 GRAFRMFI-produced graphs of RMF data gave funny-looking
GRAFRMFI graphs if your RMFINTRV dataset INTERVAL was less than
Sep 7, 1989 one hour. This change still produces plots versus hour,
but uses fractional values to plot between hours if
necessary. New line 009310 inserted
HOURPART=TIMEPART(STARTIME)/3600;
and change *HOUR= to *HOURPART in all occurrences.
Thanks to Joseph Ng Khek Uak, Port of Singapore Authority, SINGAPORE.
Change 07.120 Was accidentally skipped, and was never used.
Change 07.119 Boole & Babbage RMF replacement CMF product's SMF records
VMAC7072 can be created simultaneously with RMF records. This will
VMAC71 cause MXG datasets to contain essentially duplicate data
VMAC73 for the intervals when both monitors were running. This
VMAC74 change decodes the IBM reserved field at OFFRMFP+28 and
VMAC75 sets variable PRODUCT's value (normally "RMF") to either
VMAC76 "CMF-CPM" or "CMF-IPM", depending on the CMF mode that
VMAC77 created the record. This allows CMF and RMF records to
VMAC78 be separated, if both should exist. Since the variable
Sep 7, 1989 PRODUCT exists only in MVS/XA and later, this change does
not support identification of MVS/370 CMF from RMF data.
On the subject of CMF, though not related to this change,
CMF creates a PR/SM data segment in its type 70 record
under either IBM's PR/SM or Amdahl's MDF hardware. MXG
creates observations in TYPE70PR from the PR/SM segment.
(RMF users must use TYPEMDF, Change 7.087, to decode its
separate SMF record from Amdahl's MDFTRACK instead.)
Also, note there is no type 79 record created by CMF.
Thanks to Richard L. Gimarc, Boole & Babbage, USA.
Thanks to Allan Callahan, SAC Offutt AFB, USA.
Change 07.118 MXG DB2PM-like reporting has been further enhanced. All
ANALDB2R reports possible have been tested with DB2 Version 2.1
Sep 6, 1989 data (as well as prior DB2 versions). Additional reports
have been added, and all reports planned for MXG Version
7 have been named (even though some do not yet exist).
See member for revised documentation and details.
Change 07.117 DB2 Report PMACC01 values on **TOTAL** lines were totals
ANALDB2R of averages because wrong denominator was used in three
Sep 5, 1989 places. Insert three lines to correct:
line 07951000 FREQ=L2FREQ;
line 08411000 FREQ=L1FREQ;
line 08871000 FREQ=GFREQ;
Thanks to Alan W. Maloney, Telenet Communications, USA.
Change 07.116 A minor omission, &OTHER6 was left out in lines 019300 to
GRAFTRND 019600. 12="&OTHER6" inserted after 11=, and &OTHER7 to
Sep 5, 1989 &OTHER9 became 12 to 15, deleting the extra &OTHER9.
Thanks to Raymond Zieverink, Belk Stores Services, USA.
Change 07.115 ACF2 data sets ACF2NRA & ACF2NRB contain 0 observations.
VMACACF2 ACF2 SMF record subtype 'A' has JOB name of hex zero.
Sep 5, 1989 MXG includes IMACJBCK (an MXG macro which allows for JOB
name selection during creation of MXG data sets) BEFORE
checking the record subtype, which caused all ACF2 'A'
records to be deleted. Line 0345's %INCLUDE was moved to
after 0365 and executed within a do group:
IF ACSMFREC NE 'A' THEN DO;
%%INCLUDE SOURCLIB(IMACJBCK);
END;
Additionally, line 0376 (ACFAPMLN) should be PIB2. vice
PIB1., and line 0379 AFCAPARM should be spelled ACFAPARM.
Finally, ACFACID is formatted as $HEX2. (in line 0328).
Thanks to Raymond Wallace, NRMA, AUSTRALIA.
Thanks to Bill Gibson, SAS Institute, AUSTRALIA.
Change 07.114 VMAC7072 PR/SM variables were wrong (only) when SMF data
VMAC7072 was read from the VSAM SMF file. Line 132700 should read:
Sep 5, 1989 LOCPRDS=OFFPRDS+BDNSKIP*LENPRDS-3+OFFSMF;
Additionally, SMFTIME was not kept in TYPE72MN, and
ZDATE was not kept in TYPE72MN or TYPE70PR datasets.
Thanks to Barry Pieper, First Bank System Information Services, USA.
Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 07.113 RMF Monitor III VSAM data set support validation found a
VMACZRB few changes. In VMACZRB, field GEISIZ is now spelled as
ZRBJCL GEISIZE. The lengths (see inital comments in VMACZRB) of
Sep 5, 1989 ASISIZE was changed from 84 to 88, and of GEISIZE was
changed from 92 to 96 by RMF 3.5. In ZRBJCL, the correct
DDNAME is RMFIII vice ZRBIII. It has been reported that
only minor changes (tests LENGTH was tested for explicit
value instead of GE, I think) are needed for this code to
also support RMF 4.0 (MVS/ESA) RMF III, but that has not
been identified/tested yet.
Thanks to Neil Ervin, Sara Lee Direct, USA.
Change 07.112 Member ANALBNC1, for the analysis of benchmark runs, is
ANALBNC1 not really complete (in that the benchmark job stream is
Sep 5, 1989 not yet in existence) but some users have still found the
member was a good starting point for comparisons of their
own benchmark stream. This change upgrades the code so
that at least it runs without errors due to incomplete
comments, misspelled variables, etc.
Thanks to Harry Olschewski, DVG Kiel, GERMANY.
Change 07.111 This is a major revision to the MXG VTOC reading utility.
VMXGVTOC All variables are now labeled, and additional fields in
Sep 1, 1989 the VTOC (tracks allocated, tracks used, expiration date,
last use date, etc.) are now decoded in the MXGVTOC data
set. The VTOC itself is now recognized as occupying DASD
space, and free space after the last dsname on the volser
is now included in the MXGFREE data set. With this change
MXG really does capture the VTOC information for capacity
management of your DASD farm as well as for the billing
of DASD usage. The number of tracks on the volume is now
contained in the MXGVTOC data set in the DSNAME of the
VTOC data set (see comments in member).
Thanks to J. Cary Jones, Philip Morris, USA.
Thanks to Chris Luckman, SAS Institute, ENGLAND.
Thanks to Jugdish Mistry, SAS Institute, SCOTLAND.
Change 07.110 In searching for info on 3480-IDRC in INFO/MVS, I found a
VMACEXC2 reference to a new Device Type of x'81' for Device Class
VMACUCB of x'80' (Magnetic Tape), decoded as device type 9348. On
Aug 31, 1989 Sep 5, the 9348 (a 1600/6250 reel drive) was announced!
In examining UCBTYPE for decoding the 9348, a new Device
Class value of x'04' (Character Reader) was noted. Also
on Sep 5, IBM announced the 3490 tape cartridge device,
(a 3480 with IDRC built-in and a smaller footprint).
MXG member VMACUCB creates values of variable DEVICE.
MXG member VMACEXC2 accumulates EXCP/IOTM counts into the
device-specific variables (EXCP3420, EXCP3480, etc.).
a. VMACUCB now sets DEVICE variable values of 2400, 3420,
3480 or 9348. (Previouly, DEVICE was either 3420 or 3480,
and 3420 meant "all tapes not-3480").
b. VMACEXC2 IOTM/EXCP summarization for Tape Class continues
to keep only XXXX3420 and XXXX3480 variables, and 9348
counts are included in the XXXX3420 variables. XXXX3420
variables still mean "all tapes not 3480".
c. VMACUCB also now creates a value of CHARRDR for DEVICE
for device class of x'04'. (If you had actually had any
x'04' values, MXG would have produced an error message on
the SAS log, and none have ever been reported!)
d.VMACEXC2 counts EXCP/IOTM counts from device class x'04'
in the XXXXUREC variables.
Attended SHARE to present paper on the history of SMF Product's 1969
release, twenty years ago (and the 20th anniversary of the SHARE CME
Project as well). The paper is published in MXG Newsletter FIFTEEN,
in Volume One of the SHARE 73 PROCEEDINGS, and elsewhere as well.
Change 07.109 Unknown DOS Accounting records caused MXG to STOP reading
TYPEDOS the DOS file, which was inappropriate. Now, if an unknown
Aug 3, 1989 record id is encountered, a message and a hex dump of the
first ten occurrences are printed on the SAS log, but the
MXG program continues to read the rest of the POWER data.
The unkonwn record encountered was RECID='D', which looks
like an execute record, but is still under investigation;
it may be created by a vendor-product.
Thanks to P.J. Penrith, Kleinwort Benson, ENGLAND.
Change 07.108 Landmark's Monitor for CICS History Data OVHD Records are
TYPEMONI incorrect due to an error in Landmark's TMV630 program.
Aug 1, 1989 The OVHD,History record (not typically used by MXG users)
is one byte too short, and causes an "INPUT EXCEEDED" SAS
error message and STOPOVER ABEND. Landmark now has a fix
to create valid records, but until you apply their fix,
this circumvention will avoid the ABEND:
Insert after line 040600 (USER $CHAR8.) :
@; IF SUBSTR(TRANSACT,1,4) NE 'OVHD' THEN INPUT
Insert after line 040800 (@;) :
ELSE INPUT LUNAME $CHAR7. @;
Remember to remove this fix after you get the fix from
Landmark installed.
THIS CIRCUMVENTION WILL NOT BE PUT IN MXG SOURCE CODE.
IT IS ONLY FOR YOU TO TEMPORARILY INSTALL IN YOUR SYSTEM.
Thanks to Neil Ervin, Sara Lee Direct, USA.
October 19, 1989 update:
Another site tried the above circumvention before they
got the fix from Landmark, and still abended, because
in their case, the record had no FILESEGs, so that the
input DO loop is not executed, then the code in line
048600 is executed, and the STOPOVER occurs in trying
to input UTNUM PIB1.
Their additional circumvention, then, was
IF SUBSTR(TRANSACT,1,4)='OVHD' THEN UTNUM=0;
ELSE INPUT UTNUM PIB1. @;
Thanks to Anthony Miekle, Composite Buyers, AUSTRALIA.
Change 07.107 Change 7.060 (7.0 Beta ONLY) added type 37 support for
VMAC37 NETVIEW 1.2 and NETVIEW 1.3 records. Earlier versions of
Aug 1, 1989 NETVIEW (1.1) and prior NPDA (V3R2,V3R3) STOPOVERed. The
code now supports all of these records, and additionally
now decodes the local and remote modem reports into 12
new variables each.
Thanks to Bruce Widlund, Texas Utilities, USA.
Change 07.106 IDMS SMF records have been further validated and a few
VMACIDMS fields (which had existed in the old RTE records) are now
Aug 1, 1989 added in this minor enhancement.
Add TASMSSEV to keep list in line 013700.
Label TASMSSEV='TASK ABEND*SEVERITY*CODE'
PMHTSKID='TASK ID*NUMBER' after 019700.
Add TASPRTY to the $HEX2. format list in 072400.
Insert after 136100:
TASMSSEV=MOD(TASABMSG,10);
TASABMSG=INT(TASABMSG/10);
Thanks to Rodney L. Reisch, Wacovia Bank and Trust Company, USA.
Change 07.105 Type 6 PSF records had variable FORM wrong, because IBM's
VMAC6 8-byte "form" field in the Common Section of the PSF type
Jun 30, 1989 6 record does not contain the form! This fix may change
Feb 7, 1990 if IBM ever moves an 8-byte form name into the PSF record
but for now, you must change line 021300-021500 to read:
IF SMF6LN3 GE 14 AND SUBSYS NE 'PSF' THEN INPUT FORM $CHAR8. @;
ELSE IF SMF6LN3 GE 14 THEN INPUT +8 @;
Feb 7, 1990 update: SMF6LN3 was printed here in CHANGES
as SMFLN3 in error, and corrected today. VMAC6 was okay.
Thanks to Agneta Bergsten, SPP, SWEDEN.
Change 07.104 Shift calculation changes made in Version 6.6 did not
IMACSHFT affect the SHIFT variable, but the value of the DATETIME
Jun 28, 1989 variable passed back to the caller was not always right.
Since the returned value was used only infrequenly and
only in trending, this should not really cause a problem:
Insert new line 005701:
ELSE IF WEEKDAY(DATEPART(DATETIME)) EQ 2 THEN
Remove ELSE from beginning of line 005800.
Thanks to Gary Kallenber, CONTEL, USA.
Change 07.103 New style macro %VMXGSUM requires SAS System Option of
ANALDB2R MWORK=28K, else an 1453 Invalid Parameter Length error
Jun 28, 1989 occurs. While MWORK=28K was shown in MXG Trending example
in 6.6, rewrite of ANALDB2R using the new style macro did
not remind you to specify MWORK=28K for DB2 reports.
Change 07.102 MXG Tape Mount Monitor SMF record processing code had two
FORMATS formats reversed (lines 004900 and 005000) and failed to
VMACTMNT decode TMNTMTYP (Type of Mount, 0=Demand, 1=Private, and
Jun 28, 1989 2=Scratch) correctly. New format MGTMNTM. added to member
FORMATS. Replace present line TMNTRTRN PIB4. with two:
TMNTRTRN PIB2.
TMNTMTYP PIB2.
Thanks to Ray Dickensheets, Yellow Freight System, USA.
Change 07.101 VM/370 Monitor data for USER class did not exactly match
VMACVMON VMMAP. MXG did not output the first interval record, and
Jun 28, 1989 then deleted the second interval user record in the DIF()
logic. Change line 248700 (precedes EXVMOUSR's include)
to read IF INTRVCNT GT 0 THEN DO; instead of GT 1 THEN.
Thanks to Rob Owens, SAS Institute Europe, GERMANY.
Change 07.100 TMS DSN record caused STOPOVER due to bad logic. Correct
VMACTMS5 by inserting IF I=1 THEN before INPUT in line 0146.
Jun 28, 1989 Also, all packed decimal input fields were precedeed with
?? (between variable and PDn.) to protect if the field
has nulls instead of a valid PD field. The ?? tells SAS
to suppress the "invalid PD" message and to suppress the
hex dump of a record with invalid PD data!
Thanks to Brenda Rabinowitz, Prudential-Bache Securities, USA.
Change 07.099 Default record ID of 255 in IMACAION caused STOPOVER when
IMACAION an SMF ID=255 record (from a diferent product) was read.
Jun 18, 1989 Default should have been 512.
Thanks to Jim Kane, Reader's Digest, USA.
========Changes thru 7.098 were on the 7.0 Beta Tape===================
Change 07.098 Creation of CICS data sets by BUILDPDB beginning in 6.6
BUILDPDB removed the PROTECT=ZZZZZ option from the CICSACCT,
May 31, 1989 CICSEXCE, and CICSYSTM data sets. This could cause an
error when 6.6 attempts to reuse a 5.5 PDB library. (See
extensive discussion of PROTECT= in member CHANGE06). To
avoid the problem, you can simply scratch and reallocate
each PDB library before its re-use. Alternatly, you could
simply delete the three protected datasets from the PDB
library before you run MXG 6.6, by executing:
PROC DATASETS NOLIST DDNAME=PDB MT=DATA;
DELETE CICSACCT CICSEXCE CICSYSTM PROTECT=ZZZZZ;
Thanks to Greg Bowman, Walmart, USA.
Change 07.097 MXG support for type 79 SMF records is not functional.
VMAC79 This member needs lots more work before it can even be
May 31, 1989 tested. Do not try to use or understand it.
Change 07.096 HSM can create an SMF user record, whose contents is in
EXHSMDSR LY35-0080-1 pp180ff as the Daily Statistics Record. The
EXHSMFUN MXG support creates two data sets, HSMDSRST (statistics)
IMACHSM and HSMDSRFU (for each function) from the DSR record.
TYPEHSM There are two other subtypes of the DSR record that are
VMACHSM documented (FSR, p191 and VSR, p348s) but are not yet in
May 31, 1989 this preliminary code. I have only bench tested the code.
Member VMXGHSM contained the basic code for the DSR data
record, and FSR and VSR will be restructures of that code
as well. All of these segments existed (apparently) in a
single SMF record, but there is yet another SMF record
that I can not recognize. This is just a beginning.
Thanks to J. D. Hill, CyCare Systems, USA.
Change 07.095 The VMSQL... datasets created from VM/ACCOUNT cards will
TYPEVM exist only if your VM SQL machine's name (USER) begins
May 30, 1989 with SQLDBA. If your SQL machine has a different name,
see comments in the member. Additionally, data records
with apparently invalid values for SQLCPUTM (FFF91A25x)
have been reported to IBM, but no response yet. MXG uses
PIB4. format, and these values show up as large positive
values. Using IB4. instead would create negative values,
which might be easier to detect if you are looking for
bad values. But I think PIB4. is still safer, since you
can hardly overlook the bad data with large positive data
values, but with mixed positive and negative numbers, the
summing could cause the bad data to be overlooked. You
should always compare CPU measurement with the elapsed
duration of the interval (in this case, how long the VM
SQL machine was executing) to detect this type of IBM
error (which should eventually be fixed by an IBM PTF).
Should I externalize the test for SQL machine name into
a new macro name in a new member of MXG?
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 07.094 EPILOG CL1000 Version 440 support was tabled until later.
XMACEPIL I did not have all of the DSECTs I need when working on
XXACEPIL XMACEPIL, and when Candle provided me with their sample
May 30, 1989 code, it did not agree with the actual records. Member
XXACEPIL is partially corrected, decoding at least the
header (due to the DSECTS sent for Change 7.090), but
development was pended awaiting DSECTS and test data from
Candle.
Thanks to David Lloyd, Talbots, USA.
Thanks to M. Peller, Braun AG, GERMANY.
Change 07.093 Type 22 SMF record for 3990-3 Cache DASD controller has
VMAC22 had its problems. The subtype 10 data was left out of ESA
May 30, 1989 by IBM, and in the fix to that problem, four new bytes
have been added to the end of the record. Unfortunately,
segment length is not in the data record, and if IBM ever
writes more than one subtype 10 per section, the TYPE22_A
data may be incorrect. This is not an important record.
The missing segment was reported in MVS/ESA with APARS
OY22641/OY11323, and PTFs OY22641/UY90164 add the new
fields and for ESA creates the missing subtype.
Change 07.092 Preliminary support for SMF record created by COMPUWARE
IMACFILA product FILEAID. The access records seem usable, but the
TYPEFILA Field Update and Comprehensive Update records appear to
VMACFILA be of questionable value, especially since pointers do
May 25, 1989 not appear to exist to connect the record to its dataset!
Thanks to Mark A. Hawkes, Monarch Systems Group, USA.
Thanks to Timothy T. Tadeo, Monarch Systems Group, USA.
Change 07.091 This contributed report uses the TYPE30_5 record to count
ANALBATQ how many batch jobs are in the input queue. This report
May 25, 1989 has not been extensively tested yet, and may change.
Thanks to Neil Ervin, Sara Lee Direct, USA.
Change 07.090 Support for Candle's Omegamon Audit (hence OMAU) SMF user
EXTYOMAU record, written for each execution by an operator of an
IMACOMAU audited OMEGAMON command. The code is syntax checked and
TYPEOMAU visually validated with a hex dump of the data. but has
VMACOMAU not been actually used to read real audit records.
May 25, 1989
Thanks to Jonathan Swann, Belk Stores Services, USA.
Change 07.089 Support for AION Development System's SMF record, which
EXTYAION creates data set AIONACCT, an accounting record created
IMACAION when AION executes under IMS.
TYPEAION
VMACAION
May 25, 1989
Thanks to David Daner, Sun Refining and Marketing, USA.
Change 07.088 Variable DOWNTIME in TYPE90 is a duration, not a datetime
VMAC90 stamp and should have been FORMATed TIME12.2 instead of
May 25, 1989 DATETIME21.2. (It really should have been spelled DOWNTM
to be consistent, but its too late to change its name.)
Move DOWNTIME from line 009100 to 009000.
Thanks to Jonathan Swann, Belk Stores Services, USA.
Change 07.087 Support for Amdahl's SE Tool MDFTRACK's SMF record. This
EXTYMDF record describes activity in other MDF Domains, using the
IMACMDF MDFWATCH data. Amdahl cautions that this is not really a
TYPEMDF supported product but instead it is an SE's tool and is
VMACMDF subject to change (and not all fields are documented).
May 25, 1989 - GBLTOD is GMT while GBLBEGTS/GBLENDTS/SMFTIME local.
- GLBENDTS/GBLBEGTS resolve only to seconds.
- GLBINTMS is the actual interval duration.
- Units of DOMMIN,TGT,MAX,NORM,ATGT and GBLELTM? All
are same (and 879.068 if PIB4.3).
- Units of DOMDUTIL, DOMSUTIL,DOMUTIL.
- Validity of DOMNTSC.
- Validity of GBLRSERN.
- Avg Time slice calculation?
By comparing your online screen displays of the numbers
with a PROC PRINT of the MXG-built data sets, you should
be able to figure out how to replicate the screen report
values exactly from the MXG variables. Let me know.
Thanks to Dennis Dwyer, Citicorp St. Louis, USA.
Change 07.086 FOR VM/XA ONLY: Remove both occurrences of STOPOVER in
VMACVMXA the two INFILE statements for VM/XA Monitor processing!
May 24, 1989 I never thought I'd recommend not using STOPOVER, but it
looks like that's the best way to deal with the newest
idiosyncrasy of VM/XA. MONWRITE creates logical records
that span physical blocks! The only case in which this
spanning has occurred so far is the MTRDDR (1.14) record,
written only at VM/XA Monitor Start-Up. A large number of
devices + userids created a 1980 byte record which began
at byte 3021 of one 4096 byte block (1076 bytes in the
first block, 904 in the second). If this had been real
IBM VBS Record Format, SAS could handle spanned records,
but the VM/XA data is a series of blocks of 4096 byte
pages written in blocks of from 4096 to 7*4096=28672
bytes, containing two different sets of control records
interleaved between sequences of blocks of data records.
This non-standard record structure would permit the DCSS
to be re-created in an analysis program. The IBM manual
suggested algorithm required keeping track of page within
block and byte within page and databytes within control
interval; that's a lot of unnecessary CPU processing if
it's really "data processing" (i.e., reading lots of
monitor data) you want. Besides, maybe someday we'll
get MONWRITE re-written to create real, valid, VB data
record format to really minimize the I/O overhead.
The MXG Algorithms treat the VM/XA Monitor data as an
imperfect VB architecture, building heuristics to skip
over defects, such as the End of Frame record, a valid
self-describing 20 byte record followed by an undescribed
number of hex zeros - if the Record Length included the
zeros following the header, the MONWRITE data records
would at least be valid Variable-Blocked data between the
control records! But spanned logical records were not in
IBM documentation, nor seen until now.
The STOPOVER option has been discussed in the book, and
in previous CHANGExx/NEWSLTRS entries. It is very useful
to protect me and you from coding and data errors. It
makes SAS stop reading input records when the MXG program
tries to read beyond the end of the current logical (to
SAS) record. HOWEVER, the simplest fix to the VM/XA
Monitor's "spanning" of data is to remove STOPOVER from
the INFILE statements. SAS will continue on to the next
block with no other change to the MXG algorithm! You will
receive a "SAS READ BEYOND THE END OF A LOGICAL RECORD"
note (which does not set any error condition) on the log.
Martyn Stevens has coded a circumvention which works at
his site, but which works only if the end of each 1.14
record occurs exactly at the end of a page. The removal
of STOPOVER is thought to be a more robust solution, and
it demonstrates the versatility of SAS. The ability to
read multiple logical records as a single data record is
a boon to social scientists with 80-byte card image data,
10 card images per subject. SAS lets you treat that as a
single, 800 byte record (which reduces the human errors
in data entry, coding, etc.). STOPOVER is still useful in
SMF and other structured data records, but I think the
tests built into MXG are strong enough to detect any real
VM/XA errors softly. The removal of STOPOVER in this case
may let the latent power of SAS shine through, but Martyn
says even MISSOVER may not always work and he is sending
a VM/XA monitor tape for further analysis.
Thanks to Martyn Stevens, Barclays Bank, ENGLAND.
Change 07.085 VM/XA IUCV/VMCF fields had two labels reversed; PLSVSEVM
VMACVMXA should be "GOOD FROM" and PLSVSTVM should be "GOOD TO".
May 24, 1989 The following table may make IUCV/VMCF analysis easier.
--------TO--------- --FROM--
Service Destination GOOD BAD GOOD
IUCV: BLKIO PLSISTBL PLSISUBL PLSISEBL
CCS PLSISTCC PLSISUCC PLSISECC
MSG PLSISTM PLSISUM PLSISEM
MSGALL PLSISTMA PLSISUMA PLSISEMA
MONITOR PLSISTMO PLSISUMO PLSISEMO
RPI PLSISTRA PLSISUTA PLSISETA
SIGNAL PLSISTSI PLSISUSI PLSISESI
CP*SYSTEM SERVICES PLSISTVM PLSISUVM PLSISEVM
VMCF: A Virtual Machine PLSVSTVM PLSVSUVM PLSVSEVM
Thanks to Rob Owens, SAS Institute Europe, GERMANY.
Change 07.084 The 1984 MXG Guide, page 213, shows the IBM CICS tables
MXG Guide that need to be assembled to create type 110 CMF SMF data
May 24, 1989 records. The syntax CLASS=(PERFORM,ACCOUNT,EXCEPTION) is
not acceptable, apparently, for CICS 1.7. A site reported
IBM support said a separate DFHTYPE=RECORD statement is
needed in the MCT for each Class of data monitored. Also,
the example on page 213 should have suggested CONV=YES be
specified, so that each CICS interaction/conversation's
response time is measured.
Thanks to Bill Fox, National Futures Association, USA.
Change 07.083 RMFINTRV variables SIO74CNT,DEVACTTM,DEVCONTM,DEVDISTM, &
RMFINTRV DEVPNDTM were documented in the MXG Supplement to contain
May 24, 1989 only DASD device data, but RMFINTRV was never updated to
select only DASD type 74 records. (Note that even after
this change, that total SIO counts are still carried in
the SIO78CNT variable). Insert new line 072010:
IF SUBSTR(PUT(UCBTYPE,HEX8.),5,2)='20';
Thanks to Cathy Librachi, Aurora Health, USA.
Change 07.082 CICSTRAN variables MAXTASK and SHRTSTOR were not correct,
VMAC110 because once either condition was found in a transaction,
May 24, 1989 the rest of the transactions in that physical SMF record
were also flagged "Y", because the two variables were not
reset/initialized.
Insert two new lines 058410 and 069310:
ELSE MAXTASK=' ';
Insert two new lines 058510 and 069410:
ELSE SHRTSTOR=' ';
Thanks to Dennis Mahbubani, Aetna Casualty, USA.
Change 07.081 TYPE72MN (MVS/ESA-Only RMF Monitor III records) are all
VMAC7072 trashed because MONIDLS, MONPGIN and MOSLOT should have
May 9, 1989 all been PIB4. (this was a finger fault; the SKIP logic
expected 4-byte counters!)
Thanks to Don Friesen, B.C. Systems, CANADA.
Change 07.080 These sample CICS SAS/GRAPH routines had not been updated
GRAFCICS for SAS 5.18. All GOUT= were changed to PDB.GRAFCICS and
May 9, 1989 the final data step deleted. After execution, the graphs
can be replayed with PROC GREPLAY IGOUT=PDB.GRAFCICS;
Thanks to Bill Salassi, BHP Systems, AUSTRALIA.
Change 07.079 DB2ACCT and DB2STAT0 variable QTXAPREC was decoded into a
VMACDB2 set of eight new variables: QTXABLLM QTXAIOLM QTXAINLM
May 9, 1989 QTXASALM QTXASELM and QTXASPLM for ease in reporting DB2.
Change 07.078 IBM added four undocumented bytes to the end of RMF 77
VMAC77 record in MVS 3.1.0e (and, yes, it is a lower case "e" in
May 4, 1989 the MVSLEVEL variable!). MXG did not use "skip" logic in
type 77 processing, and the TYPE77 data set is trashed.
Insert two new lines after line 018800:
018810 SKIP=LENEDSS-156;
018820 IF SKIP GT 0 THEN INPUT +SKIP @;
Thanks to Carol Rogers, K-Mart Apparel, USA.
Change 07.077 If you used %VMXGSUM with MAX= but without MIN=, wrong
VMXGSUM values were calculated. This did not affect any MXG code,
May 4, 1989 as all MXG uses of %VMXGSUM specified both MAX= and MIN=.
Delete line 031500 %LET LASTX = &NUMMIN;
Change 07.076 Landmark Monitor system record daccumulation (MONISYST)
TYPEMONI is wrong. The revised de-accumulation algorithm added in
May 4, 1989 MXG 6.6 to process concatenated files always fails. This
ONLY affects the MONISYST data, and not the MONITASK data
set. (That it took until now to be noticed suggests that
few users take advantage of the MONISYST dataset!). The
correction is to change lines 084600 thru 088900. Each
line is now of the form Hnn = Variable;
Each line must be changed to read Hnn=Variable+Hnn;
For example, after the change:
084600 H1 =CPUTCTBM+H1 ;
...
089000 H45 =WTTSIOTM+H45;
Thanks to Joe Faska, Depository Trust, USA.
Change 07.075 Processing IMS 1.3 Log data is NOT possible with the MXG
TYPEIMS1 algorithms for IMS 2.1 and IMS 2.2. These power of these
VMACIMS1 algorithms (which recognize each IMS transaction instead
May 4, 1989 of each program schedule) depend on several fields that
simply do not exist in the archaic 1.3 release:
-LINENR is not in type 35 log record
-LTERM is not in type 31O log record
-ARRVTIME is always nulls in 03P record
-DLRTOKEN only exists in the 07/08 records
The ability to recognize multiple transactions within a
program schedule is absolutely dependent on these data.
Thus MXG cannot claim to support transaction measurement
for IMS 1.3. We have restored MXG Version 5.5 IMS logic
in new members TYPEIMS1/VMACIMS1 for IMS 1.3 sites. That
code made no attempt to recognize multiple transactions
per program schedule, but instead matched IBM's DFSILTA0
results to produce one observation in IMSTRAN for each
program schedule. Since only 7 sites have requested our
IMS 1.3 processing, we can only offer this restoration.
Change 07.074 Unused change number.
Change 07.073 In TYPE26J2, TYPETASK may contain JOB0, TSU0, or STC0 as
VMAC26J2 IBM prepared for JESNR greater than 9999 in the JCTJOBID
May 4, 1989 field. This change reads only the first three bytes of
JCTJOBID into TYPETASK, but keeps its length at four to
avoid conflict with other data sets. Insert new line
013311 after 013310: TYPETASK=' '; /*4 blanks*/
In line 013400 Change $CHAR4. to $CHAR3.
In line 013500 Change +4 to +5
Thanks to Carol Harper, E G & G Idaho, USA.
Change 07.072 In TYPE90, variable DETAIL was not reset for each class
VMAC90 os SMF recording (JOB, TSU, STC). Now it is by insertion
May 4, 1989 of ELSE DETAIL=' '; after DETAIL='Y';
Thanks to Diane Eppestine, Southwestern Bell Telephone, USA.
Change 07.071 In ROSCOE 5.6 RTM the number of complexity levels is set
TYPEROSJ by ROSCOE sysgen parameter RTMCMARK and the number of
VMACROSC time levels is sysgened by RTMTMARK. The actual number
VMACSMF of buckets in the RTM record is one less than the number
May 3, 1989 of levels. MXG expects three complexity level buckets and
five time level buckets (assumed RTMCMARK=4,RTMMARK=6).
You will encounter a STOPOVER abend if you sysgen less.
This change now uses information in the record to read in
only as many fields as exist. Many lines were changed.
An unrelated change to ROSCOE processing was also made:
member TYPEROSJ has been deleted, and the code in VMACSMF
that set OFFROSC was removed, because ROSCOE journal and
ROSCOE SMF records can be processed with member TYPEROSC
using a DDNAME of SMF for either dataset. TYPEROSJ was
only for ROSCOE 5.4 and earlier, and caused confusion.
Thanks to Art A. Brax, Jefferson Co. Colorado School District, USA.
Thanks to Sandy Recchio, Chase Lincoln First Bank, USA.
Change 07.070 This enhancement to dataset activity analysis added VSAM
ANALDSET TYPE64 records, new fields (eg. OPENTIME) from TYPE1415,
Apr 30, 1989 and enhanced the description of the job. If you want to
know which program in which job opened which file for
how long and for how much I/O, this is the place to go.
Change 07.069 This enhancement to DB2PM-like reporting adds many small
ANALDB2R changes as a result of more detailed validation with DB2
Apr 30, 1989 Version 2.1 data and report formats, and adds additional
reports. This revision now invokes %VMXGSUM to summarize
which reduced the size from 12,000 lines to only 7,150!
Change 07.068 The VTOC processing code only expected 16 extents, since
VMXGVTOC the code was written before there was VSAM. With this
Apr 30, 1989 enhancement, MXG now expects up to 128 extents to fully
support VSAM data spaces in a VTOC.
Change 07.067 The long promised MXG Tape Mount Monitor, MXGTMNT, lives!
ASMTMNT Member ASMTMNT contains the assembly source for the load
EXTMNTMN module MXGTMNT and the JCL to create the proclib member
EXTMNTSW MXGTMNT. MXGTMNT executes in its own address space and it
IMACTMNT creates an SMF record for every tape mount with the start
TYPETMNT and end timestamps, duration of the mount, and the job
VMACTMNT causing the mount. MXGTMNT also creates a record if a
Apr 30, 1989 "tape swap" occurs as the result of a permanent error.
The installation instructions for the tape mount monitor
are contained in comments at the beginning of ASMTMNT.
Please read completely before executing. Member IMACTMNT
contains the SMF record ID that you chose in ASMTMNT.
Member TYPETMNT/VMACTMNT creates two data sets from the
SMF record: TYPETMNT contains mount information and
TYPETSWP contains swap events. The monitor has been
tested under MVS/370 and MVS/XA, and should execute under
MVS/ESA as well. Members ASMTPMON and ASMTP370 have been
replaced by ASMTMNT.
Change 07.066 Exits EXPDBWEK and EXPDBMON have been added to the PDB
EXPDBMON WEEKBLD and MONTHBLD members so that users who have added
EXPDBWEK additional SMF records to BUILDPDB/3 (using the MXG Exit
MONTHBLD Facility, page 139 in the MXG Supplement) can copy those
WEEKBLD additional data sets into their MONTH and WEEK PDBs.
Apr 29, 1989
Change 07.065 DB2 Trace SMF type 102 record support has been expanded
FORMATS and further validated and revised with Release 2.1 data.
IMAC102 The subtype 106 (System Parameter) record (in T102S106)
VMAC102 was completely re-formatted by IBM in 2.1, requiring a
Apr 28, 1989 rewrite. Subtypes 67, 98, 99, 101, 112, 122, and 123
May 9, 1989 have now been tested with 2.1 data. An entire new class,
Audit (subtypes/IFCIDs 140-145) is now supported, though
only subtypes 140 and 141 were available for testing.
Logic now tests QWHSNSDA (in 2.1) or record length (1.3)
to determine the actual number of triplets, which avoided
a STOPOVER conditions. Subtype 53 and 58 were rewritten
to decode the SQLCA and to avoid STOPOVER conditions. New
macros are now defined in IMAC102 for the Audit classes.
Some subtypes that were not in their correct trace class
groups were moved to where they belong, and the subtype
to trace class documentation (in IMAC102) revised. This
was a significant change to type 102 processing for 2.1.
Note: All 120+ T102Snnn datasets are always created by
MXG, but only those "enabled" by IMAC102 will actually
have observations. However, SAS requires virtual storage
for each data set at compile time. With only a 4MB region
it was necessary to specify SAS Option BLKSIZE=8192 for
the TYPE102 program to execute.
Thanks to Stan Stoots, Virginia Power, USA.
Thanks to Stan Majka, Virginia Power, USA.
Thanks to Peter Gallinari, Reader's Digest Association, USA.
Change 07.064 CICSEXCE variables TSWAITTM,CN,MSWAITTM,CN,VSWAITTM,CN
VMAC110 were not initialized and could be carried forward into
Apr 27, 1989 a subsequent exception observation. All six variables
are now initialized to missing after line 101600.
Thanks to Dee Ramon, Mutual of America, USA.
Change 07.063 Trending RMFINTRV from PDBs built before MXG 6.6 causes
TRNDRMFI Variable Not Found condition (which cannot be solved by
Apr 27, 1989 the NOVNFERR SAS option), because of the new OTH6-OTH0
variables added in MXG 6.6 to RMFINTRV that are not in
RMFINTRV built by prior versions of MXG. If you want to
use previously built PDB librarys as input for trending
you must create 70 new lines after 014500 (one line for
each of the 14 variables in each of the 5 OTHn groups).
The 70 variable names are in lines 003900-004100 and in
lines 005700-006800. Each new line will be:
IF variable=. THEN variable=.;
For example, the first line will be:
IF OTH6ACTV=. then OTH6ACTV=.;
Thanks to Georg Simon, Federal Reserve Bank of Philadelphia, USA.
Change 07.062 NETSPY records caused zerodivide condition because the
VMACNSPY denominator in lines 041200 thru 041500 should have been
Apr 26, 1989 TOTRSPNO instead of TRANSNO.
Thanks to ???, KF Data, SWEDEN.
Change 07.061 TYPE74 variables AVGPNCHA, AVGPNCUB, AVGPNDEV are labeled
VMAC74 as containing milliseconds of pending time for channel,
Apr 25, 1989 control unit, and device, but erroneously are in seconds.
This change corrects the calculation so that the values
are in milliseconds and agree with the labels. In lines
039700 thru 039900, change the lines which now read:
AVGPNxxx=DURATM*PCTPNxxx/(100*SSCHSAMP);
to read:
AVGPNxxx=10*DURATM*PCTPNxxx/SSCHSAMP;
Thanks to Ron Higgins, American Honda, USA.
Change 07.060 NetView Release 2 writes "Hardware Monitor External Log
VMAC37 Record" as SMF type 37 Records and their contents are
Apr 27, 1989 described in NetView Administration Reference SC30-3361-2
(Appendix A pages 97ff). This change adds support for
three new segments (LPDA-2, LAN, and Generic Event) into
the TYPE37 data set.
Change 07.059 NetView Release 2 writes "Session Monitor External Log
VMAC39 Record" as SMF type 39 Records and their contents are
Apr 27, 1989 described in NetView Administration Reference SC30-3361-2
(Appendix A pages 163ff). This change adds support for
new subtypes 7 and 8. Subtype 7 in TYPE39_7, Init Failure
is identical to pre-existing TYPE39_6 dataset. Subtype 8
in TYPE39_8, Storage and Event contains 44 new variables.
(VM NetView also writes SMF format data to its external
file which should be processable with TYPE39, but this
has not yet verified).
Thanks to Russell Brooks, James River Corporation, USA.
Change 07.058 JES3 BUILDPD3 prints TYPE30_5 (twice!) due to debugging
BUILDPD3 code (lines 013900 and 014300) which are now deleted.
Apr 20, 1989 Two PROC CONTENTS of the PDB and WORK ddnames are deleted
(lines 059100 thru 059400) because ANALCONT provides the
same report. (Some sites did not want the contents, but
I find them worthwhile in tracing problems.)
Thanks to George Scott, Rockwell International Corporation, USA.
Change 07.057 VM/XA Monitor records have been altered by PTF VM35971
VMACVMXA and VM35321 which are now supported by MXG. VM35971 adds
Apr 20, 1989 VMDCTMIG (Pages Migrated from ESTORE to DASD), VMDCTXWT
(Pages written from main to ESTORE) and VMDCTXRD (pages
read into main from ESTORE) to the VXUSEACT and VXUSEATE
detail data sets. MXG adds the new variables to the MXG
created VXBYUSR, VXSUMUSR and VMXAINTV datasets, storing
the values as rates per second as are other paging data.
PTF VM35321 adds VMDCPUAD (CPU Address) to the VXSCLADL,
VXSCLDDL and VXSCLAEL Schedule records. This now permits
MXG to properly de-accumulate those data (prior to this
fix, the schedule data was unusable because VMDCPUAD was
needed to de-accumulate those data).
Thanks to Richard Steele, Louisville Gas and Electric, USA.
Change 07.056 TPX SMF records read directly from active VSAM data set
VMACTPX cause STOPOVER because MXG was incomplete. In line 032000
Apr 19, 1989 change TPXOFF=TPXOFF-3; to TPXOFF=TPXOFF-3+OFFSMF;
There is no problem processing TPX records from a normal
SMF dumped dataset.
Thanks to Bob Lemaster, Central Bank of the South, USA.
Change 07.055 Support for the TLMS (Tape Library Management System) CA
TYPETLMS product is added by this user contribution. The code was
Apr 19, 1989 restructured but has yet been tested with real data in
its revised form. The TLMS Catalog is read to create an
observation for each tape volume.
Thanks to Wing Louie, Chase Manhattan Bank CDC, USA.
Change 07.054 NPM Type 28 Subtype 5C (Dynamic Reconfigure Notification)
VMAC28 caused STOPOVER because DRNTNAM, Target Resource Name, is
Apr 18, 1989 not always present (this is not documented by IBM).
Insert new line 164310 after line 164300:
164310 @; IF LENTOF GE 19 THEN INPUT
to conditionally input DRNTNAM when it is actually there!
Thanks to Larry Doub, R J R, USA.
Change 07.053 DB2 Version 2.1 causes "VMACDB2 DATA. UNEXPECTED ID=100
VMACDB2 NRINSD=14 and NRIFCID=13" messages on the SAS log. This
Apr 18, 1989 is not really a problem to worry about. The NRINSD and
NRIFCID count the number of Destination Data Sections and
Instrumentation Data Sections in the record, which count
records written for the monitor, and do not relate to the
DB2 system itself. As a result, MXG kept only the first
three NRINSD destination names and only the first five
IFCIDs (see page 203 of the MXG Supplement for the list
of variables that are kept). I don't think the counters
are useful, and if they were, it should be done with an
additional data set. Until someone demonstrates a need to
use this obscure data, I have re-worded the text of the
message: "MXG KEEPS THE FIRST THREE/FIVE IFCID/INSD, BUT
YOUR DATA HAD n. THIS IS NOT USUALLY IMPORTANT". If I
knew for sure it was always 14/13 I might suppress the
note. This change also corrected some minor logic errors
in deciding when to print the message: Line 094800 should
GT 3 instead of GT 5, and -4 should be -2, and 094900 is
PIB2. instead of $CHAR4.
Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 07.052 SYNCSORT SMF records read from "active" VSAM SMF file
VMACSYNC caused STOPOVER abend (but worked fine from dumped SMF).
Apr 18, 1989 Remove +OFFSMF from line 026200.
Thanks to Dave Greene, Kwasha Lipton, USA.
Change 07.051 RMF Monitor III VSAM data sets are supported by this
EXZRB... major user contribution. (In MVS/ESA, a very small
IMACZRB part of the Monitor III data is written as a subtype
TYPEZRB of the Type 72 record and supported in TYPE72MN data
VMACZRB set introduced in MXG Version 6.6). The workload
ZRBJCL delay monitor data is far more extensive that that,
ZRBRPTn and this extensive set of code processes those VSAM
ZRBWORK RMF III data into several data set names. Although
Apr 12, 1989 the "ERB" acronym is the more appropriate name for
these data, I renamed Dick's use of ERB to ZRB as I
expect this code will be short lived as MVS/ESA takes
over in the future.
Thanks to Dick Whiting, Precision Castparts, USA.
Change 07.050 Concatenated VM/Monitor data contained invalid values
VMACVMON for the first interval after each START event, because
Apr 12, 1989 MXG incorrectly outputted all intervals, when it was
intended to only output beginning with the second. In
all twenty occurrences of IF INTRVCNT GT 0 THEN ....
must be changed to IF INTRVCNT GT 1 THEN
Thanks to Rodney L. Reisch, General Electric Plastics, USA.
Change 07.049 The references to _CICOTHR for the ddname of the CICS
ANALCICS ACCT, EXCE, and YSTM data sets should have been changed
Apr 11, 1989 to _CICACCT.CICSACCT, _CICEXCE.CICSEXCE and
_CICYSTM.CICSYSTM to be consistent with IMACCICS.
Thanks to Mark Hutchinson, Atlantic States Bank, USA.
Change 07.048 IMS Log Record decoding corrections.
VMACIMS a.After 024700 (the @; after DEST $CHAR8.), insert line
Apr 9, 1989 IF _IMSVERS GE 2.2 THEN INPUT MSGIHSQN $CHAR8. @;
IMS 2.2 added this eight byte field and MXG missed it.
Without the fix, IMS 2.2 abended with STOPOVER (though
several IMS sites looked at the hex dumps, inserted an
+8 before the SIZELU6 variable to align and circumvent!)
b.Change 027400 from LOC=MSGPRFLL; to LOC=MSGPRFLL-3;
so that MSGXDLEN is correctly read in and used for the
MSGLEN, MSGSZIN, and MSGSZOUT variables.
c.Both references to unused unkept COMMFLAG were deleted.
d.Insert after line 043500 (between DLRTOKEN and PSTTSKID
@; IF _IMSVERS GE 2.1 THEN INPUT
e.Insert after line 056010 (between MSGDRRN and DLRTOKEN
@; IF _IMSVERS GE 2.1 THEN INPUT
Items d. and e. prevent STOPOVER with IMS 1.3 data.
f.Any time stamp was set missing if PTIME was exactly zero
(midnight). The PTIME/PDATE INPUT statement uses the ??
syntax (suppresses hex dump and error message and makes
value missing for invalid PD. data). Thus PTIME could be
zero, causing MXG to not calculate a datetime variable.
All statements testing PTIME GT 0 were changed to test
PTIME GT . (missing value).
g.Log type 35x records were not always output, causing the
ENQTIME to be missing which caused an out-of-sort-order
failure to merge ENQTIME with other transaction records.
Heuristic logic testing ENQFLAG and FLAG2 bits determine
if a 35x record is for input, output, message-switch, or
program-to-program, brute-force determined by finding a
combination, then looking at a detail trace to determine
the proper IMS35x data set to output. Values previously
unseen were skipped and not output. Now, unknown values
are printed on the SAS log. (If you should encounter a
new combination, call and we'll discuss how you can dump
the IMS log records to figure out which IMS35x dataset it
should be put in - I sure wish there were a better way!)
This change restructured logic in IMACIMS to remove the
RETURN statements and replaced IF's with ELSE IF's.
Thanks to Harry Olschewski, DVG Kiel, GERMANY.
Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 07.047 RACF Auditor reports from SMF type 80 record exposures.
ANALAUDT 1.In member ANALAUDT, references to _RACF must be changed
FORMATS to _AUDT (which sets the DDNAME containing your TYPE80
Apr 9, 1989 data set, defined in IMACANAL).
2.The remainder of this change corrects only the values of
variables ALLOW and INTENT in SUF/INSUF Auth. reports.
There is no other impact if you do not put this fix on.
This report decoded ALLOW and INTENT from the wrong byte
of RACFDATA, in a block of code in the wrong location,
and were not RETAINed for multi-observation RACF events!
a.ANALAUDT changes:
-Add ALLOW INTENT to RETAIN at line 009400.
-Block COPY lines 016300 thru 018100 (from /* RESOURCE
to associated END;) TO AFTER line 012500. In the new
block you copied:
-Add OR RACFQUAL=200 after RACFQUAL=201
-Change both tests for RACFDLN GE 3 to RACFDLN GE 1
-Change SUBSTR(RACFDATA,3,1) to SUBSTR(RACFDATA,1,1)
in ten statements within this copied block.
-Delete the statement OUTPUT INSUF;
-Now, go back to lines 016300 thru 018100, delete the
entire block, and replace it with these two lines:
016400 IF RACFQUAL=201 THEN OUTPUT INSUF;
016500 IF RACFQUAL=200 THEN OUTPUT SUF;
b.Additional cosmetic changes made for next Version that
are truly optional for now:
-In ANALAUDT, after RETAIN at line 009400 new line:
FORMAT ALLOW INTENT MG080AI.;
-In FORMATS, after MG080EV definition, add new format:
VALUE MG080AI
0='0:ALTER'
1='1:CONTROL'
2='2:UPDATE'
3='3:READ'
4='4:NONE'
;
c.One additional change, but only for users of the FACOM
operating systems type 80 records. Format MG080QU has a
slightly different meaning for four values, which are
changed in member FORMATS (after VALUE MG080QU) to now
describe either IBM or FACOM type 80 records:
101:INVALID PASSWORD (FACOM: OR GROUP)
102:INVALID GROUP (FACOM:UIDCARD)
103:INVALID OIDCARD (FACOM:TERMINAL)
104:INVALID TERMINAL (FACOM:APPLICATION)
Thanks to Ingrid Ahmer of Australian National, AUSTRALIA.
(railways), who sent an excellent discussion and fix for the code
relocation logic.
Thanks to Thomas Peiper, KommunData, SWEDEN.
Change 07.046 MVS Step Accounting fields were decoded in MXG TYPE30_4
IMACACCT variables ACCOUNTn, but BUILDPDB/3 does not carry these
IMACPDB STEP accounting fields into PDB.STEP. Instead, the JOB
VMAC30 accounting variables ACCOUNTn from the TYPE30_1 (Init)
Apr 30, 1989 or TYPE30_5 (Job termination) records are used through
out BUILDPDB/3 logic, which is what almost every site
really wants. Step level accounting really does not work:
you can't tell which step caused which PDB.PRINT data;
which account do you use in PDB.JOBS if different fields
are used on different steps, etc. However, IBM does not
provide a mechanism for putting job-level account fields
in type 30_1 or type3-_5 records for Started Tasks (STC).
This change creates additional variables SACCTn in both
TYPE30_V (interval) and TYPE30_4 (step) records, and the
SACCTn variables are now added to PDB.STEPS. Please NOTE
that PDB.JOBS is unchanged; ACCOUNTn variables for STCs
will still contain blanks. Further design considerations
of BUILDPDB logic is required before step account fields
could replace blank job accounting fields in PDB.JOBS.
1.Member VMAC30
SACCT1-SACCT9 was added to KEEP of TYPE30_4 and TYPE30_V
2.Member IMACACCT
SACCT1-SACCT9 were added. IMACACCT is usually modified as
described on page 311 of the MXG Guide; changes made to
the number and length of ACCOUNTn variables must also now
be made to the SACCTn variables.
3.Member IMACPDB:
SACCT1-SACCT3 added to the MACRO _PDB30_4 list of which
TYPE30_4 variables will be carried into PDB.STEPS. (MXG
defaults to 3 ACCOUNT and now 3 SACCT variables).
Thanks to Michel Leveille, CTTL, USA.
Change 07.045 MXG Programs can be executed through JCL with either an
JCLPDB explicit DD DSN=MXG.SOURCLIB(XXXXXXXX) member name in the
JCLTREND JCL, or by a //SYSIN DD * JCL statement followed by SAS
PDBTREND %INCLUDE SOURCLIB(XXXXXXXX); statements. MXG members that
Apr 9, 1989 contain JCL were inconsistent, some used member name and
some used %INCLUDE.
1. In favor of member name:
a. There was a historical limitation when JES could not
submit a job from a job if the submitted job contained a
SYSIN DD * JCL statement. The submitted job would simply
not execute. Making the DD * statements a member of a PDS
and then using only member name DD statements solved the
problem. (This still is occasionally encountered at some
sites and/or levels of JES - anyone know why/when/what?)
b. JCL is easier to comment out than SAS. JCL needs only a
asterisk in col 3 of the DD statement. SAS usually needs:
an INSERT character to make room for the leading /*,
typing of the /* delimiter before the statement,
a long shift cursor to the end of the statement,
typing of the */ delimiter after the statement,
(and only if you did not first have to cursor right, char
delete to make room in the line buffer!)
c. Production jobs which failed could be re-submitted in one
step by editing the JCL member, commenting out the member
names that had successfully completed and submitted to
run from that point.
2. In favor of %INCLUDE.
a. The MXG Exit Facility. You need the ability to change any
MXG program in your USERID.SOURCLIB, and the use of JCL
member name prevents you from making effective use of the
Exit Facility. Items b. and c. above were encountered at
State Farm and Sun, before there was an Exit Facility!
3. The conclusion. MXG will now use only %INCLUDE statements
in JCL examples. Furthermore, all %INCLUDE statements in
JCL examples will be precedeed by five blanks to make any
editing easier (as long as I don't forget to do so).
Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
Change 07.044 IDMS Performance Monitor SMF record processing did not
VMACIDMS retain TASBFLDS and TASNDBLV in the IDMSTAS data set. Add
Apr 9, 1989 TASBFLDS to the RETAIN statement (line 130300) and change
the 2nd occurrence of TASMXRBB line 131000 to TASNDBLV.
Variable TASTTYPE in IDMSTAS identifies the type of task
(DC Task, CICS ERU, Batch ERU, or TPMON ERU) and several
variables only apply to specific task types. MXG did not
initialize these variables, and because these variables
must be retained (the IDMSTAS record is segmented into
256 byte pieces because of the 256 byte IDMS Journal),
the "other" variables will have retained values from a
prior IDMSTAS observation. As long as you use TASTTYPE
you should not have a problem, but the real fix inserted
25 lines after 123300 to initialize the retained values:
SKIP=SKIP-40; 123300
TASTSKCD =' '; 123310
TASPGMNM =' '; 123320
TASLTEID =' '; 123330
TASPTEID =' '; 123340
TASUSER =' '; 123350
TASPGDBN =' '; 123360
TASPGNOD =' '; 123370
TASLDLST =' '; 123380
TASAMNAM =' '; 123390
TASFACCD =' '; 123391
TASCTI =' '; 123392
TASCPGNM =' '; 123393
TASCTETI =' '; 123394
TASCLID1 =' '; 123395
TASCLID2 =' '; 123396
TASCTEOI =' '; 123397
TASCJBNM =' '; 123398
TASBJBNM =' '; 123399
TASBPGNM =' '; 123400
TASBNFLD =.; 123401
TASBBALN =.; 123402
TASBFLDS =' '; 123403
TASTPGNM =' '; 123404
TASTLID1 =' '; 123405
TASTLID2 =' '; 123406
IF TASTTYPE='1.......'B THEN DO; /*ONLINE - DC TASK */123410
Thanks to Randy Springs, Glidden Paint, USA.
Change 07.043 VM/370 Account records contain blanks (rather than hex
TYPEVM zeros) for the VECVMTM and VECVIRTM vector CPU fields.
Apr 9, 1989 (Four bytes of blanks input as PIB4.3 is 1,077,952.576!)
Lines inserted after 036900 to conditionally input:
036910 @;
036920 INPUT @65 TSTCHAR1 $CHAR4.
036930 @69 TSTCHAR2 $CHAR4.
036940 @;
036950 IF TSTCHAR1 NE ' ' AND TSTCHAR2 NE ' '
THEN INPUT
Thanks to J. D. Hill, CyCare Systems, USA.
Change 07.042 NPM Type 28 SMF record subtype 60x,61x, and 62x were not
VMAC28 output. Expand the test at line 200300 to include those
Apr 9, 1989 three values of NPMSUBTY (and change comment in 200400
for EX028IN8 to read for NPMINNSA vice NPMINPMT).
Thanks to J. D. Hill, CyCare Systems, USA.
Change 07.041 Variables QTXAFLG1, QTXAIRLM, and QWHCOPID were not kept
VMACDB2 in DB2ACCT keep list, but will be needed in DB2PM-like
Apr 9, 1989 reports for DB2 Version 2.1. They are now kept.
Change 07.040 Support for Tape Management System (TMS) Catalog records
ANALTMS5 (tape volume sizes, last use, etc.) is now upgraded from
TYPETMS "X-rated (i.e, extra but not supported member) XMACUCC1"
VMACTMS5 to these members. There may be additional logic added
Apr 8, 1989 after further testing. See comments in TYPETMS.
Thanks to Joe Faska, Depository Trust, USA.
Change 07.039 The subtype 3 (Storage) type 22 SMF record (seldom if
VMAC22 ever needed) fails with MVS/370 and old MVS/XA because
Apr 7, 1989 NRPAGES may not exist and LOWADDR may be 2 or 4 bytes.
Change lines 046100 to 046300 to read:
046100 IF LENGTH-COL EQ 1 THEN INPUT LOWADDR PIB2. @;
046200 ELSE IF LENGTH-COL GE 3 THEN INPUT LOWADDR PIB4. @;
046300 ELSE IF LENGTH-COL GE 7 THEN INPUT LOWADDR PIB4.
NRPAGES PIB4. @;
Thanks to Dana Yam, Washington University, USA.
Change 07.038 These five members are one possible circumvention for a
XMAC7072 "SAS Error 344 - Compiler Limit Exceeded" condition in
XMAC71 executing BUILDPDB/3. By copying these five members to
XMAC73 your USERID.SOURCLIB library and renaming them to their
XMAC74 corresponding VMAC.... name, the number of interative
XMAC75 "DO" statements is reduced, and BUILDPDB might be able
Apr 5, 1989 to compile successfully. (The ultimate fix will be SAS
Version 6 on the mainframe, which eliminates the limit in
their compiler.) These members reduce the number of "DO"s
by processing only MVS/XA and MVS/ESA RMF records, but
depending on which additional SMF processing members you
have added to BUILDPDB/3, even with this circumvention in
place, you might still exceed the compiler limit.
An alternate circumvention which completely avoids any
exposure, and is only slightly more complicated, is to
use the IMACFILE exit to write the newly wanted SMF data
records to a temporary SMFOUT file, which is then passed
to an additional step in your BUILDPDB/3 job, which then
creates the additional data sets and copies them into the
PDB ddname. In this way you will still only read your SMF
dataset once, and by good choices of which records are in
this temporary data set versus which records you process
in BUILDPDB/3, you can keep the temporary data set small.
The XMAC7... members on Version 6.6 were unfortunately
not built correctly, and created different exposures. If
you need to use these five XMAC7... members to attempt to
avoid the compiler limit, you will need to recreate them
their corresponding VMAC.... member, replace the MVS/370
processing lines with the indicated "Initialization IF"
statements so they end up as shown below:
XMAC7072:
Replace lines 043900 thru 085000 to be:
043900 IF (ID=70 OR ID=72) AND NOT MVSXA THEN DO;
044000 IF SUPATERN=' ' THEN SUPATERN=' ';
085000 END; /* TYPE 70, 72 RECORD FOR NON-MVSXA */
XMAC71:
Replace lines 031500 thru 046100 to be:
031500 IF ID=71 AND NOT MVSXA THEN DO;
031600 IF FRAMES =. THEN FRAMES =.;
031700 IF LPSWRCLM=. THEN LPSWRCLM=.;
031800 IF PVTMVCLC=. THEN PVTMVCLC=.;
031900 IF PVTMVDWN=. THEN PVTMVDWN=.;
032000 IF PVTMVUP0=. THEN PVTMVUP0=.;
032100 IF PVTMVUP1=. THEN PVTMVUP1=.;
046100 END; /* MVS/370 TYPE 71 RECORD */
XMAC73:
Replace lines 012700 thru 002270 to be:
012700 IF ID=73 AND NOT MVSXA THEN DO;
012800 IF AVGENQUE=. THEN AVGENQUE=.;
012900 IF CHANMAP0=. THEN CHANMAP0=.;
013000 IF CHANMAP1=. THEN CHANMAP1=.;
013100 IF C0ANYCH =. THEN C0ANYCH =.;
013200 IF C0BYWT =. THEN C0BYWT =.;
013300 IF C1ANYCH =. THEN C1ANYCH =.;
013400 IF C1BYWT =. THEN C1BYWT =.;
013500 IF DEFCUBY =. THEN DEFCUBY =.;
013600 IF DEFDEVBY=. THEN DEFDEVBY=.;
013700 IF DEFERED =. THEN DEFERED =.;
013800 IF DEFLCHBY=. THEN DEFLCHBY=.;
013900 IF DEFPHYBY=. THEN DEFPHYBY=.;
014000 IF FQCUBY =. THEN FQCUBY =.;
014100 IF FQDEVBY =. THEN FQDEVBY =.;
014200 IF FQLCHRQ =. THEN FQLCHRQ =.;
014300 IF FQPHYRQ =. THEN FQPHYRQ =.;
014400 IF LCHAN =. THEN LCHAN =.;
014500 IF LCI =. THEN LCI =.;
014600 IF PCTDEFCU=. THEN PCTDEFCU=.;
014700 IF PCTDEFDV=. THEN PCTDEFDV=.;
014800 IF PCTDEFER=. THEN PCTDEFER=.;
014900 IF PCTDEFLC=. THEN PCTDEFLC=.;
015000 IF PCTDEFPY=. THEN PCTDEFPY=.;
015100 IF QUEUE0 =. THEN QUEUE0 =.;
015200 IF QUEUE1 =. THEN QUEUE1 =.;
015300 IF QUEUE2 =. THEN QUEUE2 =.;
015400 IF QUEUE3 =. THEN QUEUE3 =.;
015500 IF QUEUE4 =. THEN QUEUE4 =.;
015600 IF SIO73CNT=. THEN SIO73CNT=.;
015700 IF AVGPHYNQ=. THEN AVGPHYNQ=.;
015800 IF CPUID =. THEN CPUID =.;
015900 IF PCHANWT =. THEN PCHANWT =.;
016000 IF IDWRONG=' ' THEN IDWRONG=' ';
022700 END; /* MVS/370 TYPE 73 RECORD */
XMAC74:
Replace lines 012800 thru 002380 to be:
012800 IF ID=74 AND NOT MVSXA THEN DO;
012900 IF CUBUSY =. THEN CUBUSY =.;
013000 IF DEFERCUB=. THEN DEFERCUB=.;
013100 IF DEFERED =. THEN DEFERED =.;
013200 IF DEFERSVD=. THEN DEFERSVD=.;
013300 IF DEVBUSY =. THEN DEVBUSY =.;
013400 IF LCHAN =. THEN LCHAN =.;
013500 IF PCTDEFCU=. THEN PCTDEFCU=.;
013600 IF PCTDEFER=. THEN PCTDEFER=.;
013700 IF PCTDEFRS=. THEN PCTDEFRS=.;
013800 IF PCTQUEDV=. THEN PCTQUEDV=.;
013900 IF PCTQUEPA=. THEN PCTQUEPA=.;
014000 IF QUEUE0= . THEN QUEUE0 =.;
014100 IF QUEUE1= . THEN QUEUE1 =.;
014200 IF QUEUE2= . THEN QUEUE2 =.;
014300 IF QUEUE3= . THEN QUEUE3 =.;
014400 IF QUEUE4= . THEN QUEUE4 =.;
014500 IF UNITADR= . THEN UNITADR =.;
023800 END; /* MVS/370 TYPE 74 RECORD */
XMAC75:
Replace lines 006500 thru 012000 to be:
006500 IF ID=75 AND NOT MVSXA THEN DO;
012000 END; /* MVS/370 TYPE 75 RECORD */
Thanks to Larry Cecil, First National Bank of Chicago, USA.
Change 07.037 Version 6.6 added variable PRENTIME to PDB.PRINT and its
BUILDPDB BY-list, but the change was incomplete and needed to be
BUILDPD3 fixed (see Change 7.006) and documented (Change 7.036).
Apr 3, 1989 Another exposure to incorrect sort order was seen and is
fixed by this change. The exposure only exists on the
very first run of the new BUILDPDB when PRENTIME does not
yet exist in SPIN library, and only if the same job had
multiple print files with exactly the same PRINTIME on
different devices with one record in SPIN and one record
in today's SMF, AND only if the device names are not in
ascending alphabetical sequence! No one has reported the
exposure, but once noted, it was fixed by this change.
References to JPURTIME in this change fix another first
time exposure induced by Change 7.008, and make JES3
purge records sort order consistent with JES2.
Changes made to both BUILDPDB and BUILDPD3:
BUILDPDB BUILDPD3
018800 019200 LENGTH DEFAULT=4 READTIME PRINTIME PRENTIME 8;
019310 019710 IF PRENTIME=. THEN PRENTIME=.;
019320 019720 IF OUTDEVCE=' ' THEN OUTDEVCE=' ';
019330 019720 IF SYSPRN =' ' THEN SYSPRN =' ';
019410 019810 SYSTEM=SYSPRN;
020110 020510 IF JPURTIME=. THEN JPURTIME=.;
n/a 023900 BY READTIME JOB JESNR JPURTIME;
022900 023300 BY READTIME JOB JESNR PRINTIME PRENTIME OUTDEVCE
SYSTEM;
Thanks to Raymond Zieverink, Belk Stores Services, USA.
Change 07.036 Implementation Considerations for WEEKBLD/MONTHBLD.
WEEKBLD Changes to MXG Software can usually be implemented at any
MONTHBLD time. A powerful feature of the SAS system is its ability
Apr 3, 1989 to add variables to existing datasets and to create new
datasets automatically. To further ease implementation,
MXG logic uses SAS options "NOVNFERR" and "NODSNFERR" to
avoid "variable not found" and "dataset not found" errors
whenever approriate. Unfortunately, the NOVNFERR option
does not work if the variable is in a BY-list. Thus when
Version 6.6 added variable PRENTIME to PDB.PRINT dataset,
we failed to document all that you might have to do to
avoid a "variable not found" or "data set is not sorted"
error in WEEKBLD or MONTHBLD. This is that documentation:
If you implement the new BUILDPDB/3 code on Monday after
you have built your weekly PDB, you will avoid any change
to WEEKBLD, since all of the new daily PDBs will contain
PRENTIME and will be correctly sorted.
If you must implement the new BUILDPDB/3 in the middle of
a week, you must modify WEEKBLD by inserting new line:
003110 PROC SORT;
(between the SET MON.PRINT ... SUN.PRINT; statement and
the BY ... statement). This will create the WEEK.PRINT
by concatenating all seven dailies in unsorted order, but
now WEEK.PRINT will contain PRENTIME (since at least one
of the seven dailies was built with MXG 6.6 code). Then,
WEEK.PRINT is sorted by the original BY list. The only
cost of this modification is the double processing of the
WEEK.PRINT dataset.
You MUST modify MONTHBLD since at least one prior weekly
PDB will have been built before the 6.6 BUILDPDB. You
must remove "PRENTIME OUTDEVCE SYSTEM" from the end of
the MACRO _BYLIST definition for the MONTH.PRINT dataset
in line 016001. As soon as all input datasets used by
WEEKBLD/MONTHBLD have been built with the new version of
MXG, you can remove the modified members from your USERID
SOURCLIB or MXG.CHANGLIB libraries and use the unmodified
MXG code.
Page 263 of the MXG Supplement documented the sort order
of the PDB.PRINT data set, and should now read:
BY READTIME JOB JESNR PRINTIME PRENTIME OUTDEVCE SYSTEM.
Thanks to Bill Salassi, BHP Petroleum, AUSTRALIA.
========Changes thru 7.035 were printed in NEWSLETTER FOURTEEN==========
Change 07.035 If you used the new member IMAC30IO to remove variable
IMAC30IO D3330DRV from the _IO30DR macro defined therein, and you
IMACPDB did NOT also change member IMACPDB to adjust the dummy
Mar 15, 1989 X1-X9 variables, your PDB.JOBS data set contains wrong
values for ALL numeric values in the _SUMSTP macro that
is defined in IMACPDB. The documentation in IMAC30IO was
grossly inadequate, because it did not tell you to read
the instructions in lines 020000-023900 in IMACPDB. This
error affects ONLY the PDB.JOBS data set. Any TYPE30 data
sets and the PDB.STEPS were built correctly, even if you
removed D3330DRV. Also, removing other variables from the
other two macros (_IO30EX and _IO30TM) in IMAC30IO would
not cause any error.
FIX: The simple fix is to simply leave variable D3330DRV in
the MACRO _IO30DR definition in IMAC30IO.
If you really are concerned about the extra four bytes
and do want to delete D3330DRV from your PDB.JOBS and
PDB.STEPS data, you can remove D3330DRV from the MACRO
_IO30DR definition in IMAC30IO, but you must then change
IMACPDB:
a) Line 024400, change DROP=X1-X9 to DROP=X1-X8
b) Line 024700, remove X9 from the SUM= list
Thanks to Trevor Holland, AUSTRALIA.
Thanks to Richard Evans, Mervyn's, USA.
Comments expanded April 9, 1989:
And even if you do delete D3330DRV as described above,
you will still find an UNINITIALIZED value note because
BUILDPDB/3 still have D3330DRV in two length statements
where it should have been changed to _MAXSTP:
BUILDPDB BUILDPD3
051600 051900 change D3330DRV to _MAXSTP
055300 056100 " " "
Thanks to Lucy Fukishima, California Health & Welfare Agency, USA.
Change 07.034 The FMXGUCBL function to dynamically allocate all DASD
FMXGUCBL devices may attempt to allocate a printer device. This is
FMXGUCBL a soft error condition. It turns out that the FMXGUCB7
Mar 15, 1989 function (provided because FMXGUCBL was thought to be an
MVS/XA-only function) actually uses an MVS/XA facility
that was retro-fitted into MVS/370. FMXGUCB7 not only is
usable under MVS/XA, it does not try to allocate printer
devices! This change replaces FMXGUCBL member with the
contents of FMXGUCB7, changes FMXGUCB7 therein to read
FMXGUCBL, and deleted member FMXGUCB7.
Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
Thanks to Dan Squillace, SAS Institute Cary, USA.
Change 07.033 The VTOC processing example in member TYPEVTOC should use
TYPEVTOC %VMXGVTOC instead of the erroneous %_MXGVTOC, and comment
TYPEVTOC refering to member VMACVTOC should have been VMXGVTOC.
Mar 15, 1989 Member VMACVTOC was replaced by VMXGVTOC and now VMACVTOC
has been deleted to avoid the confusion.
Thanks to Chun-Heng Liu, Brooklyn Union Gas, USA.
Change 07.032 MVS/ESA-only variables for SQA, LPA, CSA, LSQA, and REGS
VMAC71 frames in CS (Central Storage, formerly Real Storage) and
Mar 15, 1989 in ES (Expanded Storage, formerly Extended Storage) are
missing. The test in these lines should have been:
083000 IF VERSNRMF GE 410 AND LENPGDS GE 504 THEN DO;
085600 IF VERSNRMF GE 410 AND LENPGDS GE 536 THEN DO;
Thanks to Don Friesen, B.C. Systems, CANADA.
Change 07.031 RMF Monitor III variables in Subtype 2 SMF Type 72 record
VMAC7072 (MVS 3.1.0e only) WSETACT WSETIDL WSETDIV WSETFIX WSETASM
Mar 15, 1989 need zero divide protection in lines 165794 thru 165810:
IF denominator GT 0 THEN WSETACT = numerator/denominat
ELSE WSETACT=.;
Thanks to Don Friesen, B.C. Systems, CANADA.
Change 07.030 In member ASUMCICS the label in line 009100 for variable
ASUMCICS RESPBKT6 should be 8 SEC instead of 6 SEC. Additionally,
VMXGSUM in member VMXGSUM the example in comments for "min, max,
Mar 15, 1989 and sum" actually calculated mean, max and sum (and also
misspelled statistics).
Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
Change 07.029 An unexpected limitation of CMS SAS (although it is noted
new macros in a documentation footnote): new style %MACRO names are
Mar 9, 1989 limited to seven position names! Current MXG %MACROs that
are now eight-characters long: ANALDB2R ANALDMON ANALNSPY
GRAFRMFI GRAFTRND IBM3287F PCONLINE VMXGGOPT and ZETAFOIL
Thanks to J. D. Hill, CyCare Systems, USA.
Change 07.028 Value tested for RECFM=VM should have been (line 003200):
VMACRCFM 003200 ELSE IF RECFMT='0100001.'B THEN RECFM='VM ';
Mar 9, 1989
Thanks to Mr. Rathfelder, Taylorix, GERMANY.
Change 07.027 Beginning and ending times of DB2 reports were taken from
ANALDB2R SMF timestamp and not the actual interval, causing loss
Mar 9, 1989 of first interval.
Line 089300 Change VAR SMFTIME; to VAR QWHSSTCK DURATM;
Line 089400 Change MIN=MINSMF MAX=MAXSMF; to
MIN=MINSMF MAX=MAXSMF SUM=X1 DURATM;
Thanks to Jan van Lent, Fokker, NETHERLANDS.
Change 07.026 DOS/VSE POWER records have again (incompatibly) changed
IMACDOS the location of the RECID and the OFFSET that need to be
Apr 26, 1989 set in IMACDOS. IMACDOS now defaults to DOS 2.1.7.
VSE Version OFFSET value RECID @xx value
3.1.2 0 @43
2.1.7 8 @51
2.1.3 16 @59
Earlier 0 @43
Note that processing DOS data usually requires the JCL
LABEL parameter of (,NL) or (,LTM).
Thanks to Bill Sikora, EDS Auburn Hills Mi, USA.
Thanks to Barry Debenham, Cigna Services, ENGLAND.
Change 07.025 Cache DASD SMF record variables RWRATIO and READHR could
VMACACHE be non-zero even though there was no activity to a device
Mar 9, 1989 because they were not reset missing from the prior device
segment in the same record. Insert two new lines:
051410 ELSE RWRATIO=.;
051510 ELSE READHR=.;
to reset when the denominators are zero.
Thanks to Ray Dickensheets, Yellow Freight System, USA.
Change 07.024 IDMS 10.2 Performance Monitor data written to Journal and
TYPEIDMJ not to SMF was not correctly handled. There is a header
Mar 9, 1989 of 20 bytes when data is written to the IDMS journal that
is not in the SMF format data. Change to read
001100 INPUT +20 PMSTYPE PIB1.
(and make sure IMACIDMS was updated with the same value
set by #PMOPT RECID= in your IDMS gen.)
Thanks to Mike Eisenhart, York International, USA.
Change 07.023 The PROC DATASETS NOLIST; DELETE DUMMY. _DSET; in the old
MONTHBLD definition of _MNTHBLD is not acceptable to SAS. The full
Mar 8, 1989 dataset name is not supported in the DELETE statement. In
place, and also at the end of the new definition which
follows the old definition, the correct syntax added is:
PROC DATASETS DDNAME=DUMMY NOLIST; DELETE _DSET:
All this simply keeps the DUMMY library at minimum size.
Thanks to Pat Stockel, New Jersey Educational Computing Network, USA.
Change 07.022 Reading SMF data with the CMS version of SAS will cause a
VMACSMF DMSSOP0363 Code 04 OPEN error. The CMS Version of SAS is
Mar 8, 1989 limited by IBM's CMS OS Simulation code, which does NOT
support LRECL=32760, even though SMF records can contain
a real LRECL of 32760. MXG Version 6.6 did change the
LRECL value in _SMF macro in VMACSMF from 32756 to 32760
precisely because we encountered STOPOVER abends when SMF
data with real LRECL=32760 was encountered. If you must
process your SMF data under CMS SAS, you will need to
change the LRECL in the _SMF macro to 32756, and try it.
If the actual SMF data contains records actually 32760
bytes LRECL, you will STOPOVER abend, but if there are
no records that long you will be home free. If you do
have actual LRECL=32760 physical records, there may be
no immediate solution, but please call. (The IBM limit
is described on page 172 of SC19-6209 for VB and VBS
support under CMS Release 4). I have an open problem
with IBM on this IBM limitation.
Thanks to J. D. Hill, CyCare Systems, USA.
Change 07.021 Sample CMS REXX EXEC for testing of MXG had the wrong
REXXTEST name for the FILEDEF in line 000523. Change MONWRITE to
Mar 7, 1989 MWINPUT (and also in line 000524 change DIKS to DISK).
Thanks to J. D. Hill, CyCare Systems, USA.
Change 07.020 CICS sample reports for AMXT and CMXT task delays could
ANALCICS require lots of work space because all CICSTRAN variables
Mar 7, 1989 were kept. This change keeps only the needed variables.
Remove semicolon from line 043300 and insert new line:
043310 (KEEP=APPLID TERMINAL STRTTIME ENDTIME TRANNAME);
Thanks to Janet Davis, Anchor Systems, USA.
Change 07.019 IBM documents SMF type 30 triplets (offset,length,number)
VMAC30 as present if "number" is non-zero, but one site found a
Feb 20, 1989 record with length=0 and non-zero offset and number. (In
addition, the offset put this section in the middle of
the EXCP section!) Though this is probably an APARable
IBM problem, it caused MXG a STOPOVER abend. As a result,
MXG added a nonzero length test to each test for offset
and number, and then compares the record length to the
offset+(length*number)-1 to protect MXG from yet another
potential IBM data error. Whenever a bad triplet is found
MXG prints an error message on the log, then deletes the
bad record and continues processing the SMF data.
Added Apr 5, 1989: ACCT section variable NRACCT does NOT
count the number of sections of length LENACCT, instead
NRACCT is the count of accounting fields within the one
account segment of length LENACCT. Test for ACCT is thus
offset+length-1.
Thanks to John Brown, Performance Systems Incorporated, USA.
Change 07.018 The variable DEVICE for a Channel-to-channel adapter
VMACUCB was OTHER. This minor change now sets DEVICE='CTC'.
Feb 15, 1989 Add new line
004110 ELSE IF DEVCLASS=41X THEN DEVICE='CTC';
Thanks to Bill Mullen, BGS, USA.
Thanks to Rodney L. Reisch, General Electric Plastics, USA.
Change 07.017 Type 80 SMF records for RACF Version 1 Releases 8.1 and
FORMATS 8.2 were already supported by MXG 6.6! There is only one
VMAC80 new flag field and three new values of RACFQUAL (204-206,
Feb 15, 1989 whose meaning can easily be deduced from Table 1 in the
Appendix 10 of SC28-1343-4) added by RACF 1.8, and none
are significant. This change creates variable RACFRE2
and adds three values to the MXG MG080QU. format.
Change 07.016 This VM/370 HPO-only change affects user class variables
VMACVMON DRPCANUS, DRPPOPUS, and RPCUMUS in VMONUSRD and VMONUSRS
Mar 8, 1989 and their values in VMONPERF. DRPCANUS and DRPPOPUS were
never de-accumulated and have always been wrong. In VM
HPO (version 4.2 and version 5, although documented only
for version 5) the user class record was incompatibly
changed by IBM, affecting the other user class variables
input after DRPPOPUS. This should be low impact for most
VM/370 HPO sites (unless, of course, you need the data!).
a.This part supports the incompatible changes documented in
Release 5 HPO, which have also been found (almost exact,
missing only the new VMACNT field) in HPO 4.2 data.
I don't yet know the PTF which made the 4.2 changes.
Move line 246700 to after 248600
Change line 246800 GE to EQ
Replicate lines 246800 to 248100
Change line 248110 EQ 178 to GE 192
Copy 246200 to 246500 after 248110
Change 248111 from PIB4. to PIB8.
Remove @133 @135 @137 from 248112 thru 248114
Change @139 PPSTSWUS PIB2. (line 248120) to
@145 PPSTSWUS PIB4.
Change line 248130 from PPSTPPUS PIB2. to PPSTPPUS PIB4.
b.This part applies to both HPO releases and corrects the
DPRCANUS and DRPPOPUS variables (and eliminates their
meaningless average and maximum value variables DRP...AV
and DRP...MX).
New Lines:
315910 DRPCANUS=DIF(DRPCANUS);
315920 DRPPOPUS=DIF(DPRPOPUS);
319910 IF . LT DRPCANUS LT 0 THEN LOGON=1;
319920 IF . LT DRPPOPUS LT 0 THEN LOGON=1;
322810 DRPCANUS=.;
322820 DRPPOPUS=.;
Line 328700 (follows /*AVG), DRPCANUS DRPPOPUS. This line
must be moved immediately following 329400 (DEFRQ).
Line 330800 change X12 to X10.
Lines 331000 and 331200, remove DRPCANAV DRPPOPAV.
Line 331500 remove X11 X12.
Line 331800 add DRPCANUS DRPPOPUS after DEFRQ.
Lines 333900 thru 334200 (Labels for DRP...), delete.
Line 338100 remove DRPCANAV DRPCANMX DRPPOPAV DRPPOPMX
Thanks to Ron Roberts, The Equitable Life Assurance Society, USA.
Change 07.015 This new member will be incomplete in your source library
ANALALL even though the complete member is on the source tape!
Feb 15, 1989 The member (to read SMF and print all records from a job)
contains IEBUPDTE ./ control cards, which were processed
(unexpectedly) by IEBUPDTE in creating your MXG.SOURCLIB!
Had you looked at the IEBUPDTE log, you would have seen a
IEB816I message for ANALALL, followed by three IEB816I
messages for IMACJBCK, IMAC30DD, and IMACINTV which were
actually part of ANALALL! (Later in the log you would see
the real IMACJBCK,IMAC30DD,IMACINTV create with IEB817I.)
To create the ANALALL member, copy the source tape to a
sequential dataset on disk (IEBGENER,FB,80,6160), with
SPACE=CYL(1) and DISP=(,CATLG,CATLG). The job will ABEND
with B37, but the one cylinder data set will contain the
ANALALL member. Then use your editor to block copy the
lines between ./ ADD NAME=ANALALL & ./ ADD NAME=ANALAUDT.
I have changed the "./" to "XY" and added comments to
change them back to avoid the problem in the future.
Change 07.014 The Assembler parameters OJB/OBJECT and SYSLIN/SYSGO may
EXITMONI be different for different levels of ASM. Assembler XF
Feb 15, 1989 (IFOX00) used SYSGO and OBJ. Early Assembler H (IEV90)
required SYSLIN and OBJECT, and if OBJ was used, NOOBJECT
was set (with no condition code) and no object deck was
created, causing the LINKEDIT step to fail. An old PTF
(PP29236) to ASM H allows either OBJECT or OBJ (probably
as a result of ASM XF user complaints), even though only
OBJECT is actually documented for ASM H. This change is
for info only, and was revised after Newsletter FOURTEEN.
Thanks to John McAlpine, CSX, USA.
Thanks to Bob Rutledge, CSX, USA.
Change 07.013 This is an interesting problem. Three separate STOPOVER
VMACVMON abends were encountered on three different VM/SP records
Feb 15, 1989 that were shorter than expected. The culprit turned out
to be an error in VM Systems Group's VCOPY Product (a
replacement for IBM's CMS COPYFILE command). This site
used IBM's COPYFILE to copy VM/Monitor data. COPYFILE has
has an option "TRUNC" (although IBM's default is NOTRUNC)
that truncates blanks (X'40') when a fixed length file is
converted to a variable length file (to save DASD space).
When VCOPY replaced IBMs COPYFILE, its default of TRUNC
and a coding error in VCOPY (now fixed by Fix Co0263) had
truncated all X'40's at the end of VM monitor records!
If you have VCOPY, you can either request the fix from
the vendor, change their system wide default to NOTRUNC,
or specify NOTRUNC on the COPYFILE statement to avoid
the unexpected data trunction. Hopefully, you will not
encounter the problem, but the MXG circumventions made
(before the truth was known) were left in place!
Change line 212800 to read:
INPUT @9 USER : $8. @; /*MN098UID*/
Change line 216400 to read
IF LENDATA GE 1 AND LENDATA+19 LE LENGTH THEN
Insert two new lines after 229400:
229410: @;
229420: IF LENGTH GE 40 THEN INPUT
Thanks to Steve Smith, Hammermill Paper Co, USA.
Change 07.012 MVS/ESA TYPE1415 data now uses three bits of SMF14RIN to
VMAC1415 indicate ILIB managed data set (Bit 0 on), Trunc macro
Feb 15, 1989 issued (Bit 1 on) and/or Null segment encountered (Bit 3
on). MXG read byte one of SMF14RIN as variable RECIND1 &
byte two as RECIND2, but kept only RECIND1 (because all
bits in RECIND2 were formerly reserved). This change adds
RECIND2 to the KEEP list for TYPE1415.
Change 07.011 -In a major enhancement to CPU data capture in MVS/ESA,the
IMACPDB type 30 SMF records capture three new CPU measures:
VMAC30
VMAC434 CPUHPTTM - Hiperspace CPU. The CPU time used to read from
VMACSMF and write to hiperspaces by this step/job.
Feb 15, 1989 CPUIIPTM - CPU I/O SLIH time. The CPU time used by the
Second Level Interrupt Handler in servicing
I/O requests for this step/job.
CPURCTTM - Region Control Task CPU Time. The RCT handles
QUIESCE and RESTORE and thus predominately is
involved in SWAP management. This CPU measure
should significantly help TSO capture.
All three CPU measures are NOT captured in the RMF TYPE72
performance group data, nor are they in the type 4 or 34
step records. While the CPUHPTTM is a new measure of an
MVS/ESA-only activity (movement in/out of hiperspaces),
the CPUIIPTM and CPURCTTM now capture CPU times that have
been THE major contributor to uncaptured CPU times: I/O
interrupt handling and TSO swap processing.
IBMs CPU timing comparisons in the DFSORT 11 announcement
(289-036) use the sum of ALL CPU measures (the three new,
plus the two TCB measures AND the two SRB measures). For
those of you who have had trouble convincing your bosses
to use TCB plus SRB for billing, etc., you can use this
example from big blue! Note that IBM refers to "five"
CPU fields, but there are really seven fields now.
-Variables RECLAIMS, COMRECLM, and LPARECLM in TYPE30 and
TYPE434 (and hence in PDB.STEPS and PDB.JOBS) no longer
exist in MVS/ESA. In their same location are three new
MVS/ESA only variables:
CREADMIS - Incorrect CREADS. Number of misses when an
attempt to read data from an expanded-storage-only
hiperspace failed because the data was not found (was
variable RECLAIMS)
HIPAGINS - Hiperspace pageins from auxiliary storage
into processor storage (was variable COMRECLM).
HIPAGOUT - Hiperspace pageouts (was variable LPARECLM).
MXG 6.6 will "Tolerate" the new CPU fields (i.e. execute
without error), but for MXG to be "Capable" (i.e., to
create the new CPU fields in TYPE30 and PDB.JOBS/STEPS
data sets, and to create the three Hiper-related fields
you must make the following changes:
-In member VMAC30:
-Add the three CPU variables (CPUHPTTM,CPUIIPTM,CPURCTTM)
and the Hiper variables (CREADMIS,HIPAGINS,HIPAGOUT) to:
-KEEP list for TYPE30_V, TYPE30_4, TYPE30_5, TYPE30_6.
-LABEL statement.
c. CPU vars only to FORMAT statement for TIME12.2 format.
-Delete the CPUTM=SUM( ... ); statement, line 056800.
-Insert the following seven lines after line 057500:
IF LENCPU GE 56 THEN INPUT
CPUIIPTM PIB4.2
CPURCTTM PIB4.2
CPUHPTTM PIB4.2
@;
CPUTM=SUM(CPISRBTM,CPITCBTM,CPUHPTTM,CPUIIPTM,
CPURCTTM,CPUSRBTM,CPUTCBTM);
-Insert these lines after line 062000 (contains @;):
(Note that in the MXG implementation this change is more
extensive; variable MVSESA is now created by VMACSMF for
MVS/ESA. This change avoids that additional Edit.)
IF MVSXAFLG='....1...'B THEN DO; /* MVS/ESA */
CREADMIS=RECLAIMS;
HIPAGINS=COMRECLM;
HIPAGOUT=LPARECLM;
RECLAIMS=.;
COMRECLM=.;
LPARECLM=.;
END;
-In member IMACPDB add the six new variables (CPUHPTTM,
CPUIIPTM,CPURCTTM,CREADMIS,HIPAGINS,HIPAGOUT) to:
-The _PDB30_4 definition at lines 013200-013300.
-The _SUMSTP definition at lines 017700-017800.
Thanks to Dave Greene, Kwasha Lipton, USA.
Change 07.010 DB2 reports had minor errors. The use of "ALL" (to create
ANALDB2R reports for all plans, all ids, etc.) was removed in MXG
VMAC102 6.6 (but not specifically documented) because you might
Feb 17, 1989 have "ALL" as a plan name, etc. Now, to create reports
for "all" of something, use the default (by specifying no
value for the argument).
In ANALDB2R:
Line 235800 and 235900 must be reversed so DB2COUNT+1
precedes the CALL SYMPUT statement.
Line 254300 should be QWPZTOUT and line 255100 should
be QWPZISWI. (They are reversed).
In VMAC102:
Insert new line after 081900:
QWPZTRSZ=QWPZTRSZ*4;
Thanks to Ervin Claxon, Ashland Oil, USA.
Change 07.009 Processing multiple VM/XA Monitor files will cause the
VMACVMXA "Range is Repeated" error message in attempting to create
Feb 16, 1989 the temporary Format which maps Device Information to the
RDEVSID value. Duplicate RDEVSID values do exist in the
VXMTRDEV data set, but MXG's logic to remove duplicate
values incorrectly included BEGINMTR in the BY statement.
FIX: Remove BEGINMTR from both BY statements in lines 678500
and 678800.
Thanks to Ray Dickensheets, Yellow Freight System, USA.
Change 07.008 The JES2 Spool Transfer program causes multiple job purge
BUILDPDB records. If a job which is still in the execution queue
Mar 11, 1989 after it has been executed (eg., a job which encountered
a DSENQ conflict that was canceled and requeued, or any
job processed by the MVS Throughput Manager product) is
spool transfered and reloaded, two purge records will be
created (one at offload, one after real execution) and
both contain non-blank values for SYSEXEC. A non-blank
SYSEXEC separated the "real" purge record (for PDB.JOBS)
from the multiple NJE purge records (into PDB.NJEPURGE).
If two (or more) purge records with non-blank SYSEXEC are
found in the same BUILDPDB run, duplicate observations in
PDB.JOBS were built. The use of just SYSEXEC to identify
"real" purge records is insufficient. Part of this fix is
a guarantee that only one "real" purge record is used by
MXG, even if multiple are found. The other part of the fi
selects the purge record created at offload by JES2 Spool
Transfer program (DEVNAME, Transmit Device Name beginning
with OFF) into the PDB.NJEPURGE data set. If your site
does not use Spool Transfer, you have no exposure.
FIX: 1.BUILDPDB.
Insert new line after 014200:
014210 DEVNAME=:'OFF' OR
Add JPURTIME to the end of the BY list at line 023500.
Insert new line after 023600:
IF LAST.JESNR THEN OUTPUT;
2.IMACPDB
Add DEVNAME to line 008600 (inside _PDB26J2 macro).
Thanks to Don Friesen, B.C. Systems, CANADA.
Change 07.007 MONTHBLD on the MXG 6.6 Library causes a SAS 180 SYNTAX
MONTHBLD error. In making the member more comsmetically appealing,
Feb 14, 1989 the invocations of _MNTHBLD ended up ending in column 72.
Since the next line starts with MACRO, SAS combined the
end of one line with the beginning of the next to create
the string _MNTHBLDMACRO, which SAS cannot recognize!
FIX: Delete the blank before the percent sign in each line
than ends with _MNTHBLD in column 72.
Thanks to John Mattson, National Medical Enterprises, USA.
Change 07.006 Variable PRENTIME in PDB.PRINT was added to the sort list
BUILDPDB in BUILDPDB but was left in a DROP list in BUILDPDB/3 and
BUILDPD3 not added to the BY list in WEEKBLD. This caused PRENTIME
WEEKBLD to not exist in PDB.PRINT and caused WEEKBLD to ABEND.
Feb 9, 1989
FIX: 1.BUILDPDB: remove PRENTIME from DROP statement line 048300
2.BUILDPD3: remove PRENTIME from DROP statement line 048700
3.WEEKBLD: add PRENTIME to line 003200 between PRINTIME and
OUTDEVCE.
Thanks to John Mattson, National Medical Enterprises, USA.
Thanks to Gary Ruedinger, Response Graphics, USA.
Change 07.005 DB2 Trace 102 SMF record subtype 58 or subtype 87 caused
VMAC102 STOPOVER ("Input exceeded record length") for DB2 1.3 or
Mar 11, 1989 earlier records.
FIX: Insert new line after line 163900:
163910 @; IF QWT02R1L GE 302 THEN INPUT
Add PIB4. after QW0087FR in line 144400.
In subtypes 15,17,18,22,53, and 58 incorrect calculations
caused the input to end before all fields had been read.
Change ENDPROD to ENDPRODA in lines 098200,250800, and
255600.
Change OFFPROD to OFFPRODA in lines 160200,166400,
260400, and 263900.
Thanks to Jan-Ake Christoffersson, Gotabankendata, SWEDEN.
Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
Change 07.004 NPM type 28 produces "Unexpected Subtype" message for 08X
VMAC28 NPMSUBTY for the ENABLE NSA event record.
Feb 7, 1989
FIX: Change first occurrence of 09X in line 197600 to 08X.
Thanks to Michelle Buchecker, IBM Boulder, USA.
Change 07.003 JCL for HSM processing included non-existent testing name
JCLHSM of XMXGHSM.
Feb 7, 1989
FIX: Change XMXGHSM to VMXGHSM in line 006600.
Thanks to Billy Westland, Candle Corporation, USA.
Change 07.002 MXG variable CPUTM in the CIMSTRAN data set from IMF data
VMACCIMS from Boole & Babbage did not include all CPU variables,
Feb 7, 1989 and the variable was not in the KEEP list. Also, SERIALIO
was not protected if it overflowed its two byte counter.
FIX: 1.Insert new line 002410 (after 002400) containing CPUTM
2.Add CPUCOPTM,CPUMOPTM, to the SUM function arguments
in line 044000.
3.Add CPUCOPTM,CPUMOPTM,CPUSBFTM,CPUSDLTM,CPUSOPTM,
CPUDB2TM to the SUM function arguments in line 070400.
4.Change LE 12 to LE 13 in line 065900.
Thanks to Kenneth D. Jones, Maritime Telephone and Telegraph, CANADA.
Thanks to Agneta Bergsten, SPP, SWEDEN.
Change 07.001 TREND data base code fixes. Always specify SAS Options
GRAFTRND MACRO and DQUOTE when using %MACROs. GRAFTRND will only
TRNDJOBS produce first and last pair of graphs if MXG Version 5.5
TRNDRMFI PDBs were used (because SU_SEC variable did not exist in
TRND72 RMFINTRV until 6.6). When a macro variable is set by data
PDBTREND value in a data step, a RUN; statement seems required at
VMXGSUM the end of the data step to actually set the macro value.
Mar 9, 1989
FIX: 1.GRAFTRND: Change all occurrences of OTHRn (ten separate
times for n=0,1,...,9) to OTHn (without the R).
Line 007800 add OTH6CPU OTH7CPU OTH8CPU OTH9CPU
Insert two new lines:
011310 RUN;
017110 RUN;
2.TRNDJOBS line 002300 Add NUMJOBS after SUM= (before IWT)
3.TRNDRMFI:
Insert new line after 001200:
001210 %INCLUDE SOURCLIB(VMXGSUM,VMXGDUR);
Line 001400 add (IN=INWEEK) after WEEK.RMFINTRV
Lines 002600,29,32,35,38,41,44,47,50,53,56,59,62,65,68,75
add BATCNT TSOCNT IMSCNT CICSCNT OTHRCNT OTH0CNT
OTH1CNT OTH2CNT OTH3CNT OTH4CNT OTH5CNT OTH6CNT
OTH7CNT OTH8CNT OTH9CNT TRIVCNT to respective line.
Lines 011400,115,117,119,121,123,125,127,129,131,133,135
137,139,141,143 change / ....TRAN to / ....CNT
respectively.
Insert new line after 014500:
014510 IF INWEEK THEN DO;
Insert new lines after 014700:
014710 END;
014711 IF SU_SEC =. THEN SU_SEC=.;
014712 IF PARTNCPU=. THEN PARTNCPU=.;
014713 BATCNT=BATTRAN*DURATM;
014714 TSOCNT=TSOTRAN*DURATM;
. (one for each of the 16 ...CNT variables added
. in lines 002600-007500 above)
014727 OTH9CNT=OTH9TRAN*DURATM;
014728 TRIVCNT=TRIVTRAN*DURATM;
After line 15400 insert
DROP BATCNT TSOCNT IMSCNT CICSCNT OTHRCNT OTH0CNT
OTH1CNT OTH2CNT OTH3CNT OTH4CNT OTH5CNT OTH6CNT
OTH7CNT OTH8CNT OTH9CNT TRIVCNT;
4.TRND72 line 001400 Semi-colon must be a comma
5.PDBTREND line 009500 %GRAFTRN must be %GRAFTRND
insert new lines after 011200:
011210 PROC SORT;
011220 BY SYSTEM PERFGRP;
6.VMXGSUM:
line 025900 Add DATETIME &DATETIME 8 before semicolon
new line 025910 IF DATETIME=. THEN DATETIME=.;
line 035400 Add DATETIME &DATETIME 8 at end of line
new line 035510 IF DATETIME=. THEN DATETIME=.;
Thanks to Alan W. Maloney, Telenet Communications, USA.
Thanks to J. D. Hill, CyCare Systems, USA.
Thanks to Pete Shepard, Ashland Oil, USA.
Thanks to Rich Lopez, Ethicon, USA.
LASTCHANGE: Version 7
This page is (almost) blank (intentionally).
End of Changes Log, but how's this for page filler, printed verbatim
from an entry in IBM's INFO/SYS (SMF6CPS is COPIES in TYPE6):
E343725 (HIT LIST 000003/000013)
LINES: 1 THRU 15 OF 15
H E343725 S=TOOLS C=GY4 D=JUL89 E=JUL91 L=00015
TITLE: PSF NOT UPDATING SMF6CPS FIELD IN TYPE 6 SMF
RECORDS.
F -SUGG -OY21704--5665-27-501--IN-INCORROUT
REPORTED RELEASE R220
ERROR DESCRIPTION:
SMF6CPS IS NOT UPDATED CORRECTLY.
COMMENTS:
THIS APAR IS BEING CLOSED SUG (SUGGESTION). THE SUGGESTED
Change WILL NOT BE IMPLEMENTED.
89/07/19,CHICAGO FS