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

Thanks to Howard Glassetter, Weyerhaeuser, USA

Change 15.264 IDMS 10.02 observations were not OUTPUT in the IDMSTAS

VMACIDMS dataset; the statement IF '1201' LE SMFHVER LT '1400' ...

Nov 3, 1997 that is immediately before %INCLUDE SOURCLIB(EXIDMTAS);

must be changed to IF '1002' LE SMFHVER LT '1400' ... if

you still have records from archaic IDMS 10.02 release.

It is possible there will be no obs in IDMSBUF and INT,

with 10.02 as well.

Thanks to Jill Billings, First Data, USA.

Change 15.263 Support for Boole & Babbage MQ Series 1.1.4 MVMQS 1.2.0

EXBBMQBP VSAM file of statistics records adds 3 new MXG datasets:

EXBBMQPS RTIN MXG DATASET VARS DESCRIPTION

EXBBMQQM 'E1'x BBMQQMGR 125 Queue Manager Record

IMACBBMQ 'E2'x BBMQBUFF 96 MQ Buffer Pool Record

TYPEBBMQ 'E3'x BBMQPAGE 16 MQ Page Set Record

VMACBBMQ This Boole product is also called MainView for MQSeries,

Nov 2, 1997 and the MXG support reads their online historical files.

Change 15.262 Availability Analysis example using PROC CALENDAR and the

ANALAVAL PDB.SMFINTRV dataset (must be enabled in IMACINTV) is

Nov 1, 1997 provided in this nice user contribution.

Thanks to Rob Wunderlich, USS/POSCO Industries, USA.

Change 15.261 Cosmetic. APAR OW15518 is the IBM APAR that added the

YEAR2000 year 2000 support to all SMF-owned SMF records; the

Nov 1, 1997 member YEAR2000 incorrectly typo'ed OW16518.

Thanks to Don Friesen, B.C. Systems, CANADA.

Change 15.260 Cosmetic. Change @28 QWACRINV MGDB2RC16. to MGDB2RC15.

ANALDB2R and there will be a space between the reason and the

Nov 1, 1997 count of SELECTs and so it doesn't look overlaid.

Thanks to Bob Gauthier, American Stores Company, USA.

Change 15.259 Pairing DB2 type 102 59 and 63 records was wrong when

ANALDBTR there were multiple 63s due to lots of SQL text. The

Oct 31, 1997 correction is to only increment PAIRNR in the BEGIN63

logic IF QWHSSTCK NE OLDTME63 THEN PAIRNR+1; and add

OLDTME63 to the RETAIN and DROP statements, and to set

OLDTME63=QWHSSTCK; just before the OUTPUT statement.

This affected the S064058 file because PAIRNR was being

incremented by more than the one count MXG expected in

the IF HOLD63 AND HOLD64 logic block. This correction

was diagnosed and the fix coded by its discoverer.

Thanks to Ken Michalik, Kraft Foods, USA.
Change 15.258 Support for CICS APAR UN98309 (INCOMPATIBLE) which

IMACPTF adds new field RLSCPUT (MXG variables CPURLSTM and

VMAC110 CPURLSCN) to dataset CICSTRAN. You must update member

UTILCICS IMACPTF to enable macro _UN98309 if you install this

Oct 31, 1997 PTF, because there is no way to tell from the SMF

record that the PTF is installed. If you use any

of the "User" fields, or have any optional segments

(e.g., those created by Candle or Boole & Babbage)

those data will be wrong with this PTF until you both

install the MXG 15.06 or later version and update the

IMACPTF member. Sorry, but this is what happens when

IBM adds data to the type 110 transaction record without

changing version numbers (and there is no maintenance

level flag for them to update, either!).

MXG utility UTILCICS was updated and it will now detect

that APAR UN98309 has been installed on any of your CICS

regions; see its comments for instructions and output.

Thanks to Martin Peck, CA-IT/Capacity Management, GERMANY.

Change 15.257 Support for type 88 subtype 11 (System Logger Alter

EXTY8811 Structure) data creates new dataset TYPE8811.

IMAC88 Also, variable SMF88EDO is now input and created in

VMAC88 the TYPE88 dataset.

Oct 31, 1997

Thanks to Pat Quinnette, Principal Mutual Life Insurance, USA.

Change 15.256 OPC segmented type 29 records caused INPUT STATEMENT

VMACOPC EXCEEDED error; MXG only inputs the EQE control block

Oct 31, 1997 fields, which does not exist in the segmented records,

