* copyright (C) 1984-2019 merrill consultants dallas texas usa

Nov 19, 1999 because you can have two copies of the server running in

the same host with same IP Address, differing only in the

Port Number.

Thanks to Joseph J. Faska, Depository Trust, USA.

Change 17.313 Tests for STC11CI, STC11CE, and STC11TOL should have been

VMACSTC IF STC11xx='.......1.B THEN DO .... instead of ='01'.

Nov 17, 1999 Variables were blank without this change.

Thanks to Herb Strazinski,

Change 17.312 The _KSU70PR "Keep/Drop" macro was not referenced in the

ASUM70PR building of ASUM70PR dataset, so variables could not be

Nov 17, 1999 dropped. The token _KSU70PR was added inside the parens.

Thanks to Gary Morris, Centre Link, AUSTRALIA.

Change 17.311 If you had an old IMACPDB from before MXG 16.04, you can

SPUNJOBS get and error DATASET CONDCODE NOT FOUND. Removing your

Nov 12, 1999 old IMACPDB and instead using the new %LET ADDnn= macro

variables will correct the error, but this change also

protects by using the same logic in BUILD005 to create a

zero obs CONDCODE dataset.

Thanks to Rudolf Werner, Audi Ag, GERMANY.
Change 17.310 Input statement #25 (STIVSR36-STIVSR44) should have been

VMACCADM #25 (STIVSR37-STIVSR44).

Nov 12, 1999

Thanks to Freddie Arie, Lone Star Gas, USA.

Change 17.309 The remaining subtypes of CA-VIEW Metrics have now been

VMACSARR validated and corrected. Segment tests were change to

Nov 12, 1999 IF SV31xOF+SV31xLN-1 LE LENGTH AND SV30xLN GE 1 THEN DO;

and the input of SV30IVAL now uses SV30IVLN vice SV30INLN

to eliminate INPUT STATEMENT EXCEEDED on some subtypes.

Thanks to Bruce Sloss, PNC Bank, USA.

======Changes thru 17.308 were in MXG 17.08 dated Nov 12, 1999======
Change 17.308 Support for the SQL*NET Network Information Vector, added

VMACORAC to the Oracle user SMF record. New variables IPADDR and

Nov 12, 1999 PORTNR for TCP/IP connnections or NIVNETNM and NIVLUNAME

for SNA connnections are created and kept.

Thanks to Sudie Wulfert-Schickedanz, Anheuser-Busch, USA.
Change 17.307 Support for APAR OW41147 to recognize ORGEXPDT=0099999 as

VMACDCOL a "valid" migration date when creating variables DCDEXPDT

Nov 12, 1999 and UMEXPDT. This change (insert before ORGEXPDT=9999999

in two places the line ORGEXPDT=99999 OR ) corrects

SAS dates to be "MXG infinite" date in 2099 instead of to

be missing in DCDEXPDT or UMEXPDT. However, the variable

ORGEXPDT is unchanged, so you can use your current MXG to

examine your DCOLLECT datasets DCOLDSET and DCOLMIGS, and

if you have any datasets with ORGEXPDT=99999, then you

MUST either install that APAR or follow its instructions

to prevent unexpected loss of any SMS dataset with its

ORGEXPDT=99000 on Jan 1, 2000. What is critical is that

you read the APAR and see if it has impact on our site.

This MXG change is not required for year 2000 support in

MXG Software.
Change 17.306 Support for CA VIEW Metrics report program SARSMFUX SMF

EXSARR20 records create seven datasets:

EXSARR21 Dataset Label

EXSARR30 SARRU20 User Logon

EXSARR31 SARRU21 User Logoff

EXSARR32 SARRU30 Report was viewed

EXSARR33 SARRU31 Report was reprinted

EXSARR34 SARRU32 Report was loaded to database

TYPESARR SARRU33 Report was deleted

TYPSSARR SARR&34 Report was deleted from disk

VMACSARR

Nov 11, 1999

Thanks to Bruce Sloos, PNC Bank, USA.
Change 17.305 Support for RACF General Resources Started Task subtype

