COPYRIGHT (C) 1984-2023 MERRILL CONSULTANTS DALLAS TEXAS USA
MXG CHANGES 16.16
=========================member=CHANGE16================================
/* COPYRIGHT (C) 1984-1999 MERRILL CONSULTANTS DALLAS TEXAS USA */
MXG Version 16.16 is dated Feb 20, 1999, thru Change 16.394.
Newsletter THIRTY-FIVE was dated Feb 20, 1999, thru Change 16.367.
First MXG Version 16.10 was dated Feb 8, 1999, thru Change 16.364.
MXG Version 16.09 was dated Jan 20, 1999, thru Change 16.334.
MXG Version 16.08 was dated Dec 23, 1998, thru Change 16.315.
Last MXG Version 16.07 was dated Dec 5, 1998, thru Change 16.299.
First MXG Version 16.07 was dated Dec 4, 1998, thru Change 16.296.
Last MXG Version 16.06 was dated Dec 2, 1998, thru Change 16.292.
Fifth MXG Version 16.06 was dated Nov 30, 1998, thru Change 16.289.
Fourth MXG Version 16.06 was dated Nov 21, 1998, thru Change 16.285.
Third MXG Version 16.06 was dated Nov 18, 1998, thru Change 16.284.
Second MXG Version 16.06 was dated Nov 17, 1998, thru Change 16.279.
First MXG Version 16.06 was dated Nov 16, 1998, thru Change 16.278.
MXG Version 16.05 was dated Nov 1, 1998, thru Change 16.259.
Fourth MXG Version 16.04 was dated Oct 19, 1998, thru Change 16.242.
Third MXG Version 16.04 was dated Oct 9, 1998, thru Change 16.231.
Second MXG Version 16.04 was dated Oct 7, 1998, thru Change 16.224.
Newsletter THIRTY-FOUR was dated Sep 30, 1998, thru Change 16.221.
First MXG Version 16.04 was dated Sep 30, 1998, thru Change 16.221.
Beta 6 MXG Version 16.03 was dated Sep 23, 1998, thru Change 16.216.
Beta 5 MXG Version 16.03 was dated Sep 9, 1998, thru Change 16.196.
Beta 4 MXG Version 16.03 was dated Aug 11, 1998, thru Change 16.171.
Beta 3 MXG Version 16.03 was dated Jul 15, 1998, thru Change 16.147.
Beta 2 MXG Version 16.03 was dated Jul 14, 1998, thru Change 16.147.
Beta 1 MXG Version 16.03 was dated Jul 10, 1998, thru Change 16.147.
Final MXG Version 16.02 was dated Jun 8, 1998, thru Change 16.120.
First MXG Version 16.02 was dated Jun 2, 1998, thru Change 16.112.
Real MXG Version 16.01 was dated Apr 9, 1998, thru Change 16.053.
First MXG Version 16.01 was dated Apr 8, 1998, thru Change 16.052.
MXG Version 15.15 was dated Feb 23, 1998, thru Change 15.391.
Newsletter THIRTY-THREE was dated Feb 23, 1998, thru Change 15.382.
Contents of member CHANGES:
I. MXG Software Version 16.16 is now available.
II. MXG Technical Notes
III. MVS Technical Notes.
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. Incompatibilities and Installation of MXG 16.16.
X. Online Documentation of MXG Software.
XI. Changes Log
I. MXG Software Version 16.16 was shipped with Newsletter THIRTY-FIVE.
1. Major enhancements added in MXG 16.16 (not printed in Newsletter 35)
Support for CA UniCenter Unix Performance Monitor.
Support for TMON for CICS Version 2 PTF TH01129
Support for NETSPY Version 5.2 (COMPAT).
Support for new SNA BASE and IBM SNA objects.
ANALHSM rewritten as %MACRO, new thread use/queue measures.
XSUM70PR created to not-count ICF partition's CPU as a CPU.
Trending member for PDB.SMFINTRV / TYPE30_V dataset.
Automatically tailor BUILDPDB with the new UTILBLDP utility.
CPU increase (16.06-16.10) in BUILDPDB due to CICINTRV corrected.
Major enhancements added in MXG 16.10:
OS/390 R2.7, CICS TS 1.3 and DB2 6.1 were supported in MXG 16.09
and that support is now documented. See 16.09 enhancements.
Support for IDMS Version 14 Journal Records.
Support for Sterling's SOLVE NetMaster TCP/IP SMF.
Support for BETA93 subtypes 1,2,3,4,20,40,41,42.
Support for WINDOWS NT 5.0 (INCOMPATIBLE) with NTSMF.
Support for new NT 4.0 objects.
Major enhancements added in MXG 16.09 (revised):
Support for Year 2000 kept julian date fields input as 0cyyddd.
Support for CICS TS 1.3 (INCOMPATIBLE):
Lots of new CICSTRAN data, including Java execution
and wait times and web statistics, and new statistics data for
each of the now-eleven CICS TCBs. See Change 16.322.
Support for DB2 Version 6.1 (COMPATIBLE).
New header identifies end user's USERID and TERMINAL, more
wait information, CPU time for Stored Procs and Triggers and
User Defined Functions (with SQL time separated). Change 16.318.
Support for OS/390 Release 2.7 (COMPATIBLE)
New Type 74-6 HFS Global/Buffer/File Statistics, Type 73/79 CPMF
mode, Type 70 Dec/Shared Processors Changed, new type 74 time of
Device-Active-Only, and OS/390 Firewall Server Log Messages are
written in new Type 109 SMF record. See Change 16.329.
Major enhancements added in MXG 16.08:
Support for APAF for more than 8 CPU Engines.
Support for BETA93 Release 3.1.3 INCOMPATIBLE subtype 0, 20.
VMXGSUM will use new INHERIT if executed under SAS Version 7.
IMS 6.1 support corrected for APPC, CPIC driven transactions.
Support for DOS/VS Power V6.3.0 (COMPATIBLE).
Revisions to RMM EDGR support - numeric date variables.
Major enhancements added in MXG 16.07:
Support for APAF 4.1 and 4.3 (INCOMPATIBLE).
Support for BETA93 Release 3.1.3 INCOMPATIBLE subtype 21.
ANALRMFR RMF reports added REPORT=XCF.
Major enhancements added in MXG 16.06:
Support for NPM 2.4, unfortunately very INCOMPATIBLY changed!
PDB.CICINTRV dataset may be real bad; please get this new code!
Support for CICS TS 1.2 Journal Format, INCOMPATIBLE.
Support for PSF/MVS Release 3.1.0 (COMPATIBLE).
Support for subtypes 17-20 (FSRTYPE=) HSM FSR records.
Support for IXFP / ICEBERG fields added by APAR L170017.
Support for Boole & Babbage MainView for CICS CMRDETL file.
Correction for SMF 118 TCP/IP logic to not use length/subtype.
MXG 16.04-16.05 only. ASUM70PR summarized to SHIFT vice HOUR.
Major enhancements added in MXG 16.05:
Fix for TMS5 multi-datasets tapes (was wrong).
Fix for IMS 6.1 Log Records (TYPEIMSA) if GMT Offset was not zero.
Support for OAM (Optical Access Method) SMF type 85 record
Support for DFSORT Release 15 (no change)
Support for Interlink TCPaccess Vers 5.2 (INCOMPAT)
Support for decompression of MainView history files.
Support for RACF "installation-defined data field".
ML-18 of MXG ASMTAPES MXGTMNT monitor fixes DSAB circular queue.
Major enhancements added in MXG 16.04:
2. MXG 16.04 is a major internal redesign of MXG, the new "MACKEEP"
architecture, which makes tailoring of MXG datasets simpler and more
powerful. You can change the output DDNAME for a large dataset with
a simple "%LET Pdddddd=DDNAME;" statement, you can put all of your
MXG changes in the single member IMACKEEP (instead of having to EDIT
an IMACxxxx for each product), or you can even tailor MXG instream
using the new "%LET MACKEEP = ;" logic, and never have to EDIT any
members into your USERID.SOURCLIB!. This redesign to externalize
all attributes of every dataset began in MXG 10.10 with the "_L,_K"
macros; now that the software is finally done, I can get back to the
rewrite of MXG documentation (but note that member DOCMXG already
exists to document the new architecture, with examples!).
And most, if not all, of your existing MXG tailoring should still
work without change!
"MACKEEP" Architecture of MXG-built SAS "Datasets"
Highlights
Everything about the creation of an MXG dataset is now
fully externalized, and ALL MXG tailoring can now be done
either by
EDIT into a single member, IMACKEEP (instead of EDITing
a separate IMAC for each product)
or
all tailoring can be done "instream" using the new syntax
%LET MACKEEP= MACRO _oldname newvalue % ;
All MXG datasets now have an &Pdddddd macro variable as the
destination DDNAME/LIBREF, so you can use %LET Pdddddd=MYDD;
in IMACKEEP or with MACKEEP to change the DD to which each
MXG dataset is written or read from.
See member DOCMXG, INSTALL, and Change 16.134 for details.
Major enhancements added in MXG 16.04:
MXG "MACKEEP" Architecture - see INSTALL, DOCMXG, Change 16.134.
Support for OS/390 Release 2.6 (COMPATIBLE).
Support for IMS Log processing for IMS 6.1.
Support for NTSMF Version 2.2.
Support for ACF2 Version 6.2 type 'V' (INCOMPATIBLE).
Support for TCP/IP 3.4 SMF type 118 (INCOMPATIBLE) changes.
Support for NCR Teradata DBS performance data.
Support for Landmark's SQL/CAPTURE Products 'D6' record.
Support for XCOM Release 3.0 (COMPATIBLE).
Support for Soft Audit's Installed Products File.
Support for BGS I/O Monitor Version 5.1.0 (COMPAT).
Support for HSM APAR OW31281 adds RECALL, DSR, FSR statistics.
Support for DFSMS 1.4.0 added WFSCPUTM for ABARS CPU cost.
Support for NTSMF CachingManager and Packet Filter objects.
Support for NT Service Pack 5A SYSTEM/PROCESS fields.
Major revision of TMS/CA-1 processing logic in TYPETMS5.
ML-17 of MXGTMNT/ASMTAPES synchronizes automatically.
Enhanced TPM support reads all possible variables in TYPETPMX.
Analysis of SMF Write Rates (MEGABYTES at 10/100sec)
MXG CONFIG value of VMCTLISA=40K raised to 160K.
VMXGSUM syntax for "DATETIME" now uses real name.
ABEND/CONDCODE in PDB.JOBS is now valid, has 1st ABEND.
(MXG 16.03 was only released as a Beta.)
Major enhancements added in MXG 16.02:
Support for TYPEIMS7 for IMS 6.1.
Support for OS/400 Version 4.2.0 COMPATIBLE.
Support for MQ Series Version 1 Release 2 INCOMPATIBLE.
Support for Landmark's Monitor for DB2 V 3.1 INCOMPATIBLE.
Support for Candle Omegamon V400 CANMQ and CANWLMSC.
Support for Candle Omegamon CICS V400 "255" record.
Support for Raptor Systems' Eagle Firewall 121 Log.
Support for TME 10 NetView for OS/390 V1 R1 SMF 38.
Support for Web Proxy logs Extended Common Log fmt.
Support for Magstar tapes in TYPETMS5 INCOMPATIBLE.
&PDBxxxx and &yyyzzz "Dataset &Macro" naming rules.
New PDB datasets TYPE74CO/ME/PA/SY/OM/LK added to daily PDB.
New ANALABND report ABENDs from PDB.STEPS, uses PROC TABULATE.
Multiple JES3 purge records created duplicate PDB.JOBS obs.
All MXG variables with format MGBYTES are now stored in 8-bytes.
New ANAL6264 merges VSAM type 62 and 64 for OPENTIME.
Major enhancements added in MXG 16.01:
The major thing in 16.01 is support for Year 2000 products that
were not Y2K compliant when 15.15 was built, so MXG 16.01 is now
the minimum level to support all vendor records that provide year
2000 dates, but there are also a few fixes and several enhancements
and new products supported.
Year 2000 issues that require MXG 16.01 or the specific change:
TYPE6 READTIME was 1900 in 2000 due to MXG error (Change 16.039).
AS/400 Year 2000 Support was Incorrect (Change 16.035).
NETVIEW NPM type 28 year Y2K Ready but INCOMPATIBLE record change.
Landmark TMON for CICS V2 converted to V8.1 Y2K Ready, INCOMPAT.
IPAC RDS View Direct V 6.1 Y2K Ready, but INCOMPATIBLE change.
MXG Software now warrants it is "Year 2000 Ready".
Support for new NTSMF objects (Database, SMTP Server, WEB Service).
Support for revised NTSMF Active Server Pages and IISG records.
Support for Software Engineering's SpaceManager data records.
Support for DECnet/SNA DTF SMF records.
MXG 15.15 problems reported and fixed:
Variable MXGVERSN in TYPE70 was blank in 15.15; impacts CPEXPERT.
Deactivated PR/SM Partition may cause over 100% CPU Busy for CEC.
All of these enhancements are described in the Change Log, below.
Availability dates for the IBM products and MXG version required:
Availability MXG Version
Product Name Date Required
MVS/ESA 4.1 Oct 26, 1990 8.8
MVS/ESA 4.2 Mar 29, 1991 9.9
MVS/ESA 4.2.2 Aug 1991 9.9
MVS/ESA 4.3 Mar 23, 1993 10.10
MVS/ESA 5.1.0 - compatibility Jun 24, 1994 12.02
MVS/ESA 5.1.0 - Goal Mode May 3, 1995 13.01
MVS/ESA 5.2.0 Jun 15, 1995 13.05
MVS/ESA 5.2.2 Oct 19, 1995 13.09
OS/390 1.1.0 Feb 22, 1996 14.01
OS/390 1.2.0 Sep 30, 1996 14.05
OS/390 1.3.0 Compatibility Mode Mar 28, 1997 14.14
OS/390 1.3.0 WLM Goal Mode Mar 28, 1997 15.02
OS/390 2.4.0 Sep 28, 1997 15.06
OS/390 2.5.0 Feb 24, 1998 15.06
OS/390 2.6.0 Sep 24, 1998 16.04
OS/390 2.7.0 Mar 26, 1999 16.09
CICS/ESA 3.2 Jun 28, 1991 9.9
CICS/ESA 3.3 Mar 28, 1992 10.01
CICS/ESA 4.1 Oct 27, 1994 13.09
CICS/ESA 5.1 aka CICS/TS V1R1 Sep 10, 1996 14.07
CICS-Transaction Server V1R1 Sep 10, 1996 14.07
CICS-TS V1R1 with APAR UN98309 Sep 15, 1997 15.06
CICS-TS V1R2 Oct 27, 1997 15.06
CICS-TS V1R3 Mar ??, 1999 16.09
CRR 1.6 Jun 24, 1994 12.02
CRR 1.7 Apr 25, 1996 14.02
DB2 2.3.0 Oct 28, 1991 10.01
DB2 3.1.0 Dec 17, 1993 13.02A
DB2 4.1.0 Tolerate Nov 7, 1995 13.07
DB2 4.1.0 Full support Sep 11, 1996 14.07
DB2 5.1.0 Tolerate Jun 27, 1997 14.14
DB2 5.1.0 Full support Jun 27, 1997 15.02
DB2 6.1.0 Mar ??, 1999 16.09
DFSMS/MVS 1.1 Mar 13, 1993 11.11
DFSMS/MVS 1.2 Jun 24, 1994 12.02
DFSMS/MVS 1.3 Dec 29, 1995 13.09
DFSMS/MVS 1.4 Sep 28, 1997 15.04
DFSMS/MVS 1.4 HSM Sep 23, 1998 16.04
MQM 1.1.2, 1.1.3, 1.1.4 Apr 25, 1996 14.02
MQ Series 1.2.0 May 26, 1998 16.02
NETVIEW 3.1 type 37 ??? ??, 1996 14.03
NPM 2.0 Dec 17, 1993 12.03
NPM 2.2 Aug 29, 1994 12.05
NPM 2.3 ??? ??, 1996 15.08
NPM 2.4 Nov 18, 1998 16.06
RMDS 2.1, 2.2 Dec 12, 1995 12.12
TCP/IP 3.1 Jun 12, 1995 12.12
TCP/IP 3.4 Sep 22, 1998 16.04
DOS/VSE POWER V6.3.0 Dec 19, 1998 16.08
VM/ESA 2.0 Dec 23, 1992 10.04
VM/ESA 2.1 Jun 27, 1993 12.02
VM/ESA 2.2 Nov 22, 1994 12.06
VM/ESA 2.3 ??? ??, ???? 16.08
IMS 4.1 Jul 4, 1994 12.02
IMS 5.1 Jun 9, 1996 14.05
IMS 6.1 ??? ?, 199? 16.04
AS400 3.7.0 Nov 1, 1996 15.01
AS400 4.1.0 Dec 30, 1996 15.08
AS400 4.2.0 Apr 27, 1998 16.02
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
Microsoft
Windows NT 4.0 and NT 3.51 14.14
Windows NT 4.0 Service Pack 2 15.03
Windows NT 4.0 Service Pack 5 16.04
Demand Technology
NTSMF Version 1 Beta 14.11
NTSMF Version 2.0 15.05
NTSMF Version 2.1 15.06
NTSMF Version 2.2 16.04
Landmark
The Monitor for DB2 Version 2 13.06
The Monitor for DB2 Version 3.0 16.02
The Monitor for DB2 Version 3.1 16.02
The Monitor for CICS/ESA 1.2 - 12.12
The Monitor for CICS/ESA 1.3 - 15.01
The Monitor for CICS/ESA 2.0 - 15.06
The Monitor for MVS/ESA 1.3 - 12.05
The Monitor for MVS/ESA 1.5 - 12.05
The Monitor for MVS/ESA 2.0 - 15.09
Candle
Omegamon for CICS V200 User SMF 12.05
Omegamon for CICS V300 User SMF 13.06
Omegamon for CICS V400 User SMF 16.02
Omegamon for CICS V400 type 110 segments 16.02
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for MVS V300 13.05
Omegamon for MVS V400 13.06
Omegamon for DB2 Version 2.1/2.2 13.05
Omegamon for VTAM V160 12.04A
Omegamon for VTAM V400 15.15
Omegamon for SMS V100/V110 12.03
CA
ACF2 6.2 16.04
ASTEX 2.1 14.04
NETSPY 4.7 14.03
NETSPY 5.0 14.03
NETSPY 5.2 16.05
Boole & Babbage
IMF 3.1 (for IMS 5.1) 12.12
IMF 3.2 (for IMS 6.1 only) 15.09
IMF 3.2 (for IMS 5.1 and 6.1) 16.04
Memorex/Telex
LMS 3.1 12.12A
MXG IMS-Log Not-Officially-Supported
IMS 6.1 - ASMIMSL6/TYPEIMSA 16.06
IMS 5.1 - ASMIMSL5/TYPEIMSA 16.01
Amdahl
APAF 4.1, 4.3 16.08
II. MXG Technical Notes
1. Counting tape mounts.
Tape mount counts from the MXGTMNT monitor can be compared with the
tape mount counts (TAPNMNTS+TAPSMNTS) in the step records, and there
can be differences, mostly due to the difference in time-frame of
the mount records (when they occur) and the step records (when the
step ended):
- MXG will count high for Started Tasks that never end (e.g.DFHSM),
or for any job whose step record had not yet been written in the
SMF time-frame you examined.
- MXG will count low for steps that ended in the SMF time-frame, but
whose mounts occurred before the start of that SMF file.
- MXG counts physical mount events, but the type 30 counts completed
mounts, so when your tapeape intentionally mounts the wrong VOLSER
five times
if they can't find the right tape, they mount any tape, knowing
MVS label-check will prevent it from being used, but any mount
terminates the outstanding mount message so the MVS console guy
can't see how long the real mount has been waiting!
the MXG count is five mounts, the step record count is one.
- MXG misses some VTS scratch mounts, when using the default two
second sampling in MXGTMNT, because scratch mounts to VTS can be
fast. In one day MXG missed 200 VTS scratch mounts out of 2000
total VTS mounts with the two second sampling, but MXGTMNT saw
all of the VTS scratch mounts with one-half second sampling.
Recommendations:
If you want to compare totals, use the TYPE30_V or PDB.SMFINTRV data
from type 30 interval records instead of TYPE30_4 or PDB.STEPS data
to minimize (but not eliminate) time-frame error, since the interval
records will count the mounts for those long-running jobs and STCs.
If you do have Virtual Tape Devices, you could change the interval
constant in member ASMTAPES (INTERVAL DC F'200' to DC F'050') to
change the MXG default of 2.00 seconds to 0.50 seconds, and then
re-assemble to change the MXGTMNT program to sample at half-second
intervals. While 2 seconds is still the MXG default, half-second
was tested and briefly suggested as an alternative, as the CPU cost
was still small:
At half-second sampling, it took less than 3 CPU seconds per
15 minute interval to scan 100 tape devices, and another 1 CPU
second for every 100 tape mounts, or a few minutes per day with
2000 mounts.
However, even with .5 second interval, the mount monitor missed some
fast VTS mounts, which caused me to create the completely new logic
in the ASUMTAPE program, which creates the new PDB.ASUMTAPE dataset
(that should be used in place of PDB.TYPETMNT in tape mount
analysis). The new logic is driven by the type 21 dismount record,
so even if MXGTMNT missed the fast mount, PDB.ASUMTAPE has the tape
event, albeit with the tape mount duration missing (so you know it
was less than 2 secs!), so the original 2 second default was kept.
If you decide to change the sample interval, you can compare the
number of observations in PDB.ASUMTAPE that have missing TAPMNTTM,
to see how many more of the fast-scratch-VTS-mounts you actually
capture at 1/2 second instead of the MXG default of 2 seconds.
III. MVS Technical Notes.
1. APAR OW35684 confirms that the BLKSIZE in the DD segments of type 30
records is correct for tape but incorrect for a DASD dataset that is
being opened for output DISP=NEW when DADSM allocate did not
determine a system determined blocksize (SDB) even though BLKSIZE=0
was specified on the DD statement. DADSM SDB processing was not
done because DSORG and/or LRECL were not also specified. The APAR
is closed "FIN" - Fixed in Next DF/SMS Release in 18-24 months.
2. APAR OW31700 RMF OS/390 type 74 subtype 5 describes "short records"
created when there are more than 153 devices on a cache controller
(because 153 segments fills the 32756-byte limit of SMF data). They
have no impact on MXG, as MXG reads each record and outputs from
each device data section (but IBM had to add counters so RMF
could reassemble the large event from these 32K "small" records).
There may be an error, as I have seen type 74 subtype 5 records with
only the Product and Control section, with no status nor data and
with R745CCNT, record sequence, of 2. Site is talking to IBM.
3. SMF type 42 APARS:
APARs OW29633 corrects timestamps in TYPE42DS (type 42 subtype 6)
SMF records that caused SMF42PTS to be much earlier than the job's
READTIME. Reported in OW10694 (closed RET) and OW25624 (closed PER)
the actual error was a failure to freemain between jobs, so you
would have someone else's READTIME in your record. This error was
not fixed to correct SMF, but because someone's system stayed up
long enough that the memory leak causes a storage shortage ABEND!
APAR OW32248 discusses type 42 VSAM/RLS counter errors, affecting
SMF41IAY/IAZ/IBA/IBB/ICY/ICZ/IDA/IDB/IBG/IDG fields.
APAR OW35762 corrects count of SEQ blocks read and written for PS
datasets on non-SMS managed volumes.
4. APAR OW35952 corrects large value for IOUNITS in type 30 records;
the problem primarily affected DB2 address spaces with very large
(but legitimate) I/O counts that caused an overflow internally in
IBM code. The APAR text cites negative values in SMF30IO (IOUNITS),
but as MXG uses PIB instead of IB, very, very large values (so they
are noticed!) are created rather than small negative values.
5. APAR PQ18797 for MQ Series Release 1.3.0, PTF UQ23424 corrects zero
values for 'QMSTxxxx' variables in dataset MQMMSGDM from type 115
SMF record subtype 2.
IV. DB2 Technical Notes.
1. Boole and Babbage's MainView for DB2 product's THRDHIST VSAM file is
used for online access and its keyed record format is not public, so
MXG cannot support that file. But Boole recommends you create DB2
SMF records (their DB2 batch reports use the 100/101/102 records) so
THRDHIST was never intended to be useful for accounting or trending.
2. MXG Newsletter 34 reported that after installing APAR PN55122 and
migrating to CICS 5.1, that LU6.2 terminal's QWHCTOKN no longer had
the UOWID token in their DB2ACCT record (as a result, MXG's ASUMUOW
could not match DB2ACCT to CICSTRAN by Unit-of-Work ID). IBM has
now released APAR PQ15565 (and PTF UQ18583) to correct their error.
3. APARs PQ10864/PQ06968/PQ10864 discuss excessive numbers of DB2 type
101 SMF records that are created with CPU parallelism; if your DB2
application is running with more than 1 degree of CPU parallelism,
the child tasks will create SMF 101 accounting records every time
they are spawned (i.e., every SQL execution). In cases where an
application loops thru static SQL frequently or for transaction type
queries the volume can be a very serious problem. Use the DSNZPARM
macro DSN6SYSP PTASKROL parameter for parallel task accounting
control. APAR PQ06968 has been created to allow RLF to disable
modes of parallelism during static BIND; by using RLFFUNC=4 during
BIND, you can force problem applications back to IOP parallelism
(versus CPU parallelism). APAR PQ28414 provides a new ability to
limit the degree of query parallelism, and provides a maximum degree
parameter, PARAMDEG, and adds the field to the install process in
Version 6. This note updated with IBM input 19Dec1999.
V. IMS Technical Notes.
VI. SAS Technical Notes.
1. MXG 16.05 QA stream has executed using the SAS Version 7 Beta, under
OS/390, Windows 95/98 and Windows NT. Minor changes were needed in
MXG code, mostly to circumvent Beta things that SAS will have fixed
by the Production release this fall. A complete list will be in a
future MXG Technical Note when Version 7 is available.
Initial performance measurements of the MXG QA stream show no change
in the runtime between Version 6.12 TS045 and Version 7 Beta, so
it looks like lots of new features at no cost, for a change!
SAS Version 7 datasets cannot be read by SAS Version 6; the format
of SAS data libraries on all platforms was changed incompatibly.
Fortunately, MXG will not exploit on any SAS Version 7 features in
the near future, and there are no compelling reasons to migrate to
SAS Version 7 (run times and resources were about the same), but
when you do migrate to SAS V7, you will either have to drop it in
all at once, or at least you will need to install from the back end:
convert your report programs first and then convert the programs
that build the datasets that the reports use.
2. RETAIN statement only retains variables in assignment statements.
You cannot use a RETAIN statement with SET A B logic to retain the
value of variable A from dataset A into processing of observations
from dataset B. While the A variable will exist in the OUT dataset
its value will be missing:
DATA A; A=1;
DATA B; DO B=1 TO 5; OUTPUT B; END;
DATA OUT; SET A B;
RETAIN A;
To retain the value of variable A, you must assign it to a new name
(AA) while reading an observation from dataset A, retain that AA
name, and then when reading an observation from dataset B, assign AA
back to its original name A (and then DROP variable AA from OUT):
DATA OUT; SET A (IN=INA) B (IN=INB);
RETAIN AA; DROP AA;
IF INA THEN AA=A;
IF INB THEN DO; A=AA; OUTPUT; END;
Fortunately, variable A's attributes (LABEL, FORMAT, etc) are indeed
propagated into variable A in the OUT dataset.
3. SAS 6.09 TS455 and TS460 on MVS may encounter SAS "VM1319" or "NO
MKLEs" ABENDs, due to a memory overlay introduced by TS455. SAS ZAP
Z609E449 exists and is flagged as REQUIRED, but is not a true fix.
That ZAP forces SAS options MVARSIZE=0 and MSYMSIZE=0, which causes
%MACRO variables and symbol tables to be written/read to/from disk
instead of from memory. By reducing memory for macros, the overlay
may be avoided, but depending on how %macros are used, that ZAP
could impact runtime performance. The text of ZAP Z609E449 suggests
that increasing MEMSIZE may circumvent the error, since the overlay
is less likely with more addressability, so if you encounter the
error, first increase MEMSIZE by 8MB (and remember to increase your
REGION size), and then if that doesn't work, then either install the
ZAP, or install its effect by setting MVARSIZE=0 and MSYMSIZE=0
yourself.
4. SAS 6.09 TS455/TS460 do not free memory for user formats, which can
cause an out of memory error if there are repeated references to a
user format, e.g.,a DO Loop around PUT(variable,format) statement
where the format is NOT one supplied with SAS (MGxxxxx formats or
your own build with PROC FORMAT are "user formats").
SAS ZAP Z609F331 will correct this memory "leak".
VII. CICS Technical Notes.
1. There are two CICS summary programs in MXG:
ASUMCICS summarizes the detail CICSTRAN.CICSTRAN transactions, so
variable NUMTRANS counts the number of transactions.
ASUMCICX summarizes the already-summarized ASUMUOW unit-of-work
dataset, so NUMTRANS counts the number of unit's-of-work,
and variable MROTRANS counts the number of CICSTRAN
transactions that were executed by that unit-of-work.
2. APAR PQ13647 corrects invalid Y2K date in IBM type 110 subtype 2
TS Server records written by CICS TS 1.1 and 1.2. The dates will
contain 1AYY instead of 20YY without this fix.
VIII. Windows NT Technical Notes.
There are no Windows NT Technical Notes in this Newsletter.
IX. Incompatibilities and Installation of MXG 16.16.
1. Incompatibilities introduced in MXG 16.16 (since MXG 15.15):
a- IMACs that were changed (if they exist in your USERID.SOURCLIB, you
must refit your tailoring, starting with the new IMAC member):
IMACPDB - new PDB.STEPS/PDB.JOBS CONDCODE. Change 16.106
b- Other incompatibility changes:
All MGBYTES formatted variables are now length 8, instead of 4.
If you use PROC APPEND without FORCE, SAS will ERROR when you try
to combine new and old datasets with dissimilar length variables.
c- These products were incompatibly changed by their vendor, and they
require MXG Version 16.01 as indicated:
MXG Y2K support for AS/400 MXG 16.01 Change 16.035
CA-1/TMS TYPETMS5 with Magstar drives MXG 16.02 Change 16.088
LANDMARK CICS V2 recs convert to V8.1 MXG 16.01 Change 16.049
LANDMARK DB2 V 3.1 MXG 16.02 Change 16.097
MQ Series V1 R2 SMF 115 MQMLOG dataset MXG 16.02 Change 16.099
MXG Y2K support for Type 6 SMF record MXG 16.01 Change 16.039
NETVIEW NPM (Year 2000 dates) MXG 16.01 Change 16.003
NTSMF EXCHANGE 5.5 MXG 16.01 Change 16.024
2. Installation and re-installation procedures are described in detail
in member INSTALL (which also lists common Error/Warning messages a
new user might encounter), and sample JCL is in member JCLINSTL.
X. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
XI. Changes Log
==========================Changes Log=================================
You MUST read each Change description to determine if a Change will
impact your site. All changes have been made in this MXG Library.
Member CHANGES of the MXG SOURCLIB will always be more accurate than
the printed changes in a Newsletter, because the software is normally
created after the newsletter is sent to the printer! Member CHANGES
on the www.MXG.com homepage are the most timely, as they are updated
(sometimes) between MXG versions.
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 than described in the change text (which might have printed
only the critical part of the correction that can be made by paper).
Scan each source member named in any impacting change for any comments
at the beginning of the member for additional documentation, since the
documentation of new datasets, variables, validation status, and notes,
are often found in comments in the source members.
Alphabetical list of important changes after MXG 15.15 now in MXG 16.16:
Dataset/
Member Change Description
Many 16.216 Support for OS/390 Release 2.6 (COMPATIBLE).
Many 16.078 MXG variables with format MGBYTES are now 8-bytes.
Many 16.068 &PDBxxxx and &yyyzzz "Dataset &Macro" naming rules.
ADOCQAPM 16.301 Enhanced documentation for AS/400 processing
ANAL6264 16.071 Analysis merges VSAM type 62 and 64 for OPENTIME.
ANALABND 16.082 ABEND stats from PDB.STEPS, uses PROC TABULATE.
ANALCISH 16.104 MORE THAN 32767, MORE THAN 10 errors corrected.
ANALPATH 16.006 SUBSCRIPT OUT OF RANGE, report expected 10 LCUs max.
ANALRMFR 16.295 ANALRMFR RMF reports added REPORT=XCF.
ANALSRVC 16.098 Report now works for CPU Percent by Service Class.
ANALUOW 16.075 Enhancements, DB2 Class 3 waits. etc were added.
ANALVTS 16.162 Analysis combines 30s, TMNT, TALO and 21s for tapes.
ANANCNCR 16.206 COUNT= option corrected.
ASMIMSL5 16.058 ASMIMSL5 in MXG 15.15 failed during assembly.
ASMIMSL6 16.185 Support for IMS Log processing for IMS 6.1.
ASMMNVW 16.247 Support for decompression of MainView history files.
ASMTAPES 16.154 ML-17 of MXGTMNT synchronizes automatically.
ASMTAPES 16.164 MXGTMNT misses too-fast VTS tape mounts.
ASMTAPES 16.259 ML-18 of ASMTAPES protects DSAB circular queue.
ASUM42DS 16.046 New summary member for TYPE42DS by dataset.
ASUM70PR 16.028 Deactivated Partition may cause over 100% CPU Busy.
ASUM70PR 16.271 16.04-16.05. ASUM70PR summarized at SHIFT vice HOUR.
ASUMCACH 16.141 DURATM in ASUMCACH revised for accuracy.
ASUMCICS 16.137 INVALID ARGUMENT TO FUNCTION SQRT when N=1.
ASUMHSM 16.315 Revision to Support HSM Y2K julian dates.
ASUMHSM 16.345 HSM summarization separates HSM active from queued.
ASUMTALO 16.076 Revised to work with TALO records from old ASMTAPES.
ASUMTALO 16.169 SPIN.SPINTALO now backed up into PDB library.
BLDNTPDB 16.180 NTSMF Daily/Weekly/etc BUILD program enhanced.
BUILDPD3 16.080 JES3 BUILDPDB - Multiple PDB.JOBS obs - multi purges.
BUILDPDB 16.008 Duplicate TYPE30_V records might not be deleted.
BUILDPDB 16.107 PDB.TYPE74CO/ME/PA/SY/OM/LK added to day/week PDB.
BUILDPDB 16.183 ABEND/CONDCODE in PDB.JOBS now valid, has 1st ABEND.
BUILDPDB 16.230 Duplicate type 30 records caused RESTARTS to be high.
BUILDPDB 16.231 TYPE6 vars STDUPLEX/FCB/OVLYLOAD/OVLYUSED added.
BUILDPDB 16.348 BINxxxx variables added to PDB.PRINT.
CICINTRV 16.253 Revision of CICINTRV auto-determine input location.
CICINTRV 16.277 PDB.CICINTRV dataset may be real bad; get this code!
CONFIG 16.066 Option SASAUTOS=(SOURCLIB SASAUTOS) is now used.
CONFIG 16.117 CODEPCT=150 now set to eliminate SAS message.
CONFIG 16.157 MXG CONFIG value of VMCTLISA=40K raised to 160K.
CONFIG 16.209 NOSTIMER now specified, SAS 6.12 TS045 changed.
DOCGRAF 16.018 Examples of getting graphs from mainframe to your PC.
DOCMXG 16.134 New &MACKEEP and IMACKEEP MXG architecture changed.
FORMATS 16.214 Support for DF/SMS 1.4 changes to HSM (COMPAT).
IMACFILE 16.016 &MACFILE macro added for instream tailoring.
IMACICDM 16.067 Support for Candle Omegamon V400 CANMQ and CANWLMSC.
IMACPDB 16.106 Enclave CPU time and count added to PDB.STEPS/JOBS.
IMACPDB 16.341 IMACPDB documentation, no code was changed.
MXGSAS 16.081 JCL parameter TAILORNG now spelled TAILOR.
RMFINTRV 16.288 Sort order of RMF is now BY SYSPLEX SYSTEM STARTIME.
TRND70 16.021 TRENDing of TYPE70 now supports 16 buckets of CPUs.
TRND72GO 16.029 Variable R723CIMP in TRND72GO SUMmed vice IDd.
TRNDTALO 16.221 Overlapped hour could miscount tape allocations.
TYPE109 16.329 Support for TYPE109 OS390 Firewall Server.
TYPE110 16.031 CICS UNEXPECTED STID=0 was error in STID=94 segment.
TYPE110 16.153 GMT offset calculation in CICS off by up to 1.4 secs.
TYPE110 16.270 Support for CICS TS 1.2 Journal Format, INCOMPATIBLE.
TYPE110 16.322 Support for CICS TS 1.3 (INCOMPATIBLE).
TYPE115 16.099 Support for MQ Series Version 1 Release 2 (INCOMPAT).
TYPE16 16.254 Support for DFSORT Release 15 (No Change).
TYPE28 16.003 NETVIEW NPM type 28 INCOMPATIBLE year 2000 change.
TYPE28 16.290 NPMLANOD dataset TIC_UTIL variable was missing.
TYPE28 16.336 STOPOVER NPM 2.4 NPMSUBTY='DD'x; IBM doc was wrong.
TYPE30 16.150 TYPETASK='ASCH' or TYPETASK='OMVS' now set in PDB.
TYPE38 16.101 Support for TME 10 NetView for OS/390 V1 R1 SMF 38.
TYPE42 16.339 SMF type 42 subtypes 15-19 (VSAM RLS) now validated.
TYPE57 16.234 JES3 with more than 9999 job numbers INVALID DATA.
TYPE6 16.039 READTIME in TYPE6 and hence PRINT is 1900 in 2000.
TYPE6 16.264 Support for PSF/MVS Release 3.1.0 (COMPATIBLE).
TYPE7072 16.009 Variable MXGVERSN in TYPE70 was blank in 15.15.
TYPE7072 16.194 Delay Percents now divided by R723CTSA.
TYPE7072 16.326 TYPE72 Compat Delay variables were incomplete.
TYPE7072 16.327 PERFINDX sometimes missing for Average Resp Goals.
TYPE7072 16.328 Variable PCTMETGO added to TYPE72GO for Percentiles.
TYPE7072 16.342 New variable CECSER with CPU Serial of the CEC.
TYPE72GO 16.064 Variables AVGRESP, EXETTM, AVGXETTM added/changed.
TYPE72GO 16.083 Variables R723CQDT/CADT/CCVT/CIQT wrong multiplier.
TYPE74 16.032 NO STRUCTURE MATCH message understood and eliminated.
TYPE74 16.095 TYPE74 variable IORATE changed to match IBM's RMF.
TYPE74 16.329 Support for TYPE746B/F/G datasets in OS/390 R2.7.
TYPE79 16.213 Type 79 Subtype 15 (IMS Long Lock) corrected.
TYPE7xxx 16.288 Sort order of RMF is now BY SYSPLEX SYSTEM STARTIME.
TYPE80A 16.236 Support for RACFEVNT=26 APPCLU Session Establish.
TYPE80A 16.245 Support for RACF "installation-defined data field".
TYPE85 16.255 Support for OAM type 85 SMF record, 11 datasets.
TYPE94 16.135 VTS variables SMF94VBA/VLA were misdocumented by IBM.
TYPE99 16.026 New subtype 6 SMF type 99 INVALID SERVER SECTION.
TYPEACF2 16.215 Support for ACF2 Ver 6.2 type 'V' (INCOMPATIBLE).
TYPEAPAF 16.305 Support for more than 8 engines in APAF data.
TYPEBETA 16.293 BETA93 Version 3.1.3 INCOMPATIBLY changed.
TYPEBETA 16.351 Support for BETA93 subtypes 1,2,3,4,20,40,41,42.
TYPEBGSI 16.155 Support for BGS I/O Monitor Version 5.1.0 (COMPAT).
TYPECIMS 16.030 ABENDUSR in CIMSPROG has never been right.
TYPECIMS 16.227 IMF 3.2 with IMS 5.1 INPUT STATEMENT EXCEEDED.
TYPEDB2 16.318 Support for DB2 Version 6.1 (COMPATIBLE).
TYPEDB2 16.148 Dataset DB2STATR was invalid, duplicate observations.
TYPEDCOL 16.017 DCOLLECT DSORG field expanded to 3 in MXG (PSU etc).
TYPEDECS 16.034 Support for DECnet/SNA DTF SMF records.
TYPEDOS 16.312 Support for DOS/VS Power V6.3.0 (COMPATIBLE).
TYPEEAGL 16.102 Support for Raptor Systems' Eagle Firewall 121 Log.
TYPEEDGR 16.308 Revisions to RMM EDGR support - numeric dates.
TYPEHSM 16.136 DFSMS 1.4.0 added WFSCPUTM for ABARS CPU cost.
TYPEHSM 16.145 Support for APAR OW31281 adds RECALL, DSR, FSR.
TYPEHSM 16.149 SHORT ABAR message after Change 16.025 fixed.
TYPEHSM 16.263 Support for FSRTYPE=17 thru 20 HSM FSR records.
TYPEHSM 16.315 Revision to Support HSM Y2K julian dates.
TYPEICE 16.280 Support for IXFP fields added by APAR L170017.
TYPEIDMJ 16.361 Support for IDMS Version 14 Journal Records.
TYPEIDMS 16.002 New TASNxxx variables labels were incorrect.
TYPEIDMS 16.012 IDMS 10.2.1 caused INPUT STATEMENT EXCEEDED.
TYPEIDMS 16.033 IDMS 10.2 records were not output.
TYPEILKA 16.249 Support for Interlink TCPaccess Vers 5.2 (INCOMPAT)
TYPEIMS7 16.119 Support for TYPEIMS7 for IMS 6.1.
TYPEIMSA 16.069 ASMIMSL5 process now has _L, _K macros, exit members.
TYPEIMSA 16.257 IMS 6.1 Support correct only in European Summer Time.
TYPEIMSA 16.343 Zero observations in IMSFASTP, SUBCODE not kept.
TYPEIPAC 16.052 Y2K INCOMPATIBLE IPAC RDS 6.1 user SMF record.
TYPEMON8 16.049 Y2K Support for TMON V2 records converted to 8.1.
TYPEMON8 16.073 INVALID DATA FOR TMMDMODL message corrected.
TYPEMON8 16.091 TMON for CICS V2 Converted records MONIRECD='D'.
TYPEMVCI 16.260 Support for Boole & Babbage MainView CMRDETL file.
TYPENDM 16.060 Sterling's Connect Direct aka NDM PI=754129 open.
TYPENSPY 16.147 NETSPY='N' record support was restored for old 4.4.
TYPENTSM 16.024 Support new "Database" object and EXCHANGE 5.5.
TYPENTSM 16.045 Support for IISG, Active Server Pages, Web Service.
TYPENTSM 16.049 New SNA LU, SNA 3270 Response, etc, NTSMF objects.
TYPENTSM 16.121 Support for NTSMF Cache Mgr & Packet Filter objects.
TYPENTSM 16.133 Summarization of NETWSEGM into NTINTRV wrong if two.
TYPENTSM 16.177 Support for NT Service Pack 5A SYSTEM/PROCESS fields.
TYPENTSM 16.199 NTSMF Object='WidetoMBErr' explained.
TYPENTSM 16.208 Support for NTSMF internal 0.1 configuration record.
TYPENTSM 16.217 New objects NetShow Station/Unicast Service support.
TYPENTSM 16.228 Support for NTSMF V2.2 with Record Header 2.2.1.
TYPENTSM 16.317 Support for NTSMF 2.2.1 header (or use COMPRESS).
TYPENTSM 16.337 Support for new NT 4.0 objects.
TYPENTSM 16.350 Support for WINDOWS NT 5.0 (INCOMPATIBLE) with NTSMF.
TYPEOMCI 16.116 Support for Candle Omegamon CICS V400 "255" record.
TYPEOMVT 16.262 Candle Omegamon for VTAM documentation error.
TYPEQAPM 16.035 Year 2000 Support for AS/400 was corrected.
TYPEQAPM 16.063 Support for OS/400 Version 4.2.0 (COMPATIBLE).
TYPESFTA 16.175 Support for Soft Audit's Installed Products File.
TYPESOLN 16.356 Support for Sterling's SOLVE NetMaster TCP/IP SMF.
TYPESPMG 16.020 Support for Software Engineering's SpaceManager data.
TYPETAND 16.118 Tandem variables CnBLKS and CnBLKSAV corrected.
TYPETCP 16.211 Support for TCP/IP 3.4 (sorta INCOMPATIBLE).
TYPETCP 16.242 TCP SMF record subtype externalized _SUBTCP5 macro.
TYPETDTA 16.170 Support for NCR Teradata DBS performance data.
TYPETMDB 16.097 Support for Landmark's Monitor for DB2 V 3.1 INCOMPA
TYPETMDB 16.160 Support for Landmark's SQL/CAPTURE type 'D6' record.
TYPETMO2 16.122 Variables SYSID,APPLID,SYSPLEX blank in MXG.
TYPETMS5 16.088 Lost obs in TMS dataset DSNBRECD for Magstar tapes.
TYPETMS5 16.129 Major revision of TMS/CA-1 processing logic.
TYPETMS5 16.191 Final revisions to TMS logic changes for FILSEQ.
TYPETMS5 16.251 TMS support for multi-dataset tapes now correct.
TYPETMV2 16.212 TMON for MVS V2 variables wrong in TMVSSYS dataset.
TYPETPMX 16.189 Enhanced TPM support reads all possible variables.
TYPETPX 16.019 TPXBYTI/BYTO wrong due to CA's documentation error.
TYPEVLFC 16.089 Zero observations in dataset TYPEVLFC corrected.
TYPEVMXA 16.310 Support for VM/ESA 2.3 MTRSYS and USEACT segments.
TYPEWWW 16.105 Support for Web Proxy logs Extended Common Log fmt.
TYPEXCOM 16.114 XCOM variable REQTYPE renamed REQTYPEX, conflict.
TYPEXCOM 16.187 Support for XCOM Release 3.0 (COMPATIBLE).
USMFRATE 16.158 Analysis of SMF Write Rates (MEGABYTES at 10/100sec)
UTILBHEX 16.070 Utility creates SMF records from hex dump from LIST;.
UTILCICS 16.061 Incorrect Candle value ERRMQ=64 in CANMQ detected.
VMAC7072 16.130 Type 70 records have CPU segment after VARY OFF.
VMACIMSA 16.313 IMS 6.1 type 08 correction for APPC, CPIC driven.
VMXGSUM 16.120 New ERASEOUT parameter added.
VMXGSUM 16.131 UNIX forward slashed caused VMXGSUM to fail.
VMXGSUM 16.146 VMXGSUM syntax for "DATETIME" now uses real name.
VMXGSUM 16.179 Support for SAS Version 7 (INCOMPATIBLE).
VMXGSUM 16.306 INHERIT (SAS V7 only) now exploited in VMXGSUM.
VMXGSUM 16.306 INHERIT parameter used if under SAS Version 7.
VMXGSUM 16.323 Correction after Change 16.271 &DATETIME=DATETIME;
VMXGWORL 16.266 Sorted status now validated by SORT flag for _L data.
WEEKBLDT 16.140 Weekly build of ASUMDB2B fails with wrong sort order.
XMXGSUM 16.314 New function enhancements for VMXGSUM for testing.
YEAR2000 16.330 MXG 16.09 now required for 100% YEAR2000 Support.
TYPEUNIC 16.391 Support for CA UniCenter VMS Performance Monitor.
TYPE102 16.390 Support for IFCIDS 252 and 260.
TYPETMO2 16.387 Support for TMON for CICS Version 2 PTF TH01129
TYPENSPY 16.386 Support for NETSPY Version 5.2 (COMPAT).
BUILDPDB 16.385 New WLM variables added to PDB.JOBS dataset
TYPENTSM 16.384 Support for new SNA BASE and IBM SNA objects.
ANALHSM 16.383 Rewrite as %MACRO, new thread use/queue measures.
TYPETMS5 16.382 Documentation of TMS EXPDT values.
XSUM70PR 16.381 Circumvention for IBM including ICF partition as CPU.
VMACDB2H 16.380 Invalid QWHSSTCK data value trashed dates/times.
IMAC6ESS 16.376 Optional ESS decoding of type 6 fails with 2 fields.
VMXGSUM 16.375 Invalid Argument to Substring message eliminated.
TRNDSMFI 16.374 Trending member for PDB.SMFINTRV / TYPE30_V dataset.
UTILPLDB 16.373 Automatic generate BUILDPDB utility.
ASUMUOW 16.371A Revisions for SPIN and missing values.
UTILCICS 16.371 Subtype 0 CICS 4.1 caused INPUT STATEMENT error.
TYPE7072 16.370 New PCTMETGO variable was not correct.
CICINTRV 16.367 Big CPU increase in 16.06-16.10 corrected.
Inverse chronological list of all Changes:
NEXTCHANGE: Version 16
======Changes thru 16.394 were in MXG 16.16 dated Feb 20, 1999======
Change 16.394 Support for CA MIM Version 4.3 Product SMF record adds
EXTYMIM thirteen new datasets created from its subtypes. The
EXTYMIM1 original MIMTAPE dataset is still built, but the names
EXTYMIM2 of the variables are changed to be consistent with the
EXTYMIM3 MIM documentation; where they started with STCxxxxx in
EXTYMIM4 the documentation, the variable names are MIMxxxxx now.
EXTYMIM5 This revision was a user contribution that I revised for
EXTYMIM6 the new MXG architecture, but have only run syntax check,
EXTYMIM7 as I have no sample records to test with before 16.16 is
EXTYMIM8 finalized and tapes are built!
EXTYMIM9
EXTYMIMA
EXTYMIMB
EXTYMIMC
EXTYMIMD
IMACMIM
TYPEMIM
TYPSMIM
VMACMIM
Feb 21, 1999
Thanks to Martyn A. Jones, CHASE, ENGLAND.
Change 16.393 This is the "40 GIG" paper that Chuck Hopf and I have
DOC40GIG presented at SHARE and CMG in 1998. The graphs, tables,
Feb 19, 1999 and charts that are not text documents cannot be included
in this text member, but the text contains the link to
those graphic documents, which are now on our homepage.
Change 16.392 Preliminary MXG "New User" manual is far from complete,
NEWUSER but has excellent examples of how to use MXG, how to set
Feb 19, 1999 up SMF, etc., and comprehensive documentation of the MXG
summarization macro, VMXGSUM. This will be expanded.
Most of this document can be directly read, but there are
some figures that are graphics or tables that cannot be
included in a text document; instead, the document has
the link to that document on the MXG homepage, so if you
can connect to the internet while you read, you can see
the figures and tables that can't be included in text.
Thanks to Chuck Hopf, MNBA, USA.
Change 16.391 Support for CA UniCenter VMS Performance Monitor data
EXUNICCP from their ADVISE PERFORMANCE EXPORT/TYPE=ASCII command.
EXUNICDI Thirteen datasets are created:
EXUNICDV dddddd dataset description
EXUNICIO UNICCP UNICTRCP UniCenter CPU statistics
EXUNICLK UNICDI UNICTRDI UniCenter DISK statistics
EXUNICME UNICDV UNICTRDV UniCenter DEVICE statistics
EXUNICPG UNICIO UNICTRIO UniCenter I/O statistics
EXUNICPR UNICLK UNICTRLK UniCenter LOCK statistics
EXUNICSC UNICME UNICTRME UniCenter MEMORY statistics
EXUNICSR UNICPG UNICTRPG UniCenter PAGE statistics
EXUNICSY UNICPR UNICTRPR UniCenter PROCESS METRICS stats
EXUNICVR UNICSC UNICTRSC UniCenter SYSTEM COMM stats
EXUNICXQ UNICSR UNICTRSR UniCenter SERVER statistics
FORMATS UNICSY UNICTRSY UniCenter SYSTEM statistics
IMACUNIC UNICVR UNICTRVR UniCenter VERSION number
TYPEUNIC UNICXQ UNICTRXQ UNICENTER XQP statistics
TYPSUNIC Some counters (RMTPAGNT,RMTSWPNG) in UNICTRDI Disk data
VMACUNIC that have a value of minus one that is not documented but
Feb 19, 1999 I assume means that field was not used? There is a lot
Feb 24, 1999 of information captured by UniCenter in these records!
Feb 24: Originally was mis-stated as UNIX support, but
records are from the VMS and Open VMS operating system).
Thanks to Frank d'Hoine, Nationale Bank van Belgie, BELGIUM.
Change 16.390 Support for DB2 Trace IFCIDs 250, 252 and 260, 261, and
VMAC102 262 has been added and validated with DB2 5.1 records.
Feb 18, 1999
Change 16.389 An include of IMACKEEP was added after the definition
CICINTRV of _CICINTV macro that sets the interval duration so
Feb 18, 1999 it can be overridden with IMACKEEP/MACKEEP logic.
Thanks to Alex Torben Nielsen, TeleDanmark EDB, DENMARK
Change 16.388 An include of IMACKEEP was added after the include of
RMFINTRV IMACRMFI so that the _DURSET macro that set interval
Feb 18, 1999 duration can be overridden with IMACKEEP/MACKEEP.
Thanks to Paul Oliver, BHP Information Technology, AUSTRALIA.
Change 16.387 Support for TMON for CICS Version 2 PTF TH01129 (COMPAT)
VMACTMO2 adds MQ Series fields to both the MONISYST and MONITASK
Feb 18, 1999 records, using existing reserved fields. New variables:
MONISYST MONITASK Description
TIMQQMGR TAMQQMGR MQ Series Queue Manager Name
TIMQSRCT TIMQSRCT MQ Series API Request Count
TIMQSRTM TIMQSRTM MQ Series API Request Duration
TIMQSWCT TIMQSWCT MQ Series Wait Count
TIMQSWTM TIMQSWTM MQ Series Wait Time
These new variables are defined, but the actual DSECT had
not been received so the fields are not yet actually read
in yet, so they will all be missing until this is fixed.
Thanks to Brian Kaczkowski, Kohl's Department Stores, USA.
Change 16.386 Support for NETSPY Version 5.2 is already in MXG, as none
VMACNSPY of the supported subtypes were changed. There is a new
Feb 18, 1999 NSPYREC='I' record for TCP/IP, but that new subtype is
not yet supported, pending fixes from the vendor (there
is time for all transactions and network time for 3270
emulation, but no network time for GUI users who telnet
in, etc.). When valid data is available and the record
format is stable, I will add support for type "I" data.
Thanks to Roger Zimmerman, Zurich Kemper Investments, USA.
Change 16.385 New WLM variables added by OS/390 2.4 are now added to
BUILD005 the PDB.JOBS dataset. Variables are JOBMODE0 JOBMODE1
Feb 18, 1999 SMF26WCL, SMF26WIN, SMF26WJC, SMF26WOC, SMF26WSE.
Thanks to Jack Hudnall, Southwestern Bell, USA.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 16.384 Support for three new IBM SNA Objects:
EXNTSNA1 dddddd Dataset Object Variables
EXNTSNA1 NTSNAB SNABASE SNA BASE 19
EXNTSNAB NTSNA1 SNAIBMCS IBM SNA CLIENT SERVICES 2
FORMATS NTSNA2 SNAIBMLB IBM SNA LOAD BALANCING 2
IMACNTSM Also, the _UNTDISC macro used to print discover records
VMACNTSM was revised for changed headers.
VMXGINIT
Feb 17, 1999
Change 16.383 HSM Analysis example was rewritten as a %MACRO so that
ANALHSM arguments can be passed, and additional reports on HSM
Feb 17, 1999 activity (concurrent threads, threads queued, etc). The
program requires the ASUMHSM member of change 16.345.
Change 16.382 No change, documentation only. TMS a/k/a CA-1 now has
TYPETMS5 new values for EXPDT that have special meaning:
Feb 17, 1999 EXPDT Meaning TMS Prints
9989xxx Conversion from Prior STATS/xxx
9990000 Catalog Retention CATALOG
9998xxx Retain xxx after LastRef LDATE/xxx
9999xxx Number of Cycles CYCLES/xxx
9999999 Permanent Retention PERMANENT
I have been unsuccesful in creating a FORMAT that will
extract that xxx value and print these special EXPTD
values the way TMSBINQ and other CA programs do.
Thanks to Wayne Hartman, Prudential, USA.
Change 16.381 CECs with an Integrated Coupling Facility, ICF, count the
XSUM70PR "spare" CPU in which the Coupling Facility is running as
Feb 17, 1999 a real processor. This summer, IBM will document changes
to the Diagnose 204 and 224 to define 3-byte codes for CP
types (general purpose and ICF) and will update the RMF
Type 70 SMF record so that the records for the ICF
Partition (and its PHYSICAL record for the ICF) can be
recognized and either deleted or at least excluded from
the count of CPUs. In advance of that APAR, this change
lets you delete the TYPE70PR observations from the ICF
LPAR (by LPARNAME/LCPUADDR) and lets you correct the
number of engines, so that the created PDB.ASUM70PR
counts the real workload and the real processors. You
will have to examine your TYPE70PR observations to see
what combination of LPARNAME, LPARNUM, and LCPUADDR can
be used to identify the ICF LPAR and its "PHYSICAL"
partition observations.
Thanks to Forrest Nielson, State of Utah, USA.
Thanks to Barry Rozemeijer, ING Nederland, THE NETHERLANDS.
Change 16.380 Invalid QWHSSTCK value in DB2ACCT records causes datetime
VMACDB2H variables QWACBSC and QWACESC to be trashed (dates in the
Feb 17, 1999 year 2082, wrong times). Instead of an expected 8-byte
field in TODSTAMP format (for example, the raw QWACESC is
'B1CFB43F08BF37F1'x for '15FEB1999:17:57:26.02'), the bad
QWHSSTCK field has a value in SMFSTAMP format (the raw
value '0020734600099031F'x is '31JAN1999:05:05:54.78' as
an SMFSTAMP, but that date is two weeks earlier than the
actual records (created on Feb 15, 1999), so not only is
the format wrong, the value is wrong too! MXG uses that
bad QWHSSTCK value to calculate your GMT offset, so that
QWACBSC/QWACESC can be converted back to local time, but
MXG input that bad QWHSSTCK as the expected TODSTAMP, it
is '26JAN1900:20:15:19.53', which causes GMTOFFDB to be
98 years (SMFTIME is 15FEB1999:11:57:23.02), which is
what then corrupts the QWACBSC and QWACESC values.
While investigating the source of this bad value, which
may have come from one of those Y2K-date-simulator-tools
that intercept STCK macro calls inside MVS, I now check
to see that the calculated GMTOFFDB is less than 24 hours
and if it is not, then I print an error message on your
SAS log that I could not calculate GMT offset and that
your BSC/ESC timestamps will be on GMT rather than local,
and set GMTOFFDB to zero. I will update this note when
we know if this error is due to a STCK-interceptor or if
it is an IBM DB2 error.
Thanks to Warren E. Waid, JC Penny, USA.
Change 16.379 Syntax error in this JCL example. The test should be
JCLADHOC IF APPLID='PROC' THEN OUTPUT _WCICTRN;
Feb 17, 1999
Thanks to Khalid Meskinia, SAS Institute, FRANCE.
Change 16.378 This analysis failed with dataset not found. This line
ANALVVDS PROC SORT DATA=_WTYVVDS..TYPEVVDS OUT=MXGVVDS.TYPEVVDS;
Feb 17, 1999 should have been
PROC SORT DATA=_WTYVVDS OUT=MXGVVDS.TYPEVVDS;
Thanks to David Mesiano, Sharp Electronics, USA.
Thanks to Steve Mesiano, Sharp Electronics, USA.
Change 16.377 -Format MGX37FL, used in TYPEPROS (STOPX37 replacement),
FORMATS had values of 12/16/20/24/28/32x when the actual data
VMACPROS values are 0c/10/14/18/1c/20x.
Feb 16, 1999 -Label for ABDISP now is 'ABEND*DISPOSITION'.
Thanks to Michael E. Friske, Fidelity Investments, USA.
Change 16.376 Optional decoding of the ESS segment in SMF type 6 record
IMAC6ESS fails with INPUT STATEMENT EXCEEDED RECORD LENGTH if you
Feb 16, 1999 have more than 1 address parameter in the JCL. The line
GEPARTLN=0; must be moved to before IF GEPARMKY=27X....
and new line
IF GEPARTLN GT 0 THEN GEPARMLN=GEPARTLN+(GEPARMNR-1)*2;
was added before GEOFFSET=GEOFFSET+GEPARMLN+6;
Thanks to Waldemar Rathfelder, ADP TAYLORIX GmbH, GERMANY.
Change 16.375 Fixes logic dealing with the length of the dataset names
VMXGSUM in the INDATA= that cause warning messages about invalid
Feb 16, 1999 arguments to SUBSTR function. Improved KEEP logic now
uses NODETAILS options on PROC CONTENTS to avoid reading
the entire dataset just to find out what variables exist.
Change 16.374 Trending member for the PDB.SMFINTRV dataset (which is
TRNDSMFI from Type 30 Subtype 2/3 records and is created as
Feb 16, 1999 dataset TYPE30_V, controlled in member IMACINTV.
Change 16.373 Confused by the syntax for the new %LET statements in
UTILBLDP MXG 16.16? This macro will build the SYSIN stream for
Feb 16, 1999 you to run BUILDPDB completely from SYSIN using the new
%LET architecture. You tell us the SPINCNT desired, any
time differences, any additional SMF records that you
want to add to the BUILDPDB process, and anything that
you want to suppress, and this utility builds the sysin
stream, complete with comments.
Thanks to Chuck Hopf, MBNA, USA.
Change 16.371A If you were not using ASUMUOW's normal default (use the
ASUMUOW earliest transaction record as the real transaction name)
Feb 16, 1999 then some of the variables that are used to identify the
Feb 18, 1999 transaction (such as LUNAME, USER, TERMINAL, SYSTEM,
SMFTIME) may not have come from that real transaction
record, but were erroneously picked up from the last
transaction record in the unit of work, which might have
come from the SPIN library and might have blank values.
This change treats these identifying variables the way
that TRANNAME is, so that they all come from the same
record, and corrects the logic for SPINning records.
Thanks to Kevin Marsh, AT&T Solutions EMEA, ENGLAND.
Change 16.371 Subtype 0 records from CICS/ESA 4.1 caused UTILCICS to
UTILCICS fail with INPUT STATEMENT EXCEEDED RECORD error. Replace
Feb 16, 1999 IF '02' LE OLDVERCI LE '03' THEN SUBTYPE=0;
IF SUBTYPE EQ 00 THEN DO;
with
IF '02' LE OLDVERCI LE '03' THEN DO;
SUBTYPE=0; /* CICS 1.6, 1.7, 2.1 FORMAT DATA */
The real culprit was the MXG logic error, not the record!
Thanks to Andre van de Riet, Hudson Williams Europe, THE NETHERLANDS.
Change 16.370 New variable PCTMETGO was not calculated correctly; the
VMAC7072 test should be IF R723CVAL*RTSMAP(M) GE R723CVAL THEN DO;
Feb 16, 1999 so we compare the bucket's response time (instead of the
percentage value for that bucket) to the response goal.
At present, counting the first six buckets would produce
the same value, as the 6th bucket is the 100% bucket, but
this algorithm should protect future changes.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 16.369 MXG 16.06-16.10. Cosmetic. Names of some DROP variables
VMXGCICI were truncated (DIFTQTEM,DIFIOCRS,DIFIOCWF,DIFSTL,DIFST)
Feb 16, 1999 and so they were not dropped from temporary datasets, but
the MXG datasets were built without error.
Thanks to Alex Torben Nielsen, TeleDanmark EDB, DENMARK
Change 16.368 MXG 16.09-16.10. Macro PMVCICS had not been defined in
VMXGINIT VMXGINIT for the new CMRDETL support added in 16.09.
Feb 16, 1999
Thanks to Stephen Mesiano, Sharp Electronics Corp., USA.
==Changes thru 16.367 were in MXG NEWSLETTER THIRTY-FIVE Feb 20, 1999==
Change 16.367 MXG 16.06-16.10. Big CPU increase in BUILDPDB due to
VMXGCICI CICINTRV revisions introduced in MXG 16.06. MXG's use of
CICINTRV VMXGSUM's KEEPIN= option (which creates KEEP= statement
Feb 9, 1999 to keep only the needed variables) turns out to be very
CPU intensive in CICINTRV/VMXGCICI, even when there are
zero CICS observations! Replacing KEEPIN= option with
KEEPALL=YES removed the excessive cost of KEEPIN= logic.
In a single invocation of VMXGSUM when you need to keep
only a few variables from a large number of variables,
and when you have many observations (e.g., summing ten
variables from CICSTRAN, which was its purpose) using the
KEEPIN= option still makes sense, as it will save lots of
work space during the summarization. But CICINTRV, with
its many invocations of VMXGSUM (and a KEEPIN execution
for each argument of each VMXGSUM), and with essentially
all variables kept, so no space could be saved, the CPU
cost of KEEPIN was greater than the runtime without it!
Mac reported his BUILDPDB increased from 324 to 2650 CPU
seconds, a factor of eight! In my confirming tests, I
isolated the increase to CICINTRV and saw it jumped from
64 seconds to 446 seconds, about the same increase ratio!
That high cost (one build of the OPTVAR dataset took 53
seconds) is because we have to use SAS macro language to
parse arguments into macro variables and then convert to
variables in data steps so we can sort and remove dupes!
Note that VMXGSUM turns off SAS log messages, especially
for the data steps executed by the KEEPIN= algorithms,
and so the sum of "Step Used CPU" log messages will be
much smaller than the "Total CPU Used" value. For Mac,
his Total was 2650 seconds, but sum was only 380 seconds;
over 2270 seconds of KEEPIN= were not printed on the log!
Thanks to Mac Moss, Burlington Industries, Inc.
Change 16.366 NTSMF dataset PROCESOR variable DPCQUERT replaced DPCQUED
NTINTRV but the old variable name was still used in NTINTRV,
Feb 9, 1999 causing a missing value in NTINTRV.
Thanks to Chris Weston, SAS Institute ITSV Development, USA.
Change 16.365 Type 42 subtype 9 (dataset TYPE4237) was validated and
VMAC42 revised, and subtype 19 records showed wholesale revision
Feb 9, 1999 from their earlier documentation. Revised in 10Feb tape.
Thanks to Edward McCarthy, Health Insurance Commission, AUSTRALIA.
======Changes thru 16.364 were in MXG 16.10 dated Feb 8, 1999======
Change 16.364 QA test and MXG 16.04+ revision cleanup analysis:
DOC -TYPETMS5: PROC DELETE DATA=MGTMSVL; added after last use.
Feb 8, 1999 -SPUNJOBS: Variable DATETIME now formatted.
-MNTHDB2S: Variable STRTTIME now formatted.
-VMACTMDB: Variables D6ACBSC/D6ACESC now formatted.
-VMACVMXA: Variable DELTATM is now LENGTH 4 instead of 8.
-VMACEDGS: EDGSV: and EDGSU: added to dataset labels.
-VMACIMS/VMACIMSA: dddddd: added to dataset labels.
-TYPEMON8: dddddd: added to dataset labels.
-VMACOPC: OPC20: added to dataset label.
-VMAC28: L028IN7: corrected to 028IN7:.
-VMAC42: TY42P2: was missing colon in label.
-VMACMDF: Dataset Label was added.
-VMACHMF: Dataset Labels were added where missing.
-DIFFTPX: Dataset Labels was added.
-DIFFNTCP: Dataset Labels was added.
These products are not yet converted to the 16.04 design,
because they are second phase processes that don't read
raw data and don't really need the additional macro names
but they will eventually be revised to be consistent:
TRND70,TRND70PR,TRND71,TRND72,TRND27GO
TRNDDB2A,TRNDDB2S,TRNDDBDS,TRNDIDMS,TRNDRMFI,TRNDVMXA,
MNTH70,MNTH70PR,MNTH71,MNTH72,MNTHCICS,MNTH72GO MNTHDB2A
MNTHDB2S,MNTHDBDS,MNTHRMF,RMFINTRV.
VMXGHSM - does read HSM catalogs, but is standalone.
These products have not yet been 16.04 converted, and
won't be until someone asks for it, or until a change in
data requires an enhancement in these either standalone
or archaic programs:
TYPECRAY, TYPEFACO, TYPEPDL, TYPEVLFC, TYPEWWW, TYPEZARA
TYPE200, TYPETPNS, TYPERRTM.
Change 16.363 16.09 only, JCLTEST6 only. The new VMACMVCI for CMRDETL
JCLTEST6 still had RECFM=S370VB from PC testing, and MVS SAS does
VMACMVCI currently accepts only RECFM=VB, (although SAS has plans
Jan 21, 1999 for a fix to make S370VB an alias on MVS in Version 8?).
Change 16.362 The dataset name in MACRO _LHSMFUN should be HSMDSRFU.
VMACHSM The typo, HSMFSRFU, has never been a real dataset.
Feb 5, 1999 This 16.04 error has impact only if you used the _LHSMFUN
macro as the destination of your own PROC SORT, or if you
used the new _SHSMFUN macro; that created PDB.HSMFSRFU
instead of PDB.HSMDSRFU (but since it has all of the
variables, you can just rename it back to PDB.HSMDSRFU
without re-read of your SMF data).
Thanks to John McCray, Huntington Services Company, USA.
Change 16.361 Support for IDMS Version 14 Journal Records. Most IDMS
TYPEIDMJ sites write to SMF rather than a journal, and the SMF
VMACIDMJ records were fine, but the TYPEIDMJ support for journal
Feb 5, 1999 format had not been updated from IDMS Version 12! This
change only works with Version 14 data; I didn't take the
time to write it to work with both, as I don't think you
can be still running Version 12, but if you need it, I'll
enhance it for the old version too!
Thanks to David Thorn, Dow Jones, USA.
Change 16.360 -VMAC110: 16.09 only, new time variables in CICDS and in
IMACICOM CICINTRV did not have TIME12.2 format.
VMAC110 -IMACICOM: several MQxxxxTM duration variables had the
VMACDB2 same label as the MQxxxxCN count variables.
VMACTMDB -VMACDB2: new variables QXCOORNO/QXCRGTT/QXISORR/QXSTREOP
TYPETMON and QZZCBPNX/QZZCSKIP were missing because they had been
TYPEMONI added to the KEEP= list for DB2STAT0 instead of DB2STAT1.
Feb 5, 1999 -VMACTMDB: variable LMRKFLG1 was listed twice in FORMAT
statement; the last instance - $HEX2. - was removed as
it was overriding the $MGTMDGF decoding format.
-Archaic TYPETMON and TYPEMONI were upgraded to the 16.04
architecture, mostly for QA purposes than real need, as
both are archaic (replaced by TYPETMO2 and TYPEMON8).
Thanks to Chris Weston, SAS Institute ITSV Development, USA.
Change 16.359 Change 16.204 externalized tailoring for IMACACCT among
IMACACCT others, but the &MACACCT; statement was not added to
Feb 3, 1999 the end of the IMACACCT member until now.
Thanks to Paul Oliver, BHP, AUSTRALIA.
Change 16.358 TYPE39_6 variables DURATM, STARTIME, in the SCS segment
VMAC39 were originally only created in Netmaster records, but
Feb 3, 1999 became unneeded when IBM added ACTSTIME/ACTETIME to the
accounting segment. I never noticed, but now in NetView
for OS/390 Version 1 Release 1 type 39 records, IBM has
put several character fields where those old fields were
input, causing strange dates (like 2008) when MXG reads
those characters as TODSTAMP datetimes! The unneeded old
Netmaster variables are now set missing/blank, and the
new fields (Primary/Secondary CP NetworkID/Name and APPN
class of service name and APPN transport priority) were
added to each of the subtype 1-8 TYPE39 datasets.
Thanks to Tracy Blackstone, Kaiser Permanente, USA.
Change 16.357 Variable DDNAME was not kept in TYPETMNT, but no one had
VMACTMNT need of it. But now, in developing a new MXG tool that
Feb 3, 1999 decomposes all job delays, we find DDNAME is needed so we
can detect "parallel" tape mounts (when one tape DD has
multiple tape drives allocated) so we can not-include the
second-and-subsequent mount delays in the job delay total
(the reason you allocate two drives for one tape DD is so
that the rewind/mount time of one is in parallel with the
job's use of the other, to prevent any delay to the job).
Change 16.356 Support for Sterling's SOLVE NetMaster for TCP/IP SMF
EXTYSOLN creates one observation in dataset TYPESOLN for each
FORMATS record (which are identified as either interval or
IMACSOLN event), decoding as many of the up-to-12 fields that
TYPESOLN might be present. Variable ATTRID identifies what is
VMACSOLN measured in each record, and has values in mixed case
VMXGINIT (like "ifInPktsNUcast" and "ifInPktsDiscard") for each
Feb 3, 1999 metric. There are nearly 60 metrics available:
TCP/IP Stack: FTP/TELNET/Workload Connection activity
TCP/IP Node Monitor: SNMP counters/response/available
CISCO Monitor: Channel card load/errors/TN3270 use
Local Interface: Status and Thruput
The complete list and description is in SOLVE:Netmaster
Graphical Performance Manager User's Guide, Appendix C,
Attribute Descriptions.
Thanks to Wendy Wong, Sterling (Field Engineer), AUSTRALIA
Change 16.355 The DB2 Buffer Hit Ratios calculated in DB2STATS became
VMACDB2 negative because the TSPP field apparently should not be
Feb 2, 1999 included. The old equation TGET-(TSIO+TDPP+TLPP+TSPP)
had values of 175-(101+0+0+1621) so clearly TSPP is out
of place, and thus has been removed from the equations
for B1HITRAT/B2HITRAT/B3HITRAT/B4HITRAT and BPHITRAT.
I am now looking for an IBM update to their equations.
Change 16.354 There are additional fields captured in HPs MeasureWare
VMACMWSU for Sun that can now be output; some fields were removed
Feb 2, 1999 and some were reordered. The new fields are defined, but
you may need to compare the headings of the report with
the MXG input sequence to see that they are the same.
Thanks to Tim Crocker, NCCI, USA.
Change 16.353 The RMF WKLD Workload Activity Report was updated for
ANALRMFR OS/390 MODE=COMPAT, the WLMGL Report RPTORP=RCLASS
Feb 2, 1999 SCLASS SCPER has been updated for MODE=GOAL, the WGPER
Feb 20, 1999 BY lists now have BY SYSPLEX STARTIME ....
Thanks to Jiann-Shiun Huang, CIGNA, USA.
Change 16.352 Some report/summary members had not been revised for the
ANALARB 16.04+ architecture and still %INCLUDEd their product's
ANALDB2R IMACxxxx member instead of its VMACxxxx member. As long
ANALPDSM as the program ran in the same step that built its data
ASUMHPSU sets, there was no error, because the VMACxxxx member
ASUMHPUX would have already been %INCLUDEd, but standalone runs
Feb 2, 1999 caused SAS "180" syntax errors due to missing macros.
MXG no longer defines macros in the product IMACxxxxs,
but instead MXG defines its macros in the VMACxxxx's,
which themselves include the IMACxxxx if you have one.
any overrides of the MXG defaults.
But not all includes of IMACxxxx members were changed,
as there are non-product IMACxxxx members (IMACRMFI)
that are still validly included by these programs.
Thanks to Chuck Hopf, MBNA, USA.
Change 16.351 -Support for BETA93 3.1.3 Subtypes 1, 2, 3, 4, 20, 40, 41
FORMATS and 42 has been validated with single-record tests. In
VMACBETA one subtype 20, the READ DATE and TIME are invalid, which
Feb 2, 1999 means variable READTIME (which is necessary to match the
Beta records to other SMF records for the job accounting)
has a missing value, so the Beta records can't be matched
to their jobs other data! In the one test record:
valid LINP date invalid LJOB date
S20LINPT+S20LINPD S20LJOBT+S20LJOBD
time cyyddd time cyyddd
'0064B47A 0095001F' '00000000 0100000F'x
That record was written on 2Nov98; the 95 date shows the
document has been around for a while. This discovery
will be forwarded to the MXG site to forward to the Beta
vendor for response and correction. I will update this
MXG note when I hear back from the vendor, but since the
invalid date causes a hex dump of the record on the SAS
log, I have added "??" to suppress the dump and message.
Create the Beta datasets and use PROC MEANS N DATA=....
to see how many records have invalid data for READTIME.
-Existing format MGBETRT for variable BETAATT4 was updated
since it now has character rather than hex values.
Thanks to Wolfgang Prescher, Quelle, GERMANY.
Change 16.350 Support for WINDOWS NT 5.0 (INCOMPATIBLE) for NTSMF adds
EXNTAPLT new objects and new counters, but NT 5.0 appears to have
EXNTGWNW removed some important data:
EXNTHTIS =Changes to existing supported objects:
EXNTINSF -SYSTEM object removed all of the CPU busy fields; these
EXNTINSR variables will have missing value in the SYSTEM dataset:
EXNTJOB APCBYPAS DPCQUERT DPCRATE DPCBYPAS INTERUPT
EXNTJOBD PCTCPUTM PCTUSRTM PCTPRVTM PCTDPCTM PCTINTTM
EXNTMACF But those variables are also in the PROCESOR dataset
EXNTPRNQ (although per-CPU instead of per-interval), and NTINTRV
EXNTRASI logic sums those PROCESSOR variables into the interval
FORMATS CPU busy measures (by accident, because it happens that
IMACNTSM the MERGE statement lists SYSTEM before PROCESOR, and SAS
VMACNTSM always takes values from the last dataset when the same
VMXGINIT variable is in multiple datasets), so you should make
Feb 1, 1999 sure you are creating the Processor object so you can get
Feb 4, 1999 those most-important measures in PDB.NTINTRV dataset.
And if you were using dataset SYSTEM in your reporting
for those fields, you'll need to change to use PROCESOR
or PDB.NTINTRV for the interval utilizations in NT 5.0.
Two new variables, PROCESES and THREADS were added to the
SYSTEM object to count processes and threads.
-LOGLDISK object no longer has the physical disk name,
variable PDSKNAME, so you can't recognize which logical
disks are on which physical devices! Two new measures
PCTIDLE (percent idle time) and SPLTIORT (SPLIT I/Os per
second) were added to this object.
-PHYSDISK object has the same two new measures, PCTIDLE
and SPLTIORT that were added to LOGLDISK object.
=New objects, their "NTdddd" suffix and dataset name:
suffix dataset
AppleTalk NTAPLT APPLETLK
Gateway Service for Netware NTGWNW GTWYNETW
Http Indexing Service NTHTIS HTTPINSR
Indexing Service NTINSR INDEXSRV
Indexing Service Filter NTINSF INDSRVFL
Job Object NTJOB JOB
Job Object Details NTJOBD JOBDETLS
MacFile Server NTMACF MACFILE
Print Queue NTPRNQ PRINTQUE
RADIUS Server [IAS] NTRASI RADIUIAS
This support is based on Windows NT 5.0 Beta 2 discovery
records, and some records have been tested, but none of
new objects yet. NT 5.0 is to be renamed Windows 2000.
With 486 processors and NTSMF earlier than 2.2, an INPUT
STATEMENT EXCEEDED RECORD LENGTH on the 0.0 record is now
avoided; the CPUSPEED fields are now only input if your
NTSMF version is 2.2 or higher.
Change 16.349 The statement SQRTARG=(SSQELAP/TRANS-(RESPAVG**2);
ASUMCICS caused INVALID ARGUMENT TO SQRT function because it
ASUMCICX should have been IF TRANS GT 0 THEN SORTARG=(....
TRNDCICS Change 16.137 protected for negative square roots, but
TRND72 did not protect for zero divide with zero transactions.
Jan 30, 1999
Thanks to Normand Poitras, ISM, CANADA.
Change 16.348 The internal _PDB6 macro was enhanced, adding variables:
BUILD005 BINUSED BIN1BNCT BIN2BNCT BIN3BNCT BIN4BNCT
BUIL3005 BIN5BNCT BIN6BNCT BIN7BNCT BIN8BNCT BIN1USED
Jan 30, 1999 BIN2USED BIN3USED BIN4USED BIN5USED BIN6USED
BIN7USED BIN8USED
so they are kept in PDB.PRINT to measure bin activity.
Thanks to John A. Rivest, TDS-Computing Services, USA.
Change 16.347 Preliminary report merges datasets HSMFSRST and PDB.JOBS
ANALALOC to report how much of ALOCTM allocation delay was due to
Jan 30, 1999 HSM recall (and recall time spent queueing for an HSM
Feb 17, 1999 thread is separated from actual recall time), and how
much was real allocation delay. Further enhancements to
bring in other delay records (e.g., MXGTMNT allocation
and tape mount delay) are planned, to ultimately provide
measurement of each separable delay in a job's life.
Revised, Feb 17, 1999, but does not yet account for
overlap of mount times when parallel devices mounts are
used (i.e., multiple tape devices for one DD).
Thanks to Rebecca Cates, PKS Computer Services, USA.
Change 16.346 Thruput Manager SMF records with no token entries caused
VMACTPMX ERROR.VMACTPMX. TOKEN NOT FOUND, FIELD WAS NOT INPUT.
Jan 30, 1999 because MXG logic assumed there would always be tokens.
Change the DO UNTIL (NEXLOC=0); to now read
IF OFFXFE GT 0 THEN DO UNTIL (NEXTLOC=0);
and the record will be output.
Thanks to Joseph Montana, Trans Union Corporation, USA.
Change 16.345 Enhanced HSM summarization now separates the HSM delay
ASUMHSM into active and queued requests so you can track HSM's
TRNDHSM concurrent thread count, used and required. Triggered
Jan 30, 1999 by the new ANALALOC program, in Change 16.347, and now
used by the revised ANALHSM in Change 16.383.
Change 16.344 RMF Reports are enhanced:
ANALRMFR -Coupling Facility, Average CF utilization corrected.
FORMATS PCTCFBSY, if logical processors present, calculate
Jan 30, 1999 using logical processor effective.
-Updates PARTITION DATA REPORT for deactivated LPARs.
The values for counts in the MXG reports, will be
output as they are in the MXG/SAS database. (IBM
reports counts as 80K but ANALRMFR shows 80396).
Some values (standard deviation, delay time and /all
time), are still in development/validation.
-ADD Subchannel Activity Report.
-Format MGRMFF was revised to round percentages better.
Thanks to Scott Wiig, USBank, USA.
Change 16.343 Using JCLIMSLG/ASMIMSLG logic to read IMS log records for
VMACIMSA IMS FastPath transactions created zero observations in
Jan 30, 1999 IMSFASTP dataset, because the variable SUBCODE was not
kept in the IMS591,593,596,597, and IMS598 datasets.
The variable was added to the KEEP= list for those five
datasets (but Pete just used the five _KIMS59x macros
to add SUBCODE to circumvent the error in the interim).
Also, the PUT _ALL_'s that were unlimited will now only
print for the first five instances of unmatched fastpath.
Thanks to Pete Gain, SAS Software Pty, ENGLAND.
Change 16.342 New variable CECSER, the CPU SERIAL NUMBER OF THE CEC,
VMAC7072 (Central Electronic Complex) is created from CPUSER in
Jan 29, 1999 TYPE70 and TYPE70PR datasets, to identify the hardware
box in which this MVS system ran. The last two bytes of
CPU Serial (CPUSER) are converted to hex representation
and stored in the new 4-byte character variable CECSER,
so a CPUSER='03870F'X has CECSER='870F'.
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Change 16.341 IMACPDB documentation. No code was changed.
BUILD005 The new architecture eliminates tailoring member IMACPDB,
BUIL3005 but I failed to document how! Previously, you EDITed the
IMACPDB macros (_PDB6, _PDB26J2, etc.) in IMACPDB to add fields
ZMACPDB (not kept by default) from type 6, 25, 26, and 30 SMF
Jan 29, 1999 records, into the PDB.JOBS, PDB.STEPS, and PDB.PRINT
datasets. But then you had to update your IMACPDB each
time when I changed something, because your IMACPDB will
(still) override my defaults. But now, with the 16.04+
design, you can instead use the &ADDxxxx macro variables,
with %LET ADDxxxx= var1 var2 ... ; syntax, to add your
variables. Your %LET can be in member IMACKEEP or can
be in the SYSIN stream using the "MACKEEP=". So if you
have an IMACPDB member, compare it with the old member in
ZMACPDB to see what your site added, and use the %LETs to
add those variables and eliminate your IMACPDB.
The new macro variable names and their function are:
MACRO Variable For Dataset/Function
ADD6 TYPE6
ADD25 TYPE25 (JES3 only)
ADD26J2 TYPE26J2 (JES2 only)
ADD26J3 TYPE26J3 (JES3 only)
ADD30U1 TYPE30_1
ADD30U4 TYPE30_4
ADD30U5 TYPE30_5
ADDACT2 Account fields back-merged
from JOBS to STEPS/PRINT
(JES2 only)
ADDACT3 Account fields back-merged
from JOBS to STEPS/PRINT
(JES3 only)
The macros formerly defined in IMACPDB member are now
defined in members BUILD005 (JES2) or BUIL3005 (JES3).
Thanks to Mike A. Geiger, A. C. Nielsen, USA.
Change 16.340 Some variables in ENDEAVOR dataset ENDEVRSE were wrong
VMACENDV because the end-of-comment was missing after the INPUT
Jan 29, 1999 of variable EDVIFUNC, causing out-of-alignment.
Thanks to Kenneth D. Jones, SHL Systemhouse, CANADA.
Change 16.339 Type 42 subtypes 15-19 (VSAM RLS) now exist and test data
VMAC42 exposed IBM errors: their length field in the triplet has
Jan 29, 1999 total length, instead of the length of the segment, which
caused MXG to DELETE all the records with a WRONG LENGTH
message on the log because of this invalid length value.
MXG circumvents by constructing the segment length from
the total length and number of segments. However, IBM
has changed some fields after the early documentation,
and real data corrected several typos & logic errors so
that now each repeated segment will be output. Also, all
TYPE42xx datasets now have their _BTY42xx "By" and their
_STY42xx "Sort" macros implemented.
Thanks to Ed McCarthy, Health Insurance Commission, AUSTRALIA.
Change 16.338 The old &PDB70,&PDB71,...&PDB78 macro variable names were
ASUM70PR still used as the source DDNAME of the TYPE7xxx datasets
RMFINTRV that are read into RMFINTRV, but in the new 16.04+ design
Jan 28, 1999 those names should have been &PTY70,&PTY71... PTY78.
There was no execution error, because both sets of macros
variable names have default values of "PDB", but if you
tried to use the new 16.04+ tailoring to split your PDB
into multiple destinations, DATASET NOT FOUND errors
would result. All of the &PDB7xxx's are now &PTY7xxx's.
Note that &PDBRMFI is still the name for RMFINTRV.
-Same error in ASUM70PR, but &PDB70PR is now &PTY70PR.
Thanks to Linda Carroll, IBM Global Services, USA.
Change 16.337 -Support for these new NT objects:
EXNTBENC -DB2 NT DATABASE MANAGER object creates dataset DB2.
EXNTDB2 with one instance variable and 15 counter variables.
EXNTFAXG -FAX SR. GATEWAY MONITOR object creates dataset FAXGATEW,
EXNTMSCC with one Instance variable and 8 counter variables.
EXNTPCHB -VPN ADAPTER object creates VPNADAPT dataset with two
EXNTRADI Instance variables and 15 counter variables.
EXNTUSER -Terminal Server object USER creates dataset USER with
EXNTVINE one instance variable (USER) and the other fields in the
EXNTVPN PROCESS object (except for IDUSER/IDLOGON!).
FORMATS -Radius Server object creates dataset RADIUS, but only
IMACNTSM discovery records have been read.
VMXGINIT -Benchmark Factory object creates dataset BENCHMRK, but
VMACNTSM only discovery records have been read.
Jan 30, 1999 -Microsoft Exchange object MSExchangeMSCC created MSEXCHCC
with counts and rates of mail activity between Exchange
and Lotus CC:MAIL. Only Discovery have been read.
-Vines Communications object creates dataset VINES with
33 counters.
=Enhancement/correction to existing NT objects:
-PROCESS dataset variables IDLOGON and IDUSER had missing
values, because MXG had a test for NRDATA=20 instead of
NRDATA=21. The WIDE2MBE variable was renamed to CREATPID
when Demand Technology was able to discover what was put
in that undocumented field (Creation Process ID).
-WINPROXY dataset has two variables now removed from the
record (but MXG still creates them, with missing value,
so your reports won't die), and five new fields were
added (incompatibly, of course!).
Thanks to Jim Quigley, Consolidated Edison, USA.
Change 16.336 IBM Documentation for NPM 2.4 is wrong, causing STOPOVER
VMAC28 error with NPMSUBTY='DD'x record. The VTT section has a
Jan 26, 1999 documented length of 196 bytes, but records with only 176
bytes (thru VTTNNCDS) are being created by IBM. To avoid
the error, two lines were inserted in the VTT input:
VTTNNCDS &PIB.4. original line
@; inserted line
IF LENAOF GE 196 THEN INPUT inserted line
VTTNRRGC &PIB.4. original line
Mar 10, 2000: APAR OW37758 fixed the 2.4 error, but that
APAR was not applied to the 2.5 release, so APAR AW43578
exists for 2.5, with no PTF. See Change 18.032.
Thanks to Brian Crow, British Telecom, ENGLAND.
Change 16.335 Variables H15TCSDT and H15TCEDT in TYPERDSn RDS datasets
VMACRDS have never been correct, because MXG used JULDATE() where
Jan 22, 1999 it should have had DATEJUL(). No one noticed/complained,
probably because variable SMFTIME was valid, but now the
dates use DATEJUL() and its protection algorithm.
Thanks to Forrest Nielson, State of Utah, USA.
======Changes thru 16.334 were in MXG 16.09 dated Jan 20, 1999======
Change 16.334 Variable INNODE in TYPETPMX was changed to INNODEC, from
VMACTPMX numeric to character because INNODE was already defined
Jan 19, 1999 as numeric in other datasets created from SMF records.
Change 16.333 ADSM data transfer units were true Kilobytes so their
VMAC42 multiplier is changed from 1000 to 1024 for variables
Jan 17, 1999 ARCBYTCS,BKPBYTCS,DATBYTCS,ARCBYTRE and BKPBYTRE in
dataset TYPE42AD. I guessed the 1000 because most of
storage in IBM "KB" means 1000 rather than 1024, but
this guess was wrong.
Thanks to Kristyann Manske, University of Wisconsin-Milwaukee, USA.
Change 16.332 Variables DPRTY and IODP are both now formatted as HEX2.
VMAC99 to be consistent with historic priority ranges that are
Jan 17, 1999 commonly in hex (00-FF) rather than decimal.
Thanks to Chuck Hopf, MBNA, USA.
Change 16.331 "Cosmetic Audit" of duplicate variables in LABEL, LENGTH
DOC and FORMAT statements, incorrect dataset name in comments
Jan 17, 1999 and _L macro names where _W macro names belong, and other
similar typos were corrected in these members:
VMAC102 VMAC110 VMAC28 VMAC30 VMAC40 VMACAPAF
VMACCIMS VMACCIMS VMACCMF VMACCMFV VMACDCOL VMACHSM
VMACICE VMACILKA VMACIMS VMACIMSA VMACMWAI VMACMWUX
VMACNTSM VMACPW VMACRMFV VMACVMON VMACVMXA
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 16.330 Status of MXG Year 2000 Support as of Jan 20, 1999.
ASUMHSM
TYPE80A MXG 16.09 is now required for full Year 2000 Support of
TYPEBETA all fields in all records from all supported products.
TYPEDCOL This replaces all prior statements of MXG Y2K Support.
TYPEHSM
TYPEMON8 MXG 16.01 and later do support almost all products, but
TYPEMOND five common products now require MXG 16.09 or later:
TYPEOPC HSM SMF Records
TYPETMON CA-1 aka TMS Tape Management Records
TYPETMS5 BETA93 SMF Records
TYPETMV2 Landmark Monitor for MVS Version 2
TYPETMVS VM Accounting records
TYPEVLFC Additionally, six other products that have variables
TYPEVM that were not Y2K compliant, but those variables were
YEAR2000 unlikely to have been used in your reports:
Jan 17, 1999 DCOLLECT - one julian date variable, UCCOLDT
Jan 20, 1999 OPC/A - three obscure julian date variables
Landmark - CICS: TYPEMON8,TYPETMON,TYPEMOND
MVS: TYPETMV2,TYPETMVS
one internal datetime TMMDCCLK.
ASTEX - one julian date SDATE
RACF SMF - two variables REVOKEDTE, RESUMEDTE
VLF - VLF Catalog records from SYSLOG.
Products were found with julian dates that were kept as
0cyyddd value (0100001 for 01Jan2000), which is a valid
Y2K format, but which is one not supported by SAS's
DATEJUL() function, so while MXG correctly created valid
Y2K values, your reports or exit logic would fail if they
used DATEJUL() on those 0cyyddd values. No ABEND, but
missing values or invalid argument messages on your log.
For example, TMS records have julian date values like the
EXPDT that are kept as 0cyyddd that could cause problems.
This DATEJUL() problem itself is not new. MXG reported
it and has provided an algorithm (described in member
YEAR2000, implemented by Change 15.050) that protects
julian dates as they are converted into SAS DATETIME
or DATE variables, which are Y2K compliant. But that
algorithm did not change the raw julian date value.
This change revises the protection algorithm so that it
now replaces the original 0cyyddd value with the valid
yyyyddd value in the raw julian date variable, unless the
yyyyddd value is missing (i.e., an invalid "date" like
99000), when the original raw value is not overwritten.
ASUMHSM testing with Y2K HSM records exposed the error,
and I realized that TMS and all products that keep julian
date variables were exposed, so every MXG member that had
a julian date field was examined, and I found four more
with the kept-julian-date-problem. I also found six
products (nine variables) that had been overlooked by MXG
Change 15.050 that were having unprotected sex with the
DATEJUL() function. All are now algorithm-protected.
Members with kept-julian-date-fields and the variables
that are now converted to yyyyddd:
TYPEDCOL UCCOLDT
TYPEHSM DSRDATE,VSRDATE,FSRBDATE,FSRDATR,FSRDLM,
FSRDLU
ASUMHSM DSRDATE
TYPEOPC TRLEVDAT,MT0CPED,MT0DAT
TYPETMS5 BTHDATE,CRTDT,DSADT,EXPDT,TMVADATE,LDATE,
TMAUDATE
TYPETMV2 JDRDATE
TYPETMVS (archaic) JDRDATE
Members overlooked in Change 15.050 and the variables
that are now protected:
TYPEBETA BETASTRT, BETAEND, BETASTSE, BETAENSE
TYPEDMON SDATE
TYPEHSM WFSRDATR, WFSRDATS, WFSRDATE
TYPETMV2 LMRKDATE, ENDTIME, STRTTIME
TYPETMVS (archaic) LMRKCARK
TYPE80A REVOKDTE, RESUMDTE
TYPEMOND TMMDCCLK
TYPEMON8 (archaic) TMMDCCLK
TYPETMON (archaic) TMMDCCLK
TYPEVLFC DATETIME
TYPEVM STARTIME, ENDTIME
In addition, thirty-five other members were changed
to streamline the algorithm where the creation of the
DATEYYYY variable was not required. These members
were and still are Y2K compliant, but are now more
robustly protected and their non-kept julian dates
are now converted to yyyyddd format:
TYPE90,TYPE84,TYPE434,TYPE37,TYPE1415,TYPE110,
TYPECTLT,TYPEFILA,TYPEIDMJ,TYPEIDMS,TYPEIMS,
TYPEIMSA,TYPEIPAC,TYPEITRF,TYPENDM,TYPENETP
TYPENSPY,TYPEOMVT,TYPEPDSM,TYPEROSC,TYPESIM,
TYPETRMS,TYPEWSF,TYPEXCOM,TYPEXSTR,TYPESUPR,
TYPESLRI,TYPERTEJ,TYPEDMS,IDMSLO57,IDMSJRNL,
ANALTMS,ANALSNAP,ANALRACF,ANALCM29
Thanks to John McCray, Huntington Services Company, USA.
Thanks to Xiaobo Zhang, Insurance Service Office, USA.
Change 16.329 Support for OS/390 R 2.7 (COMPATIBLE) adds new subtypes,
EXTY746B records, and segments:
EXTY746F -RMF type 74 record has new subtype 6 which creates three
EXTY746G new MXG datasets describing Hierarchical File Systems.
FORMATS While storage size fields in the raw record are in pages
VMAC42 or MB, MXG converts them all to bytes and formats with
VMAC7072 MGBYTES so the storage variables have the same, standard
VMAC73 units that display as MegaBytes, GigaBytes, etc.
VMAC74 -TYPE746G - HFS Global Statistics - one per interval
VMAC79 R746G1C ='FIRST PAGE*FINDS*IN CACHE'
VMXGINIT R746G1NC='FIRST PAGE*NOT FOUND*IN CACHE'
VMAC109 R746GLRC='RETURN CODE*BPX1PCT*BUFFLIM'
EXTY109 R746GLRS='REASON CODE*BPX1PCT*BUFFLIM'
IMAC109 R746GMC ='METADATA*FINDS*IN CACHE'
TYPE109 R746GMNC='METADATA*NOT FOUND*IN CACHE'
TYPS109 R746GMNF='VALUE OF FIXED(MIN)'
Jan 16, 1999 R746GMXV='VALUE OF*VIRTUAL(MAX)'
R746GSFL='STATUS FLAGS'
R746GSRC='RETURN CODE*BPX1PCT*GLOBSTAT'
R746GSRS='REASON CODE*BPX1PCT*GLOBSTAT'
R746GUSF='PERMANENT*FIXED*STORAGE*IN USE'
R746GUSV='VIRTUAL*STORAGE*IN USE'
-TYPE746B - HFS Buffer Statistics - one per buffer pool
R746GBF ='BUFFER*WAS FIXED*PRIOR TO*IO REQUEST'
R746GBNF='BUFFER*WAS NOT FIXED*PRIOR TO*IO REQUEST'
R746GNDS='NUMBER OF*DATA SPACES*FOR BUFFER POOL'
R746GSB ='SIZE OF*BUFFERS*IN BUFFER POOL'
R746GSBN='BUFFER*POOL*NUMBER'
R746GSBF='SIZE OF*PERMANENT*FIXED*BUFFERS'
R746GSBP='SIZE OF*BUFFER*POOL'
-TYPE746F - HFS File System Detail Statistics
R742PSNM='FILE*SYSTEM*NAME*(DSN)'
R746F1C ='FIRST PAGE*WAS FOUND*IN CACHE'
R746F1NC='FIRST PAGE*NOT FOUND*IN CACHE'
R746FCTM='CURRENT*TIME*STAMP'
R746FIJ ='INDEX JOINS'
R746FINT='INDEX NEW TOPS'
R746FIRH='INDEX PAGE READ HITS'
R746FIRM='INDEX PAGE READ MISSES'
R746FIS ='INDEX SPLITS'
R746FIWH='INDEX PAGE WRITE HITS'
R746FIWM='INDEX PAGE WRITE MISSES'
R746FMC ='METADATA WAS FOUND IN CACHE'
R746FMNC='METADATA NOT FOUND IN CACHE'
R746FMTM='MOUNT*TIME*STAMP'
R746FPC ='DATA BUFFER BYTES CACHED BY THIS FILESYS'
R746FPD ='BYTES USED FOR ATTRIBUTE*DIRECTORY'
R746FPF ='BYTES*INTERNALLY*USED*BY HFS'
R746FRFI='RANDOM FILE DATA I/O REQUESTS'
R746FSF ='BYTE SIZE OF*FILE*SYSTEM'
R746FSFI='SEQUENTIAL FILE DATA I/O REQUESTS'
R746FSFL='STATUS*FLAGS'
R746FSNL='LENGTH OF*FILE*SYSTEM*NAME'
R746FSRC='RETURN CODE*BPX1PCT*FSSTATS'
R746FSRS='REASON CODE*BPX1PCT*FSSTATS'
-RMF type 70 record has new bit values for SMF70PFG that
MXG decodes into two new variables in TYPE70PR:
LPARCHDE='NUMBER OF*DEDICATED*PROCESSORS*CHANGED?'
LPARCHSH='NUMBER OF*SHARED*PROCESSORS*CHANGED?'
-RMF type 73 record has new CPMF (Channel Path Measurement
Facility) mode variable in dataset TYPE73:
SMF73CMI='CPMF*MODE'
which is decoded by the new MG073CP format:
0='0:CPMF IS NOT ACTIVE'
1='1:COMPATIBILITY MODE'
2='2:EXTENDED MODE'
-RMF type 79 record subtype 12 also has a new CPMF*MODE
variable in dataset TYPE79C
R79CCMI='CPMF*MODE'
that is also decoded by the new MG073CP format, above.
-SMF type 42 subtype 5 and 6 contain new field S42DSDAO
that MXG creates in datasets TYPE42DS, TYPE42SR, and
TYPE42VT as new variable named:
AVGDAOMS='AVERAGE*I/O DEV-ACTIVE-ONLY*MS PER SSCH'
-New SMF type 109 record is written by OS/390 Firewall
Server, and contains log messages of firewall activity
that appear to be quite useful to security folks. The
ICAxxxxx and ICACxxxx message structure will be decoded
when I have test data from an interested site; for now,
those messages are just carried as text strings.
These changes have not been tested with 2.7 data yet.
Change 16.328 For Percentile Goal Service Classes, a new MXG variable
VMAC7072 PCTMETGO reports the actual percentage of transactions
Jan 14, 1999 that met the goal. For example, take a Service Class
Sep 17, 2002 that has a goal value of 1 second. Its MAP values are
actually percentages of the goal and the product of the
MAP value and the goal value is the response time value.
If the goal is 90% in 1 second, and your data values are:
MAP .5 .6 .7 .8 .9 1 1.1 1.2 1.3 1.4 1.5 2 4 FF
TRN 8638 108 101 69 59 53 56 43 42 30 1 147 134 22
then 90.9% (8638/9503) of those transactions ended in the
first bucket, in one-half-second. You easily met your
90%-in-one-second goal; in fact 90% of your transactions
were satisfied in less than 50% of your goal value, so
your goal is being met at a level of 50% of the response
time goal, so IBM's PERFINDX is 0.5, "twice as good".
(See why you need to be careful with percentages,
and always include, "of what").
But if we sum the number of transactions in the first six
buckets (i.e., those transactions whose response time was
less than or equal to the goal value), there were 9028 of
the 9503 transactions (95%) that met the one second goal,
and the value of new variable PCTMETGO=95.00.
Thanks to Chuck Hopf, MNBA, USA.
Change 16.327 For Service Classes with Average Goal value that had no
VMAC7072 delay samples (i.e., PCUTSOU=0 and PCTDLTOT=0), VELOCITY
Jan 14, 1999 cannot be calculated so it was missing value, but MXG
then erroneously set PERFINDX to zero, even when it
could be calculated. The original logic:
IF (TRANS EQ 0 AND TRANSEXC GT 0) OR R723CRGF='A' THEN ..
IF R723CVAL LE 0 OR VELOCITY LE 0 THEN PERFINDX=0;
ELSE PERFINDX=AVGELPTM/R723CVAL;
END;
now has the test for VELOCITY removed:
IF (TRANS EQ 0 AND TRANSEXC GT 0) OR R723CRGF='A' THEN ..
IF R723CVAL LE 0 THEN PERFINDX=0;
ELSE PERFINDX=AVGELPTM/R723CVAL;
END;
Thanks to Chuck Hopf, MBNA, USA.
Change 16.326 TYPE72 for Compatibility Mode OS/390 R2.4+ was incomplete
VMAC7072 as new delay variables were input in the subtype 3 SMF
Jan 14, 1999 record for WLM Goal Mode, but were not input for the
subtype 1 Compat Mode record. These variables are new:
SMF72ADT='INELIGIBLE*AFFINITY*TIME'
SMF72CVT='JCL CONVERSION*TIME'
SMF72IOD='TOTAL*I/O*DELAYS*SAMPLES'
SMF72IOT='DASD*IOS QUEUE*TIME'
SMF72IQT='INELIGIBLE*OTHER*RESOURCE*TIME'
SMF72QDT='TOTAL*QUEUE*DELAY*TIME'
SMF72TSA='TOTAL*EXECUTION*SAMPLES'
Thanks to Rick Mansfeldt, GE Capital, USA.
Change 16.325 Documentation only; the instructions implied you needed
BLDNTPDB to run three separate BLDNTDPBs, one for DAY, WEEK, and
Jan 14, 1999 MONTH, but in fact, all you need is to use daily:
%BLDNTPDB(RUNDAY=YES,RUNWEEK=YES,RUNMNTH=YES);
and the daily will always be built, the weekly will be
built on the WEEKSTRT= date (default=MON), and the
monthly will be built on the first day of the month.
Thanks to Wayne Holzback, Reynolds Metal Company, USA.
Change 16.324 Variables R744FTIM, FSQU, FCTM, and FCSQ should have
VMAC74 been divided by 4096.
Jan 14, 1999
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 16.323 Change 16.271 was not supposed to change VMXGSUM, but it
VMXGSUM did; the comments around &DATETIME=DATETIME; statement
Jan 14, 1999 that were added by 16.271 have now been removed.
Thanks to Freddie Arie, Lone Star Gas, USA
Change 16.322 Support for CICS TS 1.3 (INCOMPATIBLE). IBM inserted
ADOC110 data fields in the middle of the accounting record, so
EXCICCF6 you MUST use MXG 16.09 or later to read CICS TS 1.3 data.
EXCICCF7
EXCICCF8 Lots of new measurements have been added, especially for
EXCICCF9 Web activity (and the first JAVA measurements in MVS!!!).
EXCICNC4 There are also new subtypes 3, 4 and 5, and new stat data
EXCICNC5 records and new fields added to existing statistics, and
EXCICSOR there are now 11 TCBs that CICS can dispatch!
FORMATS The type 110 subtype 1 (CICSTRAN dataset) has these 61
VMAC110 new variables added:
VMXGCICI ACTVTYID='ACTIVITY*ID'
Nov 29, 1998 ACTVTYNM='ACTIVITY*NAME'
Jan 12, 1999 BAACDCCT='ACTIVITY*DATA*CONTAINER*REQUESTS'
BAACQPCT='ACQUIRE*PROCESS*REQUESTS'
BADACTCT='DEFINE*ACTIVITY*REQUESTS'
BADCPACT='DELETE*ACTIVITY*AND CANCEL*REQUESTS'
BADFIECT='DEFINE*INPUT*EVENT*REQUESTS'
BADFTECT='DEFINE*TIMER*EVENT*REQUESTS'
BADPROCT='DEFINE*PROCESS*REQUESTS'
BALKPACT='LINK*PROCESS*ACTIVITY*REQUESTS'
BAPRDCCT='PROCESS*DATA*CONTAINER*REQUESTS'
BARACTCT='RESET*ACTIVITY*REQUESTS'
BARASYCT='RUN*PROCESS*ACTIVITY*ASYNC'
BARATECT='RETRIEVE*REATTACH*EVENT*REQUESTS'
BARMPACT='RESUME*PROCESS*ACTIVITY*REQUESTS'
BARSYNCT='RUN*PROCESS*ACTIVITY*SYNC'
BASUPACT='SUSPEND*PROCESS*ACTIVITY*REQUESTS'
BATOTCCT='TOTAL*DATA*CONTAINER*REQUESTS'
BATOTECT='TOTAL*EVENT*REQUESTS'
BATOTPCT='TOTAL*PROCESS*ACTIVITY*REQUESTS'
CFCAPICT='OO CLASS*LIBRARY*API*REQUESTS'
CFDTWACN='CF DATA*TABLE*WAIT*COUNT'
CFDTWATM='CF DATA*TABLE*WAIT*TIME'
CHMODECT='CICS*DISPATCHER*MODE*CHANGES'
CLIPADDR='CLIENT*IP*ADDRESS'
DB2CONCN='DB2*CONNECTION*WAIT*WAIT*COUNT'
DB2CONTM='DB2*CONNECTION*WAIT*WAIT*TIME'
DB2RDYCN='DB2*READY*QUEUE*WAIT*COUNT'
DB2RDYTM='DB2*READY*QUEUE*WAIT*TIME'
DB2REQCT='DB2*REQUEST*COUNT'
DB2WAICN='DB2*WAIT*WAIT*COUNT'
DB2WAITM='DB2*WAIT*WAIT*TIME'
DHCRECT ='DOCUMENT*CREATE*REQUESTS'
DHINSCT ='DOCUMENT*INSERT*REQUESTS'
DHRETCT ='DOCUMENT*RETRIEVE*REQUESTS'
DHSETCT ='DOCUMENT*SET*REQUESTS'
DHTOTCT ='TOTAL*DOCUMENT*REQUESTS'
DHTOTDCL='TOTAL*DOCUMENT*CREATED*LENGTH'
GNQDELCN='GLOBAL*ENQUE*DELAY*COUNT'
GNQDELTM='GLOBAL*ENQUE*DELAY*TIME'
IMSREQCT='IMS*REQUEST*COUNT'
IMSWAICN='IMS*WAIT*COUNT'
IMSWAITM='IMS*WAIT*TIME'
J8CPUTCN='USER TASK*J8 MODE*CPU TCB*COUNT'
J8CPUTTM='USER TASK*J8 MODE*CPU TCB*TIME'
JVMSUSCN='JAVA*VM*SUSPEND*COUNT'
JVMSUSTM='JAVA*VM*SUSPEND*TIME'
JVMTIMCN='JAVA*VM*EXECUTION*COUNT'
JVMTIMTM='JAVA*VM*EXECUTION*TIME'
L8CPUTCN='USER TASK*L8 MODE*CPU TCB*COUNT'
L8CPUTTM='USER TASK*L8 MODE*CPU TCB*TIME'
MAXOTDCN='MAX*OPEN*TCB*DELAY*COUNT'
MAXOTDTM='MAX*OPEN*TCB*DELAY*TIME'
MSCPUTCN='USER TASK*OTHER MODE*CPU TCB*COUNT'
MSCPUTTM='USER TASK*OTHER MODE*CPU TCB*TIME'
MSDISPCN='USER TASK*OTHER MODE*DISPATCH*COUNT'
MSDISPTM='USER TASK*OTHER MODE*DISPATCH*TIME'
PCDPLCT ='DPL*PROGRAM*LINKS'
PRCSID ='PROCESS*ID'
PRCSNAME='PROCESS*NAME'
PRCSTYPE='PROCESS*TYPE'
QRCPUTCN='USER TASK*QR MODE*CPU TCB*COUNT'
QRCPUTTM='USER TASK*QR MODE*CPU TCB*TIME'
QRDISPCN='USER TASK*QR MODE*DISPATCH*COUNT'
QRDISPTM='USER TASK*QR MODE*DISPATCH*TIME'
QRMODDCN='QR*MODE*DELAY*COUNT'
QRMODDTM='QR*MODE*DELAY*TIME'
RRMSURID='RRMS/MVS*UNIT OF RECOVERY*ID'
RRMSWACN='RRMS/MVS*WAIT*COUNT'
RRMSWATM='RRMS/MVS*WAIT*TIME'
RUNTRWCN='RUN*TRANSACTION*WAIT*COUNT'
RUNTRWTM='RUN*TRANSACTION*WAIT*TIME'
S8CPUTCN='USER TASK*S8 MODE*CPU TCB*COUNT'
S8CPUTTM='USER TASK*S8 MODE*CPU TCB*TIME'
SOBYDECT='BYTES*DECRYPTED'
SOBYENCT='BYTES*ENCRYPTED'
SOIOWTCN='SOCKET*IO*WAIT*COUNT'
SOIOWTTM='SOCKET*IO*WAIT*TIME'
SRVSYWCN='SERVER*SYNCPOINT*WAIT*COUNT'
SRVSYWTM='SERVER*SYNCPOINT*WAIT*TIME'
SYNCDLCN='SYNCPOINT*DELAY*COUNT'
SYNCDLTM='SYNCPOINT*DELAY*TIME'
TCBATTCT='CICS*DISPATCHER*TCB*ATTACHES'
WBCHRIN ='WEB*CHARACTERS*RECEIVED'
WBCHROUT='WEB*CHARACTERS*SENT'
WBRCVCT ='WEB*RECEIVE*REQUESTS'
WBREPRCT='REPOSITORY*READS'
WBREPWCT='REPOSITORY*WRITES'
WBSENDCT='WEB*SEND*REQUESTS'
WBTOTCT ='TOTAL*WEB*REQUESTS'
The type 110 subtype 1 (CICSEXCE dataset) adds variables:
EXCMNBTR='BRIDGE*TRANSACTION*ID'
EXCMNCPN='CURRENT*PROGRAM*NAME'
EXCMNFCN='TRANSACTION*FACILITY*NAME'
EXCMNNPX='NETWORK*UNIT-OF-WORK*PREFIX'
EXCMNNSX='NETWORK*UNIT-OF-WORK*PREFIX'
EXCMNRIL='EXCEPTION*RESOURCE*ID*LENGTH'
EXCMNRIX='EXCEPTION*RESOURCE*ID'
EXCMNTRF='TRANSACTION*FLAGS'
EXCMNURI='RRMS/MVS*UNIT OF RECOVERY*ID'
-Statistics STID=55 now creates CICDS Dispatcher Stats
dataset (replacing STID=56 or STID=57). There are now
eleven TCBs separately reported in CICDS dataset:
TCB Var Prefix Abbreviation Description
1 DSG QR Quasi Reentrant
2 DS2 RO Resource Owning
3 DS3 CO Concurrent
4 DS4 SZ Secondary LU
5 DS5 RP ONC/RPC
6 DS6 FO File Owning
7 DS7 SL Sockets Owning SL
8 DS8 SO Sockets Owning SO
9 DS9 J8 J8 Open
10 DSA L8 L8 Open
11 DSB S8 S8 Open
The CICDS labels now conain the TCB abbreviation.
-Statistics STID=67 (CICFCR dataset) has new variables:
A17DTCFP='CF*DATA*TABLE*POOL NAME'
A17DTCON='CHANGED*RESPONSES*FOR CFDT'
A17DTLDS='LOADING*RESPONSES'
-Statistics STID=42 (CICTQR dataset) has new variable:
TQRPDSMN='PDS*MEMBER*NAME'
-Statistics STID=52 (CICCONSR dataset) has new field:
A14ESTPC='PROGRAM*CONTROL*FUNCTION*SHIP*REQUESTS'
-Statistics STID=97 now creates CICNQG ENQ Manager data;
it was previously in STID=96, but not only was the STID
changed, there are four new variables:
NQGGNQSW='TOTAL*SYSPLEX*ENQUES*WAITED'
NQGGNQWT='TOTAL*SYSPLEX*ENQ*WAITING TIME'
NQGSNQSW='CURRENT*SYSPLEX*ENQUEUE*WAITING'
NQGSNQWT='CURRENT*SYSPLEX*ENQ*WAITING TIME'
-New Statistics segments and new Subtypes create seven new
datasets, but I have no test data to validate the code,
so no deaccumulation (if needed) has been written. The
contents of these new datasets are impressive:
MXG DATASET STID DSECT Subtype Description
CICTCPIP 108 SOR 2 TCP/IP Statistics
CICNCS4D 124 NCS4D 5 NC Server List Structure
CICNCS5D 125 NCS5D 5 NC Server Storage Stats
CICCFS6D 126 CFS6D 4 CFTD Server List
CICCFS7D 127 CFS7D 4 CFTD Buffer Statistics
CICCFS8D 128 CFS8D 4 CFTD Request Statistics
CICCFS9D 129 CFS9D 4 CFTD Storage Statistics
Contents of CICTCPIP - TCP/IP Statistics
SORBACKL='TCP/IP*SERVICE*BACKLOG'
SORBYTRC='BYTES*RECEIVED*(ALL SOCKETS)'
SORBYTSN='BYTES*SENT*(ALL SOCKETS)'
SORCLOSG='GMT SERVICE*CLOSE TIME*(GMT)'
SORCLOSL='LOCAL SERVICE*CLOSE TIME*(LOCAL)'
SORCUCON='CURRENT*NUMBER OF*CONNECTIONS'
SORIPADR='TCP/IP*SERVICE*IP ADDRESS'
SOROPENG='GMT SERVICE*OPEN TIME*(GMT)'
SOROPENL='LOCAL SERVICE*OPEN TIME*(LOCAL)'
SORPKCON='PEAK*NUMBER OF*CONNECTIONS'
SORPORTN='TCP/IP*SERVICE*PORT*NUMBER'
SORRECVS='RECEIVES*(ALL SOCKETS)'
SORSENDS='SENDS*(ALL SOCKETS)'
SORSERVN='TCP/IP*SERVICE*NAME'
SORSSLFL='TCP/IP*SERVICE*SSL*SUPPORT'
SORTRANA='TRANSACTIONS*ATTACHED'
Contents of CICNCS4D - NC Server List Structure
S4ASYCT ='NUMBER OF*ASYNCHRONOUS*REQUESTS'
S4CNPREF='PREFIX FOR*CONNECTION*NAME'
S4CNSYSN='OWN MVS*SYSTEM NAME*FROM*CVTSNAME'
S4CRECT ='CREATE*COUNTER'
S4DELCT ='DELETE*COUNTER'
S4ENTRCT='CURRENT*NUMBER*OF ENTRIES*IN USE'
S4ENTRHI='HIGHEST*NUMBER*OF ENTRIES*IN USE'
S4ENTRLO='LOWEST*NUMBER*OF FREE*ENTRIES'
S4ENTRMX='MAX ENTRIES*RETURNED*BY IXLCONN'
S4GETCT ='GET AND*INCREMENT*COUNTER'
S4KEQCT ='INQUIRE*KEQ'
S4KGECT ='INQUIRE*KGE'
S4POOL ='POOL NAME*PART OF*STRUCTURE NAME'
S4PREF ='FIRST*PART OF*STRUCTURE*NAME'
S4RSP1CT='NORMAL RESPONSE EVERYTHING OK'
S4RSP2CT='NO MATCHING*ENTRY*WAS FOUND'
S4RSP3CT='ENTRY*VERSION*DID NOT*MATCH'
S4RSP4CT='LIST*AUTHORITY*COMPARISON*MISMATCH'
S4RSP5CT='THE LIST*STRUCTURE*IS OUT*OF SPACE'
S4RSP6CT='IXLLIST*RETURN*CODE*OCCURRED*OTHER'
S4SETCT ='SET*COUNTER'
S4SIZE ='STRUCTURE*SIZE*(UNSIGNED*FULLWORD)'
S4SIZEMX='MAXIMUM*STRUCTURE*SIZE'
Contents of CICNCS5D - NC Server Storage Statistics
S5ANYFR ='NUMBER OF*FREE PAGES*IN THE POOL'
S5ANYLO ='LOWEST*FREE*PAGES*(SINCE RESET)'
S5ANYMX ='TOTAL PAGES*IN THE*STORAGE*POOL'
S5ANYNAM='POOL NAME*AXMPGANY'
S5ANYPTR='ADDRESS OF*STORAGE*POOL*AREA'
S5ANYRQC='COMPRESS*(DEFRAGMENTATION)*ATTEMPTS'
S5ANYRQF='GETS*WHICH FAILED*TO OBTAIN*STORAGE'
S5ANYRQG='STORAGE*GET*REQUESTS'
S5ANYRQS='STORAGE*FREE*REQUESTS'
S5ANYSIZ='SIZE OF*STORAGE*POOL*AREA'
S5ANYUS ='NUMBER OF*USED PAGES*IN THE POOL'
S5LOWFR ='NUMBER OF*FREE PAGES*IN THE POOL'
S5LOWLO ='LOWEST*FREE*PAGES*(SINCE RESET)'
S5LOWMX ='TOTAL PAGES*IN THE*STORAGE*POOL'
S5LOWNAM='POOL NAME*AXMPGLOW'
S5LOWPTR='ADDRESS OF*STORAGE*POOL*AREA'
S5LOWRQC='COMPRESS*(DEFRAGMENTATION)*ATTEMPTS'
S5LOWRQF='GETS*WHICH FAILED*TO OBTAIN*STORAGE'
S5LOWRQG='STORAGE*GET*REQUESTS'
S5LOWRQS='STORAGE*FREE*REQUESTS'
S5LOWSIZ='SIZE OF*STORAGE*POOL*AREA'
S5LOWUS ='NUMBER OF*USED PAGES*IN THE POOL'
Contents of CICCSF6D - CFTD Server List
S6CNPREF='PREFIX*FOR*CONNECTION*NAME'
S6CNSYSN='OWN MVS*SYSTEM NAME*FROM CVTSNAME'
S6ELEMCT='CURRENT*NUMBER OF*ELEMENTS*IN USE'
S6ELEMHI='HIGHEST*NUMBER OF*ELEMENTS*IN USE'
S6ELEMLN='DATA*ELEMENT*SIZE'
S6ELEMLO='LOWEST*NUMBER OF*FREE*ELEMENTS'
S6ELEMMX='MAX ELEMENTS*RETURNED*BY IXLCONN'
S6ELEMPE='MAX ELEMENTS*PER ENTRY*(FOR 32K)'
S6ELEMPW='DATA*ELEMENT*SIZE*AS POWER OF 2'
S6ELEMRT='ELEMENT SIDE*OF ENTRY*ELEMENT RATIO'
S6ENTRCT='CURRENT*NUMBER OF*ENTRIES*IN USE'
S6ENTRHI='HIGHEST*NUMBER OF*ENTRIES*IN USE'
S6ENTRLO='LOWEST*NUMBER OF*FREE*ENTRIES'
S6ENTRMX='MAX ENTRIES*RETURNED*BY IXLCONN'
S6ENTRRT='ENTRY SIDE*OF ENTRY*ELEMENT RATIO'
S6FREECT='NUMBER OF*ENTRIES*ON FREE LIST'
S6FREEHI='HIGHEST*ENTRIES*ON FREE LIST'
S6HDRS ='MAXIMUM*NUMBER OF*LIST*HEADERS'
S6HDRSCT='HEADERS*USED FOR*CONTROL*LISTS'
S6HDRSTD='HEADERS*AVAILABLE FOR*TABLE DATA'
S6INDXCT='NUMBER OF*ENTRIES*IN TABLE INDEX'
S6POOL ='POOL NAME*PART OF*STRUCTURE*NAME'
S6PREF ='FIRST PART*OF*STRUCTURE*NAME'
S6RSP8CT='AN IXLLIST*RETURN*CODE*OCCURRED*OTHER'
S6SIZE ='STRUCTURE*SIZE*'
S6SIZEMX='MAXIMUM*STRUCTURE*SIZE'
S6USEDCT='NUMBER OF*ENTRIES*ON USED LIST'
S6INDXHI='HIGHEST*ENTRIES*IN TABLE INDEX'
S6APPLCT='NUMBER OF*ENTRIES*IN APPLID LIST'
S6APPLHI='HIGHEST*ENTRIES*IN APPLID LIST'
S6UOWLCT='NUMBER OF*ENTRIES*IN UOW LIST'
S6UOWLHI='HIGHEST*ENTRIES*IN UOW LIST'
S6RDICT ='READ*TABLE*INDEX*ENTRY'
S6WRICT ='WRITE*TABLE*INDEX*ENTRY'
S6RWICT ='REWRITE*TABLE*INDEX*ENTRY'
S6DLICT ='DELETE*TABLE*INDEX*ENTRY'
S6CRLCT ='CREATE*LIST'
S6MDLCT ='MODIFY*LIST'
S6DLLCT ='DELETE*LIST'
S6RDDCT ='READ*DATA*ITEM'
S6WRDCT ='WRITE*DATA*ITEM'
S6RWDCT ='REWRITE*DATA*ITEM'
S6DLDCT ='DELETE*DATA*ITEM'
S6INLCT ='INQUIRE*ON*DATA LIST'
S6RDMCT ='READ*MESSAGE*QUEUE'
S6WRMCT ='WRITE TO*MESSAGE*QUEUE'
S6RDUCT ='READ*UOW*ENTRY'
S6WRUCT ='WRITE*UOW*ENTRY'
S6RWUCT ='REWRITE*UOW*ENTRY'
S6DLUCT ='DELETE*UOW*ENTRY'
S6RDACT ='READ*APPLID*ENTRY'
S6WRACT ='WRITE*APPLID*ENTRY'
S6RWACT ='REWRITE*APPLID*ENTRY'
S6DLACT ='DELETE*APPLID*ENTRY'
S6RRLCT ='REREAD*ENTRY FOR*FULL DATA*LENGTH'
S6ASYCT ='NUMBER OF*ASYNCHRONOUS*REQUESTS'
S6RSP1CT='NORMAL*RESPONSE*EVERYTHING*OK'
S6RSP2CT='BUFFER LEN*TOO SHORT*FULL LENGTH*REREAD'
S6RSP3CT='NO MATCHING*ENTRY*WAS FOUND'
S6RSP4CT='ENTRY VERSION*DID NOT*MATCH'
S6RSP5CT='LIST*AUTHORITY*COMPARISON*MISMATCH'
S6RSP6CT='MAXIMUM*LIST*KEY*REACHED'
S6RSP7CT='THE LIST*STRUCTURE*IS OUT OF*SPACE'
S6USEDHI='HIGHEST*ENTRIES*ON USED LIST'
Contents of CICCSF7D - CFTD Buffer Statistics
S7OCCLOS='CLOSE*TABLE'
S7OCDELE='DELETE*TABLE'
S7OCOPEN='OPEN*TABLE'
S7OCSET ='SET TABLE*ATTRIBUTES'
S7OCSTAT='EXTRACT*TABLE*STATISTICS'
S7RQHIGH='RETURN*HIGHEST*KEY'
S7RQLOAD='LOAD '
S7RQPOIN='POINT '
S7RQRDDL='READ*AND*DELETE'
S7RQREAD='READ*(INCLUDING READ*FOR UPDATE)'
S7RQREWR='REWRITE'
S7RQUNLK='UNLOCK'
S7RQWRIT='WRITE*(NEW RECORD)'
S7TABLE ='TABLE*NAME'
Contents of CICCSF8D - CFTD Request Statistics
S8IQINQU='INQUIRE*TABLE'
S8OCCLOS='CLOSE*TABLE'
S8OCDELE='DELETE*TABLE'
S8OCOPEN='OPEN*TABLE'
S8OCSET ='SET TABLE*ATTRIBUTES'
S8OCSTAT='EXTRACT*TABLE*STATISTICS'
S8RQDELE='DELETE*RECORD'
S8RQDELM='DELETE*MULTIPLE*RECORDS'
S8RQHIGH='RETURN*HIGHEST*KEY'
S8RQLOAD='LOAD*RECORD*AT INITIAL*LOAD TIME'
S8RQPOIN='POINT*TO*RECORD'
S8RQRDDL='READ*AND*DELETE*RECORD'
S8RQREAD='READ*RECORD*(INCLUDES*FOR UPDATE)'
S8RQREWR='REWRITE*EXISTING*RECORD'
S8RQUNLK='UNLOCK*RECORD'
S8RQWRIT='WRITE*NEW*RECORD'
S8SPBACK='BACK OUT*UNIT OF WORK'
S8SPCOMM='COMMIT*UNIT OF WORK'
S8SPINQU='INQUIRE*ABOUT*UNIT OF WORK'
S8SPPREP='PREPARE*TO COMMIT*UNIT OF WORK'
S8SPREST='RESTART*RECOVERABLE*CONNECTION'
S8SPRETA='RETAIN*LOCKS FOR*UNIT OF WORK'
Contents of CICCSF9D - CFTD Storage Statistics
S9ANYFR ='NUMBER OF*FREE PAGES*IN THE POOL'
S9ANYLO ='LOWEST*FREE*PAGES*(SINCE RESET)'
S9ANYMX ='TOTAL PAGES*IN THE*STORAGE*POOL'
S9ANYNAM='POOL NAME*AXMPGANY'
S9ANYPTR='ADDRESS OF*STORAGE*POOL*AREA'
S9ANYRQC='COMPRESS*(DEFRAGMENTATION)*ATTEMPTS'
S9ANYRQF='GETS WHICH*FAILED TO*OBTAIN STORAGE'
S9ANYRQG='STORAGE*GET*REQUESTS'
S9ANYRQS='STORAGE*FREE*REQUESTS'
S9ANYSIZ='SIZE OF*STORAGE*POOL*AREA'
S9ANYUS ='NUMBER OF*USED PAGES*IN THE POOL'
S9LOWFR ='NUMBER OF*FREE PAGES*IN THE POOL'
S9LOWLO ='LOWEST FREE PAGES (SINCE RESET)'
S9LOWMX ='TOTAL PAGES*IN THE*STORAGE POOL'
S9LOWNAM='POOL NAME*AXMPGLOW'
S9LOWPTR='ADDRESS OF*STORAGE*POOL*AREA'
S9LOWRQC='COMPRESS*(DEFRAGMENTATION)*ATTEMPTS'
S9LOWRQF='GETS WHICH*FAILED TO*OBTAIN STORAGE'
S9LOWRQG='STORAGE*GET*REQUESTS'
S9LOWRQS='STORAGE*FREE*REQUESTS'
S9LOWSIZ='SIZE OF*STORAGE*POOL*AREA'
S9LOWUS ='NUMBER OF*USED PAGES*IN THE POOL'
Change 16.321 If the last structure in a type 74 subtype 4 record had
VMAC74 an extension, the extension was not input, so variables
Jan 12, 1999 R774CRHC thru R744CWUC were missing TYPE74ST dataset for
that observation. My existence test for the extension:
IF R744CDSI GT 0 AND CDSILOC+200 LE LENGTH THEN DO;
INPUT @(SMF744CO+(R744CDSI-1)*SMF744CL)
should have been:
IF R744CDSI GT 0 AND CDSILOC+200 LE LENGTH-1 THEN DO;
but clearer/safer logic is to use R744CDNE to validate
the existence of the extension, so the test now is:
IF R744CDSI GT 0 AND R744CDNE GE 1 THEN DO;
INPUT @CDSILOC
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 16.320 This test member had hex strings that caused FTP to gag
ZTIMECHK when the MXG Source Library was FTP'd from MVS; as it was
Jan 10, 1999 only for my internal testing, the member was deleted.
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 16.319 Using the new TYPSAIM0 member (for FACOM operating sys)
VMACAIM0 failed, as the MACRO _SAIM0 _SAIM0 % syntax failed. As
Jan 10, 1999 it was not really needed, it was deleted. This was the
only instance in which a dataset sort macro name was the
same as the member sort macro name, and the only place
that that syntax was used in a VMAC member.
Thanks to Chuck Hopf, MBNA, USA.
Change 16.318 Support for DB2 Version 6.1 (COMPATIBLE):
EX102230 It appears that all of the changes in 6.1 were added at
EX102233 the end of segments, so MXG 15.15+ will not fail with the
EX102242 DB2 6.1 records, but none of the new information will be
EX102243 decoded by MXG until you install MXG 16.09 or later.
EX102247 -The QWHA Data Sharing Header (new in Version 5.1) is now
EX102248 decoded, creating new variables in Accounting datasets
EX102249 DB2ACCT,DB2ACCTP, DB2ACCTB and DB2ACCTG:
EX102250 QWHAMEMN='DB2*MEMBER*NAME'
EX102251 QWHADSGN='DB2*DATA SHARING*GROUP*NAME'
EX102252 -The QWHC Correlation Header was extended and contains new
EX102254 End User information added to DB2ACCT,DB2ACCTP,DB2ACCTB
EX102255 and DB2ACCTG Accounting datasets.
EX102256 QWHCEUID='END USERS*USERID*AT WORKSTATION'
EX102257 QWHCEUTX='END USERS*TRANSACTION*NAME'
EX102258 QWHCEUWN='END USERS*WORKSTATION*NAME'
EX102259 -New QWAX segment contains waits and counts, some of which
EX102260 were previously QWACxxxx fields in the DB2ACCT datasets:
EX102261 QWAXALCT='ARCHIVES*LOG MODE*(QUIESCE)'
EX102262 QWAXALOG='WAIT TIME*DUE TO PROCESSING*OF ARCH LOG'
EX102263 QWAXANAR='WAITS FOR*ARCHIVE READS'
EX102265 QWAXARNC='WAITS FOR*SUSPENSIONS*FOR CLAIMS'
EX102266 QWAXARND='WAITS FOR*A DRAIN LOCK'
EX102267 QWAXAWAR='WAIT TIME FOR ARCHIVE READS (TAPE)'
EX102268 QWAXAWCL='WAIT TIME FOR A DRAIN FOR CLAIMS'
EX102272 QWAXAWDR='WAIT TIME FOR A DRAIN LOCK'
EX102273 QWAXDSNS='WAITS FOR*DATASPACE MGR*TASKS'
EX102305 QWAXDSSE='WAIT TIME*FOR DATASPACE SERVICE'
EX102306 QWAXOCNS='WAITS FOR*OPEN/CLOSE OR*HSM RECALL'
EX102311 QWAXOCSE='WAIT TIME*FOR OPEN/CLOSE OR*HSM RECALL'
EX102312 QWAXOTNS='WAITS FOR*SWITCH TO OTHER*DB2 SERV TASKS'
EX102313 QWAXOTSE='WAIT TIME*SWITCH TO OTHER*DB2 SERV TASKS'
EX102314 QWAXSLNS='WAITS FOR*SYSLGRNG*RECORDING'
FORMATS QWAXSLSE='WAIT TIME*FOR SYSLGRNG*RECORDING'
VMACDB2 -The QWAC segment was extended with SIGNIFICANT NEW DATA!!
VMACDB2H for DB2's interaction with Workload Manager's new Enclave
Jan 9, 1999 architecture, as well as new measurements of the elapsed
Jan 12, 1999 and TCB CPU time spent in Stored Procedures and in User
Defined Functions, and with SQL time separated as well:
QWACLRAB='BYTES*LOGGED'
QWACLRN ='LOG*RECORDS*WRITTEN'
QWACPECT='TCB TIME*BEFORE*ENCLAVE*CREATION'
QWACSPEA='ET EXECUTING*STORED PROCS*INCLUDES SQL'
QWACSPEB='ET EXECUTING*STORED PROCS*SQL TIME'
QWACTREE='ET*EXECUTING*TRIGGERS*UNDER AN*ENCLAVE'
QWACTRET='ET EXECUTING*TRIGGERS*NOT UNDER ENCLAVE'
QWACTRTE='TCB TIME*EX TRIGGERS*UNDER AN*ENCLAVE'
QWACTRTT='TCB TIME*EX TRIGGERS*NOT UNDER ENCLAVE'
QWACUDCP='TCB TIME*USRDEFUN*STORED PROC*OR WLM AS'
QWACUDEA='ET USRDEFUN*TOTAL INCLUDES*SQL TIME'
QWACUDEB='ET USRDEFUN*ONLY*SQL TIME'
QWACUDNE='SQL ENTRY/EXIT*EVENTS*USER DEF FUNCTION'
QWACUDST='ET WAITNG FOR AVAIL TCB*TO SKED*USRDEFUN'
QWACUDTT='TCB TIME*USRDEFUN*SQL TIME*(IN QWACUDCP)'
QWACWLME='SERVICE*CLASS*NAME'
-The first QWDA segment is now decoded creating variable
QWDAXCQO='MEMBER NAME OF*PARALLELISM*COORDINATOR'
for child tasks. There can be multiple segments for the
coordinating task, but only the first is read now, until
test data and a need presents itself.
-For packages, the QPAC segment that created DB2ACCTP has
been enhanced with new variables:
QPACAAFG='ACTIVITY*TYPE*FLAG'
(decoded with new format $MGDB2PK with values of
01-stored proc,02-userdefun,03-trigger executing)
QPACAANM='NAME*OF*ACTIVITY'
QPACASCH='NESTED*ACTIVITY*SCHEMA*NAME'
QPACSPNS='STORED*PROCEDURES EXECUTED'
QPACUDST='ET WAITING*FOR TCB*BEFORE SKED*USRDEFUN'
QPACUDNU='USER-DEFINED*FUNCTIONS*SCHEDULED'
-The QXST segment was extended with new variables in both
the DB2ACCT and DB2STATS datasets:
QXALOCC ='ALLOCATE*CURSOR*STATEMENTS*EXECUTED'
QXALOCL ='ASSOCIATE*LOCATOR*STATEMENTS*EXECUTED'
QXALPRO ='ALTER*PROCEDURE*STATEMENTS'
QXALUDF ='ALTER*FUNCTION*STATEMENTS'
QXCASCDP='MAX LEVEL*OF NESTED*SQL CASCADING'
(includes cascading due to triggers, udfs,
and stored procedures).
QXCAUD ='USER*DEFINED*FUNCTIONS*EXECUTED'
QXCAUDAB='TIMES*USERDEFUN*ABENDED'
QXCAUDRJ='TIMES USERDEFUN*WAS REJECTED'
QXCAUDTO='TIMES*UDF*TIMED OUT*WAITING TO BE SKED'
QXCDIST ='CREATE*DISTINCT*TYPE*STATEMENTS'
QXCRATB ='CREATE*AUX TABLE*STATEMENTS'
QXCRPRO ='CREATE*PROCEDURE*STATEMENTS'
QXCRUDF ='CREATE*FUNCTION*STATEMENTS'
QXCTRIG ='CREATE*TRIGGER'
QXDDIST ='DROP *DISTINCT*TYPE*STATEMENTS'
QXDRPFN ='DROP*USER*DEFINED*FUNCTION'
QXDRPPR ='DROP*STORED*PROCEDURE'
QXDRPTR ='DROP*TRIGGER'
QXFREEL ='FREE*LOCATOR*STATEMENTS'
QXHOLDL ='HOLD*LOCATOR*STATEMENTS'
QXREPOP1='PARALLEL*GROUPS*REFORMULATED*SYSPLEX'
QXREPOP2='PARALLEL*GROUPS*REFORMULATED*BUFFERS'
QXRNTAB ='RENAME*TABLE'
QXROIIDX='DIRECT ROW*REVERTED*USED*AN INDEX'
QXROIMAT='DIRECT ROW*ACCESS*WAS SUCCESSFUL'
QXROITS ='DIRECT ROW*REVERTED*USED*TABLESPACE SCAN'
QXROWTRG='ROW TRIGGER*WAS ACTIVATED'
QXSETPTH='SET*CURRENT PATH*STATEMENTS'
QXSTDEXP='EX COPY*DISCARDED*DUE TO*MAXKEEPD LIMIT'
QXSTDINV='EX COPY*PURGED*DUE TO*DEPENDENT OBJECT'
QXSTFND ='PREPARE REQUESTS*SAT BY*COPY FROM CACHE'
QXSTIPRP='IMPLICIT PREPARE*BUT DB2*HAD NO VALID'
QXSTLOBV='MAX STORAGE*BYTES USED*FOR LOB VALUES'
QXSTNFND='PREPARE REQUEST*BUT NO*MATCH IN CACHE'
QXSTNPRP='PREPARE AVOIDED*DB2 HAD*VALID KEEPDYNAM'
QXSTTRG ='STATEMENT TRIGGER*WAS ACTIVATED'
QXTRGERR='SQL ERRORS*DURING EX*OF TRIGGERED ACTION'
-The QBGL segment added new variables to DB2STATS:
QBGL2F ='CHANGED*PAGE WRITES*FAILED*STORAGE'
QBGL2D ='DELETE*NAME*LIST*REQUESTS'
QBGL2N ='DELETE*NAME*REQUESTS'
QBGL2R ='READ*CASTOUT*STATS*REQUESTS'
QBGL2S ='COMPLETION*CHECKS*SUSPENDED'
QBGL2W ='CHANGED*PAGE WRITES*FOR DUPLEXING'
DB2 Trace Records:
-IFCID 106 added these new variables to T102S106:
QWP1BDUR='RESTART*BACKOUT*LIMIT*(0-255)'
QWP1DBPR='DATABASE*PROTOCOL*FOR 3-PART*NAMES'
QWP1DTIM='TIME*BETWEEN*RESET OF*DSET STATS'
QWP1EXBR='MAX EXTRA*DRDA QUERY BLKS*REQUESTER'
QWP1EXBS='MAX EXTRA*DRDA QUERY BLKS*SERVER'
QWP1FLBZ='MAX DSN1DBM1 STORAGE*FAST LOG APPLY'
QWP1IXPL='DEFAULT*BUFFER POOL*FOR USER INDEXES'
QWP1LMBO='LIMIT*RESTART*BACKOUT*(NO,YES,AUTO)'
QWP1LVA ='KILOBYTES*FOR LOB VALUES*PER AGENT'
QWP1LVLC='QWP1LVLC*(S)'
QWP1LVS ='MEGABYTES*FOR LOB VALUES*PER SYSTEM'
QWP1SCER='EXTENDED*SECURITY'
QWP1TBPL='DEFAULT*BUFFER POOL*FOR USER DATA'
QWP1URCK='UR*CHECKPOINT*THRESHOLD'
QWP1WLME='DEFAULT*WLM*ENVIRONMENT'
QWP4AURT='QWP4AURT*(S)'
QWP4FLBS='QWP4FLBS*(S)'
QWP4FLMT='QWP4FLMT*(S)'
QWP4MXKD='MAXIMUM*KEPT*DYNAMIC*STATEMENTS'
QWP4PAC ='PACKAGE*AUTHORIZATION*CACHE'
QWP4RHTI='QWP4RHTI*(S)'
QWP4SREC='QWPRSREC*(S)'
QWP4UBS ='QWP4UBS*(S)'
QWP4UMD ='QWPRUMD*(S)'
QWP4WBMP='IMS/BMP*TIMEOUT*FACTOR'
QWP4WDLI='IMS/DLI*TIMEOUT*FACTOR'
QWP4XCTH='QWP4XCTH*(S)'
QWP9MAX1='MAXIMUM*TYPE 1*INACTIVE*THREADS'
QWPBAGID='ASCII GBCS CCSID'
QWPBAMID='ASCII MBCS CCSID'
QWPBAR ='DECIMAL ARITHMETIC DEFAULT'
QWPBASID='ASCII SBCS CCSID'
QWPBCHAR='CHARSET DEFAULT'
QWPBCMP ='COMPATIBILITY OPTION'
QWPBDATE='DATE FORMAT (ISO,JIS,EUR,LOCAL,USA)'
QWPBDE ='PERIOD/COMMA DEFAULT'
QWPBDL ='DELIMITER DEFAULT'
QWPBDLEN='LOCAL (ONLY) DATE LENGTH DEFAULT'
QWPBDSD ='DISTRIBUTED SQL STRING DELIMITER'
QWPBENS ='DEFAULT ENCODING SCHEME'
QWPBGID ='GBCS CCSID'
QWPBGRA ='YES/NO MIXED GRAPHIC DEFAULT'
QWPBLANG='LANGUAGE DEFAULT'
QWPBLVL ='QWPBLVL*(S)'
QWPBMID ='MBCS CCSID'
QWPBREL ='VERSION*RELEASE*MOD LEVEL'
QWPBRIB ='POINTER TO RELEASE INFO BLOCK'
QWPBSDL ='SQL DELIMITER DEFAULT'
QWPBSID ='SBCS CCSID'
QWPBSQL ='LEVEL OF SQL LANGUAGE SUPPORT'
QWPBSSID='SUBSYSTEM DEFAULT'
QWPBTIME='TIME FORMAT (ISO,JIS,EUR.LOCAL,USA)'
QWPBTLEN='LOCAL (ONLY) TIME LENGTH DEFAULT'
-IFCID 0258 was added by APAR PQ17544 for 5.1 and 6.1. It
is decoded (even though I have no test data) as it may be
very useful: dataset T102S258 tracks when any of your DB2
databases are expanded in size. You can use it to track
database growth and avoid the catastrophy of exceeding
the maximum size of a DB2 table! These variables are
in the new T102S258 (DB2 DATASET EXTEND SPACE) dataset:
QW0258DB='DATABASE*ID*(DBID)'
QW0258DN='DATABASE*NAME'
QW0258DS='DATASET*NAME'
QW0258HA='HIGH*ALLOCATED*AFTER*EXTEND,BYTES'
QW0258HB='HIGH*ALLOCATED*BEFORE*EXTEND*BYTES'
QW0258MS='MAXIMUM*DATA*SET*SIZE,BYTES'
QW0258PQ='PRIMARY*QUANTITY*BYTES'
QW0258PS='PAGESET*ID*(OBID)'
QW0258SQ='CURRENT*SECONDARY*QUANTITY,BYTES'
QW0258TN='TABLE/INDEX*SPACE*NAME'
QW0258TS='TIMESTAMP*AFTER*EXTEND*COMPLETED'
QW0258VA='NUMBER OF*VOLUMES*AFTER'
QW0258VB='NUMBER OF*VOLUMES*BEFORE'
QW0258VM='MAXIMUM*VOLUMES'
QW0258XA='NUMBER OF*EXTENTS*AFTER'
QW0258XB='NUMBER OF*EXTENTS*BEFORE'
QW0258XM='MAXIMUM*EXTENTS'
The storage measures labeled "bytes" are formatted with
MGBYTES so they will print as MB, GB, etc.
The QW0258TS timestamp is a blind guess as to format, so
it may be wrong until I get test data for validation.
-Trace IFCIDs thru 314 now exist, although many IFCIDs are
skipped. MXG defines a set of macro names for all 314 of
the possible IFCIDs, thru dataset T102S314, so that IFCID
ranges can be selected in READDB2 and ANALDB2R logic, but
there are only 32 new IFCIDs (some of which were added by
DB2 5.1) that can have any observations. I have created
the DB2 header variables in the new datasets for these
new subtypes of type 102 records, but I need test SMF
data records before I can decode their innards.
Dataset Description
T102S230 DATA SHARING GLOBAL STATS'
T102S233 START/END CALL TO STORED PROC'
T102S242 BEGIN WAIT FOR SKED STORED PROC'
T102S243 END WAIT FOR SKED STORED PROC'
T102S247 INPUT HOST VARIABLE'
T102S248 INPUT HOST VARIABLE'
T102S249 INPUT HOST VARIABLE'
T102S250 CONNECT/DISCONNECT GROUP BUFPOOL'
T102S251 INTEREST CHANGES DATA SHARING'
T102S252 BEGIN XES REQUEST'
T102S254 CACHE STRUCTS FOR GROUP BUFPOOL'
T102S255 BUFFER REFRESH CROSS-INVALIDATED'
T102S256 ALTER GROUPBUFFERPOOL COMMAND'
T102S257 INTER-DB2 NOTIFY MESSAGE SENDING'
T102S258 DB2 DATASET EXTEND SPACE'
T102S259 P-LOCK STATE CONSTANTS'
T102S260 END MVS XES REQUEST'
T102S261 GROUP BUFFER POOL'
T102S262 GBPOOLT CASTOUT THRESHOLD'
T102S263 PAGESET AND PARTITION CASTOUT'
T102S265 SCA ACCESS REQUEST BEGIN'
T102S266 SCA ACCESS REQUEST END'
T102S267 START CF STRUCT REBUILD/EXPAND'
T102S268 END CF STRUCTURE REBUILD/EXPAND'
T102S272 ASSOCIATE LOCATORS STMT EXEC'
T102S273 ALLOCATE CURSOR STATEMENT EXEC'
T102S305 TABLE CHECK CONSTRAINT'
T102S306 LOG RECORDS'
T102S311 GLOBAL TEMPORARY TABLE USAGE'
T102S312 DCE SECURITY AUDIT TRAIL'
T102S313 CHECKPOINT LONG RUNNING UR-S'
T102S314 ACCESS CONTROL AUTH EXIT PARMS'
Change 16.317 Protection for NTSMF 2.2.1, which does not write a 0.0
VMACNTSM record for each interval. Change the test
Dec 28, 1998 IF VERSION LT : '2.1' THEN to IF VERSION LT : '2.1' or
VERSION EQ '2.2:1' THEN ....
If you have specified COMPRESS, then the expected header
version value of 2.2.2 is created and MXG has no error.
Thanks to Wayne Holtz, Reynolds Metal, USA.
Change 16.316 First MXG 16.08 only. CICINTRV failed in building CICDS
VMXGCICI because the member VMXGCICI from CICS TS 1.3 testing was
Dec 23, 1998 inadvertently shipped. The VMXGCICI from MXG 16.07 has
been put back in this MXG 16.08.
Change 16.315 Year 2000 dates cause this summarization example to fail.
ASUMHSM The DATEJUL() function does not support the Century Byte
Dec 23, 1998 (which is an MVS-only Packed-Decimal-implementation) and
this example used DATEJUL() in an INCODE= on a DSRDATE
value of 0100001 (01Jan2000 in 0cyyddd format). The MXG
use of DATEJUL() was replaced by the YEAR2000 member's
algorithm to protect this example. See Change 16.330.
Thanks to John McCray, Huntington Services Company, USA.
======Changes thru 16.315 were in MXG 16.08 dated Dec 23, 1998======
Change 16.314 New function enhancement to VMXGSUM. Named XMXGSUM for
XMXGSUM testing; it is not yet the default. Copy it into your
Dec 21, 1998 USERID.SOURCLIB, rename to VMXGSUM, and check it out.
Feb 16, 1999 This rewrite exploits some new features added by SAS in
Version 7 (if it finds it is running under V7), and adds
new parameters for additional descriptive statistics
under either Version 6 or Version 7 of SAS.
New Parameters and defaults:
(Percentile values only in version 7+.)
P1=, List of variables to calculate Pctile 1
P5=, List of variables to calculate Pctile 5
P10=, List of variables to calculate Pctile 10
P25=, List of variables to calculate Pctile 25
P50=, List of variables to calculate Pctile 50
P75=, List of variables to calculate Pctile 75
P90=, List of variables to calculate Pctile 90
P95=, List of variables to calculate Pctile 95
P99=, List of variables to calculate Pctile 99
STD=, List of variables for Standard Deviation
STDERR=, List of variables for Standard Error
CV=, List of variables for coeff of variation
T=, List of variables for T value
VAR=, List of variables for variance
KURTOSUS= List of variables for kurtosis
AUTONAME=NO, Use the AUTONAME feature
In prior releases of VMXGSUM, you always had to ensure
that any variable you specified in one of the operands
actually existed or the output variable would not be in
the output dataset. Thus, if you wanted the MAX and the
SUM of the variable CPUTM, you would have to specify:
%VMXGSUM(...
SUM=CPUTM,
MAX=MAXCPU,
INCODE=MAXCPU=CPUTM;,...
The INCODE created the variable MAXCPU as being the same
as CPUTM and the MAX=MAXCPU calculated the maximum value
found. With version 7, there is a new option in PROC
MEANS called 'AUTONAME.' By using this feature, you can
create 'long' variable names and avoid the need to create
the variables via INCODE processing that you want. The
variable name is constructed by adding an underscore
followed by the statistic name such as MEAN or MAX or
SUM. Using the example above, the specification would
be:
%VMXGSUM(...
SUM=CPUTM,
MAX=CPUTM,
AUTONAME=YES,...
In the output dataset you would then have the variables
CPUTM_SUM and CPUTM_MAX. The format, length, and labels
are all inherited from the initial variable so all of
these have exactly the same labels and formats.
It is NOT my intention to use this feature; I do NOT
intend to create MXG variables with long names (at least
not in the near future!). MXG-provided invocations of
VMXGSUM will NOT exploit this capability; they continue
to use the current design of creating 8-character names
in the INCODE= operand.
But adding this feature to VMXGSUM may be useful in your
own invocations of VMXGSUM.
-Both Versions.
Number of obs were counted with SUM(MISS,NMISS) but now
_FREQ_ variable is used because it's better and avoids an
exposure in V7:
If INHERIT is used, the format of output variables
MISS/NMISS will have a DATETIME format if the first
variable in the VARIABLE statement happens to be a
DATETIME variable. Quite confusing, but not wrong!
Feb 16, 1999: Enhanced code after 16.08 version.
Change 16.313 IMS 6.1 support did not correctly decode type 08 records
VMACIMS for IMS usage via APPC, CPIC driven, due to a modified
VMACIMSA record layout. The quick circumvention is to replace the
Dec 19, 1998 line ELSE IF LINTSUB='.1......'B THEN DO;
with ELSE DO;
to ensure TRANSACT is always input. CPIC records caused
"INVALID DATA FOR YYYYDDD in line xx 65-68" messages.
Thanks to Johannes M. Laveuve, dvg Hannover, GERMANY.
Change 16.312 Support for DOS/VS Power V6.3.0 COMPATIBLY added fields
TYPEDOS LSTEPGN and LSTPGN for RECID='L' (dataset DOSLIST) and
Dec 19, 1998 INCOMPATIBLY inserted DESTUID in the RECID='M' and 'V'
(dataset DOSXRC) shifting LOCLNODE/ADJCNODE/NACACCT/
NACINCR/NACDLR. This change assumes you have V6.3.0;
if you have an earlier version, you will need to find
the line with comment "DELETE IF PRE 6.3.0" and delete!
Thanks to Trevor Ede, EDS (NZ) Ltd, NEW ZEALAND.
Change 16.311 A type in a LABEL for variable ASIESF had CSTORE, but the
VMACRMFV variable contains Average ESTORE for Swapped In users.
Dec 19, 1998 The label for ASIESF is now ESTORE, and variables ASIFMCT
and ASIFMCTI contain 'CSTORE' to be consistent and clear.
Thanks to Tim VanderHoek, Fidelity Investments, USA
Thanks to Juergen Holtz, IBM RMF Development, GERMANY
Change 16.310 Support for VM/ESA 2.3 (COMPATIBLE) changes to MTRSYS and
VMACVMXA USEACT segments adds four new variables to VXMTRSYS data
Dec 19, 1998 set and two new variables to VXUSEACT dataset.
Thanks to Steve Clark, California Federal Bank, USA.
Change 16.309 New variable MKDELDAO contains the original julian value
VMACEDGS for the MKDELDAT value (which becomes the data part of
Dec 19, 1998 datetime variable MKLCTIME). For special values that MXG
changed to 2099 in MKLCTIME, you will have the exact,
original value as a numeric in MKDELDAO.
Thanks to Sam Bass, McLane Co., USA.
Change 16.308 -Revision to RMM EDGR support creates numeric SAS date and
VMACEDGR SAT time variables for CREATE/LAST CHANGED dates/times so
Dec 19, 1998 normal SAS data manipulation can be done. Previously the
fields were carried as character variables. This change
is INCOMPATIBLE if you join old and new EDGR datasets
together, but this finalizes the support as it should be.
-Variables RVRETDAT, RVRELIXD and RVRELSI are now input.
Thanks to Don Friesen, ISM-BC, CANADA.
Thanks to Bob Lembo, American Stores, USA.
Change 16.307 -DB2 GTF-format records only. Using TYPEDB2G or PDB=GTF
VMACDB2 to read GTF records created zero observations in DB2ACCT
UDB2GTF and DB2ACCTB because SUBTYPE was missing for the ID=101
Dec 19, 1998 record. The GTF record doesn't have ID/SUBTYPE and MXG
has to create, but this GTF section was not updated when
the ID=101 record was split into subtypes. Most use of
GTF-format for DB2 is trace records, so this had little
impact for most sites.
-It turns out that not all segments for a single record
occur together in the GTF file. For example, the final
segment for record 160 came after the first segment of
record 161. This requires that the GTF file be SORTed
before it is input to UDB2GTF to reconstruct full length
records that MXG can read. The SORT FIELDS=(37,4,BI,A)
will do the trick. Comments added to UDB2GTF.
Thanks to Ted Blank, IBM, USA.
Change 16.306 -SAS Version 7 only. The new INHERIT parameter causes the
VMXGSUM attributes (LABEL, LENGTH, FORMAT, etc.) of same-named
Dec 19, 1998 variables to be propagated from input to output when PROC
MEANS/SUMMARY is used. Designed for MXG, INHERIT is now
invoked when VMXGSUM is run under V7; with it, VMXGSUM
can frequently bypass the last step.
Change 16.305 The APAF variables kept depended on the __NRLPS macro,
VMACAPAF but even if it was set to 10, only 8 engine's data was
Dec 18, 1998 kept. The logic was revised and the &__NRLPS macro was
eliminated; sixteen CPU variables will always exist now,
with online CPUs populating their set of variables.
Thanks to Steve Donahue, Blue Cross and Blue Shield of Texas, USA.
Change 16.304 MXG 16.04-16.07 only. Observations for RACFEVNT=19
VMAC80A (PERMIT COMMAND) were output into dataset TYPE8018
Dec 18, 1998 instead of dataset TYPE8019 due to a typo. The line
_ETY8018 after ELSE IF RACFEVNT=19 should be _ETY8019.
Thanks to Michael A. Yaffee, Duke Power, USA.
Change 16.303 Archaic members TYPEMONI and TYPETMON still had _L macro
TYPEMONI names instead of _W macro names, but since TYPEMONI is
TYPETMON for now-defunct version 7 and was replaced by TYPEMON8,
Dec 17, 1998 and since TYPETMON was replaced by TYPETMO2 for V2, this
slipped thru testing.
Thanks to Chris Weston, SAS Institute Cary, USA.
Change 16.302 The MACRO _LCIMSPGM CIMSPGM % statement should be
VMACCIMS MACRO _LCIMSPGM CIMSPROG %
Dec 17, 1998 The value was misspelled starting in 16.04.
Thanks to Chris Weston, SAS Institute Cary, USA.
Change 16.301 An extended example of AS/400 processing using FTP to
ADOCQAPM send and manage the multiplicity of OS/400 files that
JCLQAPMX must be moved to the SAS execution platform for TYPEQAPM.
Dec 16, 1998
Thanks to Clark Jennings, Reynolds Metals Company, USA.
Change 16.300 Unused Change Number.
======Changes thru 16.299 were in MXG 16.07 dated Dec 5, 1998======
Change 16.299 Variable MKDELDAT contained '14MAY2051'D for YY=99 and
VMACEDGS DDD GE 365; the statement YYYYDDD='20DEC2099'D; should be
Dec 5, 1998 YYYYDDD=2099365;, which is the julian date, because later
code converts the julian date to a SAS date.
Thanks to Sam Bass, McLane Co., USA.
Change 16.298 Variable DSGTAMXT was removed from PDB.CICINTRV because
VMXGCICI it only existed in CICS 3.3; variables STAMATHD,STAMITHD,
Dec 5, 1998 and STAHIWAT were put back in PDB.CICINTRV; they had been
inadvertently dropped.
Thanks to Chris Weston, SAS Institute ITSV, USA.
Change 16.297 MXG 16.07 Dec 4 only; end-comment */ was missing after
VMAC28 variable VRTSTATE, causing UNINITIALIZED variable and
Dec 4, 1998 incorrect data in NPMLANOD dataset.
Thanks to Freddie Arie, Lone Star Gas, USA.
======Changes thru 16.296 were in MXG 16.07 dated Dec 4, 1998======
Change 16.295 Enhancement to MXG RMF reporting replicates IBM XCF
ANALRMFR report. Specify REPORT=XCF,RPTOPT=USAGE MEMBER PATH.
Dec 4, 1998
Thanks to Jiann-Shiun Huang, CIGNA, USA.
Change 16.294 Cosmetic cleanup of variable labels.
VMAC28 -VMAC110. CICRELSE='CICS*RELEASE*IN JOURNAL*SEGMENT'
VMAC110 -VMACIKLA S23TTIME='SESSION*TERMINATE*TIME'
VMACILKA -VMACMEMO ACTMTEDA='ACCMTEDA='ACC NUMBER OF*PICKED UP*EDA'
VMACMEMO ACTMTETR='ACCMTEDA='ACC NUMBER OF*PICKED UP*ETR'
Dec 3, 1998 Variable SENDNCO now kept in MEMODIST.
(If you have the MEMO product, please send me
the current documentation, as there are other
variables that I do not have good labels for).
-VMAC28 VRTNRCPN='NEW*REMOTE*CP*NAME'
VRTNRNID='NEW*REMOTE*NETWORK*ID'
VRTRTCID='REMOTE*TCID'
Thanks to Chris Weston, SAS Institute ITSV, Cary.
Change 16.293 BETA93 Version 3.1.3 INCOMPATIBLY inserted fields in all
VMACBETA subtypes, causing INPUT EXCEEDED RECORD LENGTH errors,
Dec 3, 1998 and many fields previously in the valid SMFSTAMP8 format
Dec 17, 1998 (BETALT,BETASTSE,BETAENSE,BETASTRT,BETAEND) are now in a
never-before-seen-in-SMF time format of packed hhmmss00!
If you use SMFSTAMP8 to input these non-standard times,
there is no SAS error, but incorrect datetime values
are created. Their data value for 10:12:23 on 23NOV98
is '101223000098325F'x, but when INPUT with SMFSTAMP8
the result is a wrong value of 22Dec1998:04:57:20.64
because SMFSTAMP inputs the 10:12:23:00 time value as
PIB4. and gets 2696240.64 seconds (31.2 days) which is
then added to midnight on julian date 98325, 23Nov98!
READTIME fields should be unchanged, since BETA93 copies
rather than creates them. The below table lists the data
that has been verified that it was changed to new format,
and are supported in this version of MXG. The NODATAYET
subtypes will be printed on your SAS log if found in your
data; please email me that log so I can enhance MXG to
support and validate those NODATAYET subtypes.
Subtype datetime fields MXG dataset/status
0 BETALT BETA0 VERIFIED
1 BETABT, BETALT BETA1 NODATAYET
3 BETART BETA3 NODATAYET
5 BETALT BETA5 NODATAYET
6 BETAWST BETA6 NODATAYET
20 BETALT, BETASTRT, BETAEND BETA20 VERIFIED
21 BETALT, BETASTRT, BETAEND BETA21 VERIFIED
40 BETALT BETA40 NODATAYET
41 BETALT BETA41 NODATAYET
42 BETALT BETA42 NODATAYET
Thanks to Jurgen Niegsch, AUGI AG, GERMANY.
======Changes thru 16.292 were in MXG 16.06 dated Dec 2, 1998======
Change 16.292 Support for APAF Versions 4.1 and 4.3 (INCOMPATIBLE):
EXAPAFPO -Version 4.1 adds new variables to APAFSYSD dataset:
VMACAPAF CPUDEDF ='BIT MAP*OF DEDICATED*FENCED*CPUS'
Dec 2, 1998 CPUDEDG ='BIT MAP*OF DEDICATED*G-POOL*CPUS'
Dec 18, 1998 CPUDEDMP='BIT MAP*OF DEDICATED*CPUS'
CPUFENCE='BIT MAP*OF FENCED*C-POOL*CPUS'
CPUINSTL='BIT MAP*OF INSTALLED*CPUS'
CPUSHRMP='BIT MAP*OF SHARED*CPUS'
IOCD1DAT='IOCDS-1*DATE'
IOCD1NAM='IOCDS-1*NAME'
IOCD1NUM='NUMBER OF*THE ACTIVE*IOCDS-1'
IOCD1TIM='IOCDS-1*TIME'
TOTWEIGF='TOTAL*OPER SPECIFIED*WEIGHTS'
There are two elapsed fields, one in the System section
and one in the LPAR CPU Utilization section, and they
are not exactly the same:
LPAR Duration System Duration LPAR minus System
13:24.79 13:24.71 +.08
15:02.08 15:01.96 +.12
14:59.59 14:59.08 +.51
15:00.48 15:00.79 -.31
14:59.43 14:59.79 -.38
While awaiting an explanation from Amdahl, I keep the
value from the System section as variable DURATM. Amdahl
INCOMPATIBLY inserted TIMESLIC in LPAR CPU Util section,
but it already existed in the System Data Section; if it
is possible to have different timeslice values per LPAR,
then I will change MXG, but for now I keep the TIMESLIC
from offset 82 in the System Data Section.
-Version 4.1 adds new variables to APAFLPAR dataset:
ACTLCPS ='NUMBER OF*ACTIVE*LCPS'
CIDVALUE='CID*VALUE*ZERO*OR ONE'
DEDLCPS ='NUMBER OF*DEDICATED*LCPS'
OPRLCPS ='NUMBER OF*OPERATING*LCPS'
PCPMAP ='BIT MAP*CPUS*EXECUTED ON'
SHRLCPS ='NUMBER OF*SHARED*LCPS'
-Version 4.1 adds new variable to APAFCHN dataset:
CHPSCA ='SYSTEM*CHANNEL*ADDRESS*HEX'
-Version 4.1 creates new APAFLPAC dataset from the
subtype 32x LPAR CPU Utilization Data Subsection.
-Version 4.3 adds a new Pool Data Section, but the test
data was received in time for first release, but the new
APAFPOOL dataset was added Dec 18, from subtype 49 data.
Thanks to Robert Gilbert, National Power, ENGLAND.
Change 16.291 MXG 16.06 dated Nov 30 only. Member RMFINTRV had three
RMFINTRV typos (corrected in testing, but member not updated):
Dec 2, 1998 Line 226, remove SYSPLEX. Lies 361 and 362, add SYSPLEX
to both KEEP= lists.
Change 16.290 NPMLANOD dataset variable TIC_UTIL was missing because
VMAC28 variable DURATM, the denominator of TIC_UTIL equation in
Dec 1, 1998 the AOFTYPE='CSL' logic, was not calculated. The lines
of code inside 'CSL' that created ENDTIME and STARTIME
are moved above the TIC_UTIL calculation, and a new line
of code: DURATM=ENDTIME-STARTIME; was added. Also, the
test IF LENAOF GE 204 in 'CSL' was changed to GE 192.
Variable DURATM was also not calculated in the ETH, LSV,
and SAM segments; it is now calculated there, and is also
added to macros VA28CSL/ETH/LSV/SAM so it will be kept in
the datasets created by those segments.
Variable TIC_UTIL exists in dataset NPMLANOD but has
a missing value. You can create values without having
to re-reading SMF by running this program:
DATA PDB.NPMLANOD; SET PDB.NPMLANOD;
DURATM=ENDTIME-STARTIME;
TIC_UTIL=100*
((((LCSLBYTS*LCSLBTPT)+(LCSLBYTR*LCSLBRPT))/1000000000)+
(((LCSLTFRS*LCSLFTPT)+(LCSLTFRR*LCSLFRPT))/1000000))
/DURATM;
I recommend that you cut and paste those lines of code,
rather than trying to type them!
Thanks to Anke Mineur, dvg Hannover, GERMANY.
======Changes thru 16.289 were in MXG 16.06 dated Nov 30, 1998======
Change 16.289 Final testing of 16.06 left a PUT 'JOURN= ' ... statement
VMAC110 in the (archaic) CICS non-ESA code that could print many
Nov 30, 1998 lines on SAS log, with no other impact. Deleted the line.
Thanks to Ben Coonfield, Browning-Ferris Services, Inc, USA.
Change 16.288 In 16.04+ the sort order for all RMF datasets was changed
ANALRMFI to BY SYSPLEX SYSTEM STARTIME from BY SYSTEM STARTIME,
ASUM70PR but I failed to note the change, and I failed to change
GRAFRMFI the BYs in RMFINTRV until this change. The change is
MONTHBLD required because the same SYSTEM name can be in multiple
RMFINTRV SYSPLEX members. If you have only one SYSPLEX, this
VMAC7072 change has no impact, but if you have multiple SYSPLEXs,
VMAC71 you may have to change your BYs to BY SYSPLEX SYSTEM....
VMAC73 (Otherwise, your reports may fail with NOT SORTED error).
VMAC74 The member ANALRMFI (four PROC PLOTS) was change to add
VMAC75 SYSPLEX to the BY list. In the other ????RMFI members,
VMAC76 GRAFRMFI/TRNDRMFI/etc., the reporting is SORTED by SYSTEM
VMAC77 without the SYSPLEX variable to preserve your existing
VMAC78 reporting BY SYSTEM. Unless you actually have the same
VMAC79 SYSTEM name in two SYSPLEXes, this MXG choice will keep
WEEKBLD your existing reports BY SYSTEM and hopefully avoid any
WEEKBLDT need to change your reports.
Nov 30, 1998
Thanks to Richard S. Ralston, Whirlpool Corporation, USA.
Change 16.287 MXG 16.03-MXG 16.06. NPM datasets NPMIN25L and NPMIN25P
VMAC28 were misspelled as NPMINB5L and NPMINC5P beginning with
VMAC110 MXG 16.03, but are now spelled correctly. CICS Stats
Nov 30, 1998 datasets from Boole's MainView for CICS were misspelled
as CICBBxx instead of CICSBBxx, but are now correct.
Thanks to Chris Weston, SAS Institute ITSV, USA.
Change 16.286 MXG 16.06 only, CICS TS 1.2 only. INPUT STATEMENT EXCEED
VMAC110 error. Variables DS6SWT and DS6SCT should not have been
Nov 30, 1998 input at all. When I cleaned up the code for the sixth
CICS TCB, I inadvertently INPUT those two variables, but
they existed only back in CICS/ESA 3.3 and do not exist
in the CICS Transaction Servers (and only the CICS TS
releases have the sixth TCB!). Deleting all references
to variables DS6SWT and DS6SCT will correct my error.
Thanks to Thomas Wieland, Phoenix Home Life Mutual Insurance, USA.
======Changes thru 16.285 were in MXG 16.06 dated Nov 21, 1998======
Change 16.285 IBM TCP/IP undocumented fields changed the record lengths
VMACTCP and caused MXG's length-based logic to classify FTPSERVER
Nov 21, 1998 events as TCPSERVER. This revision no longer uses LENGTH
nor subtype; events are now identified based on data in
the record. While there are subtypes that theoretically
could be used, and the initial support for the new STAT
expected subtype 5, using subtypes would require a table
that you would have to update, since IBM did not see fit
to fix subtypes to events, but left them for you to set!
This redesign eliminates the need for subtype tables too.
Thanks to Randy Shumate, LEXIS-NEXIS, USA.
======Changes thru 16.284 were in MXG 16.06 dated Nov 18, 1998======
Change 16.284 Support for NPM Release 2.4 (INCOMPATIBLE)!
EX028VCS The good news is that NPM can capture IP resources from
EX028VMN TCP/IP connections. The bad news is that the NPM coders
EX028VRT INSERTED the new fields in the middle of the SCD segment,
FORMATS so many existing fields are trashed without this change.
IMAC28 -SCD segment inserted LSCDIPNM and LSCDIPPN incompatibly:
VMAC28 LSCDIPNM='IP ADDRESS*IF RESOURCE*IS IP' $15
VMXGINIT LSCDIPPN='IP PORT NUMBER*IF RESOURCE*IS IP' $5
Nov 18, 1998 Previously, the ACD/NCD/RCD/SCD segments used the same
MXG code, because they were congruent, but the new data
was inserted only in the SCD segment, so the MXG code was
restructured to separate SCD processing from ACD/NCD/RCD.
-VCD segment added three new fields compatibly:
LVCDCSMN='CSM*GROUP*NAME' $8
LVCDMNPN='MNPN*NAME' $8
LVCDRTPN='RTP*NAME' $8
-VVR segment added new variable
VVRNRBLK='TIMES WHEN*VR*WAS BLOCKED'
-Format MG028VA values 20x-26x (32-38 in decimal) are
actually 14x-1Ax (20-26 in decimal); format corrected.
-Format MG028NT, NPM Resource Type decoding, adds new
values: 14X='14x:IP'
6CX='6CX:CSM BUFFER POOL'
6DX='6DX:CSM STORAGE'
6EX='6EX:APPN TOPOLOGY'
6FX='6FX:APPN DIRECTORY SERVICES'
70X='70X:RTP DATA'
71X='71X:MNPS DATA'
-New subtype 'DC'x creates NPMVSVCS dataset:
LABEL='028VCS: VTAM CSM COMMON STORAGE MANAGER'
with buffer pool/storage/data space statistics
for 4k/16k/32k/64k areas.
CSM enables host applications to share data with VTAM
and other CSM users without having to physically copy
the data, saving memory and CPU by sharring buffers.
-New subtype 'DE'x creates NPMVSVRT dataset:
LABEL='028VRT: VTAM RTP RAPID TRANSIT PROTOCOL'
with first-in/middle-in/last-in/non-seg sent/rcvd pius,
bytes sent/received over RTP, back pressure count/times
RTP is a highly efficient mechanism used by the High
Performance Routing (HPR) to enable SNA to run highspeed
multi-megabit links with low bit error rates on LANS and
WANS and is used by SNA to exploit frame relay, SMDS and
ATM and other new switched virtual network technologies.
-New subtype 'DF'x creates NPMVSVMN dataset:
LABEL='028VMN: VTAM MNPS MULTINODE PERSISTENT SESSION'
VTAM uses multinode persistent sessions MNPS to preserve
sessions across application outages when connected thru
the S/390 coupling facility. While MNPS is primarily
for recovery of hardware, VTAM, MVS, or other failures,
NPM 2.4 now collects, for each application connected
thru MNPS, the percent of CF blocks in use by all MNPS
sessions and by this application, with CF Structure name
and structure sizes/bytes/writes and recovery counts!
The "IBM Marketing" descriptions came from pages xxix-xxx
of NetView Performance Monitor Reference Version 2 Rel 4,
(SH19-6965-02), which also describes the new TCP/IP
Session Collection Capability (response time data for
TELNET sessions to a mainframe application, including
the IP network segment, available for TN3270E servers
that reside on the same host as NPM and are running
OS/390 Release 5 or higher).
The NetWare resource counters, although not new in
NPM 2.4, are described in Appendix B (and support for
those NCV, NGV, NLS, NLV, NRV, NVS, and NVV NetWare
segments and subtypes has been in MXG for some time).
Change 16.283 Comments only, but the LRECL values for AS/400 4.2 were
IMACQAPM wrong for QAPMCONF (LRECL=16 in 4.2, was 46 earlier) and
VMACQAPM AS/400 support is critical for correct LRECL. Comments
Nov 18, 1998 were revised and updated with correct LRECLS where known.
Thanks to Bob Eastlake, Hosiery Corporation of America, USA.
Change 16.282 Comments only, but the examples to create ASUM70PR from
ASUM70PR raw SMF were old and had not been updated for changes in
Nov 18, 1998 the datasets needed by RMFINTRV. These examples have
now been revised and tested.
Thanks to Bob Eastlake, Hosiery Corporation of America, USA.
Change 16.281 The IP Address variable CTCPIPAD in dataset CTCPPERF was
VMACCTCP blank; the eight lines decoding CTCIPAD from CTCPLOAD in
Nov 18, 1998 the SUBTYPE=2 DO group must be moved to within the
SUBTYPE=1 DO group.
Thanks to Patsy Hildredth, CMX, USA.
Change 16.280 Support for IXFP / ICEBERG fields added by L170017 adds
VMACICE new test/prod/both unique/shared capacity/used statistics
Nov 18, 1998 in new variables:
BEBYTSHR BEBYTUNQ NOTRMAPU PHCAPUSS PHCAPUSU TPHCPSRB
TPHCPSRP TPHCPSRT TPHCPUNB TPHCPUNP TPHCPUNT
Thanks to Bonnie Jean Walter, Summit Bank, USA.
======Changes thru 16.279 were in MXG 16.06 dated Nov 17, 1998======
Change 16.279 Errors only in the first 16.06 tape dated Nov 16:
FORMATS -Format MGMVCIT was missing equal signs in member FORMATS,
VMAC434 causing JCLINSTL to fail. Format was added after QA.
VMAC80A -VMAC80A MACRO name is _S80A rather than _STY80A.
VMACTSOM -VMAC434 variable TERMTIME rather than TERMIME.
VMACHMF -VMACTSOM _BTSOCAL/_BTSODRU STRTTIME vice SMFTIME.
Nov 17, 1998 -VMACHMF ending comment missing in _STYHMFB macro.
Change 16.278 SYNCSORT virtual storage sizes are now FORMATed MGBYTES.
VMACSYNC The variables are: SYNCAVLA SYNCAVLT SYNCREQT SYNCUSEA
Nov 16, 1998 SYNCUSET SYNDSMVL SYNVSCOR SYNVSCRT
Thanks to Chuck Hopf, MBNA, USA.
Change 16.277 The PDB.CICINTRV dataset can be very wrong; users must
CICINTRV install MXG 16.06 or later to correct the errors in the
VMAC110 MXG logic. Depending on which CICS Statistics records
VMXGCICI had observations, CICINTRV could be valid, but the logic
Nov 15, 1998 was completely redesigned. Many datasets did not pass
Jul 22, 1999 thru VMXGSUM, so their COLLTIME was never reset to the
start-of-interval-value, and if there were multiple obs
to be summed, their unique COLLTIME values created many
repeated instances in the MERGE which were then falsely
summed. The revised logic sends all 45 CICS Statistics
datasets thru VMXGSUM, and all have INTERVAL=&INTERVAL
and DATETIME=COLLTIME specified so that shorter intervals
are correctly summarized. KEEPIN= and ID= were also set
so that LABELs and FORMATs are propagated, which produces
notes: "Variable xx exists on file WORK.MXGSUM3".
Now that PDB.CICINTRV is valid, you can use it to measure
the maximum CPU time required for any of CICS's six TCBs,
to confirm that that single CICS TCB will fit in single
engine, for capacity planning and for backup site sizing.
MXG creates the interval duration from DSGTDT+DSGTWT and
the individual DSxPERCT is the percent of DURATM when
DSx's TCB was busy; new variable PCTCICBY is the percent
of DURATM when all TCBs in this region were busy.
Note that if you want to see the raw interval data and
set MACRO _CICINTV % (i.e., "none"), and you thought
you were writing 5 minute interval CICS statistics data,
you will find some intervals only seconds apart, because
if there are SMFSTREQ='REQ' or 'USS' event records in
between the 'INT' and 'EOD' records, the CPU times and
counts have to be de-accumulated, and you end up with
erratic, but completely accurate, intervals.
In VMAC110, the _BCICxxx BY lists now agree with those
that are used in CICINTRV, so you can insert in EXPDBOUT
MACRO _SCICEXC %
_S110
to sort and save all CICS Stat datasets into the PDB
library (and CICINTRV detects and uses sorted data).
The redefinition of MACRO _SCICEXC to a null was added
in Jul 99; it is needed because in BUILDPDB, that sort
was already invoked, and the work copy of CICSEXCE has
already been deleted. By nulling the one _Sdddddd
macro, the _S110 can be executed without error.
However, the raw CICxxxxx Statistics Datasets frequently
contain accumulations rather than interval values; this
is especially true of the CICDS (Dispatcher) dataset,
which contains the CPU TCB times (DSGACT, DS2ACT...).
Those numbers in CICDS can be very deceptive, and thus
you should use this new PDB.CICINTRV to be safe. If you
already have existing CICDS data, you can PROC SORT it
PROC SORT DATA=PDB.CICDS OUT=SRTDS;
BY SYSTEM APPLID SMFPSSPN CICSSTCK COLLTIME ;
PROC PRINT; VAR APPLID COLLTIME DSGACT ... SMFSTRQT;
DATA DIFDS; SET SRTDS;
DSGACT=DIF(DSGACT);
DS2ACT=DIF(DS2ACT);
...
DS6ACT=DIF(DS6ACT);
PROC PRINT; VAR APPLID COLLTIME DSGACT ... SMFSTRQT;
and disregard the negative numbers, to get a quick view.
If there is a need, I may expand CICINTRV to optionally
create de-accumulated CICxxxxx Stat datasets, but for
now PDB.CICINTRV in MXG 16.06 is the dataset to use!
Thanks to Mike Marek, First Card - FCC National Bank, USA.
Thanks to Tom Elbert, Fortis, USA.
Change 16.276 Testing of the new TYPSxxxx members uncovered typos:
VMXGINIT -VMXGINIT: PTY848, PTY849, PTY8026 added to GLOBAL.
VMAC79 -VMAC79: SYSTEM added to KEEP= list 79DF/79E/79EF.
VMAC80 -TYPS80: _S80 macro invocation added.
VMAC85 -VMAC85: "%" in column 72 caused SAS ERROR 180 error,
VMAC88 which technically is a SAS compiler bug, but it
VMAC94 is easier just to split the long line into two
Nov 14, 1998 and not use column 72 for ending percent signs!
-VMAC88: _BTY8811 variable is SMF88ANM, not SMF88LSN.
-VMAC94: _STY94 macro, added BY _BTY94 ; after PROC SORT.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 16.275 The INPUT of MVDSNL $VARYING44. MVDSN1L should have been
VMACEDGS MVDSNL $VARYING44. MVDSNLL so that the DSN
Nov 14, 1998 length input was the length of last DSN.
Thanks to Richard Fortenberry, Mitsubishi Motor Sales of America, USA
Change 16.274 -The _S110 macro no longer sorts CICSTRAN (high volume)
VMAC110 nor CICSACCT nor CICSYSTM (both pre-CICS/ESA only). The
Nov 14, 1998 _S110 macro should be invoked in your EXPDBOUT member if
you want all of the CICS Statistics and CICS Journal data
sets sorted into your PDB library with BUILDPDB. If you
use member TYPS110 to directly read type 110 SMF records,
it invokes _S110 to sort from work to PDB library.
Change 16.273 The default for &DFSMS was changed from 0 to 1, i.e.,
ASMIMSL6 DF/SMS is installed. Using the MXG default of zero
Nov 13, 1998 caused an 878 out of memory error, because the table
that had been moved above 16MB by Change 14.149 was put
below the line by the zero value. The correct default,
that DF/SMS is installed (not necessarily active), will
put the table above the line and eliminate the ABEND.
Thanks to Harry Olschewski, DeTeCSM/SLM - Kiel, GERMANY.
Change 16.272 The PROC SORT of TYPE25 in the _STY25 macro had SMFTIME
VMAC25 after _BTY25, but _BTY25 already contained SMFTIME. For
Nov 13, 1998 reasons still not understood, that redundant SMFTIME at
the end caused the data set to be not sorted in BUILDPD3
so it was removed.
Thanks to Jean Quinkert, Inland Steel, USA.
Change 16.271 MXG 16.04-16.05 only. PDB.ASUM70PR summarized by SHIFT
ASUM70PR rather by expected HOUR default. Change 16.146 added new
VMXGDUR line &DATETIME=DATETIME; in VMXGSUM after %VMXGDUR call,
VMXGSUM but the VMXGSUM invocation in member ASUM70PR has both
Nov 15, 1998 NEWSHIFT='Y' and MYTIME=_DURSET specified, which caused
the DATETIME variable used in VMXGDUR to inadvertently be
the start of shift. The correction is in member VMXGDUR,
so that it uses the correct DATETIME value in all cases.
Member ASUM70PR was the only place in MXG where VMXGSUM
used both the NEWSHIFT='Y' and MYTIME=xxxxx options.
Only member VMXGDUR was changed by this change.
Thanks to Lee Teague, Lockheed Martin, USA.
Thanks to Sandra M. Rodriguez, Liberty Mutual, USA.
Change 16.270 Support for CICS TS 1.2 Journal Format 110s (INCOMPAT).
EXCICJRN The type 110 subtype 0 Journal Format record was entirely
VMAC110 restructured in CICS TS 1.2 (a/k/a 5.2). The record now
Nov 12, 1998 contains an LGMS header, an LGMS CICS Product Segment,
a 56-byte LGGF (GLRH Record Header), and a 20-byte LGGF
SOR record at the start of each subtype 0 record. Then
one or more LGGF (GLRH Record Header again), an LGGF
CL_USER-HEADER (which is where the JCRUTRID Journal ID
value is finally found) and then bytes of user data.
This new code has been tested with user journal data, but
not yet with either SAP nor Shared Medical journals from
CICS TS 1.2. IBM provides a COMPAT41 facility for
journal records written to the logger, but IBM says there
is no compatibility service for user journalling records
written to SMF.
Thanks to Thomas Weiland, Phoenix Home Life Mutual Insurance, USA.
Thanks to Mark Hawks, Phoenix Home Life Mutual Insurance, USA.
Change 16.269 New variables DCMEPCT and RCIPCT added to TYPE42DS:
VMAC42 DCMEPCT 'DCME*INHIBIT*PERCENTAGE'
Nov 12, 1998 RCIPCT 'RECORD*LEVEL*CACHE*INHIBIT*PERCENTAGE'
Thanks to Michael Marek, First Card, USA.
Change 16.268 Some variables were not input from SMF type 90 subtypes:
VMAC90 Subtype 5/9/13/15 new variable SMF90SBU (SMF Flags) is
Nov 12, 1998 created, and variable ACTIVEMN is increased to $44 to
contain the full (long) name of the SMF dataset. Subtype
6, OLDDSNSM and NEWDSNSM are increased to $44.
Thanks to Jan van Kemenade, Candle, THE NETHERLANDS.
Change 16.267 MXG 16.04-16.05 only. MACRO _LRAC507 needed two decimal
TYPSRACF points: MACRO _LRAC507 &PRAC507..RACF507 % in VMACRACF,
VMACRACF and the PROC FREQ was removed from member TYPSRACF.
Nov 11, 1998
Thanks to Tom Downey, IBM Global Services, CANADA.
Change 16.266 Change 16.253 for CICINTRV used the new VMXGWORL to find
VMXGWORL the location (_W or _L) of the CICS Stat dataset that are
Nov 12, 1998 read by CICINTRV, but if found in the _L location it was
assumed that the PROC SORT could be bypassed. However,
if you used PROC COPY IN=WORK OUT=PDB; SELECT 7IC:; in
the EXPDBOUT member, CICINTRV failed as the data was not
sorted. Now, the logic in VMXGWORL tests the SORTED flag
in the found data and only if it is true is the PROC SORT
bypassed by MXG now. Why did I not let the PROC SORT
detect that the data was sorted so it would bypass the
actual sorting? Because invoking the PROC SORT would
still result in an unnecessary copy from input to output
that is avoided by MXG not evening calling the PROC SORT.
Instead of the PROC COPY syntax in your EXPDBOUT, you
should instead add the single line containing _S110
which will sort all of the CICS Statistics datasets into
the work file, (and CICINTRV will skip their sorts!).
Thanks to Jean Quinkert, Inland Steel, USA.
Change 16.265 The type 88 subtype 11 was badly misdocumented, but it is
VMAC88 now corrected by APAR OW36033, which also describes three
Nov 11, 1998 new fields, SMF88ATW, SMF88ALS, and SMF88AFG that are now
input and kept in dataset TYPE8811.
Change 16.264 Support for PSF/MVS Release 3.1.0 (APAR 35685) compatibly
VMAC6 adds a new count of the accumulated number of logical
Nov 11, 1998 pages per side, SMF6LPGE, and the size of paper (length
and width in millimeters, BINxBNLE and BINxBNWI).
Change 16.263 Change 16.214 formatted new HSM Functions in DF/SMS 1.4,
VMACHSM but failed to output the new subtypes 17-20.
Nov 11, 1998 FSRTYPE Description
17 Expire primary or migrated data set
18 Partrel function
19 Expire incremental backup version
20 Expire incremental backup version
Now, test data shows they are the same structure as the
existing subtypes 1-14, so changing the test to read:
IF (1 LE FSRTYPE LE 14) OR (17 LE FSRTYPE LE 20) THEN DO;
will output them into dataset HSMFSRTP.
Thanks to Solomon Baker, The Prudential Service Company, USA.
Change 16.262 Candle's Omegamon for VTAM SMF record NTRI segment was
VMACOMVT incorrectly documented, causing INPUT STATEMENT EXCEEDED
Nov 10, 1998 error. The eight-byte reserved field after ON14OP is in
fact only four bytes. Change the +8 to +4.
Thanks to Eric Barnes, Prudential, ENGLAND.
Change 16.261 The LABEL='NTNSHS: should have been LABEL='NTNSHU:
VMACNTSM following the _WNTNSHU reference (lines 1815-1816).
Nov 10, 1998
Thanks to Carl Kyonka, Consumers Gas Company Ltd., CANADA
Change 16.260 Support for Boole & Babbage MainView for CICS CMRDETL
EXMVCICF VSAM file creates two new datasets from CMR52:
EXMVCICS Dataset dddddd Description
FORMATS CMRDETL MVCICF MAINVIEW CICS CMRDETL file detl
IMACMVCI CMRFILE MVCICS MAINVIEW CICS CMRDETL TRANSACTS
TYPEMVCI There is one observation in CMRDETL for each transaction
VMACMVCI and one observation in CMRFILE for each file that was
VMXGINIT accessed by each transaction. The CMRDETL is similar to
Nov 7, 1998 type 110's CICSTRAN and the CMRFILE is similar to CICFCR.
Nov 13, 1998 The raw CMRDETL file is compressed, but the compression
Nov 16, 1998 algorithm Boole used for CMRDETL is not the same as the
compression algorithm that Boole now uses for its other
MainView products (i.e., the new ASMMNVW does NOT work
with CMRDETL file), but Boole intends to provide me with
a separate ASMxxxxx member to handle CMRDETL compression.
You can use Boole's PGM=CMRCMPW to decompress the data
until the new Infile Exit for CMRDETL exists.
Boole also corrected documentation errors; CICS 5.2 date
format is now MMDDYYYY and T6EUSTGX replaces T6EUSTGO.
New format $MGMVCIT decodes File type.
Thanks to Peter Hartmut, R & V Allgemeine Versicherung AG, GERMANY.
======Changes thru 16.259 were in MXG 16.05 dated Nov 1, 1998======
Change 16.259 ML-18 of ASMTAPES to protect against the circular queue
ASMTAPES situation associated with the DSAB flag. The original
Nov 1, 1998 logic looked for the end-of-queue marker, but now the
code uses the count of entries to find the end-of-queue,
as we found one instance in which there was no end-mark
and MXGTMNT went into a loop and had to be cancelled.
Change 16.258 RMFR Reports, variables SYSPLEX and STARTIME NOT FOUND if
ANALRMFR parameter overrides are PDB=SMF and REPORT=ALL. Fields
Nov 1, 1998 R744FMOD/FVER/VLVL added to Coupling Facility Usage, and
the LPAR MGMT column in the Partition Data report was
corrected (it was sometimes negative).
Change 16.257 The new IMS 6.1 Support in ASMIMSLG6 was tested with data
TYPEIMSA from European Summer time, which had GMTOFFTM of zero,
VMACIMSA but with non-zero GMT offset, VMACIMSA converted GMT to
Nov 1, 1998 local only for the ENDTIME variable in the 07/08 records
(because they contain the GMTOFFTM), but the IMSMERGE
records created as output from ASMIMSL6 do not contain
the GMT offset (because it did not exist prior to 6.1!).
The mixed time zones caused invalid (large negative in
the western hemisphere, large positive east of GMT) for
SERVICTM (service time) and RESPNSTM. This fix removed
the conversion of ENDTIME/STRTTIME in VMACIMSA, instead
keeping variable GMTOFFTM from the 07/08 record, and
then in the final MERGE, the GMT offset is added to all
timestamps in that one place. PLEASE VERIFY THIS LOGIC!
Thanks to David Martin, USS-Posco Industries, USA.
Change 16.256 DB2 Version 5.1 variables QISEDSI, QISEDSG, & QISEDSC
VMACDB2 were not input, but now they are.
Nov 1, 1998
Thanks to Craig Collins, State of Wisconsin, USA.
Change 16.255 Support for new DF/SMS OAM type 85 SMF record with 31
EXTY85AC subtypes create eleven datasets tracking Optical Access
EXTY85CV Method activity, volumes, space, durations, objects,
EXTY85LS bytes, deletes, etc., etc:
EXTY85RD Subtypes MXG Dataset Description Test Data?
EXTY85RQ 1- 7 TYPE85AC OAM OSREQ ACTIVITY Y
EXTY85SO 32-35 TYPE85ST OAM OSMC STORAGE MANAGEMENT Y
EXTY85ST 36 TYPE85SO OAM OSREQ SINGLE OBJECT N
EXTY85TD 37 TYPE85LS OAM OAMC LIBRARY SPACE Y
EXTY85TP 64-67 TYPE85VL OAM VARY LIBRARY/DRIVE N
EXTY85TV 68-73 TYPE85CV OAM LCS CARTRIDGE/VOLUME Y
FORMATS 74-77 TYPE85RQ OAM LCS READ/WRITE/REQUESTS Y
IMAC85 74-77 TYPE85RD OAM LCS READ/WRITE DETAILS Y
TYPE85 78,79,88 TYPE85TP OAM LCS TAPE READ/WRITE Y
VMAC85 78,79,88 TYPE85TD OAM LCS TAPE READ/WRITE DETAILS Y
VMXGINIT 87 TYPE85TV OAM TAPE VOLUME DEMOUNT N
Oct 31, 1998 While the record contains "kilobytes", MXG converts all
those storage size variables into bytes and formats them
with MGBYTES format which prints as KB/MB/GB etc.
I assumed 1024 bytes per kilobyte, but need to confirm.
The start and end timestamps are on the GMT clock but
there is no GMT offset in the records, but I used the
delta between SMFTIME and the R85PENDT to create the
GMT85OFF (but it probably won't contain leap seconds).
There are 24 undocumented bytes in the product section
that look suspiciously like job/step/procstep names, but
they are not decoded until they are documented by IBM.
There is an incredible wealth of information provided by
IBM for accounting, performance and capacity planning,
and the SMF manual has a brief discussion of OAM data.
Thanks to Gary Matney, American Century, USA.
Change 16.254 Support for DFSORT Release 14 SMF type 16 record (COMPAT)
VMAC16 required no change in MXG, since the record format was
Oct 31, 1998 not changed, and MXG already supported APARs that had
added bits to some flag fields.
Change 16.253 CICINTRV now figures out whether your CICS Statistic data
CICINTRV is sitting in the Work file ("_Wdddddd") or whether you
TYPS110 had used the _Sdddddd macro to PROC SORT it into the PDB
VMXGCICI ("_Ldddddd destination). This applies only to the type
VMXGWORL 110 subtype 2 SMF records. Normally, BUILDPDB/3 will
Nov 1, 1998 build AND sort all datasets for a product from WORK into
the PDB, but CICS type 110 subtype 2 records are only
created in the WORK file and are not SORTed to PDB,
(because the CICS Statistics datasets can be large and
are not useful unless your are going to use them!).
The old way to add CICS Stat data into your PDB with the
BUILDPDB added a PROC COPY IN=WORK OUT=PDB; SELECT CIC:;
in tailoring member EXPDBOUT to copy all, or individual
PROC SORTs were added in EXPDBOUT. But now with the new
MACKEEP design, you only need to add the _SCICddd macro
for each dataset you want, and you don't even have to use
a %LET PCICDS=PDB; because the default value for PCICDS
is already PDB!
Well, adding the _SCICDS macro in EXPDBOUT does create
dataset PDB.CICDS, but CICINTRV failed with DATASET
NOT FOUND, because it hardcoded the input CICS stat data
to be in the _Wdddddd, but the PROC SORT is from _W to
the _L, and housekeeping deletes the _Wdddddd dataset!
This solution is a redesign of CICINTRV to invoke new
member VMXGCICI (because CICINTRV is a "%INCLUDEd member"
but we needed the power of a "%MACRO), and creation of
a new utility %MACRO VMXGWORL to determine for a given
dddddd value whether the data is in the _W or in the _L
(and if it is in the _L, the new CICINTRV logic will
bypass the PROC SORT since it's already sorted.)
In the interim, you can override the _Wdddddd definition
and send the un-sorted dataset to the PDB library, and
then CICINTRV will use that dataset. Philosophically,
I don't want you to have to manipulate the _W or _L
macro names, just because they are messy to use, but they
will always be there, so this fix will work - it's just
not as pretty as simply adding the _Sdddddd macro(s) in
EXPDBOUT! For example, you would add
MACRO _WCICDS PDB.CICDS %
in either member IMACKEEP or with %LET MACKEEP= logic.
Additionally, member TYPS110 now invokes _S110 to sort
all of the CICS Stat datasets, as it should have.
See final revision in Change 16.266.
Thanks to Jean Quinkert, Inland Steel, USA.
Change 16.252 Six lines with pairs of 'DD'x (ASCII) or 'BD'x (EBCDIC)
ANALBATW characters should have been pairs of exclamation points
Oct 30, 1998 (for concatenation). I use exclamation points instead of
long vertical bars because exclamation points translate
between ASCII and EBCDIC in all languages and long bars
did not translate from UK to USA (hence this change).
Thanks to David Nuechterlein, Nissan Motor Corporation, USA.
Change 16.251 TMS support was still not correct for multi-dataset tape
TYPETMS5 volumes; some variables from TMSRECS dataset were blank
Oct 30, 1998 in the output DSNBRECD dataset, because it turns out that
the RETAIN statement doesn't work like I thought it did!
See SAS Technical Note 1., Newsletter 35 about RETAIN.
The SET statement to combine TMSRECS and DSNBRECS was
changed back to MERGE, the IF FIRST.VOLSER THEN was
changed to IF FIRST.VOLSER and INTMS THEN DO;, and the
subsequent adjacent END; and IF INTMS THEN DO; statements
were deleted (so that now the logic is FIRST.VOLSER to do
all the INTMS processing followed by IF INDSNB to do the
DSNBREC processing, and then the if LAST.VOLSER to output
the volume record into TMS.TMS).
Thanks to Chuck Hopf, MNBA, USA.
Change 16.250 -MXG 16.04 only. Zero observations in dataset SYNCSORT if
ASUMPRTR you used IMACSYNC from 16.04. Syncsort's ID macro name is
IMACRMDS _SYNCID, but the example in IMACSYNC had _IDSYNC. MXG's
IMACRTE convention now is for the name to be _IDxxxx, but three
IMACSYNC early names were spelled _xxxxID ( _SYNCID in IMACSYNC,
Oct 27, 1998 _RMDSID in IMACRMDS, and _RTEID in IMACRTE ) and all are
now correctly spelled in their IMAC comments. These IMAC
members: CADM, CIMS, DIOS, HO15, OLDV, SAM, SFS, TAND had
incorrect comments that have been revised
-Member ASUMPRTR deletes datasets with PROC DATASETS, but
it was missing the NOLIST option, so it printed lines of
unneeded/unwanted messages on your SAS log. Now it don't.
Thanks to Glenn Harper, Memorial HealthCare System, USA.
Change 16.249 Support for Interlink TCPaccess Version 5.2(INCOMPAT).
EXILKA23 -New subtypes and new headers for new subtypes will cause
EXILKAAP the old MXG code to fail.
EXILKAIU -New variables were added to the ILKAST20 dataset, and it
EXILKAOE now contains both subtype 20 and subtype 22 events; the
EXILKAPR variable SMFACTYP identifies which subtype created the
EXILKASP observation (20 is end of ftp, 22 is end-of-volume ftp).
EXILKAVS -New ILKAST23 dataset tracks TELNET sessions from st 23.
FORMATS -Subtypes 110 thru 124 create new ILKASTPR protocols
VMACILKA dataset. Note: Nov 4: The IF 150 LE ... statement was
VMXGINIT wrong; it should have been ELSE IF 150 LE ... and the
Oct 27, 1998 IN (110-112,118,123-124) should have been written as
Nov 4, 1998 IN (110,111,112,118,123,124) to process 111 records.
-Subtypes 150,151,152 create new ILKASTAP, ILKASTIU, and
ILKASTOE for API, IUCV, or Open Edition Close events.
-Subtype 80 creates ILKASTVS with global virtual storage
and creates ILKASTSP with individual subpool virtual
storage; only subpools with non-zero allocation/usage are
output in ILKASTSP.
-Subtype 100 is not yet decoded, no test record yet.
-However the new subtypes 80 and 150-152 have severe data
errors. The UOF and DOF offsets are off by one byte due
to SMFACACB being only 7 instead of 8 bytes. (MXG can
protect that offset). In the subtype 152, the counters
appear to be off by one byte (open problem with vendor).
In the subtype 80, the subpool sections are not all 40
bytes long - some are 39 (open problem with vendor).
Thanks to Will Evans, CNF Transportation, USA.
Change 16.248 The two ELSE IF PCTRDYWT=.; statements should have been
VMAC7072 written ELSE PCTRDYWT=.; but very fortunately, this
Oct 23, 1998 typo-that-became-a-logic-error has never been executed.
Only when there are OS/390 systems with 15 or more CPUs
would this typo have become an execution error, and then
the results (if not the cause) would have been obvious:
zero obs would have been created in dataset TYPE70!
Thanks to Harry Olschewski, DeTeCSM/SLM, GERMANY
Change 16.247 Support for MainView Compressed history files. Beginning
ASMMNVW with MainView for MVS 2.5, and soon with other MainView
TYPEBBMQ products, Boole history files are compressed (although
TYPECMFV specifying HISTCOMP=N as a parm on the EXEC card in the
VMACBBMQ MMR PAS JCL will turn compression off). Boole's SAMPLIB
VMACCMFV member MMRHUNC contains a standalone decompression job,
Oct 23, 1998 but this change creates a new SAS INFILE exit "MNVW" that
decompresses the compressed data during INPUT on the fly!
You assemble the ASMMNVW member to create the load module
named MNVWIFUE and store that member in a load library
that you concatenate to the //STEPLIB for the SAS step
that will read the compressed data.
You then copy the INFILE-macro definition from the VMAC
into the IMACxxxx member for the specific product:
IMACxxxx INFILE-macro INFILE Product
IMACCMFV _CMFV CMFVSAM CMF/MMR
IMACBBMQ _BBMQ BBMQVSAM MQ Series
and add the string "MNVW" (which is the exit name) after
the INFILE name:
MACRO _CMFV
INFILE CMFVSAM MNVW STOPOVER .... ;
%
MACRO _BBMQ
INFILE BBMQVSAM MNVW STOPOVER .... :
%
These INFILE statements are now externalized by new MXG
macros _CMFV and _BBMQ that are defined in their VMACxxxx
member, so you can enable the MNVW INFILE exit either by
copying the _CMFV or _BBMQ macro definition into the
IMACxxxx for that product, or you can use the MACKEEP
architecture to change the definitions in your SYSIN.
As long as you have the load module in the //STEPLIB
concatenation, you can enable the INFILE exit now as it
will read any mixture of compressed or uncompressed data.
The Assembly code in ASMMNVW was written by Ray Revis.
Thanks to Ray Revis, Boole and Babbage, USA.
Change 16.246 Tandem variable RESPTM in dataset TANDLINE was too large
VMACTAND by a million; it should be INPUT as @119 RESPTM &PIB.8.6
Oct 22, 1998 instead of just &PIB.8.
Thanks to Raff Rushton, Kaiser Permanente, USA.
Change 16.245 Support for the RACF "installation-defined data field" in
VMAC80A SMF80DTP='07'x data segment is now INPUT as new variable
Oct 20, 1998 RACF07DT with maximum length of 32 bytes.
-replace
WHEN (7) DO;
INPUT +RACFDLN @;
END;
with
WHEN (7) DO;
IF 0 LT RACFDLN LE 32 THEN
INPUT RACF07DT $VARYING32. RACFDLN @;
ELSE IF RACFDLN GT 32 THEN DO;
INPUT RACF07DT $EBCDIC32. @;
SKIP=RACFDLN-32;
INPUT +SKIP @;
END;
END;
-add variable name RACF07DT to the KEEP= list for datasets
TYPE8008,TYPE8009,TYPE8010,TYPE8011,TYPE8012,TYPE8013,
TYPE8020 and TYPE8021, as this field can exist in all of
those RACF events.
Thanks to Albert Venetitay, CTICEP, FRANCE.
Change 16.244 Notes amplifying what is captured in which TCP records
ADOCTCP from an IBM Support person were added to documentation.
Oct 20, 1998 The TYPETCPA "APICALLS" event appears to capture all
bytes of all TCP/IP traffic, and even includes FTP counts
so it appears using TYPETCPA for accounting bytes in/out
may be feasible.
Thanks to Xiaobo Zhang, ISO, USA.
Change 16.243 Variable ENDTIME should have been kept in all datasets in
VMACCMFV VMACCMFV, but it was missing from the KEEP= list for some
Oct 20, 1998 datasets.
Thanks to Neil Ervin, Huntington Services, USA.
======Changes thru 16.242 were in MXG 16.04 dated Oct 19, 1998======
Change 16.242 MXG expected the new TCP Statistics record to be created
IMACTCP as SUBTYPE=5, but TCP lets the TCP installer set whatever
VMACTCP value they want for each subtype. MXG has always been
Oct 19, 1998 able to look inside the TCP record to determine what it
was without using the subtype, but the Statistics record
support does depend on the SUBTYPE value. This change
defines the new MACRO _SUBTCP5 5 % with its default of
5 than can be changed with MACKEEP/IMACKEEP/IMACTCP if
your subtype is not five.
Thanks to Ben Coonfield, Browning-Ferris Services, Ind., USA.
Change 16.241 MXG 16.04 only. Dataset VXMTRDEV was not created, so the
VMACVMXA PROC MEANS caused ERROR: THERE ARE NO ANALYSIS VARIABLES.
Oct 19, 1998 The correction was inside MACRO _SIODDEV definition; the
SORT was changed to OUT=_LMTRDEV instead of ZZMTRDEV, and
the SET ZZMTRDEV was changed to SET _LMTRDEV;
Thanks to Steve Clark, California Federal Bank, USA.
Change 16.240 Counter variables MROTRAN/DB2TRAN were set to zero, but
ASUMUOW this should be done only if the observation did not come
Oct 19, 1998 from the SPIN library, so IF NOT INSPIN THEN DO; ... END;
was added around the two statements. After IF LAST.
logic, new variables WTRLIOCN/WTRLIOTM were not reset,
but now are equated to HTRLIOCN/HTRLIOTM.
Thanks to Harry Olschewski, DeTeCSM/SLM, GERMANY.
Change 16.239 Variables SMF30AIC/SMF30AID/SMF30AIW were multiplied two
VMAC30 times by 128, and variables SMF30EIC/SMF30EID/SMF30EIW
Oct 19, 1998 were not multiplied at all; the last three lines should
have been for EIC/EID/EIW instead of repeat AIC/AID/AIW.
These new address space level connect/disconnect/pend
durations were added in OS/390 Release 2.4.
Thanks to Martin Peck, iT-AUSTRIA, AUSTRIA.
Change 16.238 MXG 16.04 only. The dataset names for SMF type 115 MQ
IMAC115 Series are now as they were before 16.04. The correct
VMAC115 names of MQMLOG, MQMMSGDM, and MQMBUFER are created,
Oct 19, 1998 instead of TYPE1151, TYPE1152, and TYPE115B.
Thanks to Brian Crow, British Telecom, ENGLAND.
Change 16.237 The first occurrence of &OPTNAME=S2 should have been
VMXGOPTR &OPTNAME=S. This had no effect in any delivered code,
Oct 19, 1998 but if you had used %VMXGOPTR to reset the S= option, it
did not work.
Thanks to Tom Parker, CSC/Hogan Systems, USA.
Change 16.236 New RACFEVNT=26:APPCLU SESSION ESTABLISH now creates new
EXTY8026 dataset TYPE8026. This event is new in RACF 2.2. This
VMAC80A new record causes MXG 14.14 to fail, but MXG 15.15 and
Oct 19, 1998 later did not fail with either TYPE80A or TYPE80.
Thanks to Roger Lowe, CITIBANK Asia Pacific Center, SINGAPORE.
Change 16.235 Invalid CICS type 110 Journal Format Subtype 0 records
VMAC110 with JCRLL value of zero caused MXG to loop on the same
Oct 19, 1998 record. MXG now protects for this invalid record, prints
an error message and deletes the bad records.
Thanks to Tom Wieland, Phoenix Home Life Mutual Insurance Co., USA.
Change 16.234 JES3 with more than 9999 job numbers caused log message
VMAC57 INVALID DATA FOR JESNR because the old 4-byte location is
Oct 19, 1998 now hex zeros. Adding the ?? modifier between JESNR and
&NUM.4. eliminates the message. There actually was no
error in the TYPE57 dataset, since the real JESNR is read
from a 5-digit field later in the record, but this will
eliminate an unnecessary and confusing message.
Thanks to Bendt Wiberg, CSC Computer Management A/S, DENMARK.
Change 16.233 MXG 16.04 only. Two Sort Macros, _SDB2STB and _SDB2STR,
VMACDB2 referenced &PDB2STB..DB2STATB and &PDB2STR..DB2STATR
Oct 19, 1998 instead of _LDB2STB and _LDB2STR, causing ANALDB2R to
fail when PDB=SMF was specified, if there was no PDB DD.
Thanks to Chuck Hopf, MBNA, USA.
Change 16.232 The PROC SORT of dataset INTWKLD needed variable DURATM
NTINTRV to be added at the end of the BY statement.
Oct 14, 1998
Thanks to Howard Glastetter, Weyerhaeuser Company, USA.
======Changes thru 16.231 were in MXG 16.04 dated Oct 9, 1998======
Change 16.231 Variables STDUPLEX, FCB, OVLYLOAD, and OVLYUSED are added
BUILD005 to MACRO _PDB30_6 so that they will exist in PDB.PRINT
BUIL3005 dataset (and hence will be in ITSV's XPRINT table). These
Oct 8, 1998 variables were needed because they had been kept in MICS.
Thanks to Theo Peelen, SHELL, THE NETHERLANDS.
Change 16.230 If there are duplicate type 30 subtype 5 records, and you
VMAC30 have job records with MULTIDD='Y' (there were so many DDs
BUILD005 that SMF had to write multiple physical type 30 records),
BUIL3005 the PROC SORT of TYPE30_5 was not robust enough to delete
Oct 8, 1998 those MULTIDD duplicates, which causes variable RESTARTS
in PDB.JOBS to be greater than 1 for job/TSO/STCs that
were not restarted. Fortunately, nothing else was bad!
Member VMAC30 was changed to KEEP variable EXTRADD in the
TYPE30_5 dataset, and the BY statement in macro _STY30U5
was changed by adding MULTIDD EXTRADD at its end.
Members BUILx005 had the BY statement for the PROC SORT
of DATA=TYPE30_5 changed by adding MULTIDD EXTRADD also.
Thanks to Chuck Hopf, MBNA, USA.
Change 16.229 Validation of revised VMACTPMX uncovered several spelling
VMACTPMX typos and token id typos in the format table. Message is
Oct 9, 1998 now printed on log if an unknown token is encountered.
Oct 19, 1998 The token finding logic was revised to work under ASCII.
Variables PERFORM and INSYSAF no longer have $HEX format.
Labels were "split" with * characters and ending parens.
IMACTPMX's comments were corrected.
Thanks to Lawrence Jermyn, Fidelity Investments, USA.
Change 16.228 NTSMF Version 2.2 records with Record Header 2.2.1
VMACNTSM cause NEW OBJECT errors, OBJECT='SERVICE PACK 3', because
Oct 8, 1998 I did not understand the new Record Header Values:
Header Description
2.0 Original Header format, no 0.0 record
2.0.h Extended Header format, 0.0 record created
2.1 Compressed Header format.
2.2.1 0.1 record created, 2.0.H Extended Format
2.2.2 0.1 record created, 2.1 Compressed Format
Records with Record Header 2.2.2 were read without error.
HEADER FORMAT 1 should be specified in your DCS, as it
reduces the amount of data in each record header and
hence the volume of data sent from the monitored to the
monitor. However, if you have not installed 2.2 on all
of your machines, NTSMF 2.2 will use the old spec on the
monitored machines, and if they contains HEADER FORMAT 0,
you will write the old, longer records until you change
that parameter.
The MXG variable, VERSION, is used not only to determine
the format of the record, but whether there will be a 0.0
record (used to calculate STARTIME if it exists), whether
there are CPU fields in the 0.0 record, whether there
will be a 0.1 record, and whether it will precede (prior
to NTSMF 2.2) or follow (NTSMF 2.2+) the 0.0 record!
Thanks to Howard Glastetter, Weyerhaeuser Company, USA.
Change 16.227 IMS 5.1 records with IMF 3.2 cause INPUT STATEMENT EXCEED
VMACCIMS error, because MXG only input the new segment for 6.1.
Oct 8, 1998 Change the IMSLEVEL test from 61 to 51 so it will read:
IF IMSLEVEL GE '51' AND IMFLEVEL GE '32' THEN INPUT
@373+OFFIMS UTCA ....
Thanks to Harmut Peter, R & V Allgemeine Versicherung AG, GERMANY
Thanks to Don Cleveland, Wellpoint, USA.
Change 16.226 Variable SYSTEM was added to the KEEP= list for dataset
VMAC110 CICSSAP from the optional SAP journal segment. In 16.04,
Oct 8, 1998 the _LCICSAP and _WCICSAP datasets had incorrectly spelt
the dataset CICSAP instead of CICSSAP.
Thanks to Theo T. Peelen, Shell, THE NETHERLANDS.
Change 16.225 MXG 16.04, DFSMS 1.3 caused INPUT STATEMENT EXCEEDED, but
VMACHSM DFSMS 1.4 records caused no error message. MXG Change
Oct 8, 1998 16.136 incorrectly located the INPUT for new variables
WFSCPUTM and WFSACCT to before the INPUT of the VOLSER
segments. If there were 36 bytes of VOLSER data, the new
logic INPUT them as WFSCPUTM/WFSACCT, and then when the
old logic tried to read the VOLSERs, there were none!.
In addition, only the first VOLSER segment would have
been input. This change moves the new logic until after
any VOLSERs were input, and also iterates on WFSRNENT.
Thanks to Michael E. Friske, Fidelity Investments, USA.
======Changes thru 16.224 were in MXG 16.04 dated Oct 7, 1998======
Change 16.224 First MXG 16.04 only. JCLTEST6 fails with ID=220 SMF if
VMACOMVT they are not from OMEGAMON for VTAM. (If you have OMVT
Oct 6, 1998 records and have overridden the _IDOMVT macro in either
your IMACOMVT or IMACKEEP, you don't see this error - it
is only if you don't have OMVT but some other product is
writing type 220 records). Change the "220" in _IDOMVT
to "512", which is the impossible default SMF number that
should have been in VMACOMVT.
Thanks to Edd Carter, General Mills Restaurant, USA.
Change 16.223 The labels for variables CPUACTTM and CPUOVHTM were
RMFINTRV changed from "PROCESSOR" to "PROCESSORS" to be consistent
Oct 6, 1998 with variable CPUUPTTM and because all three variables do
contain the total time that all processors in the CEC
were active, uncaptured, or "up" (i.e., available).
Thanks to Edd Carter, General Mills Restaurant, USA.
Change 16.222 -First MXG 16.04 only. The new _STYTCPA "Sort" macro,
VMACTCP used only by the new TYPSTCP member, was missing an
VMXGINIT ending parenthesis in its definition. The DATA statement
Oct 6, 1998 that follows "MACRO _STYTCPA" statement should be:
DATA _LTYTCPA (LABEL='TYTCPA: .... API CALLS (SOCKETS)');
-Macro variable PTCPTCPS was not GLOBALed nor %LET in the
VMXGINIT member, causing unresolved macro reference.
Thanks to Chuck Hopf, MBNA, USA.
======Changes thru 16.221 were in MXG 16.04 dated Sep 30, 1998======
Change 16.221 Trending of Tape Allocations could overcount in a last
ASUMTALO interval that had data spread across two week's input
TRNDTALO with overlap during the same hour (i.e., last weeks last
Sep 30, 1998 allocation was from 0300-0315, this week has an allocate
from 0330-0345). This change corrects the allocate tape
count in that interval, but MXG's revisions in ML-17 of
ASMTAPES/MXGTMNT automatically synchronizes its interval
with SMF interval, so the exposure is reduced further.
Thanks to Jim Stevens, MBNA, USA.
Change 16.220 Logic for creation of NTCONFIG dataset from 0.0 and 0.1
VMACNTSM records was revised. For NTSMF 2.0 and 2.1, the 0.1 was
Sep 28, 1998 written first and then the 0.0, so MXG could OUTPUT to
NTCONFIG from the 0.0 record (including the three fields
that were RETAINed from the preceding 0.1 record). Now,
the output for NTCONFIG was located until after both the
0.0 and 0.1 were read and all their fields RETAINed, and
then OUTPUT from the 0.1 if NTSMF is 2.2 or later, or
OUTPUT from the 0.0 if NTSMF is Version 2.1 or earlier.
This really has minimal impact, as the NTCONFIG dataset
is only a log of configuration status, and not critical,
but now as new configuration fields are added to the 0.1
record, they will be added to dataset NTCONFIG.
Change 16.219 Final validation of MXG Support for IMS 6.1 Log Records.
ASMIMSL6 -The TIME DEC call returns a 0CYYDDDF format that is used
Sep 28, 1998 as a reference date to decide whether to delete or ignore
"old" INQUEUE records, but that value should have been
converted to the YYYYDDDF format of the INQUEUE record.
-ASMIMSL6 was enhanced to prevent U0012 abends if there
were insufficient slots being allocated on the initial
table load. While the number of slots can be provided to
ASMIMSL6 thru the //SLOTS DD statement, this enhancement
eliminates the need to specify slots in advance; the
INQUEUE is read (fast) to count records and NUMSLOTS is
reset to records+1000 if the slots are too few.
Thanks to Alan Green, British American Financial Services, ENGLAND.
Change 16.218 The VMXGTAPE macro sets TAPELIB=YES if an MVS SAS dataset
VMXGTAPE is on tape, but when run under ASCII SAS, produced notes
Sep 30, 1998 the SAS log. Additionally, when VMXGTAPE was used with a
DISK dataset, the second execution failed with an error
message UNABLE TO CLEAR LIBNAME. That error is fixed by
relocating the RUN; statement to be before the LIBNAME.
The error was not reported, because the only member to
use VMXGTAPE twice, TYPECIMS, uses tape rather than disk
for those large IMSTRAN files from IMF, and VMXGTAPE did
work fine when the MVS SAS dataset was on tape.
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 16.217 -Support for NTSMF new objects NetShow Station Service and
EXNTNSHS NetShow Unicast Service creates NETSHOWS and NETSHOWU
EXNTNSHU datasets, respectively.
VMACNTSM -Logic for NTCONFIG was revised to read CPU Speed field
Sep 23, 1998 when VERSION GE '2.0.H' AND NTVERSN GE '3.51' because
the segment exists in the 2.0.h records. Additionally,
VERSION=UPCASE(VERSION); was inserted after its INPUT
and before the test to avoid case sensitivity.
Thanks to Jim Quigley, Con Ed, USA.
Thanks to Denny C. Wong, New York Life, USA.
======Changes thru 16.216 were in MXG 16.03B6 dated Sep 23, 1998======
Change 16.216 Support for OS/390 2.6 (COMPATIBLE) added new data:
VMAC73 -Dataset TYPE73 new var SMF73ACR, Channel Path Acronym
VMAC74 -Dataset TYPE74 new var DEVDISNV, Device Disconnect Time
VMAC79 Is Not Valid flag, Y or Blank.
Sep 23, 1998 -Dataset TYPE74. IBM renamed field SMF74NID to SMF74DCT
and increased it from 26 to 28 bytes, but MXG continues
to name the variable SFM74NID and it contains either the
Node Descriptor ID for self-describing devices, or the
four-byte Device Number.
-Dataset TYPE74CA new var R745CCMT, Hardware Type and
Model of the Control Unit, 28 byte character variable.
-Dataset TYPE79C new var R79CACR, Channel Path Acronym.
-Changes to TYPE99 subtype 6 were already in MXG.
Change 16.215 ACF2 Version 6.2 INCOMPATIBLY changed the type 'V' record
VMACACF2 causing INPUT STATEMENT EXCEEDED RECORD LENGTH error.
Sep 23, 1998 Fortunately, most sites don't use the ACF2VR dataset that
is built from this record, so you can process their other
6.2 data by inserting the new line that tests LENGTH-COL
so that member VMACACF2 then contains:
IF ACVMFIDC GT 0 THEN DO _I_=3 TO ACVMFIDC;
IF LENGTH-COL+1 GE 8 THEN
INPUT ACVMFSEC $EBCDIC8. @; /*SECONDARY*AUTHID*/
CA provided same day documentation and technical support
of the changes in their record, which inserted an offset
field to the optional DB2 data fields, which is now used
and tested by MXG. No other new data was added.
Thanks to Frank d'Hoine, National Bank of Belgium, BELGIUM.
Thanks to Tim Dockter, CA, USA.
Thanks to Fred Duminy, CA, USA.
Change 16.214 Support for DF/SMS 1.4 changes to HSM records added new
FORMATS values for $MGHSMFU format to decode FSRTYPE:
Sep 22, 1998 Value Formatted value
6 USER requested Delete of a Migrated Data Set
17 HSM Expired/Deleted a Data Set
(FSRFLG3 then indicates where the dataset
existed when HSM expired/deleted it)
18 Partial Release
19='19:EXPIRE OR ROLL OFF INCREMENTAL BACKUP'
20='20:(H)BDELETE INCREMENTAL BACKUP'
Also it was noted that for a full volume restore (FSRTYPE
= 14), FSRFVOL is actually the target volume name, not
the source volume name.
Thanks to Michael E. Friske, Fidelity Investments, USA.
Change 16.213 The type 79 subtype 15 (IMS Long Lock record) fields were
VMAC79 not documented completely accurately, but will be in the
Sep 22, 1998 next SMF manual. New variable F79FTRNM is now INPUT, and
new format $MG079RT decodes F79FRGTY values. R79FPSTN is
either a PST number as 4 hex digits, or the character
string 'ID', which is 'C9C4'x. R79FLHTI is 8-bytes long,
but only the first four are used, as seconds after
midnight. R79FRSNA is now only INPUT if R79FETYP='W'.
Thanks to John Keenan, Boeing, USA.
Change 16.212 MXG did not input seven fields in the System record from
VMACTMV2 Landmark's The Monitor for MVS Version 2, causing dataset
Sep 22, 1998 TMVSSYS to have incorrect values. To circumvent, you can
insert a line with +28 between the INPUT lines for
SYSRESV4 and SYSUIC. The seven new variables in TMVSSYS:
SYSUASID,-AASID,-NASID,-SASID,-RASID,-OSASI,and SYSORASI.
are counters of ASIDs in USE/Available/etc.
Thanks to Jeff Justice, Integon, USA.
Change 16.211 Support for TCP/IP 3.4 Type 118 Subtype 5 SMF record.
EXTYTCPS The new TCP Statistics subtype causes MXG CRITICAL ERROR
FORMATS message and a delete of the new subtype, but the other
IMACTCP datasets are correctly built from the other records.
VMACTCP This support created new dataset TYPETCPS with TCP
Sep 21, 1998 Statistics counters.
Thanks to Huug Tempelmans-Plat, Hoogovens Staal BV, THE NETHERLANDS.
Thanks to Xiaobo Zhang, Insurance Service Office, USA.
Change 16.210 INVALID DATA FOR HH/MM/SS/INBUFFSZ/OUBUFFSZ from Super
VMACSUIN IND$FILE SMF records because some EBCDIC numeric fields
Sep 19, 1998 contain nulls instead of valid EBCDIC zeroes. Knowing
this now, each of the INPUTs that use &NUM. informat are
now preceded with ?? to suppress the warning messages.
The records with nulls also contain UNAVAIL for both the
TERMINAL name and the Logmode Entry Name, and the other
counters are zeroes, so I suspect these null records are
otherwise valid, and so their uninitialized fields are
now protected.
Change 16.209 SAS 6.12 for Windows, Maintenance TS045 changed what is
CONFIG printed on the SAS log when option STIMER is enabled.
Sep 18, 1998 Now, sixteen lines of Stack, Heap, Memory, and Images
stats are preceded by "HOST STATS FOR: xxxxxx" and are
printed for every data or proc step by the STIMER option.
MXG's CONFIG member has always enabled STIMER/FULLSTATS,
as they were useful in diagnosing memory problems back in
early V6, but the new output flooded my QA stream log, so
I have removed the overrides from MXG's CONFIG member, so
the SAS defaults (NOSTIMER,NOFULLSTATS) will be used. If
ever needed, they can easily be enabled in your CONFIG
file, thru the OPTIONS= in MVS JCL, or by using an
OPTIONS STIMER FULLSTATS; statement at the beginning
of your SAS program.
Change 16.208 Internal support for the NTSMF DTS 0.1 configuration data
VMACNTSM record created three new variables in NTCONFIG dataset:
Sep 17, 1998 PRFSENVR='PERFORMANCE*SENTRY*VERSION*THAT WROTE'
DCSLOCN ='LOCATION*OF DCS: REGISTRY/PRIDCS/DCSFILE/ETC'
DCSINTRN='INTERNAL*NAME*OF THE*DCS'
Change 16.207 PROC GPLOT has never worked right when its input dataset
ANALVARY has zero observations; in various SAS releases there have
ANALRRTM been Notes or Error messages, but _ERROR_ was never set.
Sep 17, 1998 But under SAS Version 7 Beta, these notes were created:
Sep 25, 1998 NOTE: No Observations in Data Set xxxxxxxx.
NOTE: The SAS System Stopped Processing due to errors.
NOTE: SAS Set Options OBS=0.
That false error message, and the setting of OBS=0, has
been accepted by SAS as a defect. However, SAS Tech
Support found that by relocating the SYMBOL statement to
precede the PROC GPLOT statement, the OBS=0 was not set,
so now the MXG 16.04 QA Stream has successfully executed
all steps under SAS Version 7 Beta!!!
Thanks to Chris Noto, SAS Institute Technical Support, USA.
Change 16.206 If you use the COUNT= option in ANALCNCR, and it has more
ANALCNCR than one variable, the BY list was wrong and it contained
Sep 17, 1998 repeated variable names. The MXG logic error is fixed by
changing &&COUNT&NUMCNT to read &&COUNT&I. Fortunately,
the important uses of %ANALCNCR in MXG don't use COUNT=.
In fact, this error was discovered by the new feature in
SAS Version 7 (ERROR: Duplicate variables in a BY list)
when the archaic example ANALTAPE that has %ANALCNCR with
COUNT=TAPEDRVS TAPE3420 TAPE3480 TAPE3490 TAPE3590,
was tested in the MXG QA stream.
Change 16.205 New format MG099TC decodes the Trace Action Codes in the
FORMATS Type 99 Goal Mode Workload Manager trace data, using the
VMAC99 Table 76 in Appendix A of OS/390 V2R5.0 MVS Workload
Sep 16, 1998 Management Services, mapping number to Trace Code Name.
The codes describe WLM decisions, and their full meaning
from that table is also in ADOC99.
Thanks to Chuck Hopf, MBNA, USA.
Change 16.204 The externalization of tailoring for IMACACCT, IMACSHFT,
IMACACCT IMACWORK, and IMACUCB can now use the "MACKEEP" design of
IMACSHFT Change 16.134, with new MACACCT, MACSHFT, MACWORK, and
IMACWORK MACUCB macros defined and nulled in VMXGINIT and invoked
IMACUCB at the end of each of those IMACs. The BUILxxxx members
BUILDPDB/3 were updated also to invoke new EPDBINC macro variable to
BUILD001 permit tailoring of the EXPDBxxx members as well.
BUIL3001
VMXGINIT
Sep 16, 1998
Thanks to Chuck Hopf, MBNA, USA.
Change 16.203 The statement LENGTH=LEN; was changed to LENGTH=LENGTH;
UTILDUMP to eliminate the Warning "Unitialized Variable LEN". The
Sep 16, 1998 new SENDDUMP is probably better documented to get dumps.
Thanks to Hertwig Rainer, Lufthansa Systems GmbH, GERMANY.
Change 16.202 Finally, the logic to create SASSWORK and USERWORK macro
VMXGDEL variables (so we know where your WORK= and USER= point)
VMXGSUM works under both SAS V6 and SAS V7 and under OS/390 as
VMXGOPTR well as Windows and Unix. All this is for housecleaning
Sep 16, 1998 (delete work datasets when we can), but we needed to not
delete WORK.X after SORTing into USER.X if you had set
SAS options WORK= and USER= to the same data library.
Our logic executes PROC SQL on VTABLE to get the WORK=
and USER= current values. We expected DDNAMES, and the
code worked on OS/390, but under Unix and Windows you get
the full file specification name, with forward and back
slashes, etc, which required more logic revisions. Now,
we find that only under OS/390 can WORK= and USER= point
to the same library, so the logic was simplified. But
then, under Version 7, we found that PROC SQL no longer
reads the VTABLE when OBS=0 is specified, which caused
macro variables SASSWORK/USERWORK to be blank. (That
PROC SQL in Version 6 did not honor OBS=0 was accepted as
a bug and fixed in Version 7; that we got output under V6
was an unintended design feature, now corrected!). But
by inserting VMXGOPTR invocations before and after each
PROC SQL to momentarily override the OBS=0 to OBS=MAX and
then reset OBS to whatever it was, solves that problem.
And VMXGOPTR itself had to be revised for first time run
so it too will work properly when OBS=0 is specified.
Now, MXG has been executed under the SAS Version 7 Beta
on both MVS (OS/390) and Windows (98 and NT) platforms.
Change 16.201 Type 74 Cache data, variable R745CSC was not kept in data
VMAC74 set TYPE74CA, and variables CSDPIDAT and DEVPIDAT were
Sep 15, 1998 misspelled as CSDPIPID and DEVPIPID, and are now correct.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 16.200 The created variable STARTIME in contained only the date
VMAC94 and hour of the calculated Start time; now the equation
Sep 15, 1998 is STARTIME=SMFTIME-DURATM; but DURATM=3600; is set in
MXG because there is (as yet) no actual duration in the
VTS record, and no way to change IBM's default of hourly.
Thanks to Pat Hansen, Automated Data Processing, USA.
Change 16.199 NTSMF OBJECT='WidetoMBErr' created dataset WIDE2MBE, but
EXNTWIDE that was an April Fool's day trick. I found that object
VMACNTSM name in Discovery records last April, assumed it was a
Sep 15, 1998 new thing, and created the new dataset in Change 16.048.
Today, I discover that THAT string is the error code that
is returned by the translate function API when a Unicode
to ASCII translation fails (like when the Microsoft field
documented as Unicode actually contains ASCII values!),
and there really was no WIDE2MBE dataset to be built, so
its exit member EXNTWIDE and the code in VMACNTSM were
removed by this Change. Demand Technology discovered the
record was really for the SNA Adapter Object, and revised
their code to deal with its idiosyncrasies! So now, when
WidetoMBErr shows up, its time to call Demand Technology
so they can look inside PERFMON to find the actual name
for these aberrant objects, but also please run Discovery
and send the data file, so that I can circumvent it.
For example, the Beta of Microsoft Terminal Server 1.0
now has a counter object named 'WidetoMBErr' inserted in
the middle of the Process object, INCOMPATIBLY causing
an INPUT STATEMENT EXCEEDED RECORD LENGTH error ABEND.
While Demand Technology gets the data to investigate
their end and tell me what's really there, this change
creates variable WIDE2MBE in the PROCESS dataset to get
the field and support the new record. Later, when we
know the field name, this text will be revised to rename
and label and possibly format the variable.
Thanks to Leigh Ann Payne,Wachovia Operational Services, USA.
Change 16.198 -MXG 16.03 only. MACRO _LIMSUNM UNMATCHED % was spelled
IMACIMSA wrong, and must be MACRO _LIMSUNM UNMATCHD % instead.
TYPEIMSA -PROC SORT DATA=IMSMERGE %VMXGFOR ; worked as long as you
Sep 10, 1998 didn't tailor the _LIMSMRG macro in your IMACIMS, but it
is now PROC SORT DATA=_LIMSMRG OUT=ZZIMSMRG %VMXGFOR;
The MERGE PRG (IN=INPRG) IMSMERGE (IN=INIO); is now
MERGE PRG (IN=INPRG) ZZIMSMRG (IN=INIO); and the DELETE
of IMSMERGE now deletes ZZIMSMRG, to make this work. The
macros will change once more when the 16.134 architecture
is applied to the IMS processing shortly.
Thanks to Kenneth D. Jones, Maritime Telephone and Telegraph, CANADA.
Change 16.197 The extra include of member IMACCICS in member TYPE110
TYPE110 prevented the &MAC110 or &MACKEEP logic from working to
Sep 10, 1998 redefine the _L macros. Member IMACCICS was removed from
member TYPE110's include, as it is already included by
the VMAC110 member, and there it include is followed by
the MAC110 and MACKEEP macros, so it can be overridden.
Thanks to Jerry Layne, Virigina Power, USA.
======Changes thru 16.196 were in MXG 16.03B5 dated Sep 9, 1998======
Change 16.196 Variables ELAPSTM, INPREQTM, and QUEUETM were calculated
VMAC33 before the variables used had been input. Now, the three
Sep 7, 1998 statements are inside the DO group, after TPNDTIME.
Variable TPUSRTYP was input and formatted, but not kept;
now it is in both TYPE33_1 and TYPE33_2 datasets.
Thanks to John Strumila, IBM Global Services Australia, AUSTRALIA.
Thanks to Lindsay Oxenham, IBM Global Services Australia, AUSTRALIA.
Change 16.195 The Printer Throughput analysis now created PDB.ASUMPRTR
ANALPRTR instead of PDB.PRINTER, to be consistent with current MXG
ASUMPRTR naming conventions. Scan your MXG Tailoring library and
Sep 6, 1998 change PDB.PRINTER to PDB.ASUMPRTR if it exists, but very
few sites regularly use this detailed analysis.
Change 16.194 -IBM now calculates the TYPE72GO Using/Delay Percentages
VMAC7072 using R723CTSA instead of CTOU+CTOT+CUNK+CIDL samples as
Sep 6, 1998 the denominator. R723CTSA adds CIOU+CIOD samples, and is
Sep 22, 1998 used even if I/O Delays are NOT being included in your
Oct 20, 1998 Velocity definition! Since R723CTSA is now larger, the
percentages will be smaller. So that MXG calculations
match the RMF reports, the correction in VMAC7072 is to
insert:
IF R723CTSA GT 0 THEN VALDSAMP=R723CTSA;
before:
IF VALDSAMP GT 0 THEN ....
-Variable PCTEXTSA is now set to missing value, as it is
a total sample count, now in R723CTSA, and not a percent.
-The I/O Velocity calculation when I/O Delay is NOT turned
on was changed to match IBM reports. MXG's old equation
VELOCITY=(CTOU+CIOU)/(CTOU+CIOU+CTOT) is changed to read
VELOCITY=(CTOU+CIOU)/(CTOU+CIOU+CTOT+CTDQ+CIOD) and the
code relocated until after CTDQ had actually been input!
OS/390 R2.4 added CTDQ in an extension of the SMR
record, but MXG's equation was back in the block of
code for the R1.3 extension. Now, 1.3 calculates
without CTDQ while 2.4 and later includes CTDQ.
When I/O Delay IS turned on, MXG sets R723VELI='Y' so the
velocity and I/O velocity are calculated the same way:
VELOCITY=VELOCIOD=CTOU/(CTOU+CTOT);
These changes now match the IBM RMF 2.4 Report values.
Oct 20, 1998 revision:
I/O Velocity enablement is system wide, and when enabled,
all of the Service Classes have R723MSCF='...1....'B, but
that bit is not on in the Reporting Class records. IBM
RMF has acknowledged their error and will fix it in a
future version of RMF, but MXG now stores R723MSCF from
the Service Class record (written first) into retained
variable SERVMSCF, which is now used instead of R723MSCF
to set R723VELI='Y' when I/O is enabled, so the correct
velocity equation will be used in spite of their error.
Thanks to Leonard Ponich, AT&T, USA.
Change 16.193 New reporting variables were added to MEMOACCT dataset:
VMACMEMO MEMDIST MEM3270 NEWMEM RETMEM SENMEM SESSION
Sep 6, 1998 TRXTOT USERPRF for direct reports from MEMOACCT.
Thanks to Harald Seifert, Huk-Coburg, GERMANY.
Change 16.192 Variable A08DURAT=A08BKDTD-A08BKCTD is now created in
VMAC110 CICS statistics dataset CICSLSRR to report how long the
Sep 6, 1998 pool existed. However, the base times are time-of-day
rather than datetimes, so if the pool exists for more
than 24 hours, the duration will not be accurate.
Thanks to Harald Seifert, Huk-Coburg, GERMANY.
Change 16.191 TMS revisions were still not complete, as FILSEQ was
TYPETMS5 missing in second and subsequent VOLSEQs. Before the
Sep 5, 1998 END; statement for the ELSE IF FILSEQ=. THEN DO; insert
MAXFLSEQ=FILSEQ;
LSTFLSEQ=FILSEQ;
and after IF MAXFLSEQ LT 999999 THEN FILSEQ=MAXFLSEQ;
insert IF FILSEQ=. THEN FILSEQ=1;
to always populate FILSEQ variable correctly.
Thanks to John Rosewarne, Telstra, AUSTRALIA.
Change 16.190 Variable PCTDLNDI is now set missing, as it was not a
ADOC7072 valid percent of anything. Instead, the raw count of
VMAC7072 samples, R723CNDI, from which PCTDLNDI was erroneously
Sep 5, 1998 calculated, is now kept. See the detail description in
member ADOC7072 for new variable R723CNDI.
Thanks to Don Deese, (CPExpert), Computer Measurement Sciences, USA.
Change 16.189 Support for Thruput Manager, TPM, was supported earlier
EXTYTPMX by member TYPETPM, but that program INPUT only the data
FORMATS fields it knew about. This new TYPETPMX was written by
IMACTPMX Susan, and it creates temporary FORMAT $MXTPMTK to token
TESTUSR1 each possible TPM field, and then VMACTPMX uses that in
TYPETPMX its TPM record processing. The output dataset contains
TYPSTPMX all possible variables, but will likely be very sparce as
VMACTPMX most TPM sites don't enable all fields, so COMPRESS=YES
VMXGINIT is specified, since sparce datasets compress so well that
Sep 5, 1998 dropping the nonexistent variables is unwarranted. As an
example, 1000 obs uncompressed required 1005 pages, but
compressed by SAS, the TYPETPMX dataset needed only 40!
Thanks to Susan Marshall, SAS Institute ITSV Cary, USA.
Change 16.188 Variable R742PSIG is now documented in ADOC74 that its
ADOC74 contents, inbound or outbound request counts, are in or
FORMATS out depending on variable R742PDIR, path direction, which
VMAC74 is now FORMATed ('80'X=Inbound, '40'X=Outbound). Also,
Sep 5, 1998 variable R742PTYP, path type, is now FORMATed ('1=CTC,
3='List Structure') by $MG074PD and $MG074PT formats.
Thanks to Leonard Ponich, AT &T, USA.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 16.187 Support for XCOM Release 3.0 (COMPATIBLE) adds variables
VMACXCOM TCPIPNAM, TCPIPADR, and XCOMMICR to TYPEXCOM dataset. But
Sep 1, 1998 I discovered that variables FLDSNNME REPTDEST REPTFORM
REPTFCB REPTNAME COPYCNT HOLDFLAG CONTFLAG SPOOFLAG
DISPFLAG and REMFLENM were input from wrong locations. I
have confirmed the two important variables, FLDSNNME and
REMFLENM (input/output dataset names) are properly input,
and I think the others are also now properly aligned, but
they are all blank in my test data.
The test data also XCOMVERS=300 when the connection is
from Unix to MVS, and XCOMVERS=3 when the connection
is from MVS to Unix (actually, the value is 'F30000'X
but it prints as 3). But there's no real problem, as
XCOMVERS is not used in any MXG logic.
Thanks to Aubrey Tang, GIO Australia, AUSTRALIA.
Change 16.186 The PROC SORT %VMXGFOR DATA=_WCICDL2 OUT=SRTDLIR; should
CICINTRV be PROC SORT %VMXGFOR DATA=_WCICDL1 OUT=SRTDLIR; as the
Sep 1, 1998 CICDLIR dataset is _WCICDL1 instead of _WCICDL2 (which is
CICDLIT, but that dataset always has zero observations).
Without this change, the A18xxxx variables were missing.
Thanks to Fiona Crane, Royal and Sun Alliance, ENGLAND.
Change 16.185 MXG Support for IMS 6.1 (Change 16.171) is now validated!
ASMIMSL6 -ASMIMSL6 had references to MXGIMSLG, but the program name
TYPEIMSA CSECT name, and comments were changed to MXGIMSL6 to be
VMACIMSA consistent with the JCLIMSL6 member, and so that IMS 6.1
Sep 1, 1998 program name is different than earlier releases.
-VMACIMSA inputs of ARRTIM, NQTIM, GUTIM and DQTIM were
changed from &PD.4. to &PK.4., and the algorithm to
convert was changed. These inputs are now separated into
a block for pre-IMS 6 and post-IMS 6, using _IMSVERS to
choose the correct format.
-TYPEIMSA KEEP= list for _IMSTRAN.IMSTRAN has variables
OLTERM and OVTAMNDE added; they were inadvertently
dropped.
-With these changes, MXG support for IMS 6.1 matches the
Transit Log Report from IBM's IMS Performance Analyzer!
-See also Change 16.171.
Thanks to Alan Green, Allied Dunbar, ENGLAND.
Change 16.184 Utility to create MXG source for Formats $MGDDDDD and
UDDDDDD $MGDDDSN to map "dddddd" to "dataset" and vice versa,
FORMATS for internal use in Change 16.134 programs, like the new
Sep 5, 1998 %BLDNTPDB. UDDDDDD reads the MXG source to find all _W
macro definitions and writes out the VALUE statement that
defines each format, and the output is copied in at the
end of member FORMATS.
Change 16.183 Revision of MXG logic for ABEND and CONDCODE in PDB.JOBS.
BUILD005 While I still think using the PDB.STEPS dataset for job
BUIL3005 ABEND analyis is strongly preferred (because steps ABEND,
IMACPDB jobs don't, and because the STEPS data gives you the
SPUNJOBS PROGRAM name so you can identify who wrote the program
Aug 31, 1998 that ABENDed, and because jobs can have multiple step
ABENDs), this revision populates the PDB.JOBS variables
ABEND and CONDCODE with useful values, and creates new
variable ABENDS that counts the abending steps in a job.
Previously in PDB.JOBS, the ABEND value indicated that
one or more steps abended, but the CONDCODE value was
taken from the last executed step. If COND=ONLY or EVEN
was specified in the JCL, you could have had an ABEND
with a wrong or zero CONDCODE. Or if a step had what is
called a pre-execution ABEND that causes the step to be
not-executed (this includes FLUSHed steps, steps with a
SYSTEM 822 ABEND, and steps with SYSTEM 213 ABEND on the
STEPLIB, which are not explicitly identified in the step
records) the ABEND='SYSTEM' but CONDCODE was zero.
With this revision, the values of ABEND and CONDCODE will
be stored from the FIRST step that ABENDed. If there are
no ABENDs, but there were non-zero condition codes in any
step, the highest non-zero condition code will be stored
in CONDCODE and ABEND='RETURN'. And if there were no
ABENDs in the step records, but the 30-5 job termination
record has the ABENDed bit set in SMF30STI bit "6", the
logic sets ABEND='PREEXE' to flag that some step of the
job had a preexecution error. (Steps with pre execution
errors will have ABEND='FLUSH', so if there was only one
step with FLUSH, you could determine which step failed,
but if there were multiple FLUSH steps, you may not be
able to identify which step actually had the ABEND).
The default of FIRST can be overridden with the MXGCOND
macro variable, which can be %LET of the values of LAST,
HIGHEST, or LOWEST to choose which ABEND/CONDCODE pair
will be stored in PDB.JOBS.
Defaults:
One or more ABENDing STEPS
CONDCODE=CONDCODE of first ABENDing step
ABEND='SYSTEM' or 'USER' from first ABENDing step
ABENDS=number of ABENDing steps
However: If the JOB TYPE30_5 record has the ABEND
bit on but CONDCODE=0, which happens if
the last step did NOT ABEND, MXG sets
ABEND='ABEND' in the PDB.JOBS dataset.
No ABENDing STEPS - ABEND flag on in type30_5
CONDCODE=CONDCODE from type30_5
ABEND='PREEXE'
ABENDS=1
No ABENDing STEPS - No ABEND flag on in type30_5
CONDCODE=highest non-zero CONDCODE from STEPS
ABEND='RETURN'
ABENDS=0
These possible values for ABEND now exist in MXG:
ABEND Description
JCL PDB.JOBS only - Job did not Start on JES.
CRSH PDB.JOBS only - Job active during SYS FAILURE
PREEXE JOBS-only: Step had a pre-execution ABEND.
SYSTEM System ABEND
USER User ABEND
RETURN Return Code
CANCEX Cancelled in SMF Exit, CONDCODE tells which
FLUSH Step Flushed or Pre-Execution ABEND
RESTAR Step was RESTARTED
NOTCTL Not Cataloged Dataset Error
OMVSEX Open Edition/MVS Execution
COND=J COND= was specified on JOB card
OTHER Any other ABEND condition
If you have an IMACPDB member in your USERID.SOURCLIB, it
must be removed and instead you use the new 16.04+ design
that lets you add variables to PDB.STEPS/JOBS/PRINT with
%LET ADDxxxx= syntax (placed in your IMACKEEP member) as
described in the text of Change 16.341. This is because
to support CONDCODE, a new dataset WORK.CONDCODE is now
created in _PDBSUMS, but your old IMACPDB will override
that with the old logic, causing a SAS error message:
ERROR: FILE WORK.CONDCODE.DATA DOES NOT EXIST.
MXG now protects execution errors by creating a
zero-observation WORK.CONDCODE dataset just before
_PDBSUMS is invoked, but if your IMACPDB is in place, you
will end up with CONDCODE always zero in your PDB.JOBS
dataset. (No matter what you do, the CONDCODE in
PDB.STEPS is always correct!).
Change 16.182 Revised logic because %VMXGDEL did not always delete the
VMXGDEL _Wdddddd dataset, even when it was different from the
Aug 31, 1998 _Ldddddd dataset. This left datasets in //WORK library.
Change 16.181 The label for GDES2 was corrected, and the INFORMAT of
VMACQAPM variable DMSTS was changed from $EBCDIC1. to &PD.1., and
Aug 30, 1998 the INPUT of DIIDLT was changed from &PD.6. to &PD.6.8,
as it caused the value of PCTIOPBY in dataset QAPMDIOP
to be 10**8 too large.
Thanks to Colin Bowen, Old Mutual, SOUTH AFRICA.
Change 16.180 The %BLDNTPDB macro for NTSMF processing is structurally
BLDNTPDB functional for building daily, weekly, monthly PDBs or
IMACNTSM for ad hoc analysis. Some reports exist, more to come!
TYPENTSM -By default, %BLDNTPDB now will read your raw NTSMF data,
TYPSNTSM (KEEPERS= or DROPERS= can be used if you don't want ALL),
Sep 5, 1998 then SORT what you kept to your PDB, then create the
PDB.NTINTRV at the raw data's interval, then create the
PDB.ASUMNTIN summary hourly interval dataset, then copy
your PDB datasets into the correct day-of-week library,
and then print and graph the daily reports. Additional
arguments RUNWEEK=YES or RUNMNTH=YES can be specified to
create the WEEKLY, MONTHLY and TREND libraries, and all
parameters are described in the BLDNTPDB member itself.
For example, if you wanted no reports or summary data,
but want only the four datasets PROCESS, PROCESSOR,
MEMORY, and LOGLDISK, you would use this invocation:
%BLDNTPDB(KEEPERS=NTPROC NTPROR NPMEM NTLDSK,
RUNNTINT=NO,ASUMDUR=NO,RPTDAY=NO);
to read those four objects and sort them into the PDB.
There are more reports to be added, and eventually the
logic will figure out when it is so a single invocation
can be used in every day's run, but that's a while away!
-Member TYPENTSM now only reads the NTSMF data and writes
to the default WORK location using the _WNTdddd macros;
TYPENTSM no longer sorts nor writes to the _LNTdddd macro
names, because new member TYPSNTMS (with the "S" instead
of the "E" to indicate "SORTs") performs the SORTs and
invokes NTINTRV to create PDB.NTINTRV.
If you were using TYPENTSM for your daily processing, you
should now use TYPSNTSM instead.
Member IMACNTSM no longer overrides the _L definitions.
Change 16.179 -SAS Version 7 incompatibility - long variable names.
VMXGSUM SAS Version 7 supports long variable names, and changed
Aug 28, 1998 the length of variable NAME (created by PROC CONTENTS)
Sep 8, 1998 from 8 to 32. MXG uses PROC CONTENTS in VMXGSUM and
expected 8-bytes; there is also a new SAS V7 warning when
different length variables are merged, and all of these
V7 "features" conspire to change the job condition code
from zero to four, which is just enough to cause your job
scheduling system to take notice of the change! The MXG
solution to this incompatibility between V6 and V7 is to
insert the statement LENGTH NAME $8 ; after the first
two statements DATA VAR1 (KEEP=NAME); in member VMXGSUM,
as that forces SAS to expect length 8 (and it is NOT my
intention to use long variable names in MXG, certainly
not in this millennium!).
-SAS Version 7 enhancement - OPEN=DEFER on SET statement.
A long-wanted Version 7 enhancement, OPEN=DEFER, lets you
read several datasets from different weekly PDBs using
only one tape drive:
SET TAPE1.JOBS TAPE2.JOBS TAPE3.JOBS OPEN=DEFER;
However, inside VMXGSUM, if you used this logic for
your input, and those datasets are on tape and KEEP=
logic was also used, VMXGSUM could have caused
unnecessary tape mounts, as it tries to figure out
what data is where, but VMXGSUM has no real awareness
of the individual datasets, and we are still examining
the best solution, but this revision now recognizes
the OPEN=DEFER parameter (and note it is not enclosed
in parenthesis, since it is a SET option and not a
dataset option. It might be that the best fix will be
to build the output keep list rather than the input
list when processing a tape, but that still is under
investigation. The caveat is that if you use the
OPEN=DEFER syntax with VMXGSUM, there will be multiple
mounts if the OS datasets are all multi-volume and the
default KEEPALL=NO is used.
With this change, MXG 16.04 or later is required for MXG
to execute under SAS Version 7. See MXG Newsletter, SAS
Notes for additional Version 7 Compatibility Issues.
-VMXGSUM now correctly figures out where the WORK option
points, so we can do housekeeping without erasing what
you just created. On an MVS system the value of the WORK
option returned by PROC SQL is the DDNAME/LIBREF "WORK",
but on Unix and PCs you get a full path name, for example
"!sasfolder\saswork" or "c:/sas/saswork" depending on the
platform. This change supports these idiosyncrasies.
"Line generated by the macro variable "TEMP01"
followed by E:\SASWORK.M was fixed by this change.
Change 16.178 MXG 16.03 only. Variables added with _PDBADD2/_PDBADD3
BUILD005 were not added to PDB.STEPS or PDB.JOBS because ACCOUNT
Aug 26, 1998 dataset was not output in the new architecture. In both
members, OUTPUT ACCOUNT; was added before _EDBJOBS;
Thanks to Dave Gibney, Washington State University, USA.
Change 16.177 Support for Microsoft Terminal Server 1.0 adds new data:
VMACNTSM for NT 3.51 and Service Pack 5A these were added:
Aug 28, 1998 Dataset SYSTEM:
ICABYTRT='TOTAL*ICA BYTES/SEC'
WINSTNAC='ACTIVE*WIN*STATIONS'
WINSTNIN='INACTIVE*WIN*STATIONS'
Dataset PROCESS:
IDLOGON ='ID*LOGON'
IDUSER ='ID*USER'
-Cosmetically, the LABEL statements in macro _CDENTSM were
consolidated and alphabetized so that they will control
the alphabetizing of the variables in each dataset.
Thanks to Bill Feeney, Hennepin County, USA.
Thanks to Leigh Ann Payne,Wachovia Operational Services, USA.
Change 16.176 MXG 16.03 only. VMXGINIT "TALO" comments were corrected
VMXGINIT and IMACKEEP spelling corrected. Labels added for the
BUIL3005 SPIN datasets.
BUILD005
Aug 21, 1998
Thanks to Lindsay Oxenham, IBM Global Services, AUSTRALIA.
Change 16.175 Support for Soft Audit's "Installed Products File" will
EXSFTPR read from filename XPPROD to create new MXG dataset
VMACSFTA SOFTPROD to track installed products.
VMXGINIT
Aug 19, 1998
Thanks to Normand Poitras, ISM, CANADA.
Change 16.174 MXG 16.03 only. The statement PUT ' DEBUG NDM .... ;
VMACNDM clearly should have been deleted.
Aug 15, 1998
Thanks to Chuck Hopf, MBNA, USA.
Change 16.173 MXG 16.03 only. Macro variable PSUNTIN was not defined.
VMXGINIT It must be added to the GLOBAL statement and then %LET to
Aug 15, 1998 DEFAULT.
Thanks to Greg Jackson, National Life of Vermont, USA.
Change 16.172 MXG 16.03 only. The LABEL='NTTUDP: ...' should have been
VMACNTSM 'NTUDP: ...', as the DDDDDD portion of the label is used
Aug 15, 1998 to drive the _S sort macros.
Thanks to Greg Jackson, National Life of Vermont, USA.
======Changes thru 16.171 were in MXG 16.03B4 dated Aug 11, 1998======
Change 16.171 Support for IMS Log processing for IMS 6.1. As stated in
ASMIMSL6 MXG Newsletter TWENTY-FIVE, this code is not officially
JCLIMSL6 supported. This code has not been fully tested, but the
VMACIMSA ASMIMSL6 program's output was read, and the VMACIMSA code
Aug 11, 1998 changes to the 07 and 08 record were lifted from VMACIMS.
I have high hopes this code will work without problem,
but plan validation against IMF records in September,
as I ran out of time to squeeze this code in as it is!
The logic in ASMIMSL6 stores the MSC time for ARRTIME
when there is an MSC segment, which I think is a change
from ASMIMSL5 - does it make any difference in your data?
Thanks to Dario Franceschi, Nordbanken, SWEDEN.
Thanks to Sal Fazio, IBM Global Services, USA.
Change 16.170 Support for the NCR Teradata DBS performance data. This
ADOCTDTA user contribution works, and even has documentation in
JCLTDTA ADOCTDTA, and the JCL will need to be tailored. This
TYPETDTA was added to MXG 16.03B4 at the last minute and has not
Aug 11, 1998 yet been added to the MXG QA stream.
Nov 12, 1998 Nov 18: Members JCLTDTA and TYPETDTA actually added!
Thanks to Richard S. Ralston, Whirlpool Corporation, USA.
Change 16.169 Member ASUMTALO did not copy SPIN.SPINTALO into the PDB
ASUMTALO library for backup, but it should have, so I added:
Aug 11, 1998 PROC COPY IN=SPIN OUT=&PDBMXG;SELECT SPINTALO;
BUILDPDB has backed-up its SPIN datasets into the PDB
since Version 8, and all MXG components that use the
SPIN library will now also backup their SPIN datasets.
Why backup the SPIN library? Because if your daily PDB
job fails, you can recover by copying all of the SPINxxxx
datasets from your last good PDB library into your //SPIN
library: PROC COPY IN=PDB OUT=SPIN; SELECT SPIN:; and
then pick up processing with the SMF data from the day
after the last good PDB was built!
Thanks to Kevin Marsh, AT&T Solutions EMEA, ENGLAND.
Thanks to David Ehresman, University of Louisville, USA.
Change 16.168 Variable SMF88RAT was described in Change 13.156, but was
VMAC88 not created in dataset TYPE88 until this change.
Aug 11, 1998
Thanks to Martin Peck, iT-Austria, AUSTRIA.
Change 16.167 Minor. Cleaned up VMACUNIK so it will execute under MVS,
VMACUNIK just for MXG test stream. The real member for UNIKIX on
JCLQAJOB MVS is unchanged, VMACUNIA.
Aug 8, 1998
Change 16.166 Variables SMSHWMDS 'HWM SIZE' and SMSHWMDT 'HWM TOTAL'
ANALCISH were reversed in their INPUT statement; DT is first, then
VMAC110 DS is input. ANALCISH reports were correct, because it
Aug 7, 1998 used the wrong names, so now it too must be changed to
use DS for Peak DSA Size and DT for Peak DSA Total.
Thanks to Andrew Adams, Australian Taxation Office, AUSTRALIA.
Thanks to Craig Magill, Australian Taxation Office, AUSTRALIA.
Change 16.165 Type 79 subtype 15 (IRLM Long Lock) records contain only
VMAC79 two triplets, and IBM's documentation makes no note that
Aug 7, 1998 there are only two, and since all other subtypes had 3,
MXG expected three. Now, the number of triplets is
tested and only two are input when there are only two!
Thanks to Kenneth C. Jones, Boeing, USA.
Change 16.164 MXG's MXGTMNT monitor misses too-fast VTS tape mounts.
ASMTAPES Scratch Tape Mounts to VTS (Virtual Tape System) can be
Aug 11, 1998 satisfied in much less than the 2-second sampling rate.
Tests at 1/2 (500ms) and 1/10 (100ms) will be made, but
the internal VTS log shows the Mount and Ready times can
be in the same .01 second. It might be that the software
delay can be captured with the 100ms sampling even when
the VTS itself thinks it took less time, but it may also
require a significant change to the architecture of the
MXG Tape Mount monitor - we may have to capture the Mount
message as an event to capture these too-fast mounts!
There was no change made by this change, but this text
will be revised when the tests have been completed.
VTS is a pretty slick technology, even if it causes me
design problems in the tape mount monitor. In the day
in question, MXG missed about 300 mounts out of 1200.
Note: Member ASUMTAPE was added after this change, and
corrects the need to reduce the ASMTAPE interval time.
Change 16.163 Variables JESNR, INITTIME, and READTIME were INPUT but
VMACTMNT not kept in TYPETMNT dataset, so Mount and Step records
Aug 6, 1998 can be combined.
Change 16.162 This analysis is not complete, but the program matches
ANALVTS SMF type 30 DD segment for tape allocations, the MXGTMNT
Aug 6, 1998 Tape Allocation SMF record, the MXGTMNT Tape Mount SMF
record, and the type 21 Tape Dismount record to construct
a complete picture of each tape allocation and mount.
The program needs some cleanup to deal with long running
tasks and steps that span the time interval in the SMF
file (start-before-end-in and start-in-end-after), but
for events which all occur within the SMF file, it's
pretty accurate. If you are interested, run the program
and give me a call - there are lots of ways these tape
events can be analyzed, now that we have total duration
of allocation and mount and usage and bytes read/written!
The ultimate name may change; this program was used to
verify that MXGTMNT was missing Virtual Tape System tape
mounts - see Change 16.163 and 16.165.
Thanks to Chuck Olsen, Alltel, USA.
Thanks to Ken Lamonda, Alltel, USA.
Change 16.161 Variables ALOCTIME and LOADTIME were added to the KEEP
VMAC30 list for dataset TYPE30_D (a/k/a PDB.DDSTATS) to support
Aug 6, 1998 the ANALVTS utility.
Change 16.160 Support for Landmark's SQL/CAPTURE type 'D6' record adds
EXTMDD6 three new datasets:
EXTMDD6B TMDBD6 - Base segment stats, CPU, counters, etc.
EXTMDD6S TMDBD6B - Per Buffer Pool counts
VMACTMDB TMDBD6S - SQL Text
Aug 4, 1998 Variable D6RECNR will be common for all observations in
the Buffer Pool and SQL Text datasets for each record and
is the merge variable to use to match observations.
This was challenging: the SQL text field has either text
in ASCII or in EBCDIC but there is no flag. I now test
the first character of the first segment for EBCDIC or
ASCII, and use that mode to decode the rest of the 100-
byte segments of SQL text. Initially, I tested the first
character of each 100-byte segment, until I hit a segment
starting with '6D'x that is an ASCII "m" or an underscore
in EBCDIC. Using the start of the SQL text will decode
correctly since the start text is real text characters.
(And the '6D'x was actually an EBCDIC underscore!).
Thanks to Robin Tremblay, Regie des Rentes du Quebec, CANADA.
Change 16.159 The calls for OUTCODE and OUTCODE1 exits were moved to be
VMXGSUM after the calculation of DURATM so that its value would
Jul 31, 1998 be available in those exits.
Change 16.158 A new analysis of SMF Write Rates (MEGABYTES at 1/10/100
USMFRATE second intervals) reads your SMF file and produces print
Jul 31, 1998 reports and an export dataset to be sent if needed. If
you have had SMF Buffer shortages, this analysis will let
you know how much SMF data is being produced and how well
it is being handled by your DASD and SMF Buffering. Read
the comments, run the program, and send the listing. An
MXG Technical Article on this subject will follow soon.
Change 16.157 MXG CONFIG member's value of VMCTLISA=40K can cause a 0C4
CONFIG ABEND in function VMZGMAE that goes away if VMCTLISA=60K,
Jul 29, 1998 and the SAS default value in 6.09 is now VMCTLISA=160K!
That old value for VMCTLISA as well as old values for the
VMPAISA VMPAOSA VMPBISA VMPBOSA PSUM SORT31PL PROCLEAVE
and SYSLEAVE options were set years ago for SAS 6.06, but
they are now deleted from member CONFIG so that MXG will
no longer override those SAS memory options.
Thanks to Lee West, Direct Line, ENGLAND.
Change 16.156 Variable R723CQDT in TYPE72GO was misspelled R723CDQT.
VMAC7072 Now, both variable names exist to protect for past usage
Jul 29, 1998 but R723CDQT is the correct spelling.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 16.155 Support for BGS I/O Monitor Version 5.1.0 (COMPATIBLE)
VMACBGSI added new triplet to support of Goal Mode changes that
Jul 27, 1998 creates new B1MONSRV dataset (I/O by Device by SRVCLASS),
and the new version supports the year 2000.
Change 16.154 ML-17 of MXGTMNT Tape Mount and Alocation Monitor adds:
ASMTAPES - SMF interval support; MXGTMNT now listens for ENF 37
Jul 27, 1998 and automatically synchronizes to your global interval
- Initialization messages are issued when MXGTMNT is run
as a batch job instead of a started task.
- Error recovery recursion was improved.
- USINGs were cleaned up to prevent HLASM warning message
and eliminate CC=4 due to USINGs.
Note that ML-16 was never generally distributed.
Change 16.153 The CICS GMT offset value, MCTMNTAD, is only four bytes,
VMAC110 causing it to be truncated by as much as 1.04 seconds.
Jul 27, 1998 Since MCTMNTAD is added to STRTTIME/ENDTIME to convert to
the local time-of-day, they were also slightly off. But
now I see there is an 8-byte GMT offset value MCTMNDTO
that is exact and eliminates the truncation, so now the
variable MCTMNTAD will be set equal to MCTMNDTO as long
as the two values are within two seconds (to protect for
a zero value in DTO?), by the addition of the line:
IF ABS(MCTMNTAD-MCTMNDTO) LT 2 THEN MCTMNTAD=MCTMNDTO;
immediately after the MCTMNTAD=1.048576*MCTMNTAD line.
(Back in MXG 14.14 I had tried to make MCTMNTAD exact
with MCTMNTAD=3600*FLOOR((MCTMNTAD+900)/3600) logic, but
but I had removed that approximation by MXG 15.15, and it
was the comparison between MXG versions that provided
this opportunity to use the exact GMT offset value.)
Thanks to Andrea C. Schiro, Duke Energy Company, USA.
Change 16.152 These archaic members that were needed only in the past
VMAC110M are deleted to save space and avoid wasting your time
VMAC110S reading their comments to find out what they were! The
VMACRRTM VMAC110's were for SAS 5.18, VMACRRTM became VMACROSC,
VMACZRB VMACTMS became VMACTMS5, and VMACZRB became VMACRMFV.
Jul 26, 1998
Change 16.151 Macro _CMFDATA was still defined in these members, but it
IMACCMF has not been referenced in MXG since Change 7.119, when
VMACCMF Boole added bits by which variable PRODUCT could be set
Jul 25, 1998 to 'CMF...' instead of 'RMF'. The macro definition and
its now-incorrect comments have been deleted.
Thanks to Dan Worsham, Ohio Bureau of Worker's Compensation, USA.
Change 16.150 Variable TYPETASK='A ' for both ASCH and OMVS address
VMAC30 spaces, but in those SMF records that contain the SUBSYS
VMAC32 field, it contains either ASCH or OMVS, so it makes sense
VMAC42 to set TYPETASK=SUBSYS when TYPETASK starts with an 'A'.
VMAC91 There are other SMF records that contain TYPETASK that do
Jul 23, 1998 not contain the SUBSYS field: VMAC's 434, 6, 26J2, 26J3,
BETA, CTLD, IPAC, NNAV, PROS, SFTA, TMNT, X37, XPSM, so
they will still have TYPETASK='A '; While both type 6
26 have a variable SUBSYS, it is not the MVS SUBSYS field
but the PDB.JOBS/STEPS/PRINT datasets will now have the
correct TYPETASK value, from the type 30 records.
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Change 16.149 The SHORT ABAR message still existed after Change 16.025
VMACHSM because an INPUT @15+OFFSMF @; is also needed after the
Jul 20, 1998 ELSE IF 15 LE FSRTYPE LE 16 THEN DO; statement.
Thanks to Alan Freed, ADP, USA.
Change 16.148 Dataset DB2STATR contained repeated outputs of the first
VMACDB2 QLST segment because CHANGE 14.195 was dropped somewhere
Jul 16, 1998 after MXG 14.14 and was not in MXG 15.15. Insert the
statement OFFQLST=OFFQLST+LENQLST; immediately before the
END; /* END TRACE SECTION FOR TYPE 100 SUBTYPE 0*/ as was
described in CHANGE 14.195.
Thanks to Warren E. Waid, JC Penny, USA.
======Changes thru 16.147 were in MXG 16.03B3 dated Jul 15, 1998======
Change 16.147 NETSPY 'N' records from old release 4.4 were dropped by
VMACNSPY MXG between MXG 14.14 and MXG 15.15, because I did not
Jul 9, 1998 think anyone was still using 4.4. The NSPYREC='N' logic
had been changed to use only NSPNRECI in recognizing the
subsubtype, but back with 4.4, NSPNRECI is always zero,
so I have had to put back the test for NCPELTYP and
NSPNSUBT to support these old records.
Thanks to Kevin Marsh, AT&T Solutions EMEA, ENGLAND.
Change 16.146 -VMXGSUM syntax for the "DATETIME" variable was kludgy;
VMXGSUM you had to say DATETIME=xxxxTIME, and then use DATETIME
Jul 9, 1998 in the SUMBY= list instead of the real xxxxTIME variable
name. This was needed so that the variable DATETIME
could carry the modified datetime values generated by
VMXGDUR when you specified INTERVAL= and DATETIME= to
create a new interval value. And, in order to retain
the original labels for the variable used in the
datetime calculations, you also had to use an ID
statement and then manually drop the variable DATETIME.
This change that logic; you no longer need to code the
name "DATETIME" in the SUMBY or ID arguments. You only
need to specify the argument DATETIME=xxxxTIME, to tell
VMXGSUM what variable to use as the datetimestamp value,
and now you can use the real xxxxTIME variable name in
the SUMBY= argument. This change is backward compatible
and will work properly if DATETIME is still used in the
SUMBY= list, but using the real variable name is better!
-VMXGSUM arguments TEMP01=,TEMP02=, and TEMP03= will still
be used to send intermediate WORK files to those DDnames
(for performance or space considerations), when they are
coded on the VMXGSUM invocation, but now you can redirect
the intermediate files externally, by %LETting the new
MXGTMP1, MXGTMP2, or MXGTMP3 global macro variables
to the desired DDname, before the include of the program
that invokes VMXGSUM. For example,
%LET MXGTMP1 = TEMPDD1 ;
%LET MXGTMP2 = TEMPDD2 ;
%INCLUDE SOURCLIB(ASUMDB2A);
Change 16.145 Support for APAR OW31281 adds HSM statistics for RECALL
FORMATS RECOVER, and additional fields to the DSR and FSR SMF
VMACHSM records. New DSR variables DSRNRCL DSRNRCV in dataset
Jul 7, 1998 HSMDSRST measure the number of times when RECALL/RECOVER
was satisfied by a tape that was already mounted. New
FSR variables FSRDEVCL FSRDEVTY FSRDSMNT FSROFF83
FSRRECRE FSRSCNAM in dataset HSMFSRBO provide device
class and device type, the number of tape mounts that
were avoided thru recall/recover, flags, number of tries
to recall, and the Storage Class Name.
The APAR also provided new values 19 and 20 for the
FSRTYPE field that were added to format MGHSMFU, but
values 15-18 have been skipped or are undocumented!
Thanks to Dave Cogar, U.S. Department of Transportation, USA.
Change 16.144 Significant enhancement uses Change 16.134 architecture
BLDNTPDB to build daily/weekly/monthly/week-to-date/month-to-date
Jul 7, 1998 PDBs for NTSMF data, with some simple reports implemented
and more to come. This member is documented in ADOCNTSM.
Change 16.143 One GRAPH of Tape Mounts had seconds instead of hours on
GRAFTMNT the x-axis, and GRAFTMNT did not accept SASGRAPH=YES if
Jul 7, 1998 specified (but using the default SASGRAPH=, did work).
Thanks to Billy Westland, Litton Enterprise Solutions, Inc.
Change 16.142 This utility, used only in JCLTEST6 to get 10 SMF records
VMXGGETM of each type and subtype, is now expanded to expect 512
Jul 7, 1998 subtypes, as DB2 type 102 records exceeded 255 subtypes.
Thanks to Chuck Hopf, MBNA, USA.
Change 16.141 The DURATM calculation in ASUMCACH was revised. Because
ASUMCACH the TYPE74 data can contain data from many systems, the
Jul 7, 1998 DURATM could have been inflated by the number of systems
that shared that volume with activity. Since you must
chose a single source system for the TYPE74CA dataset,
(in EXTY74CA), its DURATM is now used in ASUMCACH.
Thanks to Chuck Hopf, MBNA, USA.
Change 16.140 The weekly interleave of ASUMDB2B in WEEKBLDT failed with
WEEKBLDT wrong sort order. The correct sort variables are:
Jul 6, 1998 SYSTEM QWHSSSID QWHCPLAN QWHCAID QWHSLOCN
QWHCCV QLACLOCN QWHCCN QBACPID QWACBSC
SHIFT
Thanks to Scott Snyder, First Bank, USA.
Change 16.139 Invalid CMF User "240" SMF record has 20 Cache Statistics
VMACCMF segments (CMF27CCN=20) but only 19 Cache Device segments
VMACCMF (CMF27DIN=19); the device address in the 1st CCN segment
Jul 6, 1998 does not have a corresponding DIN segment. This is a CMF
record error that caused INPUT STATEMENT EXCEEDED error,
but MXG now compares device addresses in the two segments
instead of assuming they matched as documented, and MXG
circumvents their error. Boole fixes BMP6301 (4.3.0) and
BPM6303 (5.2.2) exist to correct the record, now that I
have circumvented their error!
Thanks to Ken Williams, Sun Life of Canada, ENGLAND.
Change 16.138 Landmark CICS Version 2 native records protection added.
VMACTMO2 A message is now printed if you try to read compressed
Jul 1, 1998 records without having installed the EXITMON6 decompress
exit.
Thanks to Glenn Delvecchio, Stelco Inc, CANADA.
Change 16.137 NOTE: INVALID ARGUMENT TO FUNCTION SQRT apparently occurs
ASUMCICS due to very small differences (9th digit) in calculating
TRND72 the Standard Deviation as SQRT(A-B) when N=1. A=B to 14
Jun 29, 1998 14 places with PROC PRINT, but A-B is different in 9th
place! Since the real STD is zero in these cases, the
logic now tests A-B for positive before SQRT() and sets
STD=0 if A-B is not GT zero.
Thanks to Jon Whitcomb, Great Lakes Higher Education Council, USA.
Change 16.136 DFSMS 1.4.0 added (compatibly) new variables WFSCPUTM and
VMACHSM WFSRACCT in HSMWWFSR dataset, so you can measure CPU time
Jun 26, 1998 used by HSM for ABARS ABACKUP/RECOVERY processing. If
you can figure out how to populate that WFSRACCT account
field, it might be useful too!
Thanks to Michael E. Friske, Fidelity Investments, USA.
Change 16.135 VTS variables SMF94VBA and SMF94VLA were mis-documented
VMAC94 by IBM. They are not the "Midnight" values of data bytes
Jun 26, 1998 and virtual volumes, but are the "End of Interval" values
so their label was corrected.
Thanks to Joseph G. Ogurchak, Westfield Companies, USA.
Change 16.134 -The new &MACKEEP and IMACKEEP MXG architecture is here!
BUILDPDB "MACKEEP" Architecture of MXG-built SAS "Datasets"
DIFFXXXX
DOCMXG Everything about the creation of an MXG dataset is now
fully externalized, and all dataset tailoring can now be
IMACXXXX EDITed into a single member, IMACKEEP (instead of using
TYPEXXXX each product's IMAC), or dataset tailoring can be done
TYPSXXXX "instream" using %LET MACKEEP= syntax, with no EDIT!
VMACXXXX
VMACXXXX All MXG datasets can be referenced using the new syntax
VMXGDEL &Pdddddd.DATASET and you can use %LET Pdddddd= MYDD;
VMXGINIT to change the destination to which a dataset is written
VMXGINV or the library from which it is to be read from.
VMXGLBIN
VMXGSUM Member DOCMXG contains the following description, and
Jul 4, 1998 additional discussion of the new architecture, and will
Sep 3, 1998 be the primary documentation of MXG syntax and design.
"MACKEEP" Architecture of MXG-built SAS "Datasets"
Fifth Draft Sep 3, 1998
"Product Suffix"
The xxxx suffix of the TYPExxxx/VMACxxxx/IMACxxxx/
ASUMxxxx/GRAFxxxx/ANALxxxx members for a "product":
Product xxxx Datasets
SMF Type 0 0 TYPE0
SMF Type 30 30 TYPE30_1,TYPE30_4,..
SMF Type 74 74 TYPE74,TYPE74CA,TYPE74CF,..
SMF 110 SMF 110 CICSTRAN,CICINTRV,CICFCR,..
NTSMF NTSM PROCESS,NTINTRV,PROCESOR,..
An MXG "Product" is defined by its VMACxxxx member,
which defines all of the macros for product xxxx, and
defines all datasets MXG builds from that product.
You run %INCLUDE SOURCLIB(TYPExxxx); syntax to read a
product's records and create all MXG SAS datasets in
the //WORK file. You run %INCLUDE SOURCLIB(TYPSxxxx);
to read the records and create SORTED output, normally
into the //PDB file. TYPSxxxx instead of TYPExxxx is
now the recommended program to use for a product.
IMACxxxx product members are now used only to override
the macros that you want to change. Definitions of
the Product Macros (_IDxxxx, _Nxxxx, and _Sxxxx) and
Dataset Macros (_Ldddddd, _W, _K, _E, _B, _Sdddddd)
were moved from the IMACxxxx into the VMACxxxx member.
Product IMACxxxx members are now only comments listing
the product's xxxx and its dddddd and DATASET names.
Even better and also new, all tailoring changes can
now be EDITed into only one place, member IMACKEEP,
instead of having to EDIT a separate IMACxxxx member
for each product. (Your old IMACxxxx's will still be
honored, but IMACKEEP is called after the IMACxxxx, so
existing IMACxxxx changes can still be overridden.
And still even better and also new, especially if you
don't like having to EDIT and SAVE a member to tailor,
you can now do it "on the fly", in your SYSIN stream,
by %LETting the new "&MACKEEP" macro to change any of
the dataset macros, including the Exit Member code to
select which observations are written!
And best of all, if you only want to change the DDNAME
to which a sorted DATASET is written, there is a new
&Pdddddd macro for each DATASET that you can %LET in
your SYSIN with this syntax:
%LET PTY74CA=TAPE74CA ;
%INCLUDE SOURCLIB(BUILDPDB);
to create your normal PDB, except that the TYPE74CA
dataset would be written to TAPE74CA.TYPE74CA instead
of being written to the default of PDB.TYPE74CA.
"DATASET"
SAS "Table Name" or SAS DATASET NAME, 8-characters,
are defined in the dataset's _L macro. Examples are
TYPE0, TYPE30_1, TYPE74CA, CICSTRAN, PROCESS, NTINTRV.
"Dataset Macros"
_L, _W, _K, _E, _B, _S, one set for each DATASET, are
defined in the VMACxxxx member for the product:
_L - "&P OUTPUT/SORT Destination LIBREF" macro
_W - "Work Library Dataset Name" macro
_K - "Keep/DROP Dataset Tailoring" macro
_E - "Dataset Exit" macro
_B - "BY List of Variables" macro
_S - "Dataset PROC Sort" macro
They can be overridden in &MACKEEP/IMACKEEP/IMACxxxx.
"Dataset Suffix"
The six character "dddddd" dataset suffix is a unique
string for each dataset. It is used in the old-style
_Ldddddd/_Wdddddd/_Kdddddd/_Edddddd/_Bdddddd/_Sdddddd
"dataset macros", is the suffix of the EXdddddd exit
member name, and is the suffix of the new &Pdddddd.
The dddddd values are encoded. For datasets starting
with TYPE (TYPE0, TYPE70PR, TYPE74CA) the dddddd is
TYaaaa (TY0, TY70PR, TY74CA). Other datasets encode
dddddd= yyzzzz/yyyzzz/yyyyzzz value with y= product
and z= dataset. CICS 110's have dddddd=CICTRN/CICINT
for CICSTRAN/CICINTRV datasets where yyy=CIC.
Similarly, NTSMF encodes dddddd as NTzzzz, so NTBROW
and NTPROR are dddddd for BROWSER and PROCESOR.
The dddddd value of each MXG dataset is defined in the
VMACxxxx members, but the IMACxxxx for the product is
the documentation of the dddddd and DATASET values.
"&PDB/&P macros"
The seven-character Pdddddd macro variable name, one
for each DATASET, defines the DDNAME/LIBREF to which
that sorted DATASET will be written. First, MXG
writes each DATASET to the //WORK file, using the
old-style substitution macro _Wdddddd:
MACRO _Wdddddd DATASET %
MXG then SORTs from the _Wdddddd to the _Ldddddd macro
that contains the new-style &Pdddddd macro variable:
MACRO _Ldddddd &Pdddddd..DATASET %
The default Pdddddd value, usually "PDB", is set by
VMXGINIT at MXG initialization, so now you can use a
%LET statement in you program to change the output
destination DDname for a dataset:
//SYSIN DD *
%LET PTY74CA = MYDD74CA ;
%INCLUDE SOURCLIB(TYPE74);
and you no longer have to EDIT into an IMAC member.
Most sites should never need to change much else!
(Note that while references use &Pdddddd syntax, the
ampersand is not used in the %LET statement.)
"Product Macros"
_IDxxxx, _Nxxxx, _Sxxxx, _VARxxxx, _CDExxxx members
are defined in the VMACxxxx member for the product:
_IDxxxx - "Record ID macro for user SMF records"
_Nxxxx - "_NULL_ all datasets in this product"
_Sxxxx - "SORT all datasets in this product"
_VARxxxx - "Variables/Datasets structure macro"
_CDExxxx - "Code to Decode structure macro"
The _VARxxxx and _CDExxxx macros should NEVER be
changed, as they are the heart and soul of MXG code;
all tailoring macros exist precisely so that you can
change MXG without changing the _VAR or _CDE macros!
The _IDxxxx macro sets the record number for user SMF
records, and must be changed in IMACxxxx/IMACKEEP or
with MACKEEP= logic to read product xxxx records.
The new _Sxxxx and _Nxxxx macros make tailoring easy.
The _S Sorts all datasets, the _N Nulls all datasets:
MACRO _S74 MACRO _N74
_STY74 MACRO _WTY74 _NULL_ %%
_STY74CA MACRO _WTY74CA _NULL_ %%
... ...
% %
If you %INCLUDE SOURCLIB(TYPS74) or run BUILDPDB, all
eleven TYPE74zz datasets are created and sorted. Now,
if you only want the TYPE74 dataset, and you want to
write it to the "TY74TAPE" DD name (perhaps, a tape?):
//SYSIN DD *
%LET PTY74=TY74TAPE;
%LET MACKEEP=
_N74
MACRO _WTY74 TYPE74 %
MACRO _S74 _STY74 %
;
%INCLUDE SOURCLIB(TYPS74);
and only dataset TY74TAPE.TYPE74 would be created, in
the WORK file, then sorted into the "PDB" default, and
then WORK.TYPE74 is automatically deleted.
The %LET PTY74 sets the Pdddddd macro variable value
with the output LIBREF/DDNAME of the desired dataset.
In the %LET MACKEEP=, the _N74 invocation changes the
default _Wdddddd dataset names to _NULL_, and then the
MACRO _WTY74 override "un-_NULL_'s" that dataset so
TYPE74 will be created, and the MACRO _S74 definition
contains only the _Sdddddd sort macro for the TYPE74
dataset that you want created! It's that simple.
"Old-Style Macro"
All MXG Old-Style macros start with an underscore.
The definition MACRO _oldstyl whatever %
will have "whatever" substituted when SAS sees the
string "_oldstyl" at compile time. "Whatever" can
contain characters and symbols to be used as parts of
SAS statements, or can be entire blocks of SAS code.
If "whatever" contains a percent-sign it must be a
double-percent in the MACRO definition. As SAS uses
the last MACRO definition encountered, any old-style
macro can be redefined with &MACKEEP, or in IMACKEEP.
"Macro Variable"
SAS Macro Variables are also used to substitute stored
text, but with different syntax. They start with &
when they are referenced, but that ampersand is not
used when defined with %LET or CALL SYMPUT statements:
%LET PDByyyy = value ;
or inside a DATA step, you can use SYMPUT:
CALL SYMPUT('Pdddddd','value');
For MXG's &Pdddddd macros, "value" is a LIBREF/DDNAME
for the output DATASET, which can always be %LET.
But for &MACKEEP macro, "value" can be anything from
the (most likely) redefinition of an old-style macro:
%LET MACKEEP = MACRO _IDHSMDS = 240 % ;
to the (less likely) lines of SAS statements to create
new variables, select observations to be output, etc.,
(as when you tailor a "Dataset Exit" _Edddddd macro).
If the text does not contain a semicolon, the simple
syntax of %LET MACKEEP = value ; is used,
even when there are % or %% in the value text.
But if MACKEEP= value contains any semicolons, then
syntax of %LET MACKEEP= %QUOTE( value ) ;
must be used:
And, if the value contains single-percent signs,
they must be doubled inside the %QUOTE function.
And, in a new quirk of the SAS macro language,
if the text contains double-percent-signs (as in
%%INCLUDE in the _Edddddd Dataset Exit macros),
those double-precents must be triple-percents!!
CICSTRAN Example.
You want to read type 110 CICS records but only create
CICSTRAN observations for a specific APPLID, and you
want to write them (unsorted) to the CICSTRAN DDNAME.
The product IMACxxxx member documents which dddddd to
use for which dataset, but in the expected IMAC110
member, it admits that the IMACxxxx for SMF type 110
is the inconsistently-named IMACCICS member, and there
you find out that the dddddd value for the CICSTRAN
dataset is "CICTRN". Then you can use:
// EXEC MXGSAS
//SMF DD DSN=smf.data,DISP=SHR
//CICSTRAN DD DSN=output,DISP=(,CATLG)
//SYSIN DD *
%LET MACKEEP=
%QUOTE(
_N110
MACRO _WCICTRN CICSTRAN.CICSTRAN %
MACRO _ECICTRN
IF APPLID='CICP' AND TRANNAME='XYZ1' THEN DO;
%%%INCLUDE SOURCLIB(EXCICTRN)
END;
%
)
;
%INCLUDE SOURCLIB(TYPE110);
The _N110 invocation nulls out all type 110 datasets,
so we then re-instate MACRO _WCICTRN so that it's data
is created, and by prefixing the dataset name CICSTRAN
with "CICSTRAN.", that dataset will be written to the
//CICSTRAN DD instead of //WORK, so its "full" name is
CICSTRAN.CICSTRAN.
The %QUOTE ( ) syntax is used to add a DO group around
the %%%INCLUDE, and any number of SAS statements could
be used inside the _ECICTRN macro in this better way:
Note that percent-signs were increased by one due
to the QUOTE ( ). Also, don't use "DELETE" logic
in your "Dataset Exit" logic, because records can
contain multiple transaction segments, and the
DELETE would prevent MXG from looking at the rest
of the transactions in the record. Instead, always
cause an OUTPUT of observations you want and skip
past the ones you don't want to output.
The preceding example was revised April, 1999.
The following text describes additional changes that were
made in this redesign, and that is followed by discussion
of possible compatibility issues with past tailoring.
-VMXGINV will "Inventory" a DDNAME with PROC CONTENTS and
will extract the "dddddd" dataset suffix from the LABEL
of every dataset in that library, so we can know which
datasets exist, with their "dddddd" values, so we can
auto-drive additional processing.
-VMXGLBIN will initialize a SAS data library to match the
contents of an existing library, but all datasets in the
new library will have zero observations. This is used in
the first-time logic in WEEKLY/MONTHLY processing.
-VMXGDEL will delete a _W dataset by its dddddd token if
the library pointed to by the _Wdddddd value is NOT the
same as the _Ldddddd (output) library and dataset. This
is used after the PROC SORT to delete its input, but not
when you sort the output back into the input dataset!
-BUILDPDB/BUILDPD3 phases are externalized with new macros
_DIFFDB2, _INTRMF, _INTCICS, and _BLD005 that can be set
to blank to bypass processing. The JOBS/STEPS/PRINT
logic was externalized to BUILD005/BUIL3005, and all of
the _PDB macros are defined in BUILD005/BUIL3005 rather
than in the BUILDPDB/BUILDPD3/BUILD001 members.
-MULTIDD logic in old BUIL3005 was corrected (BUILDPD3 had
been correct all along, and now BUILDPD3 calls BUIL3005).
-New formats $MGDDDDD and $MGDDDSN map dddddd to dataset
and dataset to dddddd values.
-New macro variables MXGTMP1 thru MXGTMP5 are GLOBALed,
defined in VMXGINIT, and default to WORK. Their names
&MXGTMP1, &MXGTMP2, etc., are the "Standard" macro names
for temporary work space that you can set globally. You
used to have to code TEMP01= on the %VMXGSUM invocation,
and VMXGSUM still honors TEMP01 if coded, but now you can
use %LET MXGTMP1 = MYTEMPDD ; and VMXGSUM will use that
destination instead of the //WORK default.
-LIMITATION: If you use %LET MACKEEP= logic to redefine
old-style macros, you can't use %LET MACKEEP= again in
the same SAS execution, unless you reset the old-style
macro to itself before the second %LET MACKEEP= logic:
%LET MACKEEP= MACRO _WTY0 FIRSTDSN % ;
%INCLUDE SOURCLIB(TYPE0);RUN;
MACRO _WTY0 _WTY0 %
%LET MACKEEP= MACRO _WTY0 SECNDDSN % :
%INCLUDE SOURCLIB(TYPE0);RUN;
If you did not have that MACRO _WTY0 _WTY0 % reset, the
second %LET would have used "FIRSTDSN" for the _WTY0 and
you would have %LET MACKEEP= MACRO FIRSTDSN SECNDDSN %;
and the second MACKEEP would not have changed _WTY0!
COMPATIBILITY NOTES:
-If you used a %INC SOURCLIB(TYPExxxx); program and you
also used the IMACxxxx to change the _Ldddddd macro, the
old version wrote to your modified _L destination, while
the new version writes to the _W (work) destination.
Circumvention/workaround/the way to do it now include:
a. Use: %LET MACKEEP= MACRO _Wdddddd _Ldddddd % ;
to use your _L definition from your IMAC for the _W
destination of the unsorted dataset.
b. Change your IMACxxxx to override _W instead of _L.
c. Use new TYPSxxxx instead of TYPExxxx, to write to _W
first and then SORT to your _L destination. Since the
_S SORTS eliminate duplicate records, it is now MXG's
recommendation to use TYPSxxxx instead of TYPExxxx.
d. See notes in member INSTALL, with examples of errors.
Status in MXG 16.04:
-Except for five products, (CRAY,FRYE,RSxx,SNIF,VMXP), all
VMACxxxx members and TYPExxxx members have been revised.
-Some _Sdddddd "sort" macros still have a DATA step rather
then the PROC SORT because I don't know the unique set of
variables that will eliminate duplicates for that data.
-IMACs now contain only comments that define the dddddd
and DATASET names.
-No Beta site has had any real problems with this change!
Change 16.133 -The summarization of NETWSEGM into NTINTRV was wrong if
NTINTRV there was more than one network segment instance. Now
VMACNTSM the rate variables are summed and the maximum percent of
Jun 24, 1998 any segment is added to NTINTRV dataset as NETSxxxx.
-The number of Physical Disks is counted and added into
NTINTRV as variable NRPDISK.
-The instance field NETWSEGM was missing in the _BNTNETS
definition in VMACNTSM.
Change 16.132 Revised utility that reconstructs VB or VBS data on MVS
UDEBLOCK that was uploaded from a PC file. This utility creates
Jun 24, 1998 one record per block, so if you intend to re-read the
output file multiple times, it would be worthwhile to
reblock the output file by copying with IEBGENER or SAS.
The earlier version did not always work correctly.
Change 16.131 On UNIX, VMXGSUM fails because of UNIX forward slashes.
VMXGSUM The failure produces these messages:
Jun 22, 1998 ERROR: A character operand was found in the %EVAL....
ERROR: The macro VMXGSUM will stop executing.
The failing statement is part of MXG housekeeping:
%IF &SASSWORK NE WORK %THEN ....
where &SASSWORK is a macro variable filled in by SAS
from SASHELP.VOPTION table that under MVS contains the
value of the WORK= option, which is a DDNAME or libref.
If your WORK= option is 'WORK' we do housekeeping and
delete work files, but if your WORK= is anything else,
then we don't delete anything in your library.
This statement fails under UNIX, because under UNIX, the
&SASSWORK value does not contain a libref, but instead
has a full UNIX directory pathname, with forward slashes
that here are interpreted by the SAS %Macro Compiler as
divide-by signs, which is invalid in this context, so
VMXGSUM fails to compile under UNIX!
It might be argued that the error is in the SAS macro
compiler, but the real error was in not knowing that what
is returned by SAS in &SASSWORK depends on the platform
on which MXG is executing. For PC SAS, $SASSWORK also
contains a pathname, but since PC pathnames use reverse
slashes, so SAS had no problems in compiling under UNIX.
Although the underlying logic will never be satisfied as
written for PC or UNIX SAS, adding the %QUOTE() function
around the &SASSWORK string tells SAS to ignore those
strange characters, so this change:
IF %QUOTE(&SASSWORK) NE WORK %THEN ....
allows VMXGSUM to execute anywhere!
I did test most of MXG in 1995 under UNIX, but that was
with an earlier VMXGSUM. I do not run MXG QA stream on
UNIX, as I do not have nor intend to have a UNIX system,
and believe that testing under PC SAS, plus many happy
users running MXG under UNIX with no errors, is enough.
This is the first and hopefully the last incompatibility
between ASCII SAS platforms that has had any impact on
MXG, and it's because no one had used the VMXGSUM utility
under UNIX yet.
Chris detected, diagnosed, and provided this solution.
July 9, 1998: See MXG Change 16.146.
Thanks to Chris Weston, SAS Institute ITSV, USA.
Change 16.130 -Type 70 RMF records contain an unexpected segment for
VMAC7072 CPUs that were varied offline. The segment does have
Jun 22, 1998 CAI=0 (SMF70CNF) that flags that this CPU was neither
online at the end of the interval nor reconfigured, and
has invalid VOLSER ('E00000'x). The unexpected segment
populated variables CPUSERn, CPUWAITn, IORATEn, where n
is the CPUID that the offline processor had when it was
last online. Now, MXG protects for this segment by only
populating the n-th variables when CAI is non-zero. The
PCTTPIn value was also wrong for the nth segment, but the
cause was a missing ELSE PCTTPI=.; clause to protect its
value when the IOINT denominator is zero, as was found in
these segments. Fortunately, this segment had little
impact on important type 70 measurements, because all of
the CPU-busy variables were already missing or zero. I
intend to suggest that IBM not write this unexpected and
wrong segment in type 70 records.
Thanks to Martyn A. Jones, Chase Manhattan Bank, ENGLAND.
Change 16.129 -A major revision to TMS/CA-1 processing was precipitated
ADOCTMS5 by the discovery that the DSN in the VOL records is not
TYPETMS5 always the true dataset name on that VOLSER: for multi-
VMACTMS5 volume, multi-file sets, the DSN in the VOL record of the
Jun 23, 1998 second and subsequent volumes is the dsname of the first
Aug 11, 1998 dataset in the set of multiple files. This meant there
were observations in TMS.DSNBRECD with the wrong DSN for
some VOLSERS. If you tried to select all VOLSERs for a
specific DSN, you would miss all of the interior VOLSERs
as well as the final VOLSER that contained that dataset.
Fortunately, this past error probably had little, if any,
impact on tape chargeback using TMS.DSNBRECD, for at
least two reasons. First, these sets are usually backups
of groups of common files for an application, so all of
the DSNs are usually owned by the same department that
you billed. Second, since the BLKCNT in these bad VOL
records is always zero, calculated FEET or BYTES would be
zero, so you probably zero billed the wrong DSN anyhow!
The Block Count must be zero in these VOL records (i.e.,
for datasets that start with a DSNB) because the total
block count for the entire dataset across all of its
volumes is recorded in the BLKCNT in the DSNB record.
Unless CA-1 is redesigned to break the total dataset
Block Count into the count per VOLSER, we will never know
how much of one volume is occupied by each piece of these
datasets, but at least now you have the correct DSN for
each VOLSER which contains any part of that DSN.
The final SORT order of TMS.DSNBRECD is
BY ZDATE OVOLSER VOLSEQ FILSEQ CURR;
where OVOLSER is the "Original, or first VOLSER of a set"
and is blank for single-volume tapes, where VOLSEQ and
FILESEQ have been propagated/created by the new logic,
and where CURR is the (current) DSNB number for the
DSNBRECD observations created from DSNB records. CURR
has a missing value in DSNBRECD obs created from VOL
records, and is used as a discriminate in MXG logic.
Additionally, the size of each dataset in TMS.DSNBRECD in
bytes, calculated as Block Size times Block Count, (as
was TAPEFEET) is now created in variable DSNBYTES, and
the total size of each VOLSER in TMS.TMS is now created
in variable TAPEBYTE; both are formatted MGBYTES.
This is a major revision of the logic for TMS processing,
and the gory details of the problem and its solution,
(which took three full days to figure out and implement),
complete with example, is now in member ADOCTMS5.
The before and after runs with a 194MegaByte TMC show:
TMS.TMS TMS.DSNBRECD Elapsed Duration
obs obs vars (PENTIUM II 350)
BEFORE 510,000 203,772 42 12 minutes
AFTER 510,000 203,765 46 14 minutes
so the added cost of the new sorts and data steps seems
minimal. The smaller number of observations in the new
DSNBRECD is the result of removing the VOL records which
have blanks or " IO ERROR" as their DSN values.
The AFTER run with same data on an Amdahl millennium took
15 minutes elapsed (and 9 minutes CPU) under OS/390!
Thanks to John Rosewarne, Telstra, AUSTRALIA.
Change 16.128 For NTSMF Version 2.1.0 running under NT 3.51, the error
VMACNTSM INPUT STATEMENT EXCEEDED RECORD LENGTH occurs because the
Jun 18, 1998 NTSMF record is missing the CPU Speed field in the 0,0
CONFIG record. This change only inputs the new sections
if both VERSION GE '2.1' AND NTVERSN GT '3.51'.
Thanks to Jim Quigley, Con Ed, USA.
Change 16.127 This member is still in testing, but now at least it has
BLDNTPDB been debugged and corrected and works. More is planned.
Jun 18, 1998
Thanks to J. Wayne Holzbach, Reynolds Metal Company, USA.
Change 16.126 Unused Change Number.
Change 16.125 IMACKEEP was added at the end of the %INCLUDE list, where
TYPEIMS7 it had been overlooked. Member IMACKEEP was part of the
Jun 12, 1998 original MXG architecture, designed to let you override
the _VAR macros to change the contents of MXG datasets,
but that turned out to be the wrong way to tailor MXG,
because your _VAR override died when I had to add a new
dataset for that product, so Change 10.175 introduced the
new way, by defining _L and _K macros in each IMAC for
each product. However, I kept the IMACKEEP INCLUDE in
all members, just in case it might be useful to have a
common exit in the future, and its future is now!
That future is described in Change 16.134, but it was a
conversation with Peter that triggered the realization
that IMACKEEP will again be the right place, and that led
to the &MACKEEP architecture.
Thanks to Peter Enrico, Watson and Walker, USA.
Change 16.124 Variables SELAPSTM, the step elapsed time, and JOBCLASS
ANALDSET are now kept in both DSETOPNS and DSETSUMS datasets, so
Jun 12, 1998 the OPENTM can be compared to SELAPSTM, for candidate
analysis for HiperBatch and BatchPipes, and so JOBCLASS
can be used to filter unwanted job observations.
Thanks to Lawrence Jermyn, Fidelity Investments, USA.
Change 16.123 ROSCOE code revised to execute under ASCII SAS; several
VMACROSC $EBCDIC1. fields were changed to $CHAR1. and formatted to
Jun 12, 1998 $HEX2. Fields used in binary tests, for example,
IF ROSREC EQ '60'X THEN ... failed when TYPEROSC was run
under ASCII sas with $EBCDIC informat, because SAS change
the '60'X to '2D'x with that informat. Using the correct
$CHAR informat for these binary values fixed the error.
Thanks to Martha Wearen, Department of Agriculture & Food, IRELAND.
Change 16.122 -Variables SYSID, APPLID, and SYSPLEX were blank in most
VMACTMO2 datasets. Change TMSYSID to SYSID, TMENAPLD to APPLID,
Jun 12, 1998 TMSMFSID to SYSTEM, and TMMVSID to SYSPLEX.
Jun 17, 1998 -The GMT offset variables TMENGMTO and TDENGMTO are now
input as &IB.8. rather than &PIB.8., like TAENGMTO, but
while the TAENGMTO value is almost correct, the other
two GMT offsets are wrong in Landmark's records:
Record Hex Value In Record Input as &IB8.6 value
TA FFFFFFFB CF100000 -5:00:00.90
TI FFFFBCF1 DCC00000 -20480:00:00:00.00
TD FFFFBCF1 DCC00000 -20480:00:00:00.00
Note that the TI and TD values are clearly shifted left
three nybbles, causing their invalid value, but also note
that the TA value is truncated on the right, so it is not
exactly five hours. The correct 8-byte value should be:
FFFFFFFB CF1DCC00 -5:00:00.00
Landmark has opened Activity 111176 to correct the GMT
offset; until a fix is available, the GMT offsets are not
usable.
Thanks to Brian Sanger, Eagle Star, ENGLAND.
Thanks to Mike Wroot, SAS UK Customer Support, ENGLAND.
Change 16.121 New NTSMF objects "Caching Manager" creates CACHEMGR and
EXNTCAMG "Packet Filtering" creates PACKTFLT datasets, and revised
EXNTPKFL object "Web Proxy Server Service" increased the data from
IMACNTSM 37 to 56 fields, which are now supported.
VMACNTSM
Jun 11, 1998
Thanks to Leigh Ann Payne,Wachovia Operational Services, USA.
======Changes thru 16.120 were in MXG 16.02 dated Jun 8, 1998======
Change 16.120 New ERASEOUT parameter was added so that the output data
VMXGSUM set can be erased before creation. For the TREND system
Jun 8, 1998 this will reduce the size of the TREND library, since the
old design created the new TREND dataset while the old
TREND dataset still existed, so the library needed to be
exactly twice the size of the TREND dataset. Making the
change in VMXGSUM will not change the TREND dataset sizes
until a later change adds the ERASEOUT parameter to the
TRND members. The options are NO, YES, or DDNAME, and if
DDNAME is specified, a copy of the old TREND library is
made in that DDNAME before replacement by the new data.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 16.119 Preliminary support for IMS 6.1 Log Records has tested
IMACIMS the 07 and 08 records, so that member TYPEIMS7 is now
IMACIMS7 supported (it counts transactions and total resources,
VMACIMS without response time, for resource accounting of IMS).
Jun 8, 1998 There were massive changes in all IMS log records, with
new information as well, and more work will be done in
the next few weeks to the other parts of MXG IMS code,
notably there will be an ASMIMSL6 for the JCLIMSLG code.
This change includes the 01, 03, 31x and 35x log records,
but none of the new variables have been added and there
is still much validation needed.
Thanks to Dario Franceschi, Nordbanken, NORWAY.
Change 16.118 Tandem variables C0BLKS, C1BLKS, C2BLKS, and C3BLKS are
VMACTAND the cache blocks of 512/1024/2048/4096 bytes allocated,
Jun 4, 1998 and should not have been divided by DURATM. Variable
C1BLKSAV, average entried in the dirty queue should have
been divided by DURATM (like the other three measures).
Thanks to David Foster, Norwest Services, Inc.
Change 16.117 CODEPCT=150 is now the default, replacing CODEPCT=134.
CONFIG This is a compiler option that controls how much virtual
Jun 4, 1998 storage is set aside for the generated program in a DATA
step. If SAS's original guess is too small, it prints a
message suggesting a larger value of CODEPCT (usually one
unit higher!). By setting MXG's default to 150, that SAS
message and user questions about it are eliminated, and
you may save a couple of CPU seconds during the compile
phase of BUILDPDB's SMF processing step. You can also
eliminate the message (which is seen only if you have
modified your BUILDPDB to process additional SMF record
types) by passing CODEPCT as an option in your JCL:
// EXEC SAS,OPTIONS='CODEPCT=150'
Thanks to Thierry Van Moer, COMPAREX, BELGIUM.
Change 16.116 Support for Candle Omegamon for CICS V400 SMF record 255
VMACOMCI subtype 203 sub-subtypes 1 and 2 (INCOMPATIBLE) added no
Jun 4, 1998 new information but inserted blanks and FFFFs. Other
sub-subtypes are probably affected, but only these two
were available at this time for validation.
Thanks to Steve Smith, BMC Systems, USA.
Change 16.115 The support for Landmark DB2 Version 3.1 (Change 16.097)
VMACTMDB worked fine with 3.1, but failed with 3.0 'DA' record,
Jun 4, 1998 INPUT STATEMENT EXCEEDED, because MXG read in a number of
fields in the 3.0 logic that are not in the 3.0 records!
This change deleted those fields and their INPUTs.
Thanks to Robin Tremblay, Regie des Rentes du Quebec, CANADA.
Change 16.114 Processing ICEBERG and XCOM SMF records together cause an
VMACXCOM error because variable REQTYPE is numeric in ICEBERG but
Jun 4, 1998 was Character in XCOM. Hoping that changing XCOM has
less impact than changing ICEBERG, I have change the name
in the XCOM datasets from REQTYPE to REQTYPEX.
Thanks to Sharon Hindle, EDS Australia, AUSTRALIA.
Change 16.113 Landmark DB2 Version 3.1 INVALID DATA FOR HSRN is printed
VMACTMDB on the log for record 'DE', but the output datasets built
Jun 2, 1998 are not affected. MXG incorrectly tried to read the
"standard header" but the 'DE' record doesn't have one!
To eliminate the message and hex dump, change the line
IF LMRKREC NOT IN ('DC','DD','DF','DW') THEN DO;
to read
IF LMRKREC NOT IN ('DC','DD','DE','DF','DW') THEN DO;
Thanks to Robin Tremblay, Regie des Rentes du Quebec, CANADA.
======Changes thru 16.112 were in MXG 16.02 dated Jun 2, 1998======
Change 16.112 Cosmetic. If you drop variables from DB2ACCT and use the
ASUMDB2A ASUMDB2A to summarize, UNINITIALIZED VARIABLE messages
Jun 2, 1998 are printed on the log during the ASUMDB2A execution of
VMXGSUM. These have no impact on the end results, and
are printed for those variables that are used in INCODE=
logic, but cannot be eliminated because VMXGSUM cannot
parse the INCODE or OUTCODE arguments for variable names.
However, additional UNINIT messages that were printed due
to the LABEL statement in the OUTCODE= argument are now
eliminated, by moving that LABEL statement into INCODE.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 16.111 -MQ Series SMF 115 MQMBUFER dataset misspelled QPSTDWT as
VMAC115 as QPSTDTW, so now (for a while) both variables exist,
VMAC116 but the DTW spelling will go away in a future version.
Jun 2, 1998 Variables QPSTID, QPSTLL and QPSTEYEC are dropped, as
they are always constant and should not have been kept.
-MQ Series SMF 116 MQMACCT dataset variable QWHCXTYP is
named ATYPE in MQ SMF documentation, but the values that
MQ chose for their ATYP are not at all the same as the
DB2 values for ATYP, and so MXG had to spell ATYP XTYP
in the MQMACCT dataset so that it could be formatted
for its values instead of the DB2 ATYP values. This is
not a code change, but rather explanation as to why the
ATYP variable is spelled XTYP in MQMACCT.
Thanks to Richard Tsujimoto, Chase Manhattan, USA.
Change 16.110 Cosmetic. The input data can only be the _LIDMTAS data
ASUMIDMS from the IDMS Perfmon SMF data, and this eliminates
Jun 1, 1998 UNINITIALIZED errors in my QA stream. Previously, there
were MXG-created SMF records for IDMS, and this report
would use either, but the old MXG monitor only ran under
IDMS Version 10 and earlier, and those records no longer
exist.
Change 16.109 IBM has trashed the IODF Creation Date field in RMF type
VMAC73 73-1, 74-1, and 78-3 records at least in OS/390 R1.3.
VMAC74 All three records have two separate IODF Creation Date
VMAC78 fields, and both have exactly the same character strings:
Jun 1, 1998 Field Names format data value
SMF73TDT, SMF74TDT, R783TDT mm/dd/yy 19/98/04
SMF73TDY, SMF74TDY, R783TDY mm/dd/yyyy 19/98/2004
This OS/390 R1.3 production system had never been tested
with a year 2000 IPL - I think the 2004 is an accidental
value. Several APARs document the IODF format starting in
back in 1993 (OY64585) and in 1996/1997 (OW15406/OW27552)
but there is currently no open APAR about bad values.
This error was seen in an RMF record, but CMF could have
the same problem, if IODF is creating a bad value and both
RMF and CMF are simply copying that bad value.
The nasty symptom of these bad date fields are two SAS
"INVALID ARGUMENT TO FUNCTION MDY AT LINE nnnn COL mmm"
messages, hex dumps of the several thousand bytes of the
bad record, the PUT _ALL_ lists of VARIABLE=VALUE for
about 30-40 pages of printed output.
While we research the problem with IBM, I have changed
each IF YY GT 0 THEN IODFDATE=MDY(MO,DD,YY) to now read:
IF 1 LE MO LE 12 AND 1 LE DD LE 31 AND YY GT ) THEN ....
(or YYYY for the TDY fields) to validate the arguments of
the MDY() function to prevent print of the hex dump/list.
Either way, with or without this print-prevention, the end
result is the same: variable IODFTIME will be missing
until IBM corrects their records, but everything else in
the MXG-built datasets is just fine and dandy!
Thanks to Jean Murphy, Capital Group, USA.
Change 16.108 This "NTSMF PDB Build" example is still not in its final
BLDNTPDB state, but it is getting there. This change removed the
Jun 1, 1998 PROC COPY INDD=WORK OUTDD=PDB that was left from testing
(it copied unsorted datasets over top of sorted datasets
and caused DATASET NOT SORTED errors).
Thanks to Carl Kyonka, Consumers Gas, USA.
Change 16.107 The PDB now PROC SORT's the other six TYPE74xx datasets
BUILDPDB into the daily PDB library. Four XCF datasets (TYPE74CO,
BUILDPDB TYPE74ME,TYPE74PA, and TYPE74SY), the OMVS Kernel dataset
BUILDPD3 TYPE74OM, and the IRLM Long Lock dataset TYPE74LK that
BUILD003 should have been put in your daily PDB library now are!
VMXGINIT VMXGINIT was updated to define the &PDB74xx macro name
May 29, 1998 for each PDB dataset. See Change 15.320 for discussion.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 16.106 Enclave CPU and transaction variables CPUASRTM CPUENCTM
IMACPDB and ENCLTRAN from TYPE30_4 step termination records are
May 29, 1998 now kept in PDB.STEPS and summed into PDB.JOBS datasets
with this enhancement.
Thanks to Brenda Rabinowitz, Prudential Securities, USA.
Change 16.105 Support for the Web Proxy logs in Common Log Extended
TYPEWWW format adds new variables to TYPEWWW:
May 29, 1998 CLHEADER CLRQSIZE CONTLGTH HTTPCLVS HTTPSTAT PRREQHDR
PRRESHDR PRRQSIZE RMRESHDR TOTALTM
The left and right square brackets on UNIX have hex value
of '5B'x and '5D'x, but when FTP'd to MVS, they become
'AD'x and 'BD'x, and if IND$FILE'd to MVS they then are
'4A'x and '4F'x, so MXG now tests for all three values
that have been encountered when these ASCII logs are
sent thru different ASCII to EBCDIC translation tables.
Thanks to Brian J. Farley, Reliastar Life Insurance Co., USA
Change 16.104 -ANALCISH CICFCR report can cause ERROR: MORE THAN 32,767
ANALCISH VARIABLES. The PROC TRANSPOSE and array logic that was
May 29, 1998 used (so that one pass of the CICFCR dataset could
generate four reports) breaks that SAS limit when there
are thousands of CICS files. This redesign eliminates the
array and transpose logic, with one pass of CICFCR for
each report requested. We will enhance the redesign so
that only a single pass will be required, but that change
is more extensive, and this change solves the immediate
problem of getting the reports printed.
-CICJCR report can cause ERROR: MORE THAN 10 LINK
STATEMENTS HAVE BEEN EXECUTED. The LINK HEAD;
logic was eliminated.
Thanks to Eain Aronott, Toronto Dominion Bank, CANADA.
Thanks to Ian Mackay ,Royal Bank of Scotland, SCOTLAND.
Change 16.103 Deleted change.
Change 16.102 Support for Raptor Systems' Eagle V4.0 Log Message 121
EXEAG121 is decoded into dataset EAGLE121 with information on the
IHDREAGL individual connections thru that UNIX firewall product.
IMACEAGL EAGLE121 contains duration, type of service, source and
TYPEEAGL destination IP addresses (with port number), url and the
VMACEAGL filename accessed, and bytes sent and received, etc. The
May 28, 1998 other log messages are output into dataset EAGLEOTH with
the MSGID and LOGTIME and other header variables.
The MXG support reads the Version 4.0 records that were
created by Raptor Systems' FLATTEN program. While those
records are created on UNIX, MXG can read them either as
native ASCII records if you run MXG under ASCII SAS, or
you can ship the records to your MVS system (translating
them to EBCDIC in the process) and run MXG there.
FLATTEN records have a header of fixed fields that are
delimited by '09'x on ASCII (which becomes '05'x on MVS)
and then a series of field1=value1 field2=value2 ...
that are delimited by blanks, and then an undocumented
set of six numeric fields containing one byte of zero
in ASCII/EBCDIC that is delimited by '09'x/'05'x. While
the SAS NAMED INPUT technique is meant to handle data
like the field1=value1 series, it could not be used here
for two reasons: a) one of the data fields (ARG, which is
the full url and filename) can contain equal signs, which
would prematurely terminate its input and truncate its
value, and b) once SAS starts NAMED INPUT in a record,
there can be no following fields. So MXG instead must
parse and test the name field for each field.
These records look useful for tracking firewall accesses
but there are some quirks in the data. First, not all of
the fields in Table 6 in the Eagle Configuration Guide
V4.0 are in each record. In particular, USER and AUTH
appear infrequently (only 98 of 1658 records had them),
and there are some blank values for OP(10), PROTO(59),
RESULT(124), and SRCIF(7).
Most records end with the two fields RESULT and PROTO and
the six numeric fields:
result="200 OK" proto=http.0.0.0.0.0.0.
but some records instead have a date value following the
result= field, and there is no proto= field:
result="200 OK" 05/18/1998.0.0.0.0.0.0. 320
ZONE 2767767323332442233233233330303030303030
NUMR 02535C4D22000FB2005F18F19989090909090909
and some records seem to have trashed the second quote:
280 result="200 Docume05/18/1998.0.0.0.0.0.0. 320
ZONE 76776732333246676633233233330303030303030
NUMR 2535C4D220004F35D505F18F19989090909090909
MXG has additional logic to handle these anomalies.
These values for RESULT have been found in data. Note
the real joy of UNIX programmers who have five different
case sensitive spellings for RESULT 304 and conflicting
meanings for RESULT 200 and other RESULT values!
RESULT value Count
blank or incomplete double-quote 124
"200 Document follows" 36
"200 File data follows" 2
"200 OK" 881
"204 No content" 28
"302 Found" 4
"302 Moved Temporarily" 12
"302 Object Moved" 3
"302 Object moved" 5
"302 Redirection, oh yay" 1
"304 File Has Not Been Modifed" 8
"304 NM" 40
"304 Not Modified" 183
"304 Not modified" 2
"304 Use local copy" 186
"403 Forbidden" 3
"404 File not found" 3
"404 Hostname lookup failure" 5
"404 Not Found" 2
"404 Not found" 3
"404 Object Not Found" 6
"500 Internal Server Error" 2
"500 Unable to connect to remote 6
"Not HTTP/1.0 response" 113
Thanks to Brian Harvey, Navistar International, USA.
Change 16.101 Support for TME 10 NetView for OS/390 V1 R1 SMF type 38
EXTY3801 record creates these new datasets:
EXTY3802 TYPE3801 Command Authorization Table subtype 1
EXTY3803 TYPE3802 Task Resource Utilization Data subtype 2
IMAC38 TYPE3803 Span Authorization Table subtype 3
VMAC38 but only the TYPE3802 has been tested with data. The
Jun 1, 1998 NAME column is missing in tables 45-50 for subtype 3 in
Jul 16, 1998 IBM's "Application Programmers Guide" SC31-8223-01, but
IBM provided the DSECT so MXG variable names match!
In addition, this product is NOT Year 2000 Compliant,
as the date fields in the subtype 1 and 3 are in the
MM/DD/YY HH:MM:SS format! As usual, however, MXG will
protect the YY using the 1959 windowing technique.
Note that many of the raw data fields contained units of
KB per minute, but they have been converted to bytes per
second and formatted with MGBYTES format so they will
print rates in bytes, KB, MB, etc, per second, to be more
consistent with the rest of MXG than this narrow world
that measures per minute. Also, I/O rates were converted
to rates per second versus per minute, and all rates have
"per sec" in the label to make it clear.
Thanks to Leo Meyer, Humana, Inc, USA.
Change 16.100 The NON-FATAL STRUCTURE MISMATCH message that I thought
VMAC74 I had eliminated in Change 16.032 can still show up. The
May 27, 1998 tests R744SFLG EQ '00......'B and R744SFLG NE '00......'B
was added because that value was observed in data, but
those tests must be changed to
R744SFLG EQ '0.......'B and R744SFLG NE '0.......'B
because when the structure is not online (EQ 0) there
never will be a match, so there is no message to print.
Only if there is a mismatch AND the structure was online
at the end of interval, will the message now print.
Thanks to Gary L. Beers, Boeing Information & Support Services, USA.
Change 16.099 Support for MQ Series Version 1 Release 2 (INCOMPATIBLE,
VMAC115 but only for dataset MQMLOG, Log Manager Statistics,
May 26, 1998 which will have missing values for all of the QJSTxxxx
variables without this change). New variable QJSTLLCP
was added to dataset MQMLOG by the new version.
There were no changes to the type 116 SMF record in 1.2.
Note that previous MQM Version numbers were 1.2 and 1.4,
but those were really 1.1.2 and 1.1.4 and this new one,
Version 1 Release 2, is really MQ Series 1.2.0.
Thanks to ???, ???, ???.
Change 16.098 ANALSRVC reports CPU Percentage by Service Class for Goal
ANALSRVC Mode from TYPE72GO (like ANALPGNS for Performance Groups
May 21, 1998 in Compatibility Mode from TYPE72). Two percentages are
calculated:
SVPCTCAP - Pct of total Interval Capacity (NRCPUS*DURATM)
SVPCTUSE - Pct of total CPU Used (CPUACTIV during Intvrl)
For example, a SRVCLASS that recorded 1 hour of CPU time
in a 1 hour interval on a 2-engine CEC that was 75% busy
(TYPE70 was 1.5 hours) would have its SVPCTCAP= 50% and
SVPCTUSE= 66.6%. This report was incomplete in MXG 14.14
so Glen cleaned it up so it actually works!
Thanks to Glenn Bowman, Wakefern Food Corporation, USA
Change 16.097 Support for Landmark's Monitor for DB2 Version 3.1 is
VMACTMDB INCOMPATIBLE (i.e., you must have this update to read
May 21, 1998 the 3.1 records) because fields were inserted in their
Jun 1, 1998 records. New variables were added to these datasets:
TMDBDA2 - 26 TMDBDAB - 18 TMDBDAF - 1
TMDBDB2 - 19 TMDBDBB - 1 TMDBDBR - 1
The headers are now decoded for all records, but there
are additional data in some record segments (notably
the BB-BL family, and the DC, DE, DD, and DF) that are
not decoded until someone wants to use that detail data.
Jun 1: INPUT for DABGLCK comment line was shortened.
Thanks to Robin Tremblay, Regie des Rentes du Quebec, CANADA.
Change 16.096 The Structure Type Identifier, variable R744STYP is now
VMAC74 formatted with $MG074TT format:
May 19, 1998 '01'X='01X:UNSERIALIZED LIST STRUCTURE'
'02'X='02X:SERIALIZED LIST STRUCTURE'
'03'X='03X:LOCK STRUCTURE'
'04'X='04X:CACHE STRUCTURE'
and IBM has agreed to update the SMF manual to document
the values for that field.
Thanks to Yanara Perez, UPS, USA.
Change 16.095 The TYPE74 variable IORATE has been calculated by divide
VMAC74 of SSCHSAMP (SMF74MEC) by DURATM. SSCHSAMP is the number
May 15, 1998 of SSCH instructions for which pending, connect, and
actives were stored, and is returned by the hardware to
RMF. But IBM uses SIO74CNT (SS74SSC), which is the
number of requests to the device and it includes SSCH and
RSSCH instructions, to calculate IORATE in RMF reports.
I have changed to use SIO74CNT in the numerator of IORATE
not only to match IBM, but because this will provide the
IORATE even if SSCHSAMP is zero (which Diane discovered
and is investigating with IBM and her hardware vendor).
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 16.094 The test IF &LOMONTH LE ZDATE LE HIMONTH; must be changed
BLDNTPDB to read IF "&LOMONTH"D LE ZDATE LE "&HIMONTH"D; to avoid
May 15, 1998 a 73-222 error when BLDMNTH=YES (the default) is used.
This member is undergoing revisions and enhancements,
and a new option FIRSTRUN= has been implemented to init
initialize the PDB, daily, weekly, etc., libraries.
but this will not be completed in time for MXG 16.02.
Thanks to Bob Gauthier, American Stores, USA.
Change 16.093 The test IF LENGTH EQ 1464 THEN DO; in the Interval CICS
TYPEMON8 record is now IF LENGTH-COL+1 GE 212, because the fields
May 15, 1998 starting with TIAPREQ are present but were not input (so
they had missing values in dataset MONISYST) in records
of different lengths.
Thanks to ???, ???, GERMANY.
Change 16.092 CICS Statistics (type 110 subtype 2) dataset CICDS has
VMAC110 four divides by 5096 should have been divide by 4096.
May 15, 1998 The four variables for the fifth TCB, DS5TWT, DS5TDD,
DS5TCT and DS5ACT would have been about 20% smaller than
they really were. DS5ACT is a included in CPUTCBTM, so
it too was a little bit low. Fortunately, although there
are now six TCBs in a CICS region, almost all of the CICS
CPU time is still in the first TCB (762 second out of 765
seconds, for example), so the impact of this error in the
fifth TCB is minimal on this CICS statistics dataset.
Thanks to Tony P. Steward, Post Office, ENGLAND.
Change 16.091 Landmark TMON for CICS V2 Converted Records do not set
TYPEMON8 TAFLAG6 bits to "Detail" (because V2 no longer has the
May 14, 1998 History or Summary records - all V2 records are "D"),
but MXG sets MONIRECD=' ' and then tests TAFLAG6 to set
MONIRECD to D,S, or H. But with no bits set in V2,
MONIRECD remained blank. The correction is to initialize
MONIRECD='D' instead of MONIRECD=' ' so that the V2
records will always be "D" and older version's with
TAFLAG6 bits will set the "S" or "H" if appropriate.
Only if you have added logic using MONIRECD that expects
the 'D' will this problem cause you an error (but this
site had IF MONIRECD='D' THEN OUTPUT MONITASK; in their
EXMONTSK exit, to discard the old History/Summary data,
so they had zero observations in MONITASK dataset due to
the blank value in MONIRECD in V2 records!
Thanks to Tim Downs, CSC TMG Warren, USA.
Change 16.090 Four additional fields were added to the type 42 st 14
VMAC42 ADSM SMF record that are now output as MXG variables
May 14, 1998 in dataset TYPE42AD:
SMSBYTCS='SPACE-MANAGED*DB OBJ BYTES*SENT CL-SRV'
SMSBYTRE='SPACE-MANAGED*DB OBJ BYTES*RETRIEVED'
SMSOBJIN='SPACE-MANAGED*DB OBJECTS*INSERTED'
SMSOBJRE='SPACE-MANAGED*DB OBJECTS*RETRIEVED'
and the conversion of kilo-bytes to bytes now uses the
factor of 1024 instead of 1000.
Thanks to David Ehresman, University of Louisville, USA.
Change 16.089 Zero observations occurred, apparently because the INPUT
TYPEVLFC of RESTOFIT $CHAR80. needs to be RESTOFIT $CHAR72.
May 13, 1998 The actual change was more extensive, calculating LENLEFT
in the record and INPUTting with $VARYING72.
Thanks to Martin Lee, Safeway, UK.
Change 16.088 Magstar drives have 0E8x for both DENX and TRTCH, but
VMACTMS5 MXG failed to decode those values, causing variable DEN
May 13, 1998 to be missing, and DEN is used to create observations in
DSNBRECD records, so datasets were not reported, and DEN
is also used to estimate the number of feet of tape).
This fix sets DEN=99000 for MAGSTAR so that observations
will be created, but a better density estimate may be
needed if length of tape is important. However, with
compressed data on tape, the ability to measure the feet
used is non-existent, since CA-1 provides only the
uncompressed size.
Thanks to Trevor Holland, Telstra, AUSTRALIA.
Change 16.087 The &MAC50 statement was misspelled as &MAC40 in MXG
VMAC50 15.15, but has now been corrected to &MAC50.
May 11, 1998
Thanks to Bill Shanks, BRBS Sema Group, UK.
Change 16.086 The UDKSCONT utility reads the output of PC DIR commands
UDSKCONT to measure PC filespace and estimate PC diskspace needed
May 9, 1998 (considering FAT cluster waste per file), but the MXG
algorithms (which assume the space in the last cluster
is lost) are not exact. My C: drive has 1546MB capacity,
129MB free and 1413MB in use, according to Properties.
Issuing these five DIR commands:
DIR *.* /S >> DISKFARM
DIR *.* /S /AH >> DISKFARM
DIR *.* /S /AR >> DISKFARM
DIR *.* /S /AS >> DISKFARM
DIR *.* /S /AA >> DISKFARM
to get Hidden/Read-only/System files/Archive files.
Change 16.085 The new support for Mobius InfoPac RDS View Direct 6.1
VMACIPAC in change 16.052 was validated, and minor changes were
May 8, 1998 made to deal with the changed records: subtype 1 and 2
are same length but 2-byte century field was added at the
beginning and a 2-byte filler at the end was deleted; the
subtype 3 and 4 was increased by 4-bytes, and the revised
code has been tested with both 5.2 and 6.1 releases.
Thanks to Clark Jennings, Reynolds Metals Company, USA.
Change 16.084 The new calculation of RESPSTD should have used RESPAVG
TRND72 instead of AVGELPTM.
May 8, 1998
Change 16.083 The new OS/390 R2.5 Job queueing durations in TYPE72GO
VMAC7072 variables R723CQDT, R723CADT, R723CCVT, and R723CIQT were
May 8, 1998 incorrectly multiplied by 128 when they should have been
multiplied by 1024. They are in 1024 microsecond units,
but I carried down the 128 from R723CIOT, which is in 128
microsecond units. Also, R723CQDT was incorrectly
spelled as R723CDQT, but now matches the DSECT name.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 16.082 This ABEND report uses PDB.STEPS (because programs ABEND,
ANALABND jobs don't) to produce a report similar to the example in
May 8, 1998 Table 27.5 in the MXG Guide (see member ACHAP27). This
report tabulates ABENDs by Group, where you define the
groupings by EDITing the PROC FORMAT statements. In this
example, the variable JOBCLASS is used to define groups,
but any variable in PDB.STEPS (including ACCOUNT1, JOB,
etc.) could be used to group the tabulation.
This is also a good example of how to build table lookups
with PROC FORMAT and report with PROC TABULATE.
Thanks to Kevin Clark, Amtrak, USA.
Thanks to Chuck Hopf, MBNA, USA.
Change 16.081 The JCL parameter TAILORNG in the MXGSAS JCL Procedure
MXGSAS causes a JCL error with JES 3.1.3, because the symbol is
May 8, 1998 more than seven characters, so it has been changed to
TAILOR to avoid the error. However, one other site had
to remove both references to the TAILOR parameter to
eliminate a strange SAS 180 error, after the SAS
Initialization but before the MXG initialization
messages, that was followed by another SAS message that
the USERID.SOURCLIB was not a PDS when it most definitely
was. TAILOR is an MXG optional JCL parameter that is not
explicitly used anywhere in MXG and can be removed
without causing a problem.
Thanks to Tom Marchant, Wayne State University, USA.
Change 16.080 Multiple purge records can be created for JES3 jobs,
BUILDPD3 but MXG logic in BUILDPD3/BUIL3005 did not expect more
BUIL3005 than one purge record. These JES3 purge records are
May 7, 1998 identical with same READTIME, JOB, and JESNR values, and
only these variables are different in the three records:
JFINTIME JPURTIME ENTERDJ LEFTDJ TYPETASK SPOOLREC
. 04:46:29 Y STC 780
07:53:00 07:53:00 Y JOB 468
07:53:48 07:53:48 Y JOB 468
Most triplets had STC in the first record, JOB in the
second and third record, and came from started tasks that
had run for a week, were taken down, apparently had their
SYSOUT "dumped" and later had it "entered". There were
also pairs of purge records with TYPETASK='TSU' followed
by TYPETASK='JOB', and there were many pairs with both
first and second records containing TYPETASK='JOB'. It
looks like when JES3 "enters" the SYSOUT, it uses the
same JOB and JESNR, but sets TYPETASK='JOB' in those
subsequent purge records, even when the original "job"
was a STC or a TSO USer.
In all cases of multiple JES3 purge records, the first
record had LEFTDJ='Y', indicating the job left the system
by way of DJ (dump job), and the subsequent records have
ENTERDJ='Y', indicating the job entered the system by way
of DJ, so perhaps if you never use JES3 DJ, you never had
a problem. (There were purge records with LEFTDJ='Y'
and/or ENTERDJ='Y' that did not have multiple records,
but I only looked at part of a day's data.)
The problem with these multiple purge records is that
they cause multiple observations to be built in the
PDB.JOBS dataset, so I had to add logic to ensure that
only one purge record, the first one (i.e. earliest
JPURTIME) will be used to create PDB.JOBS, and the other
purge records create a new dataset DJPURGE for further
investigation.
The actual change was
-add DJPURGE to the DATA statement that creates
TYPE26J3 from SETS TYPE26J3 and SPIN26,
-after the END; statement, insert:
IF FIRST.JESNR THEN OUTPUT TYPE26J3;
ELSE OUTPUT DJPURGE;
Thanks to Brian Harvey, Navistar, USA.
Change 16.079 New format MGDECSR had extra quotes which caused a SAS
FORMATS "WARNING: At least one string was over 98 characters long
May 6, 1998 and had special characters and had to be truncated to
98 characters" that was overlooked (perhaps because that
warning did not set a condition code - I am now revising
the MXG QA stream to automatically detect any warnings in
the PROC FORMAT step, even if it set no condition code.
(SAS does not always set a condition code for a WARNING).
Thanks to Scott Wiig, US Bank, USA.
Change 16.078 All variables with format MGBYTES are now stored in 8
DOC bytes rather than 4 bytes. There were 2051 variables
May 6, 1998 in 332 MXG-built SAS datasets with that format, but by
searching all members of MXG for MGBYTES, there were
only about 220 that had to be scanned and only 105 that
were actually changed. Typically, the lines of the
FORMAT statement were copied into the LENGTH statement
and set to length 8. It is the DEFAULT=4 operand in
the LENGTH statement that sets the stored length. Some
report members that had no length statement did not have
to be changed, and code that only used MGBYTES in a PUT
statement in a DATA step were not changed, because all
SAS numeric variables are length 8 during the data step
that creates them; it is only when output to DASD that
the variable is truncated into four floating point bytes.
See MXG Technical Note on this subject.
Change 16.077 -Under SAS V7, when you create an output dataset using
VMXGSUM the PROC CONTENTS OUT= operand, the lengths of some of
May 5, 1998 the created variables are changed. In particular, NAME
Sep 9, 1998 will be 32 bytes long in the V7 output dataset, whereas
NAME was only 8 bytes long in the V6 output dataset. In
VMXGSUM, we create a list of names in your arguments as
length 8, but when we merge that list with the output of
PROC CONTENTS (to verify the variables you listed are
actually there to summarize), SAS V7 raised a warning
message. This change forces the length of NAME to 8 s
bytes, but was not actually made until Sep 9, 1998.
Change 16.076 -Using the new ASUMTALO summarization with a version of
ASUMTALO MXGTMNT/ASMTAPES earlier than MXG 14.01 (ML-10, which
May 5, 1998 was the first version that created the End-of-Interval
allocation records) created zero observations in ASUMTALO
because the new logic did not validate that there were
any interval records to use. Now the logic only uses
interval records when they are found in your SMF records,
so ASUMTALO observations will always be created now.
-The LENGTH of variable DEVICE defaulted to 8 if there was
no SPIN.SPINTALO (i.e., for the initial run of ASUMTALO),
but the length of DEVICE in TYPETALO is 7. Under SAS V7
this raised a WARNING message about unmatched lengths
of character variables when the new and old datasets are
interleaved, so now DEVICE is set to length 7 to avoid
the warning and its associated return code of four.
Thanks to Chuck Hopf, MBNA, USA.
Change 16.075 -DB2 variables CLASS3WT and CLASS3TM (DB2 Class 3 wait
ANALUOW counts and wait durations) are added to ASUMUOW and
ASUMCICS TRNDUOW datasets. These are the sum for all of the
ASUMUOW twenty individual class 3 wait buckets, for a high
TRNDCICS level view of DB2 waits in the ASUMUOW dataset.
TRNDUOW -The new wait variables added by CICS TS 1.2 (see text
May 5, 1998 of change 15.274) are included in the ASUMUOW and the
TRNDUOW datasets.
-CICS variables SSQELAP, RESPSTD and MAXRESP are now
created in TRNDUOW.
-ANALUOW analysis reports now have MAXRESP on report 2 and
both MAXRESP and RESPSTD on report 3 to show how tightly
clustered response times are. New option PLOTIT= sets
the number of minutes between tickmarks on the X axis for
plots of response time versus time of day (and uses the
specified STARTIME= and ENDTIME= values on the x axis).
If PLOTIT is not specified, no plot is produced. If both
PLOTIT= and GRAFOUT are specified and you have SAS/GRAPH,
a graphics catalog named ANALUOW will be built in the DD
pointed to by GRAFOUT.
-Variables SSQELAP and RESPSTD were added to ASUMCICS and
TRNDCICS output datasets.
Thanks to Chuck Hopf, MBNA, USA.
Change 16.074 Change 15.320 replaced hardcoded PDB DDname references
ANALBLSR with &PDBMXG macro variables to externalize the DDname,
VMACFRYE but these members had wrong syntax. In ANALBLSR &PDBMXG
XDB2LOCK was changed back to &PDB because the usage was inside a
XNALCACH %MACRO with a PDB= operand, while VMACFRYE had PDBMXG
ZGRAFRMF changed to &PDBMXG; the other three disused members were
May 5, 1998 corrected for consistency but are not actively used.
Thanks to Chuck Hopf, MBNA, USA.
Change 16.073 INVALID DATA FOR TMMDMODL message is printed because the
TYPEMON8 INPUT TMMDMODL &NUM.2. should be TMMDMODL ?? &NUM.2.
May 5, 1998 Add the ?? modifier to suppress printing of the message
and hex dump when invalid data is attempted to be INPUT.
MXG's logic to detect whether this Landmark record has YY
or YYYY dates knows that TMMDMODL will be invalid (and
hence set to missing value) for the non-Y2K compliant
records, and so it rereads TMMDMODL as &PIB.2. when
TMMDMODL is missing, and so the datasets built by
TYPEMON8 were just fine. I just forgot to add the ??
modifier to eliminate the unnecessary print messages.
Thanks to Diane DePasquale, CSC TMG Warren, USA.
Change 16.072 Old variables FSPCBTRP FSPCBTRT FSPCCOLP and FSPCCOLT in
VMACICE dataset ICEBRGSY are renamed to FSBYxxxx because the FSPC
May 5, 1998 prefix is was intended for percentages, not storage size,
and FSPCCOLP and FSPCCOLT already existed in ICEBRGUT,
and their label and format was overlaying the ICEBRGSY
variables. The FSBYxxxx variables are formatted MGBYTES.
Thanks to Ken Williams, Sun Life of Canada, ENGLAND.
Change 16.071 This new program merges VSAM type 62 and 64 SMF records
ANAL6264 to add OPENTIME to each CLOSE record. Dataset VSAMOPEN
May 4, 1998 has an observation for each open from each job for each
VSAM ENTRNAME.
The ENTRNAME in the OPEN record will end with blanks,
'CLUSTER', 'CL', or 'BASE', but its corresponding CLOSE
records for that open end will end with blanks, 'DATA',
'DT', 'INDEX', or 'IX'. MXG strips the "last" part of the
ENTRNAME, merging on the stripped name, and stores the
"last" part in variable LAST.
For CLOSE (64s) without an OPEN, the OPENTIME is set to
the minimum SMF time of the 62/64s on that system, and
for OPEN (62s) without a matching CLOSE, their SMFTIME is
set to the maximum SMF time found. Variable OPENTM is
created only for a match-up. Close-without-open will
have OPENTM=. and ID=64, while open-without-close will
have OPENTM=. and ID=62 in the VSAMOPEN dataset.
There are often four close records for each open; I guess
the Data and Index are closed, and then when the Cluster
is closed, there is a second pair for the Data and Index.
This is work in progress, and the efficiency of the merge
will be enhanced. One consideration is using the output
dataset to measure availability of VSAM production
datasets, so there will likely be revisions to ANAL6264.
Thanks to Rachel Quiroz Holt, Fidelity Systems, USA.
Change 16.070 New utility likely to be needed only by me. UTILBHEX will
UTILBHEX build a file of readable SMF records from an email of the
May 4, 1998 SYSOUT print file of the SAS log that contains the hex
dump of SMF record(s) that were printed by the "LIST"
statement, or were printed when "INPUT STATEMENT EXCEEDED
RECORD" errors occur. That automatic hex dump on the SAS
log has been invaluable in resolving errors, incompatible
records and new product validation, and I still rely on
the dump, but debugging a problem in CICS type 110 SMF
records with excluded fields plus optional segments was
made much easier by writing this utility to create the
record and then enabling the debugging logic in MXG code.
While member SENDDATA provides instructions by which you
can re-read the SMF data and create an SMF file on MVS to
then be downloaded, zipped, and emailed, now, if you have
an error and I need to see the record, you can simply
save the SYSOUT as a file on MVS, download it and zip it
on your PC, and then email it to me for diagnosis. Also,
member SENDDUMP shows how to produce a hex dump of select
SMF records, and now its output can also be converted to
readable records by this utility.
Change 16.069 IMS log processing datasets now have _L, _K macros for
IMACIMS the additional datasets created by JCLIMSLG's TYPEIMSA,
VMACIMSA so you can control the contents of all IMS log datasets.
Apr 30, 1998 New exit members EXIMSTRN, EXIMSBMP, EXIMSUNM, EXIMSMRG
EXIMS07I, EXIMSFAS, and EXIMS598 (and similarly named
_L and _K macros) exist for the IMSTRAN, BMPS, UNMATCHED,
IMSMERGE, IMS07, IMSFASTP, and IMS5938 datasets.
Change 16.068 Macro variables &PCICTRN, &PDB2ACC, &PIMFTRN and &PIMSTRN
VMXGINIT created and GLOBALed to continue the externalization of
Apr 30, 1998 DDnames for datasets created by BUILDPDB. I have decided
Jun 25, 1998 on the naming conventions for dataset LIBNAME macros:
Exit Member Name Dataset Name Dataset &Macro
EXTYxxxx TYPExxxx &PDBxxxx
EXdddddd All others &Pdddddd
All VMACs that process SMF records will have their
&PDBxxxx or &Pdddddd "Dataset &Macro" defined and set
with a %LET in VMXGINIT member. All resolve to "PDB" by
default, except for the CICSTRAN and DB2ACCT (high
volume) datasets that are not sorted by MXG's BUILDPDB.
See Change 15.320 for further discussion.
Change 16.067 Candle's Omegamon Version V400 for CICS/ESA 4.1 and
IMACICDA CICS TS 1.2 have two new optional segments added to their
IMACICOC type 110 record, CANMQ with MQ Series counts and duration
IMACICOM and CANWLMSC with WLM Service Class names. These new
IMACICOW segments are now supported in new members IMACICOM and
VMAC110 IMACICOW respectively, and member IMACICDA was updated to
Apr 30, 1998 add their include in the default order (MQ before WLMSC),
and the new variables were added to the KEEP= list in the
VMAC110 member (but no new variables are created unless
you remove the comment block in IMACICOM or IMACICOW).
As always, you need to run UTILCICS to find out which of
the segments exist and in what order in each region, and
and might have to update IMACICDA if UTILCICS shows the
order is different in your records than MXG expects.
Since I now have the DSECTS, I found that there are two
bytes of flags in the OMEGBSC segment that are now two
variables, OMDBWRN (DB Warnings) and OMGENWRN (General
warnings) added to CICSTRAN if you enable IMACICOC.
Thanks to Melanie Floyd, UPS, USA.
Thanks to Jon Taf, UPS, USA.
Thanks to Dennis Hancock, UPS, USA.
Change 16.066 The MXG CONFIG option SASAUTOS=(SOURCLIB SASAUTOS) is now
CONFIG used so that sites that have their own macro libraries in
Apr 28, 1998 their SASAUTOS collection can be found under MXG.
The earlier option was just SASAUTOS=SOURCLIB, which
prevented you from finding your macros in your SASAUTOS.
(Many sites concatenated their macro libraries and/or
the SAS.MACRO library to their //SOURCLIB DD.)
Thanks to Alfred Mueller, ABN - Amro, USA.
Change 16.065 The NPM format MG028VA decoded an undocumented '0A'x
FORMATS value. IBM has confirmed the '10'x documented for the
Apr 28, 1998 LVMATYP field should be '0A'X, so FORMATS now contains:
10='0AX:PCT TIME IN BLOCKED RATE' instead of
16='10X:PCT TIME IN BLOCKED RATE'.
Thanks to Paul Hill, Midland Bank, ENGLAND.
Change 16.064 In dataset TYPE72GO, variable RESPAVG is kept and EXETTM
VMAC7072 is created and kept. RESPAVG is equal to AVGELPTM, but
Apr 28, 1998 keeping RESPAVG, which was the name in TYPE72, will help
Aug 14, 2001 sites migrating to Goal Mode. The Total Transact
Execution time, R723CXET, is now kept in new variable
EXETTM. Previously, only the average value AVGXETTM was
kept in TYPE72GO, and it was calculated only if TRANSEXC
was non-zero (because I thought EXETTTM was updated only
when TRANSEXC - when a transaction in execution phase had
ended). But Brenda found non-zero EXETTM with zero count
in TRANSEXC, and Don Deese's current paper confirms that
EXETTM is non-zero for batch service classes, even though
TRANSEXC is always zero for batch. So now, not only is
EXETTM a kept variable, but also AVGXETTM is calculated
as EXETTM/TRANSEXC if there were subsystem transactions
terminating, or else AVGXETTM=ELAPSTM/TRANS if there were
no TRANSEXC but TRANS was non-zero.
For non subsystem transaction service classes (like batch
and TSO), variable EXETTM now measures in Goal Mode what
was measured in ELAPSTM in Compatibility Mode.
In debugging my change, (examining the missing value
notes on the log), I found a line with PCTUSNDI that
did no harm but is now deleted, and I discovered that
replacing:
SUMPTRAN=SUMPTRAN+RTSTRN(M); /*ADDING*/
with
SUMPTRAN=SUM(SUMPTRAN,RTSTRN(M)); /*SUM FUNCTION*/
not only eliminated the missing value notes on the
log, but also saved CPU time! While SUMPTRAN (the
accumulated transaction count as I loop across the
thirteen response count buckets) was always set to
zero before the loop, if a service class had no
response buckets, RTSTRN(M) was missing, and the loop
ran thru all thirteen buckets, because the ADDING zero
to missing is still missing. Instead, using the SUM
function, zero plus missing is zero, so the test that
follows (IF SUMPTRAN GE NRPTRANS) is now satisfied on
the first iteration, so we bail out of the loop,
instead of DOing it thirteen times!
Thanks to Brenda Rabinowitz, Prudential Securities, USA.
Thanks to Carole Storby, LMCO, USA.
Change 16.063 Support for OS/400 Version 4.2.0 (COMPATIBLE).
VMACQAPM -New QAPMCONF configuration GKEY values of 'CI' and 'SJ'.
Apr 27, 1998 -New QAPMJOBS variables JBTCPU,JBTHDF,JBTHID,JBTHAC,
JBTHCT,JBMTXT, and JBSTSF were added. The QAPMJOBS file
is now LRECL=812 vice 617.
-The +52 after JBSJFG was changed to +58. This change
corrects 4.1.0 variables after JBSJFG.
-New QAPMDISK variables DSBGDR,DSBGDW,DSBGS,DSCOMP,
DSFGDR,DSFGDW,DSFGRE,DSFGS,DSFGWE,DSLBA,DSLBW,DSPBA,
DSPBCO and DSPBU were added. The QAPMDISK file is now
LRECL=346 vice 267. The variable PCTIOPBY seems to be
invalid, as the DSIDLC field contains very large values.
This needs to be examined further, and will be updated
if I learn more.
-New QAPMECL variable EMDUP was added.
-New QAPMETH variable ETMDUP was added.
-New variable XIADRN was added to QAOMIOP1-4 datasets.
Except for possible LRECL changes in your JCL, the 4.2
records were compatibly changed.
Thanks to Clark Jennings, Reynolds Metal, USA.
Thanks to Stuart Burnett, Reynolds Metal, USA.
Change 16.062 This revision to the RMF III VSAM assembly program adds
ASMRMFV support for the CSR, the Common Storage Remaining data
May 10, 1998 segments. This level 002 of ASMRMFV has been tested, but
I have not yet updated the TYPERMFV code for the CSR.
Change 16.061 The UTILCICS output listed UN98309 for any region, but
UTILCICS that APAR only applied to CICS 4.1; the fields added by
Apr 27, 1998 that APAR are in CICS TS by default, so the test to set
PTF='UN97309' now also tests SMFPSRVR=41.0. This CICS
dictionary-reading utility also now knows about the new
CANMQ and CANWLMSC sections and sets the ERRMQ=64 error
if CANMQ segments of only 64 bytes are found. The early
Candle documentation showed 64 bytes, but the correct
length is 76; if you get ERRMQ=64, then your CICS guru
needs to correct the MCT length for CANMQ to be 76 bytes.
Thanks to Melanie Floyd, UPS, USA.
Thanks to Jon W. Taff, UPS, USA.
Change 16.060 Sterling's Connect Direct (formerly NDM) subtype "PT"
VMACNDM process termination data is trashed; timestamp variables
Apr 27, 1998 NDMSUBTM and NDMSKDTM get INVALID VALUES messages, and
other PT variables are also wrong. Sterling has an open
problem report, item PI-754129, but no fix yet, but now
called Sterling CASE 7916. In 1994 there was a similar
error in "PT" in Change 11.326, but this time I found
Sterling Tech Support and received same-day service!.
But there was also an MXG error, as the INPUT for the PT
segment was off by two bytes, and there was a new
variable, NDMSEQ, added at the end that was overlooked.
Also, to prevent those INVALID VALUE messages before you
get a fix from Sterling, I inserted the ?? modifier for
each packed PT field. The MXG fix to the PT input:
change LOC=LENGTH-21; to LOC=LENGTH-23;.
Thanks to Brian Crow, BT, ENGLAND.
Change 16.059 -Variable NWMSINRT was not kept in dataset MSEXCHIS due to
VMACDECS mispelling as NWMSINRJ in the KEEP=list.
VMACNTSM -Repeats of six variables in KEEP= list in VMACDECS were
Apr 27, 1998 removed, though they caused no problem.
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 16.058 Changes made in MXG 15.15 caused ASMIMSL5 to fail during
ASMIMSL5 assembly were corrected and the revised member was tested
Apr 27, 1998 with IMS 5.1 log records without error.
Thanks to George Ellard, FEDEX, USA.
Change 16.057 -The label for variable OMVSOPR in dataset TYPE30OM built
VMAC74 by BUILDPDB was wrong, because dataset TYPE74OM also has
VMAC78 a variable OMVSOPR, and the 74's label replced the 30's.
Apr 27, 1998 To resolve the conflict, the type 74 variable OMVSOPR was
renamed to OMVSOPRP to protect the TYPE30OM variable,
which could cause VARIABLE OMVSOPR NOT FOUND, but only if
you use the TYPE74OM data set AND explicitly referred to
OMVSOPR in your SAS report code.
-The label for variable SYSNAME in member VMAC78 was used
for all BUILDPDB datasets, but it had a typo. The
correct spelling is IEASYSXX and not IESAYSXX.
Thanks to Randy Shumate, LEXIS-NEXIS, USA.
Change 16.056 Comments and INVOKEBY= were changed to ASUMCICX in this
ASUMCICX optional replacement for ASUMCICS (see Change 15.205).
Apr 25, 1998
Thanks to Jim Ray, Branch Banking and Trust, USA.
Change 16.055 Archaic FMXGUCBL failed under SAS 6.09, but re-assembly
FMXGUCBL of the member with the SETSSI AF010000 (as mentioned in
Apr 25, 1998 Change 12.015), eliminated the 0C4, and by changing
TXTUC15 DC X'0015',X'0001',X'0003' CODE 15 - UNIT ADDRESS
to increase its length from three to five bytes:
TXTUC15 DC X'0015',X'0001',X'0005' CODE 15 - UNIT ADDRESS
eliminated the DYNAMIC ALLOCATION FAILURE FOR VOLUME xxxx
with REASON-021C error on each volume.
The SETSSI statement now sets AF010000 vice AF000000.
This member is archaic in that DCOLLECT is now the MXG
recommendation, and before that, ASMVTOCs had replaced
the very old FMXGUCBL. However, it still works and
fixing it with a re-assembly was easier than re-writing
the existing reports to use ASMVTOC or DCOLLECT!
Thanks to Karl Schlichting, CSC New Zealand, NEW ZEALAND.
Change 16.054 Cosmetic. Now, if you try to use TYPETMO2 to read TMON
VMACTMO2 records that were converted to V 8.1 format, member
Apr 25, 1998 TYPETMO2 (which is for native V 2.0 unconverted format)
will tell you that you should be using member TYPETMO8.
Thanks to Diane DePasquale, CSC TMG Warren, USA.
======Changes thru 16.053 were in MXG 16.01 dated Apr 9, 1998======
Change 16.053 Minor errors corrected after first MXG 16.01 tapes:
ASUMPRTR ASUMPRTR now %INCLUDEs IMAC6 and IMAC7072 to protect the
TRND72 _LTY6 and _LTY72 macro names when ASUMPRTR is run as part
VMACIPAC of the MXG QAJOB. TRND72 had RESPSTD located after the
VMACTRSN the ending parenthesis, causing syntax error.
Apr 9, 1998 VMACIPAC syntax error. IF CC=. THEN IF .... changed to
IF CC=. AND IF .... in four lines.
VMACTRNS was deleted again; it was a misspelling that was
removed from 15.15 but crept back into the first 16.01.
======Changes thru 16.052 were in MXG 16.01 dated Apr 8, 1998======
Change 16.052 Another INCOMPATIBLE Year 2000 change, the RDS 6.1 SMF
VMACIPAC record inserted two bytes to change YY to YYYY in four of
Apr 8, 1998 their five subtypes. This change tests variable VERSION
to be NE 'V-1', but I have not been able to verify if the
record version is actually going to be useable to detect
the changed record format. At worst, you might have to
use a different SMF record number for the RDS 6.1 record,
and change the MXG test in VMACIPAC that reads IF VERSION
NE 'V-1' in four places to IF ID=nnn. V-1 is in current
version records, but is also shown in the Mobius copybook
for 6.1, so I don't know if they actually changed the
VERSION field or not. Look for an update to this change
text on our homepage once 6.1 records have been created.
View Direct 6.1 is the new name of RDS / IPAC product.
See revisions in Change 16.085.
Thanks to Clark Jennings, Reynolds Metal, USA.
Change 16.051 Variable RESPSTD, the standard deviation of the average
TRND72 response of ended SRM transactions, is now created in the
TRND72GO TRND72 and TRND72GO trending. The default MXG summary
Apr 8, 1998 level of PERFGRP or SRVCLASS can be changed to break out
each PERIOD, by simply adding variable PERIOD at the end
of the SUMBY= statement in those members, if you want to
see individual periods' data (so you can trend TSO period
one, for example). I cannot safely change my default to
a lower level without potentially destroying somebodys
reports, but you can change it for your site and then
add PERIOD to your reports.
Thanks to Chuck Hopf, MBNA, USA.
Change 16.050 PROC PRINT's that have multiple pages per BY group are
ANALCNCR messed up due to a SAS problem, a conflict between the
Apr 8, 1998 NOBYLINE parameter (which permits us to make reports
prettier) and the existence of an ID statement with the
same list of variables as the BY statement (and we used
BY &SUMBY; ID &SUMBY; to make the reports even prettier).
SAS Usage note V6-PRINT-6788 discusses the error, found
in SAS 6.07, but there will be no fix sooner than SAS
Version 7. So, while the reports are prettier still with
both the NOBYLINE parameter and the ID statement, I have
commented the two ID &SUMBY; statements, so you still get
pretty reports, but now they will print All report pages!
Thanks to Glenn Bowman, Wakefern Food Corporation, USA
Change 16.049 Landmark's TMON Version 2 records that are converted to
TYPEMON8 Version 8.1 format by TMON utility program TMONCNVT are
Apr 7, 1998 now Year 2000 compliant, but the change was INCOMPATIBLE
so you will need MXG 16.01 or later is you still convert
your new TMON records to the old format. Landmark also
replaced the TMMDCCLK field which was a series of packed
fields (0962821314185700 was 96282 13:14:18.57) with a
new value (B043AA3E81B0F701 now for April 6, 1998),
which causes INVALID DATA FOR D12 messages because D12 is
no longer a valid packed field, and since I have no clue
from Landmark documenting this change (I have only a dump
of the record causing that message), and since it is late
at night and I want to wrap up MXG 16.01 before I sleep,
variable TMMDCCLK will be a missing value in these new
Y2K-compliant-8.1-format records, and the INVALID DATA
message is eliminated. Fortunately, TMMDCCLK is an
internal datetimestamp that was not even kept by MXG.
Thanks to Tim Downs, WCI/CSC Warren Ohio, USA.
Thanks to Mike Cezarro, City of Rochester, USA.
Thanks to Kumar Thavakumar, City of Rochester, USA.
Change 16.048 -Support for NTSMF new Object SNA Logical Unit Sessions
EXNTMSES creates new SNALUSES dataset with the same variables as
EXNTSNAL in the SNA Connection Object (dataset SNACONN).
EXNTSNAR -Support for NTSMF new Object SNA 3270 Response Times
EXNTWIDE creates new SNARSPTM dataset with five response buckets
IMACNTSM R3270TH1-R3270TH5 with percentage of responses (whatever
VMACNTSM that is) in each bucket. However, the values are the
Apr 8, 1998 same for each SNACONNM value, so I believe these data
are still wrong in NTSMF 2.1.0 (which had to deal with
the people writing this object not following the rules
to write data correctly!).
-Support for new MS Exchange Event Services object
creates new MSEXCHES dataset.
-Support for the SNA Adapter SnaDlC1 (yep, that's a
lower case l, a upper case C and the numeral one!)
outputs to the existing SNAADAPT, but there is no
longer an SNAADAPT name field. I reused the same
dataset because there never were any NTSMF records
created with the original name field + counters.
-Support for the WideToMBErr object creates new dataset
WIDE2MBE.
-The _BNT macros needed these variables added to the BY
list for the dataset sorts: _BNTPROC has PID added,
_BNTNETI has INTRNAME added, and _BNTMSMC has CONNNAME
added.
Thanks to Jim Quigley, Con Ed, USA.
Change 16.047 Variable JCSPTOD in CICS Journal Segment was validated
VMAC110 for Shared Medical System's journal data, but only with
Apr 7, 1998 CICS Version 2 data. The CICS/ESA logic in VMAC110 still
had JCSPTOD ?? PDTIME4., which produced wrong values.
The logic from V2 journal was copied into the CICS/ESA
journal processing logic. This error impacts you
only if you were decoding your own journal segments.
Thanks to John Croasdale, Barclays Bank Group, UK.
Change 16.046 New ASUM member to summarize TYPE42DS (SMS Interval
ASUM42DS I/O activity) by dataset to report total I/O to each
Apr 6, 1998 dataset from all users, counting the number of users
using that dataset during each interval.
Thanks to Simone Niemczura, FISERV, USA.
Change 16.045 -Support for Internet Information Services Global Object
EXNTSMTP Version 4.0 in INCOMPATIBLE with Version 3.0; the two
EXNTWEBS counter objects Cache Size and Cache Used, MXG variables
IMACNTSM CACHSIZE and CACHUSED in dataset IISG, were removed by
VMACNTSM the new 4.0 version of IIS.
Apr 3, 1998 -Support for Active Server Pages object's nearly complete
restructure, with 14 fields kept from prior version,
with 19 new fields added, and these 10 fields deleted:
ASTHPOCU ASRQCURR ASRQERRT ASRQTOEX ASRQTONQ
ASCOMFAI ASMEMUSE ASMEMFRE ASRQBREX ASRQTOTQ
-Support for new FTP Service Object replaced the previous
FTP Server Object, but MXG outputs into the same FTPSERV
dataset that was built from the prior FTP Server Object.
The only difference between the old and new objects is
that the new FTP Service Object has an instance field,
new MXG variable FTPSERVR (name of the FTP Server), that
did not exist in the old FTP Server object.
-Support for new Web Service Object creates new WEBSERV
dataset; this new Web Service Object logically replaces
the previous HTTP Service object that created MXG HTTP
dataset, but as many HTTP fields no longer exist in the
new Web Service Object, and as there are many new fields,
the new WEBSERV dataset must be used in place of HTTP.
-Support for new SMTP Server Object creates new SMTPSERV
dataset.
Thanks to Leigh Ann Payne, Wachovia Operational Services, USA.
Change 16.044 The JCL example had //DB2ACCT DD pointing to the DB2ACCT
ANALDB2C dataset, but the default in IMACDB2 creates PDB.DB2ACCT,
Apr 2, 1998 so the example now has //PDB instead of //DB2ACCT.
The newer combination of ASUMUOW and ANALUOW are really
the better tools for matching CICS and DB2 transactions.
Thanks to Alfred Holtz, Merck Medco, USA.
Change 16.043 -ASUMIDMS was touched up. Variable TASTTYPE and TASKTYPE
ASUMIDMS now have their length set as $1 and @26 respectively, in
TESTUSER LENGTH statements instead of FORMAT statements. The
TRNDIDMS -TESTUSER was touched up. The hardcoded IDMSxxx dataset
Apr 2, 1998 names were replaced by the _LIDMxxx macro names.
Jan 19, 1999 -TRNDIDMS is a new contribution from Alan, based on the
TRNDCICS member of MXG, and provides IDMS trending.
-Updated Jan 19, 1999: In ASUMIDMS, the line that read
TSKTIMUS=TASTIMWT; was changed to TSKTIMUS=TASTIMUS;
Thanks to Alan Deepe, Perot Systems, ENGLAND.
Thanks to Richard S. Ralston, Whirlpool, USA.
Change 16.042 Using TYPERACF to read the unloaded RACF database that is
VMACRACF created by IBM utility IRRDBU00, variable OMVSPROG was
Apr 2, 1998 not created in dataset RACF0270, but now it is, being
INPUT @1050 as a $CHAR200 variable.
Thanks to Randy Shumate, LEXIS-NEXIS, USA.
Change 16.041 Change 15.320 inadvertently changed the PDB to PDBMXG in
UTILCONT two places and lost an &, so this new utility to print
Apr 2, 1998 the contents (in mega-bytes and obs) of SAS datasets in
a SAS Library fails. Change both PDBMXG to PDB, and
add the missing & to %LET PDB=%UPCASE(&PDB); .
Thanks to Rick Salazar, City of Long Beach, USA.
Change 16.040 Corrupted type 42 subtype 6 caused INPUT EXCEEDED error.
VMAC42 The record has SMF42PDL=DFSMSV1R and SMFPDN='DF TP' but
Apr 2, 1998 the rest of the product section is trash and the record
is longer than its triplets indicate is should be!
The INPUT EXCEEDED occurs because MXG did not validate
that the offset field in the PRODUCT section was less
than the record length. To detect and delete these
corrupted records, insert this circumvention:
IF OFFJDDS+LENJDDS GT LENGTH+1 THEN DELETE;
after the statement LOOP42:
The actual MXG change was more extensive, and will
produce a diagnostic message on the SAS log that the bad
record is being skipped.
Thanks to Melanie Floyd, United Parcel Service, USA.
Change 16.039 Year 2000 only. READTIME in TYPE6 will be 1900 for a job
VMAC6 read in year 2000. MXG's protection for CA-Dispatch's
Apr 2, 1998 corruption of the first byte of julian date was resetting
May 14, 1998 the century bit to zero. The statement in VMAC6 could
have been changed from
IF SUBSTR(READCADI,5,1) GT '00'X THEN
SUBSTR(READCADI,5,1)='00'X;
/*CA-DISPATCH CORRUPTION FIX*/
to
IF SUBSTR(READCADI,5,1) GT '01'X THEN
so both year 2000 and CA corrupt records can be processed
correctly. Following text revised May 14, 1998.
However, the actual change that I made was to remove the
protection for the CA corruption, since their current
versions must be installed for year 2000 anyhow, and the
MXG heuristic protection is just another opportunity for
a future error! This error would also have affected
BUILDPDB; the print records would not match the READTIME
of the other job records, so they will create separate
obs in PDB.JOBS with the 1900 date and only print
resources, while the real PDB.OBS with 2000 date will
have no print resources counted.
Thanks to Arzina Merali, Alberta Public Works, CANADA.
Thanks to Joe Zelyas, Alberta Public Works, CANADA.
Taught 3-day class in Dallas, Mar 30 - April 1, 1998.
Change 16.038 Cosmetic. Messages about INVALID SUBTYPE VALUES that
VMXGGETM seemed endless are now printed only for the first five
Mar 27, 1998 records in this utility used to create SMFSMALL file.
Thanks to Joe Zubras, Pennsylvania Hospital, USA.
Change 16.037 Cosmetic. Format $MG028ST was created by Change 13.072,
VMAC28 but was supposed to be used for variable LSCDSTYP, but
Mar 27, 1998 that was only accomplished now, with this change.
Change 16.036 Nine instances of "=F" must be changed to "@" in this
ANALMULT example report; different character translation tables
Mar 27, 1998 were used during transmission of this member.
Change 16.035 Year 2000 Support for AS/400 was incorrect. There are 44
VMACQAPM instances of IF YY GT 0 THEN ... that must be changed to
Mar 27, 1998 IF YY GE 0 THEN ....
and the four lines preceding GDES1=MDY(MO,DD,.... that
input variables YY MO DD and CC with informat &NUM.n.
need double-questionmarks between the variable and the
informat, eg., YY ?? &NUM.2.
Without this fix, the date variables in the year 2000
(only) will have 1960 dates (Because their value is zero
and the zero SAS date is 1960.
Thanks to Mike Wroot, SAS UK Customer Support, ENGLAND.
Thanks to Paul Hill, Midland Bank, ENGLAND.
Change 16.034 Support for DECnet/SNA DTF SMF records creates nine new
EXDECS01 MXG datasets:
EXDECS03 Subtype Dataset Description
EXDECS04 01x *DECSSTAR DECNET/SNA ADDRESS SPACE START
EXDECS05 03x *DECSBEGN DECNET/SNA SESSION BEGIN
EXDECS06 04x *DECSEND DECNET/SNA SESSION END
EXDECS07 05x DECSDIR DECNET/SNA DIRECTORY REQUEST
EXDECS08 06x *DECSALOC DECNET/SNA FILE ALLOCATION
EXDECS09 07x DECSOPEN DECNET/SNA FILE OPEN
EXDECS0C 08x *DECSCLOS DECNET/SNA FILE CLOSE
EXDECS0d 09x *DECSERAS DECNET/SNA FILE DELETE
EXDECS0f 0Cx DECSREQB DECNET/SNA IBM REQUEST BEGIN
EXDECS10 0Dx DECSREQE DECNET/SNA IBM REQUEST END
FORMATS 0Fx DECSTERM DECNET/SNA ADDRESS SPACE TERMINATE
IMACDECS 10x DECSRCAL DECNET/SNA DATASET RECALL ON DIR
TYPEDECS The six datasets prefixed with '*' above have been
VMACDECS tested with data records.
Mar 26, 1998
Thanks to Brian Harvey, Navistar International Transportation, USA.
Change 16.033 IDMS 10.2 records were not output, so all seven lines
VMACIDMS with IF 'xxxx' LE SMFHVER LT '1400' THEN DO; were
Mar 25, 1998 changed to IF SMFHVER LT '1400' THEN DO;
Thanks to Ron Larue, FDISG Boston, USA.
Change 16.032 The MXG DISCOVERY. NO STRUCTURE MATCH. NON FATAL message
VMAC74 should no longer occur. The message was printed when a
Mar 25, 1998 structure in the Request Data Section was not found in
the Structure Data Section, and the only impact was that
variable R744QSIZ in TYPE74ST would be missing for that
structure name in that observation. But now, having
examined sample mismatches, I find that there is an entry
for the Structure in the Request Data Section, but there
is no corresponding entry in the Structure Data Section,
and the Request Data Section has R744SFLG='00000000'B, so
this structure neither was Online at End of Interval, nor
did it Become Active during the interval, but it had been
connected at the start of the interval, hence the Request
Data Section. But IBM explains that the Structure data
is a snapshot at interval end of all allocated structures
in the coupling facility (returned by IXCQUERY), and as
the structure was not allocated at interval end, there is
no structure data. This accounts for the mismatch, so
now, the mis-match message won't be printed when R744SFLG
is zero.
Thanks to Steve Smith, BGS, USA.
Change 16.031 CICS UNEXPECTED STATISTICS RECORD with STID=0 or = large
VMAC110 was caused by incorrect processing of STID=94 record. The
Mar 25, 1998 +11 after LGSAUTOP was INPUT must be +7. This also caused
zero observations in dataset CICLGS.
Thanks to Steve Smith, BGS, USA.
Change 16.030 Variable ABENDUSR in dataset CIMSPROG has never been
VMACCIMS right. The equation ABENDUSR=MOD(ABENDSYS,16)+ABENDUSR;
Mar 24, 1998 must be replaced with ABENDUSR=MOD(ABENDUSR,4096); and
ABENDUSR must be removed from the HEX4 format statement
as IMS User Abends range from 0 to 4095, not 0 to FFFx,
so they will now print as decimal by default.
Thanks to Karen Sherman, Franklin-Templeton, USA.
Thanks to Wayne Collins, Franklin-Templeton, USA.
Change 16.029 Variable R723CIMP (Importance Level) was in the SUM=
TRND72GO argument, making it meaningless in non-zero CPU Dispatch
Mar 24, 1998 times and non-zero Percent CPU Busy values.
Change 16.028 MXG 15.15-15.07 Only. For PR/SM Deactivated Partitions,
ASUM70PR observations were created that had non-zero CPU Dispatch
VMAC7072 times and non-zero Percent CPU Busy values, which when
Mar 24, 1998 summed into ASUM70PR could record more than 100% CPU Busy
for the CEC. Fortunately, very few sites have Partitions
Deactivated, but if you have this error, there will be
observations in TYPE70PR with LPARCPUS=0, as that is the
Deactivated Partition flag.
If you do have LPARCPUS=0 obs, you can correct the old
PDB.TYPE70PR data simply by deleting TYPE70PR obs with
LPARCPUS=0, and then re-run ASUM70PR (which reads the
corrected TYPE70PR dataset) to re-create the corrected
PDB.ASUM70PR dataset:
DATA PDB.TYPE70PR; SET PDB.TYPE70PR;
IF LPARCPUS=0 THEN DELETE;
%INCLUDE SOURCLIB(ASUM70PR);
You can prevent the creation of LPARCPUS=0 observations
in tomorrow's PDB by adding an IF test before the OUTPUT
statement in member EXTY70PR:
IF LPARCPUS GT 0 THEN OUTPUT ....;
until you install this change or MXG 16.01 or later.
The Permanent Fix. Change 15.299 created observations
for the Deactivated Partitions (for availability
reporting) but it failed to reset the variables from the
previous segment in this record. The permanent fix is to
insert these lines immediately after the existing IF:
IF LPARCPUS=0 THEN DO;
LCPUPDTM=.;
LCPUADDR=.;
LCPUSHAR=.;
LPARVPF =.;
LCPUEDTM=.;
LCPUDED =' ';
LCPUWAIT=' ';
LCPUCHST=' ';
LCPUCHWT=' ';
LCPUCAP =' ';
LCPUCAPC=' ';
ORIGWAIT=.;
NEWWAIT=.;
PCTCPUBY=.;
PCTMVSBY=.;
Thanks to Wayne Lauck, State of South Dakota, USA.
Change 16.027 While Change 15.273 mentioned that JES3 APAR UW41108
VMAC26J3 was required to fix an IBM error in the JES3 type 26
Mar 23, 1998 purge record, it did not protect the absence of that
APAR. By inserting IF LENGTH-COL+1 GE 10 THEN
immediately before the INPUT SMF27LN7 &PIB.2.
statement, even if the APAR is not installed, MXG won't
fail.
Thanks to Pete Gain, SAS Software, ENGLAND.
Change 16.026 New subtype 6 SMF type 99 record caused INVALID SERVER
VMAC99 SECTION TRIPLET because SMF99CPO=SMF99CPO+SMF99CPN;
Mar 22, 1998 should have been SMF99CPO=SMF99CPO+SMF99CPL;
This also caused truncated values for SRVCLASS.
Thanks to Steve Smith, BGS Systems, USA.
Change 16.025 "SHORT ABAR" warning messages about deleted records could
VMACHSM be erroneously created. Insert the INPUT statement below
Mar 22, 1998 between the ELSE DO; and the LENGTH-COL test so it reads:
ELSE DO;
INPUT @15+OFFSMF @;
IF LENGTH-COL+1 LT 274 THEN DO;
The COL value was still @40 as a result of the prior
INPUT, so records that were sufficiently long were
incorrectly deleted, but with the warning message.
Thanks to Don Friesen, B.C. Government, CANADA.
Change 16.024 -Support for new object "Database" creates new MXG dataset
EXNTDATA named DATABASE. This object has 104 fields in the record
IMACNTSM but only 16 are populated with field names and data.
VMACNTSM -Support for EXCHANGE 5.5 (INCOMPATIBLE) inserted data in
Mar 21, 1998 seven MS Exchange objects (IMC, IS Private, IS Public,
IS, Internet Protocols, MTA, and MTA Connections), which
caused INVALID TRIPLET warnings and skipped records until
this change is installed. Scores of variables were added
and some no longer exist in the Exchange records.
-Messages INVALID DATA FOR DURATM for Discovery Records
(Discovery Records have OID=0) occurs with NTSMF 2.1.4
records, but it has no impact on the real datasets that
MXG creates. The format of the Discovery Records was
changed, causing the MXG message.
-In addition, the _UNTDISC utility to print the Discovery
Records no longer worked with Release 2.0.h, which has a
NRNAMES field only in the 0.5 and not in the 0.6 or 0.6,
and there is an extra field at the end of each 0.7 record
that contains a repeat of the penultimate field. Also,
records from NTSMF 2.1.4 have still different Discovery
records, but the NTSMF Version is still 2.0.h, so logic
based on whether DURATM is missing or not (because the
new format has OBJECT name where DURATM was) is used to
decode which Discovery Format is in place, so that
_UNTDISC is now functional.
Thanks to Jim Quigley, Con Edison, USA.
Change 16.023 Change 15.368 added the DURATM=INTERVAL parameter to the
ASUMJOBS VMXGSUM invocations in most ASUM members, but ASUMJOBS
Mar 20, 1998 was overlooked until now.
Thanks to Chris Weston, SAS Institute ITSV, USA.
Change 16.022 Only for those few who use the &DEBUGMXG symbolic during
VMXGSUM testing is this minor fix needed. The three lines
Mar 20, 1998 %IF &MXGDEBUG GE 2 ...; %ELSE %IF &MXGDEBUG GE 3 ...;
May 14, 1998 and %ELSE %IF &MXGDEBUG GE 4 ....; need the %ELSE
removed from the second and third lines.
This Change was not included in MXG 16.01, but was in
MXG 16.02.
Thanks to Graham Bell, Blue Cross Blue Shield of Kansas, USA.
Change 16.021 The TRENDing of TYPE70 dataset had not been updated for
TRND70 more than 8 CPUs. While TYPE70 contained sixteen buckets
Mar 20, 1998 for CPU's (variables suffixes 0-9,A,B,C,D,E,F), but the
TRND70 member was overlooked when variables 9 and above
were added to TYPE70. The lists of these variables were
expanded: CPUWAITn, IORATEn, PCTCPBYn, PCTTPIn, VFAFFTMn,
and logic added for PCTTPIn, PCTCPBYn and PCTRDYWT
calculations.
Thanks to Graham Bell, Blue Cross Blue Shield of Kansas, USA.
Change 16.020 Support for Software Engineering's SpaceManager's two
EXSPMGSP flat files, Space Records and Volume Records create two
EXSPMGVL new datasets:
FORMATS SPMGSPAC - SpaceManager Space Records
IMACSPMG SPMGVOL - SpaceManager Volume Records
TYPESPMG MXG requires both a //SPMGSPAC DD and a //SPMGVOL DD and
VMACSPMG will read both files with member TYPESPMG. If you only
Mar 20, 1998 want to process one file, simply DD DUMMY the unwanted.
Apr 7, 1998 Several new $MGSPMxx formats are created, so you will
need to update your MXG Format library using this new
FORMATS member.
Thanks to Hans Juergen-Beck, DVG, GERMANY.
Change 16.019 -Variables TPXBYTI and TPXBYTO have always been wrong, due
VMACEPIL to an error in CA's documentation. Instead of being two
VMACOMAU 8-byte fields, they are now input as &PIB.4. and a line
VMACOMCI with +4 follows each to skip over the unused 4-bytes.
VMACTPX -It was also noted that all of the internal TPX datetimes:
VMAC39 TPXETIME, TPXSTIME, TPXUTIME were on the GMT clock, while
Mar 20, 1998 the SMFTIME is on the local clock, but there is a GMT
Apr 6, 1998 offset in the record, so now, MXG converts those three
timestamps into local. The CVTTZ field in the record is
the high four-bytes of the GMT offset, which is not an
exact value, so the following algorithm is required to
get the GMT offset in seconds into TPXCVTTZ:
INPUT TPXCVTTC $CHAR4. @;
TPXCVTTZ=INPUT((TPXCVTTC!!'00000000'X),&IB.8.6)/4096;
IF . LT TPXCVTTZ LT 0 THEN TPXCVTTZ=FLOOR(TPXCVTTZ);
ELSE TPXCVTTZ=CEIL(TPXCVTTZ);
For example values, the raw TPXCVTTC is '00000D69'x for
a +1 hour (3600 seconds) European offset, and for a -5
hour (-18000 seconds) USA EST is 'FFFFBCF2'x.
Then to correct timestamps to local, you add TPXCVTTZ:
TPXETIME=TPXETIME+TPXCVTTZ;
-In validating this change, I looked at all of the members
that contain CVTTZ and I discovered that in four members,
VMACEPIL, VMACOMAU, VMACOMCI, and VMAC39, I had reversed
the FLOOR and CEIL functions, which caused a one second
error in value of the GMT offset, so those four members
were also corrected by this change.
Thanks to Harry Olschewski, DeTeCSM, GERMANY.
Change 16.018 Member DOCGRAF is updated with examples of getting graphs
DOCGRAF from the mainframe to your PC. The new examples were
Mar 20, 1998 originally postings on our MXG-L ListServer.
Thanks to Bob Hare, Comerica, INC, USA.
Thanks to Neal Musitano, Jr., Department of Veterans Affairs, USA.
Change 16.017 The three DSORG fields in DCOLLECT (DCDSORG,UMDSORG, and
VMACDCOL UBDSORG) are increased to three bytes long from two, and
Mar 19, 1998 the suffix "U" will be added (e.g., DSORG='PSU') for the
files that "contain location dependent information, the
old "Unmoveable" attribute. I had erroneously set the
DSORT='U' for the Unmoveable attribute.
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Change 16.016 Change 15.356 introduced the &MACxxxx macros, but member
IMACFILE IMACFILE was overlooked. Now, &MACFILE is initialized as
VMXGINIT blank in VMXGINIT and a line with only &MACFILE now ends
Mar 18, 1998 member IMACFILE (which is included after the SMF header
has been input), so that any tailoring of member IMACFILE
(formerly done EDIT and SAVE into your USERID.SOURCLIB)
and now be done inline by setting the &MACFILE variable.
Because this &MACFILE variable will be inserting actual
SAS statements with semi-colons, the always-safe-syntax
to use to insert statements in &MACFILE is:
%LET MACFILE= %QUOTE(
LINE OF CODE TO BE EXECUTED ;
LINE OF CODE TO BE EXECUTED ;
LINE OF CODE TO BE EXECUTED ;
) ;
For a specific example, your //SYSIN program could be:
%LET MACFILE= %QUOTE(
IF ID=110 AND SUBTYPE=2 THEN DELETE;
) ;
%INCLUDE SOURCLIB(TYPE110);
would delete the CICS subtype 2 (Statistics) records so
no //WORK space would be needed by them, but would read
the CICS subtype 1 transaction records to create CICSTRAN
observations. Note that while the references are
&MACFILE, the %LET syntax does not use the ampersand.
If you have an-already-tailored IMACFILE member, you must
either add &MACFILE to the end of your tailored member
(so that any code added inline with &MACFILE will be
executed AFTER the code in member IMACFILE), or you must
remove your tailored IMACFILE member and do all your
tailoring in the %LET MACFILE= statements.
For reasons that are still unclear, it was necessary to
add a semicolon after the &MACFILE statement in the
IMACFILE member to satisfy the SAS compiler under MS
Windows, but not under MVS!
Thanks to Chuck Hopf, MBNA, USA.
Change 16.015 Documentation. Variable JCSPTIME had been INPUT but not
VMAC110 kept, but was re-spelled as JCSPTOD when it was added to
Mar 17, 1998 the KEEP= list for dataset CICSSMED in Change 15.157.
Thanks to Jens Schlatter, Independent Consultant, GERMANY.
Change 16.014 Variables XMGMXT and XMGTNUM were not kept in CICINTRV
CICINTRV dataset (in CICS 4.1 XMGMXT replaced DSGTL's MAXTASK
Mar 16, 1998 limit; DSG fields for AMAXTASK no longer exist in 4.1).
In the last VMXGSUM invocation in member CICINTRV, add
XMGTNUM to the SUM= argument and XMGMXT to the MAX=.
Thanks to Steve Donahue, Blue Cross and Blue Shield of Texas, USA.
Change 16.013 Cosmetic. Variable WTSCWTCN was given FORMAT TIME12.2,
VMACTMO2 but the variable that should have been in the FORMAT
Mar 16, 1998 statement was WTSCWTTM.
Thanks to Chris Weston, SAS Institute ITSV, USA.
Change 16.012 IDMS Version 10.2.1 PMHRTYPE=1 records caused error INPUT
VMACIDMS STATEMENT EXCEEDED RECORD LENGTH. Find the FIRST instance
Mar 16, 1998 of the line reading:
ELSE IF '1201' LE SMFHVER LT '1400' THEN DO; and change
it to read: ELSE IF '1021' LE SMFHVER LT '1400' THEN DO;
Thanks to Alan Deepe, SBC Warburg Dillon Read, ENGLAND.
Change 16.011 Variable SRHCRWRT is now SRCHRWRT to be consistent with
VMACNTSM the other spelling of other SRCHxxxx variables in dataset
Mar 15, 1998 FULCRUM built from NTSMF records.
Thanks to Chris Weston, SAS Institute ITSV, USA.
Change 16.010 Member YEAR2000 now warrants that MXG is (in IBM terms)
YEAR2000 "Year 2000 Ready", and the cover letter that is normally
Mar 15, 1998 sent in reply to year 2000 requests is now included at
the beginning of member YEAR2000.
Change 16.009 Variable MXGVERSN in dataset TYPE70 was blank in 15.15.
VMAC7072 Originally MXGVERSN=SYMGET('MXGVERS'); was before the
Mar 13, 1998 IF (ID=70 OR ID=72) AND NOT MVSXA THEN DO; logic, but
Change 15.354's relocation of IF tests (for BUILDPDB's
performance) inadvertently caused the SYMGET to only be
executed for pre-XA RMF records. The simple fix is to
just copy the three lines:
IF MXGVERSN=' ' THEN DO;
MXGVERSN=SYMGET('MXGVERS');
END;
to immediately follow the IF ... AND MVSXA THEN DO;....
statement, so the SYMGET statement is executed once for
either type of record. However, Don Deese showed me that
RETAIN MXGVERSN "&MXGVERS" ;
will initialize a RETAINed character variable to the
value of a macro variable, so the actual change replaced
the existing RETAIN MXGVERSN ' ' statement with the
above syntax, deleted the three-line DO group on MXGVERSN
and added a line with MXGVERSN $6 to the LENGTH statement
to define MXGVERSN's length.
Users of CPExpert will need to install this change or get
a one-line fix from Don Deese to circumvent my error.
The PROC COMPARE that should have caught this error that
was not run for MXG 15.15 has been reinstated in MXG QA!
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Thanks to Lynn Meyer, Storage Tek, USA.
Thanks to David Ehresman, University of Louisville, USA.
Change 16.008 Duplicate observations in TYPE30_V might not be deleted.
BUILDPDB Change 15.235 discussed the addition of MULTIDD EXTRADD
BUILDPD3 to the BY list for TYPE30_4 and TYPE30_5, but those two
BUILD005 variables were not added to the TYPE30_V sort until this
BUIL3005 change.
Mar 13, 1998
Thanks to Allan Winston, MBNA, USA.
Change 16.007 Cosmetic. Format MGILKAT had repeated 4: for the RETR,
FORMATS APPE, and STOR actions, instead of having 8:RETR, 16:APPE
Mar 13, 1998 and 32:STOR for the format values.
Thanks to Ken Mazer, Internal Revenue Service WVA, USA.
Change 16.006 The ARRAY statement permitted only 10 LCUIDs, causing the
ANALPATH SUBSCRIPT OUT OF RANGE error. The array statement was
Mar 11, 1998 increased to 16, the LCU1-LCU9 instances were change to
LCU1-LCU16 and variables LCU10 thru LUC16 were added to
the initialization logic.
Thanks to Tobias Cafiero, Mercedes Benz of North America, USA.
Change 16.005 Variable PCTDLSSW was added by Change 14.318, but its
VMAC7072 value was incorrect because it was never divided by the
Mar 5, 1998 variable VALDSAMP due the misspelling as PCTLDSSW in the
line in which it should have been divided by VALDSAMP.
Thanks to Chris Weston, SAS Institute CARY, USA.
Change 16.004 Change 15.293 discussed why YEARSECS and YEARDAYS can not
TYPEDMS be used to protect non-Y2K-compliant date fields, but the
TYPEMON8 code in these four non-compliant products was not changed
TYPETMON until this change, which uses smart logic to protect.
VMACNSM
Mar 5, 1998
Change 16.003 IBM's NPM product now creates a "century" value in their
VMAC28 unique date fields, but the new and unexpected format of
YEAR2000 'CYYMMDDF'x is still not documented by IBM. APAR II10481
Mar 4, 1998 does make the following statement:
Mar 9, 1998 "97/04/30 NPM will support the year 2000. User's do
not need to do anything special.
Further details provided by NPM development:
NPM's SMF record header contains the date (SMF28DTE)
in the form 0CYYDDDF, where the '0C' represents the
century. This byte contains '00' in this century
(the 20th century) and will contain '01' in the 21st
century. Therefore, for any NPM record, it is always
possible to identify the century"
but nothing in that Informational APAR said that the 99
internal date values (like start and stop times!) were
changed to CYYMMDDF, which is a new brand new date format
that exists in no other SMF record, and that new format
causes an INVALID ARGUMENT error when MXG 15.15 read NPM
records with year 2000 dates. So NPM users do in fact
have to do something special - they now have to install
(unnecessarily) a new version of MXG because the NETVIEW
NPM product did not document their INCOMPATIBLE changes
to type 28 SMF records!
And in addition, one field in NPM, LXETTMST, has yet
another unique date format of "MM/DD/YY.DDDHH.MM.SS"
which does not have room for a "century" nybble, so NPM
is still NOT YEAR 2000 READY. However, by adding MXG
windowing protection (YY LE 59) for LXETTMST, I have now
changed member YEAR2000's NPM entry to move NPM from the
"IS NOT" to "NOW IS" YEAR2000 compliant, even though NPM
really is not compliant without help from MXG logic.
Finally, the implication in the Informational APAR that
only the date field in the SMF header needs a century bit
to be "YEAR 2000 READY" is inaccurate. To truly be YEAR
2000 READY requires that each date value be complete and
self-described. A record that requires programming logic
to test one date field to then set the date of another
date field (which may or may not have been on the same
date as the first date value) is not YEAR 2000 READY.
That IBM ultimately had to change all 99 internal fields
shows that setting only the century bit in the SMF header
was not sufficient!
By the way, NPM APAR, OW28971 is also required to correct
an error in NPM's computation of leap years; without that
APAR, NPM incorrectly thinks 2000 is not a leap year.
This extensive MXG change inserted seven new lines for
each of the ninety-nine date values to decode the new
format, and exists only because CIGNA found the data
values in their year 2000 test partition's type 28 data.
Thanks to Steve Colio, CIGNA, USA.
Change 16.002 IDMS 14.0 new variables TASNINS,TASNUPD,TASNDEL,TASNSRT
VMACIDMS TASNSRR,TASNSMI,and TASNSMX had incorrect labels, and new
Mar 3, 1998 variable TASNAMC was not created. TASNAMC is now INPUT
as &PIB.4. following TASNSMX and the labels corrected.
Thanks to Chris Weston, SAS Institute Cary, USA.
Change 16.001 Variable PKSENOUN was renamed PKSENONU in NTSMF dataset
VMACNTSM NETWINTR for consistency with PKRCNONU, but variable
Mar 3, 1998 PKSENOUN is still built, so your old programs won't fail.
Thanks to Marti Henley, MatriDigm, USA.
LASTCHANGE: Version 16