so now MXG verifies both the length and EQE eyecatcher

before decoding type 29 records.

Thanks to Randy Shumate, LEXIS-NEXIS, USA.

Change 15.255 Windows NT on a multiprocessor (two or more engines) was

NTINTRV not summarized correctly; each engine created a separate

Oct 30, 1997 observation in the NTINTRV dataset. This revision will

correct that MXG design error by summing INTPROR before

the merge and creating NRCPUS variable to count engines.

Most of the fields from the PROCESOR record exist in the

SYSTEM record, but the percentage values are slightly

different between the records. Variable ACPBYPAS in the

SYSTEM record appears to be half of the sum from the

PROCESOR records with two engines, so the (believed!)

more correct value from PROCESOR is used, rather than the

values from the SYSTEM record, by moving INTPROR to the

end of the MERGE statement (so its values will override

variables of the same name).

Change 15.254 Of no real impact, because adding zeros has none, but MXG

VMAC30 created additional observations in TYPE30_V/30_4/30_5 if

Oct 29, 1997 there were type 30 records containing only MULC or OMVS

segments. These observations had MULTIDD='Y', a flag

that this step record contained only EXCP segments, and

had zeroes for all resource variables, because resources

in the MULC (Measured Usage) and OMVS (Open Edition/MVS)

segments are output in TYPE30MU or TYPE30OM datasets.

Prior to MXG 15.05, when there was more than one multiple

record from a step, they were identical and MXG's NODUP

in PROC SORT deleted all but one. But Change 15.235 in

MXG 15.05 added variable EXTRMULC to be kept, and as its

value was not the same in each multiple record, MXG did

not delete any dupes, and comparison of MXG 15.03 and MXG

15.05 showed different messages on the SAS Log about

duplicates. While they were still zero and had no

impact, they should not have been output in the first

place. So MXG has now added a test

IF MULTIDD='Y' AND NUMDD=0 THEN DELETE;

so that only multiple records due to EXCP segments will

be output into the TYPE30_V/TYPE30_4/TYPE30_5 datasets.

In TYPE30MU dataset, INITTIME will be the job or step

initiate time for subtype 4 and 5 records, but it is now

set equal to INTBTIME in the subtype 2 and 3 interval

records so that duration of the interval can be known.
There can be multiple records created due to too many

ARMS (Automatic Restart) segments, but I have no data

with ARMS segments to investigate what I should do with

those records. Variable EXTRARMS will be nonzero if you

have ARMS segments causing multiple records, and it is

kept in TYPE30_V/_4/_5 datasets. In fact, only the data

in the first ARMS segment is actually input by MXG.

Thanks to Tom Elbert, John Alden Systems Company, USA.

Change 15.253 Text of Change 12.255 now points to revision in Change

CHANGESS 15.061, whose text was also revised to TYPE78CF rather

Oct 29, 1997 than TYPE74CF!

Thanks to Jack Fausti, EDS, USA.

Change 15.252 The example for pre-CICS 4.1 GMT protection should have

ADOC110 spelled STRTTIME instead of STTRTIME.

Oct 29, 1997

Thanks to Rey Marquez, General Accident, USA.

Change 15.251 The CICINTRV logic was still wrong after Changes 15.219

CICINTRV and 15.092. The first interval was dropped when it was

Oct 14, 1997 valid, the COLLTIME value was reset to the start time of

Oct 29, 1997 the interval, variable STARTIME was not propagated into

the PDB.CICINTRV dataset, and the HALFHOUR default value

for MACRO _CICINTV produced strange results in DSGCNT if

15 minute interval data was input. To correct the logic,

DURATM and STARTIME were added to the KEEP= list in the

one-per-interval datasets (i.e., the ones that are not

VMXGSUMed), the DROP of SMFSTRQT was removed (to help in

debugging), and the major logic changes were in both the