EXRAC540 540 in RACF Database Unload Utility IRRDBU00 file.

IMACRACF

VMACRACF

Nov 11, 1999

Thanks to Randy Shumate, LEXIS-NEXIS, USA.

Change 17.304 Counts could be negative in TYPE1032 Web Server dataset,

TYPE103 because the accumulated counters are reset each time the

TYPS103 server is "bounced". Now, MXG interleaves the subtype 1

VMAC103 (start) and 2 (interval) records to eliminate negative

Nov 11, 1999 values. Additional protection prevents negative values

if a subtype 2 is read before a subtype 1, or if data

records were lost, for the first subsequent record.

Member TYPE103 or TYPS103 both now invoke the DIFF103

member to sort both TYPE1031 and TYPE1032 datasets.

(So the //PDB ddname is required for TYPE or TYPS103).

Thanks to Joseph J. Faska, Depository Trust, USA.
Change 17.303 IMF DB2 counts are lost in datasets CIMSTRAN and CIMSDB2

VMACCIMS in MVIMF 3.2, because BMC enabled IOWAITS by default,

Nov 11, 1999 which puts some SQLCALLS in a new, undocumented DBORG=00x

Nov 19, 1999 DBD segment, instead of the documented DBORG='80'X DBD.

Sep 15, 2000 IOWAITS is the MVIMF Event Collector DBIO initialization

parameter, and the new 00x segment accounts for sync

point write activity and is also flagged by the

PLANNAME='ALLDBS'. MXG previously only knew about the

80x DBD, so the new 00x segments were decoded incorrectly

and output to the CIMSDBDS instead of CIMSDB2. And while

MVIMF documentation said there would be only one '80'x

segment, logic was added to sum SQLCALLS for these

multiple segments into CIMSTRAN. The drop in SQLCALLS

coincided with installing IMF 3.2.61.

This change was not correct. See Change 18.225.

Thanks to Winfried Waldeyer, BHF Bank, GERMANY.

Change 17.302 Format $MG074PT expected 'F1'X or 'F3'X, but actual data

FORMATS values are '01'X or '03'X, so the format now supports

Nov 11, 1999 both formats, just in case.

Thanks to Alan M. Sherkow, I/S Management Strategies, Ltd., USA.

======Changes thru 17.301 were in MXG 17.08 dated Nov 10, 1999======
Change 17.301 Variable DURATM was not created in PDB.CICS built with

ASUMCICX member ASUMCICX. Insert DURATM=INTERVAL, before the

Nov 10, 1999 INTERVAL=HOUR, macro argument.

Thanks to Alan Deepe, Perot Systems Europe, ENGLAND.

Change 17.300 If DB2 stays up long enough, and does enough SELECTs, the

ANALDB2R four-byte accumulated counter in the type 100 SMF records

VMACDB2 can wrap, causing MXG to create a negative value when it

Nov 10, 1999 DIF()'d the adjacent observations. Now, each DIF() is

followed by a test for four-byte wrapping of the form:

IF . LT Qxxxxxxx LT 0 THEN Qxxxxxxx=Qxxxxxxx+4294967296;

in member VMACDB2 (the "DIFFDB2" logic was relocated into

the _SDB2xxx sort macros in MXG 16.04 redesign). Also,

several fields in MXG's ANALDB2R reports were not wide

enough for large values, causing SAS to print exponential

notation (valid, but confusing to neophytes), so they are

now expanded along with other minor report revisions.

Thanks to Victor Chacon, Bell Atlantic Mobile, USA.
Change 17.299 MXG Variable CECSER is created by substringing the last

VMAC7072 four nybbles of the three byte CPUSER to get the hardware

Nov 9, 1999 serial number of the "CEC" or "CPC", (i.e., the box), but

Nov 10, 1999 CPU segments have been found with 'E03333'X instead of a

valid CPU Serial Number. These segments are all flagged

for an engine "not online at the end of the interval", or

"came online during the interval", and the CPUSER is not

valid in those instances. So now, MXG sets CECSER only

IF CECSER GT '000000'X AND CAI EQ '......01'B THEN ...

so that only CPUs that were online at the end of the

interval and had not come online during the interval

will be used to set the CECSER. Note, however, that

CPUSERnn (CPUSER stored into a serial number for each

CPU) will still contain whatever CPUSER value was in

its CPU segment if CAI had any bits turned on.

Thanks to Linda Berkley, Amdahl, USA.

Change 17.298 Batch Pipes datasets TYPE9112, TYPE9113, and TYPE9115 now

FORMATS contain the Input and Output counts summed from all of

VMAC91 the IEC and OEC connection segments for the End, Close,

Nov 9, 1999 or Delete events, and the Highest Error Code from those

Nov 27, 1999 connection segments. Format $MG091EC was also updated.

Nov 27: additional formats added to $MG091EC.

Thanks to Michael Oujesky, MBNA Hallmark Information Services, USA.
Change 17.297 Support for unix PerfMeter Freeware Monitor that creates

EXTYPMTR interval resource data on CPU, PKTS, PAGE, SWAP, INTR,

IMACPMTR DISK, CNTXT, LOAD, COLLS, and ERRS rates in new dataset

TYPEPMTR PERFMETR. This monitor is free from Sun MicroSystems,

TYPEPMTR for their unix.

VMACPMTR

VMXGINIT

Nov 8, 1999

Thanks to Michael Lefkofsky, Wayne State University, USA.
Change 17.296 The de-accumulation logic in DIFFTPX caused NOT FOUND as

DIFFTPX was not updated; now it has only _STPXINT invocation, as

Nov 8, 1999 deaccum is now done in the data set sort macro.

Thanks to Mike Shapland, PKS Information Services, Inc.

Change 17.295 The creation of ZDATE in this VMAC member was replaced by

VMACCTLT %%INCLUDE SOURCLIB(IMACZDAT); to be consistent with the

Nov 8, 1999 rest of MXG VMACs. The ommission was an oversight.

Thanks to Steve Clark, California Federal Bank, USA.

Change 17.294 MXG 17.06 added macro _CICXC13 to support excluded fields

IMACEXCL for CICS/TS 1.3, but the "END; /* END CICS TS 1.3 ..."

Nov 8, 1999 line number 547, must be deleted to use the 1.3 Excludes.

Thanks to Alan Deepe, Perot Systems Europe, ENGLAND.

Change 17.293 TYPEIMSA did not include member IMACKEEP; now it does.

TYPEIMSA This should have been included in Change 17.228 but was

Nov 8, 1999 overlooked.

Thanks to Gilles Fontanini, SAS Institute, FRANCE.

Change 17.292 Variable SMF6DDNM contains hex zeros for DDNAME in some

IMAC6ESS type 6 SMF records (perhaps spin data sets?), but the ESS

VMAC6 segment appears to have the DDNAME in the SWBTU text, so

Nov 5, 1999 this change inputs new variable SMF6TUDD from ESS segment

and stores SMF6TUDD into SMF6DDNM if SMF6DDNM is blank or

nulls. I'm still seeking the DSECTS for the SWBTU, and

the ESS segment itself is incorrectly documented in the

SMF manual and the DSECT, to make sure this is permanent.

Thanks to Hartmut Richter, BASF Computer Services GmbH, GERMANY.
Change 17.291 -Variable PERFINDX in dataset TYPE72GO was non-zero when

EXTY72DL it should have been missing for Service Classes with a

EXTY72GO Percentage goal. MXG calculated PERFINDX even when there

VMAC7072 were no transactions completed in the interval. Now, the

Nov 5, 1999 statement ELSE IF R723CRGF='P' THEN DO; was changed to

read ELSE IF R723CRGF='P' AND TRANS GT 0 THEN DO; so that

PERFINDX will be missing when TRANS=0. Additionally,

PERFINDX was not reinitialized for each Period, and thus

it could have been carried forward as non-zero when it

should have been missing. However, PERFINDX will always

be missing in Reporting Class (RPRTCLAS='Y') observations

and in observations for Service Classes that have System

or Discretionary Goals (R723CRGF='S' or 'D'). PERFINDX

will also be missing if the percent of transactions that

meet the goal falls into the 14th (last) bucket, which
make it impossible to calculate the PERFINDX. On RMF

reports, IBM prints four asterisk for the index; you

can recognize these cases in MXG because R732CRGF='P',

PERFINDX=., but TRANS or TRANSEXC will be non-zero.

-Observations were output in TYPE72GO for Service Classes

that had no resources nor transaction completions. The

variable NOACTVTY was non-zero (indicating activity) when

it should have been zero. Logic in VMAC7072 was revised

so R723RESS (trans states sampled) is no longer included

in NOACTVTY, and VELOCITY and PERFINDX are initialized

for each period (they were propagated into subsequent

periods in the same record that had no activity), and the

logic in EXTY72GO now tests only

IF NOACTVTY GT 0 THEN OUTPUT _WTY72GO;

-Observations were also output in TYPE72DL where there

were no delay samples. Now, EXTY72GO was revised so that

observations are only output in TYPE72DL when R723RESS is

non zero (i.e., there were transaction states sampled).

Thanks to Tan York Sin, Stock Exchange of Singapore, SINGAPORE.
Change 17.290 MXG 17.07 IMS code still had negative RESPNSTM/SERVICETM

ASMIMSLG in 5704 (out of 130000) IMS transactions. Data records

ASMIMSL5 for this (yet another!) unique sequence of IMS log events

ASMIMSL6 plus lots of detailed digging thru mounds of data allowed

JCLIMSLG Carl to enhance MXG for these new IMS idiosyncrasies:

JCLIMSL5 1. TYPEIMSA corrected 5411 of the negative cases, which

JCLIMSL6 included all of the negative RESPNSTM values. Logic

TYPEIMSA added protects when ENDTIME is less than GUTIME. This

Nov 10, 1999 left 293 transactions with negative SERVICTM.

2. ASMIMSLx assembly program revision protects cases when

IMS rerouting exits change destinations causing the

IMS communications manager to do the get unique of a

message that was originally destined to an SMB. The

change sets MTYPE='PTOT' for messages GU'd by comm.

So you must re-assemble the ASMIMSLG/L5/L6 program for

your version of IMS to correct this problem, which

corrected 291 cases of negative SERVICETM.

3. TYPEIMSA corrected the remaining two cases of negative

SERVICETM was to change the reset of STRTTIME=GUTIME

for all transactions, to use that reset only for MTYPE

starts with T, and otherwise reset STRTTIME=ENQTIME

for cases such as MTYPE='PTOT' in which the GU happens

ascynchronous to the end of the transaction.

4. The SORT statement in STEP02 of the JCL examples needs

to be changed. The "35,8" entry, for the message

arrival time, is changed to "43,8" so that the enq

timestamp is used to force the records in absolute

order (because the arrival timestamp can be zero, as

for 03 output record messages for PTOT transactions).
In summary, you need to reassemble ASMIMSLx, use the new

TYPEIMSA, and change the SORT parameter in your JCL.

The cause of the 291 negatives is documented in IBM APAR

PQ01976; they result when the site uses the IMS Input

Message Routing Exit, DFSNPRT0, to reroute a message that

was originally destined to an SMB instead to a CNT. In

this case, a multisegment IMS log 03 record has MSGDFLG2

indicating a program-to-program message switch ('81'X),

but the Exit changed the destination from another SMB to

the CNT of an IBM 3614 cash dispensing ATM terminal, so

the message is picked up by the IMS communications

manager instead of by DLI, so the get unique from the

message queue for that message is represented by a type

31 record that has a QLGUFLGS ('A0'X), indicating it's

pretty much just a normal output message, but the

resultant mismatch in log coding created a transaction

record with negative value for SERVICTM variables in

IMSTRAN. The PTF associated with IBM APAR PQ01976 does

NOT correct the log records; it only prevented IBM's

merge utility DFSLTMG0 from ABENDing (as it did when it

first saw this sequence of IMS log records!).

Thanks to Carl Meredith, SAS Institute ITSV Development, USA.

Change 17.289 Labels for several sets of TYPE71 variables AV/MN/MX

VMAC71 suffixed, now contain "*USED", to clarify which are the

Nov 3, 1999 usage measures and which are capacity measures.

Thanks to Forrest Nielson, State of Utah, USA.

Change 17.288 Variable TOTSHARE was removed from the DROP statement so

ASUM70PR it will be kept, as it may be useful to recalculate the

Nov 3, 1999 original system weights.

Thanks to Chuck Hopf, MBNA, USA.

Change 17.287 Revised Support for SMF Type 90, TYPE90A/VMAC90A should

EXTY9001 be used instead of the old TYPE90/VMAC90 members, which

EXTY9003 will no longer be updated. That old architecture kept

EXTY9004 all variables from subtypes 1-26 in the TYPE90 dataset,

EXTY9005 which not only wastes DASD space, but always requires a

EXTY9006 subset operation to select the observations you want.

EXTY9008 The TYPE90 code was the first written when subtypes were

EXTY9010 added to SMF records, and when there were only a few and

EXTY9011 they were similar in content, it made sense to create one

EXTY9012 TYPE90 dataset, and when new subtypes were added it was

EXTY9014 easier to add variables to an existing data set than to

EXTY9016 create a new data set, but now with 31 often-dissimilar

EXTY9017 subtypes, this "redesign with hindsight" is the righteous

EXTY9018 way it should have been done in the first place, as it

EXTY9019 creates 26 separate datasets, TYPE9001-TYPE9031, one for

EXTY90.. each of the operator commmand events, with only variables

EXTY90.. from that event kept in that TYPE90nn dataset. There was

EXTY9030 no complaint with the old design, since everything that

EXTY9031 was supported was in the old TYPE90 dataset, but the need

IMAC90A to support the new subtypes (27 and above, plus some that

TYPE90A per previously missed) motivated the redesing. Now all

TYPS90A subtypes are decoded, except for data segments of subtype

VMAC90A 24 and 31 (no request, no test data, complicated, shelve

Nov 3, 1999 until someone want's to us them).

Thanks to Philip Foster, Desjardins, CANADA.
Change 17.286 MXG Support for FICON Channels was wrong. Variables

VMAC73 PCHANBY/PNCHANBY were incorrectly calculated for FICON,

Nov 2, 1999 and Percent Bus Busy, PBUSBY was not even created, and

variables SMF73PRU/PWU/TRU/TWU are recalculated to now

contain read/write lpar/total rates in bytes per second,

formatted with MGBYTRT to print KB/Sec, MB/Sec, etc, to

match IBM RMF reports, now that I have test data and RMF

reports for validation!

Thanks to Joseph Rannazzisi, Salomon Smith Barney, USA.
Change 17.285 New NPM 2.4 field LSCDIPNM (IP Name) was input for all

VMAC28 records but is valid only if resource type is 'IP', so

Nov 1, 1999 that field will now be blank if not an 'IP' record.

Variable LSCDUSER is blank if LENCOF is 112, which is the

documented length for VM Session Configuration (SMF28SCD)

records, and other LSCDxxxx fields are only input if the

record is for Session Managers.

Thanks to Robert A. Brown, Arthur Andersen, USA.

Change 17.284 Support for TRMS Version 51A08 changes (COMPATIBLE) to

EXTRMS05 their user SMF record. New fields were added to subtype

VMACTRMS 3 and 4 datasets TMRS03 and TMRS04, and new subtype 5

VMXGINIT record creates new dataset TMRS05, 'Browse Tracking'.

Oct 28, 1999 The S0nACCT character variables are now formatted as

$HEX64, because the contain non-printable characters.

The length of new fields S05KEY is not defined in the

dsect, but was found to be 14 bytes in this site's data

record. It's length, T00KLEN is set somewhere else and

could be different; we're investigating.

Thanks to Carol King-Baer, Vanderbuilt University, USA.
Change 17.283 Format $MG091EC now decodes Batch Pipes error codes in

FORMATS variables SMF91IEC and SMF91OEC.

VMAC91

Oct 28, 1999

Thanks to Michael Oujesky, MBNA Hallmark Information Services, USA.
Change 17.282 Protection for bad type 80 record was not robust if MXG

VMAC80A got out of alignment and thought it had a bad record; it

Oct 27, 1999 could STOPOVER abend instead of gracefully deleting that

bad record, but protection logic from WHEN (00) was also

added in OTHERWISE DO; logic to eliminate the abend.

Thanks to Jens Schlatter, Independent Consultant, GERMANY.

Change 17.281 Support for DFSMS/MVS V1R5 is already in place, as there

VMACDCOL were no changes in the DCOLLECT records in 1.5.

Oct 26, 1999
Change 17.280 Support for Landmark DB2 Monitor Version 3.2 (INCOMPAT).

EXTMDD7 Many new variables were added to existing MXG datasets

EXTMDD7B TMDBDB, TMDBDA2, TMDBDAB, TMDBDBB, TMDBDBF, TMDBDBK and

EXTMDD7P TMDBDE2, and TMDBD6, and the new 'D7' record creates new

VMACTMDB TMDBD7, TMDBD7B, and TMDBD7P datasets. This version has

VMXGINIT lots of new stuff, including pairs of duration/counts of

Oct 26, 1999 many waiting-for-something's. Since Landmark inserted

new fields instead of adding at the end, you must install

the change to process Version 3.2 or higher data. Using

an earlier MXG version for TMDB Version 3.2 records will

cause the job to fail with many errors!

Thanks to John Enevoldson, Ellos AB, SWEDEN.

Change 17.279 CICS Statistics "EOD" records do not contain a duration,

UCICSCNT even though the "EOD" records is just the Interval Record

VMAC110 since the last "INT" record. (The "EOD" is written at EOD

Oct 24, 1999 but DOES NOT contain the entire day's data!). With no

Oct 27, 1999 DURATM, MXG sets STARTIME=COLLTIME (SMFTIME), so while

all of the obs are really there in the MXG data set, it

looks like the 9pm interval was missed with STARTIME:

STARTIME COLLTIME SMFSTRQT

31OCT:15:00 31OCT:18:00 INT

31OCT:18:00 31OCT:21:00 INT

1NOV:00:00 1NOV:00:00 EOD

1NOV:00:00 1NOV:03:00 INT

While STARTIME is wrongly equal to COLLTIME in the "EOD"

interval record in CICxxxxx Statistics datasets built by

the TYPE110/BUILDPDB programs, STARTIME is set correctly

in the PDB.CICINTRV dataset that is created from nineteen

of the "raw" CICS Stat datasets by the member CICINTRV:

-It constructs true intervals from INT/EOD/USS/REQ/RRQ

records, some of which are intervals and some of which

are accumulated, and by sorting and merging, it creates

the correct STARTIME of each interval.

-Fifteen CICS statistics datasets that are used in the

creation of PDB.CICINTRV are created one-per-interval,

so they are merged into PDB.CICINTRV with no loss of

detail; thus there should be no need to use these "raw"

CICxxx datasets with wrong STARTIME in their EOD record

because they are redundant with PDB.CICINTRV:
CICAUTO CICDMG CICDQG CICDS CICDTB CICLDG

CICM CICSDG CICST CICTC CICTDG CICTM

CICTSQ CICVT CICXMR
-Four CICS statistics datasets used in the creation of

PDB.CICINTRV have multiple observations per interval

CICDQR CICFCR CICTCR CICTSR
(i.e., CICFCR has an observation for each File). Some

useful counters are summed per interval and merged in

PDB.CICINTRV, but detail observations are likely needed

to be kept in your PDB, and you will have to live with

the incorrect STARTIME in the EOD obs.

So why not fix IBM's ommission (which was designed this

way and not likely to change)? Because the only way to

correct it would be to add a PROC SORT and DATA step for

each stat dataset to re-construct the correct STARTIME,

and that seems an unnecessary expense at this time.