big MERGE step (to not drop first interval, and to create

STARTIME) and in the final VMXGSUM (which now uses the

STARTIME rather than COLLTIME to cluster records. This

has been tested with broken data (i.e., an interval with

only FCR (file close) records, which will happen when SMF

is dumped before the end of the interval) as well as with

USS/REQ/EOD records interleaved with INT records, and now

the data looks correct.

Note that an observation in PDB.CICINTRV with missing for

DURATM is a "broken data" interval in which only event

data was found, and STARTIME will equal COLLTIME since

there is no interval duration in the event records.

It was invalid values for DSGCNT (Current Nr of Tasks)

in Dan's reports that led to this revision, so I also

moved DSGCNT from the MEAN= list to the MAX= list as it

is more useful as the maximum number of current users

when multiple intervals are summarized than the average.

Sites with SAS IT Service Vision (ITSV) should install

MXG 15.06 or later if they want to use PDB.CICINTRV

table. With MXG 14.07 thru MXG 15.05, SAS ITSV will

generate a warning message because variable DATETIME

was not found in PDB.CICINTRV. You could delete the

statement DROP DATETIME in member CICINTRV in those

earlier versions and ITSV will populate its tables,

but only the MXG 15.06 version of member CICINTRV

creates a legitimate PDB.CICINTRV dataset.
This change did remove the DROP DATETIME; statement

that was added in MXG 14.07. Eventually, the variable

DATETIME will be deleted, because STARTIME is the name

that should be used, but both are now kept to protect

ITSV until it is updated to use STARTIME.
Early versions of VMXGSUM created variable DATETIME, but

that was not my intention; instead, the original named

variable (i.e., the one used in the DATETIME= argument)

is intended to be used for the summarized datetime value.

Thanks to Dan Gilbert, Bergen Brunswig, USA.

Thanks to Ken Whitehead, Bank of New York, USA.

Change 15.250 The test IF CPUTM NE CPU72TM in RMFINTRV that validates

RMFINTRV that the sum of your work definitions (CPU72TM) is equal

Oct 13, 1997 to the sum of real work (CPUTM, all non-report perfgrps

or service classes) was too strong. Truncation effects

caused fractional differences (1E-9) when totals really

were equal. In the worst case, with 1000 numbers summed

at .01 second resolution, if all lost the max of .001,

a maximum difference of 1 second could exist, so the test

was revised to report error only:

IF ABS(CPUTM-CPU72TM) GT 1 THEN DO;

This test only comes in to play if you have enabled

IMACWORK to use both control/report performance groups

or service/reporting classes to define workloads.

Thanks to David Ehresman, University of Louisville, USA.

Change 15.249 Support for NTSMF Version 2.1 Final Changes (INCOMPAT).

VMACNTSM In the final Beta Tests of NTSMF Version 2.1, we have

Oct 13, 1997 decided to make a structural change in the timestamps of

NTSMF records that can affect the NTINTRV dataset, so

now, MXG 15.06 (or at least Change 15.249) is required

for NTSMF Version 2.1. Prior versions are not affected.

Prior to 2.1, all NTSMF records for a interval had the

same SMFTIME timestamps and DURATM durations, because

only one call to the Registry for all objects was made.

A single call sometimes generated 300K bytes of data,

which the Registry did not handle well, but in using just

one call to the registry we got back every counter in

every object, and we had wanted to allow the collection

of only some counters in some objects.

So NTSMF 2.1 now will issue multiple calls (one per

object) so you can tailor which counters are collected.

But the multiple calls create records with slightly

different SMFTIME timestamps, varying by the milliseconds

it takes NTSMF to get from the first to the last object,

and since NTINTRV uses STARTIME=SMFTIME-DURATM to collect

all of the records for an interval, STARTIME would not be

constant for each interval, which would cause multiple

obs in dataset NTINTRV for each real interval.
That is the incompatibility which is eliminated by this

change. NTSMF 2.1 writes a configuration record with

OID=0, OBJECT=0 (which contains fields that used to be in

each record's header that were moved to this record as

part of 2.1's "reduced header" redesign to reduce data

volume, as well as configuration information). This 0,0

record is now written at the start of each call sequence,

its DURATM is the duration since the last call sequence,

and MXG now uses the 0,0 record's SMFTIME-DURATM as

the retained STARTIME value for all records until the

next 0,0 record is read. So STARTIME will be constant

for each interval, NTINTRV will be correct, and each

individual record's timestamps, SMFTIME, can be examined

to see how long it takes NTSMF to write a set of data!

- This change also creates variable PRODTYPE (Server/WS)

and DSCNAME (NTSMF data set collection that was used)

from the 0,0 configuration record.
Change 15.248 Support for Applied Expert System's Clever TCP/IP SMF

ADOCCTCP record creates two new datasets:

EXCTCPPR CTCPPERF - Clever TCP/IP Performance Statistics

EXCTCPWL CTCPWORK - Clever TC/IP Workload Statistics

IMACCTCP

TYPECTCP

VMACCTCP

Oct 13, 1997

Thanks to Chuck Hopf, MBNA, USA.
Change 15.247 Support for HP MeasureWare for Terra Data Operating

ADOCMWTE System creates six new datasets:

EXHPTEAP HPTEAPPL - HP-MWA TERRADATA APPLICATION RESOURCES

EXHPTECO HPTECONF HP-MWA TERRADATA CONFIGURATION

EXHPTEDS HPTEDSK HP-MWA TERRADATA DISK ACTIVITY FROM DISK

EXHPTEGL HPTEGLOB HP-MWA TERRADATA GLOBAL ACTIVITY

EXHPTELA HPTELANS HP-MWA TERRADATA LANS

EXHPTEPR HPTEPROC HP-MWA TERRADATA PROCESS RESOURCES

IMACMWTE The Report Macro for Terra Data extract is contained in

TYPEMWTE member ADOCMWTE.

VMACMWTE

Oct 13, 1997

Thanks to Alfred Holz, Medco Data Corporation, USA.
Change 15.246 When you used TYPEEREP to read the DASD (i.e. online)

ADOCEREP SYS1.LOGREC file, MXG read the entire file, all the way

IMACEREP to End-of-File, but the DASD file contains old records

VMACEREP that should not have been read. The first record of the

Oct 12, 1997 DASD file is a header record that contains the pointer

LASTTR to the last record written. IBM utilities CLEAR

SYS1.LOGREC by updating LASTTR and leave all the records

where they were. Now, MXG detects that there is a header

record and uses its LASTTR value to STOP the input from

SYS1.LOGREC after that logical end of file record. (If

you should ever want to read the entire DASD LOGREC file,

new macro _READALL in IMACEREP will let you change the

MXG default) Note that this was only a problem if you

read the DASD SYS1.LOGREC file; the dumped file contains

only the valid records, and there is no header record in

the dumped file, so MXG reads dumped data to end-of-file.

An old IBM reference, RTA000138425 dated 11/13/1996 has

more discussion, including pointing out that SYS1.LOGREC

and EREP may not necessarily point to the same file!
This MXG change only applies if you use TYPEEREP to read

the online, DASD, SYS1.LOGREC, as only it contains the

header record. If you were reading the dumped EREP data

records, on tape or DASD, there are no dead records nor

any header, and reading to end-of-file is what you want!

Thanks to Christophe Faure, ATOS Group, FRANCE.

Change 15.245 DB2 Type 102 Subtype (IFCID 140) INPUT STATEMENT EXCEEDED

VMAC102 error due to trashed record. The data thru QW0140UR is

Oct 11, 1997 valid for the Object-Type=Plan record, but the XL8 field

QW0140HO contains '40ffff4040404040'x, and QW0140LL has

'4000'x, (indicating 16,384 bytes of SQL text follows),

but QWT02R1L is only 82 bytes (and there are 9 bytes in

the segment following QW0140LL). It looks to me that the

QW0140HO field was filled with 9 bytes rather than 8, and

it overlaid the first byte of QW0140LL. MXG previously

added protection for this IFCID=140 record when there was

no SQL text in Change 15.216; this Change makes the line

IF QW0140LL GT 2 THEN

look like this:

IF QW0140LL GT 2 AND COL+QW0140LL-3 LE LENGTH THEN

The site will pursue the bad record with IBM.

Thanks to Michael Oujesky, MBNA, USA.

Change 15.244 New variable CPU72TM was formatted TIME12.2 before it was

RMFINTRV output, but was not formatted in the step in which it was

Oct 11, 1997 created and in which it was PUT in an error message, so

it is now FORMATed when created.

Thanks to David Ehresman, University of Louisville, USA.
Change 15.243 DFSORT APAR PN71337 added flag fields (Compatibly) which

VMAC16 are new variables in MXG TYPE16 dataset:

Oct 9, 1997 LOSMCNTR='LOCALE PROCESSING*SORT MERGE*CONTROL FIELD?'

LOIOCOMP='LOCALE PROCESSING*INCL OMIT*COMPARE FIELD?'

EQUALUSE='EQUALS*WAS USED*FOR SORT*OR MERGE?'
Change 15.242 Utility program to re-create SMF VBS data records from a

UVBSNRDW downloaded SMF file that had BDW and RDW stripped. If

Oct 9, 1997 you don't download correctly (see member SENDDATA), you

can end up with an SMF file of only records; the BDW/RDW

are removed when you download from a RECFM=VBS instead of

using the RECFM=U copy. This has happened enough times

that I wrote this utility to reconstruct the original SMF

record, adding the missing BDW (Block Descriptor Word)

and RDW (Record Descriptor Word). As written, the logic

only works for SMF records that have only one instance of

SYSTEM per record (DB2 and CICS qualify); it would need

to be extended for records like JES type 26 that has the

SYSTEM repeated in several places, but it worked so I was

able to reconstruct the problem in the site's SMF data,

and to discover their error had been previously fixed!
Change 15.241 MQ Series type 116 SMF record with blank for CICS Task Nr

VMAC116 caused INVALID DATA FOR QWHCTASK message. The input of

Oct 7, 1997 QWHCTASK was protected by adding the double questionmark:

QWHCTASK ?? &PD.4. to suppress the error message and the

hex dump of the record. QWHCTASK was input only if CICS

attach (QWHCATYP=1 in MQ Series), but MXG did not expect

records with blank values.
MQ Series SMF type 116 record questions answered by IBM:
1. I have SMF type 116 record subtype 0 with QWHCATYP=1

(CICS), but the Thread Cross Reference Data is all

blanks (i.e., the CICS "thread number" QWHCCTNO,

"transaction name" QWHCTRN, and the CICS "task number"

are hex 40's). The CPU time field is hex zeroes, as

are all of the GET/PUT counts.

MQSSeries System Management Guide for Version 1.1.4

SC33-0806-04 page 343 discusses that there may be up

to 9 records containing zero CPU time. Do the blank

values in the CICS fields only occur in these records

with zero CPU time, and is a record with zero CPU time

always going to have blanks for the CICS fields, or is

the zero CPU and the blank CICS fields unrelated

conditions. Aren't blanks an error?

IBM ANSWER: Regarding records with zero cpu time on

CICS adapter related records, the null

records relate to the main CICS TCB and

8 MQ-related CICS TCBs. Depending on the

activity in the queue manager, these null

records will be written.

2. There is a third, undocumented self-defining section

in type 116 records that contains non-zero values,

including two TODSTAMP fields. The Offset of the

triplet is 36 decimal, and the note in Table 25 states

"other self-defining sections refer to data for IBM

use only". However, the data values may be of

significant value to our customers but I need

confirmation of their meaning, as well as the other

fields in the undocumented section:

- The two TOD stamp fields at the beginning of the

section look to be a start time and an endtime, and

as there is no other start time in the record, it

should be kept to measure event duration.

- The end timestamp has more resolution than the .01

seconds to which the SMF record timestamp is

truncated. Additionally, there is yet another

undocumented TODSTAMP field in the record, in the

Message Manager Accounting record QWHS section, as

the first eight bytes of the reserved field at

decimal offset 16, and this is also an ending

timestamp, but it is 26 microseconds later than the

ending timestamp in the undocumented section, so it

is clearly the timestamp of a third event.
Start Time in Undefined Section 05OCT97:04:15:42.970238

SMF Record time stamp 05OCT97:12:50:25.43

End Time in Undefined Section 05OCT97:12:50:25.438630

Reserved Time in QWHS Section 05OCT97:12:50:25.438656

By understanding what events are being timestamped,

the delta-time between them can often be used to

characterize short term problems and long term trends,

so I request information as to their meaning. In

addition, there are a number of fields in the

undocumented section that are non-zero; since they

exist in the site's SMF record, knowing what they

count so that they can be decoded would help our

mutual customers to better measure their MQ Series

systems.
The sample 116 record in SC33-0806-04 on pp 344-346 has

similar data, with SMF time of 29MAR94:16:43:15.17, its

start at 16:43:13.500017, and its two end times are at

16:43:15.174748 and 16:43:15.175460, for a delta of 712

microsec! What is happening during that delta duration?

I am aware that while the SMF time stamp is on the local

clock, all three undocumented TOD stamps are on the GMT

clock. The delta between SMF time and the end time will

let me discover the GMT offset to convert to local for

comparison with other SMF data records from CICS IMS,

etc.
IBM ANSWER: The additional data is not strictly just

for IBM use; it's just that the additional

data is not used for any purpose by MQ.

Part of this core code for MQ is based on

DB2, and while MQ cannot guarantee any of

the information in the additional section,

the layouts for DB2 Accounting Data may

indicate the contents of this section.
BARRY's STATUS: If you want to look deeply into MQ Series

with type 116 records, send me some data

records and I will decode the extra data

segment to see if it really is useful.

Thanks to Ken Whitehead, The Bank of New York, USA.
Change 15.240 Variables that had duplicate entries in LABEL statements