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

know the device type/class to put them in!

Change 20.195 New variables QWACAWTK/M/N/O/Q QWACARNK/M/N/O/Q and

VMACDB2 QWACSPVT/RLSV/RBSV were missing; IBM changed QWACLEN from

Sep 21, 2002 500 to 496 bytes, and removed a reserved field, but MXG

code was expecting 500 bytes.

Thanks to Victoria Lepack, Aetna, USA.
Change 20.194 Formats for MSU constants were updated for the 2064-2xxx

FORMATS processor family. These values are used only if you do

Sep 18, 2002 not have z/OS (which populates the CECSUSEC directly).

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

Change 20.193 ANALCICS example ERROR: VARIABLE OPERATOR NOT FOUND if

ANALCICS you excluded the archaic OPERATOR field; Change 13.268

Sep 17, 2002 noted that OPERATOR is almost always blank and that USER

is better, but ANALCICS still used OPERATOR. The example

was revised to use USER, as ANALCICS is included in the

JCLPDB8 job, and the old reference caused an unnecessary

test run to fail.

Thanks to Rick Salazar, City of Long Beach, USA.

Change 20.192 Support for the SAMS:VANTAGE 3.2.0 OBJ=POOLS record adds

EXSAMPOO new SAMSPOOL dataset with interval DASD pool statistics.

IMACSAMS There is an undocumented datetime value, but when decoded

VMACSAMS it is slightly earlier than the SMFTIME, but not enough

VMXGINIT to be a start of interval value:

Sep 17, 2002 SMFTIME SAMSTIME

Sep 30, 2002 07:19:13.44 07:17:45

07:39:05.58 07:37:45

08:00:27.22 07:57:45

Thanks to Jennifer Chu, Goldman, Sachs & Co., USA.

Change 20.191 Tape Mount Monitor records with blank JCTJOBID can occur,

VMACTMNT causing WARNING - TYPETASK NOT DECODED log messages and

Sep 16, 2002 TYPETASK blank in datasets TYPETMNT/TYPETALO/ASUMTAPE.

To suppress the warning message, VGETJESN is now only

invoked when JCTJOBID is non-blank, but TYPETASK will

still be blank when JCTJOBID is blank.

Thanks to Jesse Gonzales, The Gap, USA.
Change 20.190 The new MXG logic to create TYPETASK from "Z2" JCTJOBID

VGETJESN (i.e., the Jnnnnnnn format), tested variable SUBSYS for

Sep 16, 2002 TSO/JES2/JES3/STC to set TYPETASK='JOB', but variable

SUBSYS in TYPE6 is print subsystem (VPS,PFS, etc), and

and those records had TYPETASK='J ' (as would any SMF

record without a SUBSYS variable). This revision sets

TYPETASK='JOB ' for any record whose SUBSYS is not one

of the above four values, if JCTJOBID starts with a "J".

Thanks to Don Cleveland, Wellpoint Health Networks, Inc, USA.
Change 20.189 Candle OMEGAMON/VTAM Release 5.2.0 caused STOPOVER for

VMACOMVT IRNUM=27 internal subtype. Field OMVTINTV was inserted

Sep 16, 2002 and 40 new variables are now created in OMVTTCP dataset.

Thanks to Dave Crandall, Farmer's Insurance, USA.

Change 20.188 Example/member TYPSMQM will read //SMF and create all of

TYPSMQM the MQMxxxxx datasets from SMF 115 and 116 MQ-Series data

Sep 16, 2002 in one pass of SMF, sorting the output in to //PDB.

Thanks to Walt Blanding, Washington Mutual Bank, USA.

Change 20.187 Landmark/ASG for CICS 2.1 variables decoded from TAFLAG1

VMACTMO2 were not all decoded; variables STORVIOL and ABNDMONI are

Sep 5, 2002 now created and output, so the MONITASK dataset has the

same variables as with TYPEMON8 datasets.

Thansk To Arvid Lilleng, IBM Global Services, NORWAY.
=======Changes thru 20.186 were in MXG 20.05 dated Sep 6, 2002=========
Change 20.186 The RMF Reports printed blank for the MVS Level for z/OS

ANALRMFR systems; the test for MVSCHRLV was revised to test for

Sep 5, 2002 ZV prefix to recognize z/OS and print "Z/OS" for Level.

Thanks to Cheryl Watson Walker, Watson & Walker, USA.

Change 20.185 Change 20.168 caused MXG to create missing values for the

VMXGRMFI MSU-related variables, but only for non-z/OS systems that

Sep 5, 2002 don't have any IBM MSU numbers, and for which MXG uses a

table look-up to get the values for MSU calculations.

These old records don't have SMF70WLA populated, and MXG

incorrectly tried to calculate a value for WLA, when the

table can only return CPCMSU. The variable ZOS70WLA is

now always zero, as it should never have been created.

This error was caught in the deep QA of the first 20.05.
Note that old SMF 70s not only have SMF70WLA=., but also

SMF70CPA=., so the MSU variables in ASUM70PR/ASUMCEC will

also be missing until your SMF 70s have the added fields.
Change 20.184 Support for z800 processors might be incomplete; tests

VMAC7072 for CPUTYPE='2064'X must be CPUTYPE IN('2064'x,'2066'x).

Sep 5, 2002 Might affect LPARCPUS count and whether spare CPUs were

Sep 6, 2002 output in TYPE70PR for 2066, but if variable SMF70ONT is

populated, i.e., your z/OS maintenance is current, then

that eliminates the need to know the CPUTYPE, and your

z800 TYPE70/TYPE70PR data was just fine. No problem was

reported; this was accidentally observed as a possible

exposure that needed protection.
Change 20.183 A nice example of using a DATA step to perform a linear

ANALREG regression for two variables, returning the equation of

Sep 5, 2002 the best-fitting line, without requiring SAS/STAT.

Documented in its comments and contributed to MXG.

Thanks to Rab McGill, Standard Life, SCOTLAND.
Change 20.182 Type 42 Subtype 19 SMF42NRS='NUMBER OF SYSTEMS' is wrong.

VMAC42 Created when I saw "total cpu across sysplex" and the

Sep 4, 2002 "average cpu per system" and the number=total/average,

SMF42NRS=JNF/JNE for X1, and = JPF/JPE for X2 always

produced a value of 60 for the total to average value

for both the X1 and the X2 segments; for example, one

obs had JPF=71.555 seconds, JPE=1.193 for one system,

with SMF42JPA (interval)=900 seconds. The only clue

as to the meaning of the total:average ratio of 60 is

that SMF42JPG, the number of buffer intervals processed,

was also 60. Assuming the total CPU time is the total,

then the "average" CPU time is the average per buffer

interval, rather than the average per system, so the

label for JNE and JPE were corrected to reflect this

conclusion. The number of systems is now set from the

number of system segments, SMF42NRS=NR42X2.

Thanks to Helmut Roese, COM Software, GERMANY.
Change 20.181 Messages FILE WORK.DSNBREC WAS NOT FOUND BUT APPEARS ON A

TYPETMS5 DELETE STATEMENT were eliminated by replacing two PROC

Sep 4, 2002 DATASETS and DELETE TMSREC and DSNBREC with PROC DELETEs

with DATA=_WTMSTMS and DATA=_WTMSDSN.

Thanks to Dr. Alexander raeder, Itellium, GERMANY.
Change 20.180 MXG used the undocumented STARTHR-1 as the start time of

VMACTNG eachstart time of a performance cube, but the STARTHR may

Sep 4, 2002 only be a daylight savings flag and may not be the start.

Since the TNG data apparently should always start at hour

zero, that is now the MXG default, but that zero default

is externalized in the new MACRO _TNGSTHR TNGSTHR=0; %

If your data needs the MXG equation, you can replace that

TNGSTR=0; statement with any SAS statements that set the

variable TNGSTHR to your desired start hour. Your MACRO

definition would be put in member IMACKEEP, or could be

set in the SYSIN stream using this syntax:

%LET MACKEEP=

%QUOTE( MACRO _TNGSTHR TNGSTHR=STARTHR-1; % );

%INCLUDE SOURCLIB(TYPETNG);

Thanks to Erling Andersen, SMT Data A/S, DENMARK.
Change 20.179 TNG variable INSTANCE was blank in the NT014 (PROCESSOR)

VMACTNG data instead of zero. MXG expected the INSTANCE variable

Sep 4, 2002 to exist and be input from each 3-HDR record, and so set

INSTANCE=' ' to prevent an unexpected carry-forward of

the RETAINed value. This worked with all other objects

with more than one instance, but for the PROCESSOR object

(and presumably any other objects that can have more than

one instance, but actually have only one), CA puts the

INSTANCE value only in the 2-HDR for the object. To fix,

the INSTANCE=' '; statements were removed from the 3-HDR

logic so that the INSTANCE from the 2-HDR will be output.

For documentation and future reference, the sequence of

the TNG records for an NT server are listed here:
Record Object Metric Instance OOO
(-HDR Logical Disk %Disk Time 0;C: 5

4-HDR 1;D: 5

4-HDR _total;_total 5

3-HDR %Free Space 0;C: 5

4-HDR 1;D: 5

4-HDR _total;_total 5

... repeat one 3, two 4 for each metric in object

2-HDR Memory Avail Bytes blank 6

3-HDR Comm Bytes blank 6

... repeat one 3 for each metric in this object

2-HDR Network Interf Bytes Recvd 1 10

4-HDR Bytes Recvd 2 10

3-HDR Bytes Sent 1 10

4-HDR Bytes Sent 2 10

... repeat one 3, one 4 for each metric in object

2-HDR PROCESSOR %priv time 0 10

3-HDR %proc time blank 10

3-HDR %user blank 10

... repeat one 3 for each metric in object

Thanks to Erling Andersen, SMT Data A/S, DENMARK.

Change 20.178 The JCLTEST8 example did not have a DB2ACCT DD statement

JCLTEST8 in step TESTIBM3; if you change the default to send your

Sep 4, 2002 DB2ACCT data to the DB2ACCT DD, this test job failed.

Thanks to Jesse Gonzalez, The Gap, USA.

=======Changes thru 20.177 were in MXG 20.05 dated Sep 1, 2002=========
Change 20.177 The PHYSDISK dataset from Win 2000 Beta 3 (NRDATA=31) had

VMACNTSM incorrect values in AVGSKQL, AVDSKWQL, PCTDSKRD, PCTDSKWR

Aug 30, 2002 and SPLTIORT. Variables are now correctly INPUT in order.

Thanks to Andrzej Dabrowski, CSIR, SOUTH AFRICA.

Change 20.176 Support for ten new Oracle objects and ten new Analysis

EXNTANAC Server objects create these new MXG datasets:

EXNTANCO NTANAC ANSRAGCA ANALYSIS SERVER:AGG CACHE

EXNTANLA NTANCO ANSRCONN ANALYSIS SERVER:CONNECTION

EXNTANLO NTANLA ANSRLAQU ANALYSIS SERVER:LAST QUERY

EXNTANPA NTANLO ANSRLOCK ANALYSIS SERVER:LOCKS

EXNTANPI NTANPA ANSRPRAG ANALYSIS SERVER:PROC AGGS

EXNTANPR NTANPI ANSRPRIN ANALYSIS SERVER:PROC INDEXES

EXNTANQD NTANPR ANSRPROC ANALYSIS SERVER:PROC

EXNTANQU NTANQD ANSRQUDI ANALYSIS SERVER:QUERY DIMS

EXNTANST NTANQU ANSRQURY ANALYSIS SERVER:QUERY

EXNTORBC NTANST ANSRSTRT ANALYSIS SERVER:STARTUP

EXNTORD1 NTORBC ORACBUFF ORACLE9 BUFFER CACHE

EXNTORD2 NTORD1 ORACDBW1 ORACLE9 DBWR STATS 1

EXNTORDD NTORD2 ORACDBW2 ORACLE9 DBWR STATS 2

EXNTORDF NTORDD ORACDADI ORACLE9 DATA DICTIONARY CACHE

EXNTORDY NTORDF ORACDAFI ORACLE9 DATA FILES

EXNTORFR NTORDY ORACDYSM ORACLE9 DYNAMIC SPACE MANAGEMENT

EXNTORLI NTORFR ORACFREE ORACLE9 FREE LIST

EXNTORRL NTORLI ORACLIBR ORACLE9 LIBRARY CACHE

EXNTORSO NTORRL ORACREDO ORACLE9 REDO LOG BUFFER

IMACNTSM NTORSO ORACSORT ORACLE9 SORTS

VMACNTSM

VMXGINIT

Aug 29, 2002

Thanks to Steven M. Dunn, Mainframe Performance Products, AUSTRALIA.

Thanks to Wojtek Stanczew, Northern Territory Government, AUSTRALIA.
Change 20.175 Comments only. Corrected typo and revised descriptions of

WEEKBLD which WEEKBLD/WEEKBLDT/WEEKBL3/WEEKBL3T/JCLWEEK/JCLWEEKT

Aug 29, 2002 member to use for what.

Thanks to Ed Billowitz, Medical College of Virginia - VCU, USA.

Change 20.174 -Change 19.176 created variable R791MLIM but did not add

VMAC79 that variable to the KEEP= list for dataset TYPE791.

Aug 28, 2002
Change 20.173 Change 18.348 documented that QWACvvvv variables should

VMACDB2 be used instead of the QWAXvvvv counterparts in DB2ACCT,

Aug 28, 2002 and why the QWAXvvvv variables were kept. This change

makes these shouldn't-be-used-variables to be correct:

QWAXAWDR QWAXALOG QWAXAWCL QWAXAWAR QWAXOCSE QWAXSLSE

QWAXDSSE QWAXOTSE; they needed to be divided by 4096.

Thanks to Glen Yee, The Gap, USA.
Change 20.172 Variables PCHANBY, PNCHANBY and especially PBUSBY were

VMAC73 not initialized; PBUSBY was non-missing in SMF73CMG=1 and

Aug 27, 2002 SMF73CMG=2 records, causing confusions. Now, all three

are initialized to missing along with the others.

See Change 20.240, 29Oct2002 correction.

Thanks to Diane Eppestine, Southwestern Bell, USA.

Change 20.171 Variable DCDRECFM now contains values 10, 11, 12, or 13

FORMATS for FBA/FBM/VBA/VBM Record Formats; DCDRECFM is now set

VMACDCOL and formatted to 10:VBA, 11:FBA, 12:VBM, 13:FBM

Aug 27, 2002 by addition to the MGDCORF format.

Sep 4, 2002 Feb 4, 2003: Text and values for 10: and 11: had been

Feb 4, 2003 reversed; now change text, code, and format all agree.

Thanks to Steve Gormley, Royal Bank of Scotland, ENGLAND.

Thanks to Rob D'Andrea, Royal Bank of Scotland, ENGLAND.

Thanks to Steve Lottich, University of Iowa Hospitals, USA.
Change 20.170 Labels for Single-Engine CPU Utilization variables SBUTIL

VMACQAPM SIUTIL, SUTIL, and SWUTIL now contain "Single Engine" and

Aug 27, 2002 PCTCPUBY now contains "All Engines" for clarity.

Thanks to Stephen Hoar, Lloyds TSB, ENGLAND.

Change 20.169 -VMAC7072 adds variable SMF70LAC to TYPE70PR dataset, and

VMAC7072 -VMXG70PR creates new variables LPnLAC from SMF70LAC with

VMXG70PR IBM's 4-hour average hourly MSU, which can be compared to

Aug 25, 2002 the interval hourly rate in LPnMSUHR, and to the LPAR's

Defined Capacity, LPnMSU70, to both PDB.ASUM70PR and

PDB.ASUMCEC datasets.

-New macros added in VMXG70PR let you set the "RMFINTRV"

dataset that will be updated with the PLATxxxx variables,

and set the "ASUM70PR" and "ASUMCEC" dataset names that

will be output, making it easier to create multiples of

"PDB.RMFINTRV/PDB.ASUM70PR/PDB.ASUMCEC" with different

names and different INTERVAL= values. New comments in

member RMFINTRV show examples of the new possibilities.
For example, to build detail, hourly, and daily datasets,

you could use this code as your RMFINTRV member:

%VMXGRMFI(INTERVAL=DURSET,OUTDATA=PDB.RMFINTRV);

%VMXG70PR(INTERVAL=DURSET,RMFINTDS=RMFINTRV,

OUT70PR=PDB.ASUM70PR,OUTCEC=PDB.ASUMCEC);

%VMXGRMFI(INTERVAL=HOUR,OUTDATA=PDB.RMFINTHR);

%VMXG70PR(INTERVAL=HOUR,RMFINTDS=RMFINTHR,

OUT70PR=PDB.ASUM70HR,OUTCEC=PDB.ASUMCEHR);

%VMXGRMFI(INTERVAL=DATE,OUTDATA=PDB.RMFINTDY);

%VMXG70PR(INTERVAL=DATE,RMFINTDS=RMFINTDY,

OUT70PR=PDB.ASUM70DY,OUTCEC=PDB.ASUMCEDY);

which will create these datasets in your PDB library:

Raw RMF Interval RMFINTRV ASUM70PR ASUMCEC

Hourly RMFINTHR ASUM70HR ASUMCEHR

Daily RMFINTDY ASUM70DY ASUMCEDY

You should also put a member ASUM70PR with only comments

in USERID.SOURCLIB, so it is not executes a second time.
Your %VMXG70PR/ASUM70PR must use the same INTERVAL= value

that was used to create the RMFINTRV it will update, by

either using the same INTERVAL= argument, or by using the

DURSET macro for both RMFINTRV and ASUM70PR programs.

The system in the numeric example inChange 20.168 was in

LPARNUM 10, so that LPAR's data in PDB.ASUM70PR will be

in the LPnxxxx variables, (where n=A), for example:
STARTIME LPALAC LPAMSU LPAMSUHR LPAMSU70

12:30 42 6.65 26.62 50

Changes 20.168 and 20.169 should correct and clarify the

calculations of MSU, and I believe that MSU, rather than

MIPS, is the way we will be measuring usage and capacity

on z/OS systems. A newsletter article is in progress.

Change 20.168 With z/OS 1.1 or later, MXG logic to calculate MSU4HRAV

VMXGRMFI could be wrong, and PDB.RMFINTRV variables CECSUSEC,

Aug 24, 2002 CPCMSU, CPCNRCPU and CPCFNAME were missing. MXG logic

Aug 28, 2002 for non-zero SMF70WLA was wrong, revised, and broken in

two steps for clarity and debug, and fewer variables are

needed to be kept in SPIN.SPINRMFI.

I and others believe that the IBM MSU, Million Service

Units per hour, will replace MIPS, and that the MSU will

be the primary metric to express CPU hardware capacity

and/or workload consumption, whether or not MSU is also

used for Software Pricing. MIPS was a constant provided

by a consulting company to describe your processor. MSU

is a constant provided by IBM to describe your processor.

For either constant, it is the CPU seconds that are used,

along with the constant, to describe your capacity and

your capacity used in MIPS or MSU.

These are the important MSU-related variables:
-MSUINTRV - "CPU seconds" * CECSUSEC / 1E6 - is a count

and not an hourly rate, used to calculate

rates. Use only if you are summing MSU.
-MSUPERHR - MSUINTRV * 3600 / DURATM - is the interval

count of MSU (extended to an hourly MSU rate

if the interval is less than an hour).
-MSU4HRAV - MXG 4-hour rolling average MSU per hour from

RMF Interval data. MXG calculates the value

across an IPL, "SPIN"ing the last four hours

for tomorrow's input. Always calculated.

-SMF70LAC - IBM 4-hour rolling average of theMSU rate.

Not calculated when Hardware Capped.

Reset at IPL.
-SMF70WLA - The Defined Capacity of the LPAR MSU rate.

Zero if capacity is not defined. Based on

LPAR share and CPC capacity if Hardware Cap.
-CPCMSU - The CPC total capacity in hourly MSU rate.

-Al Sherkow's excellent research with IBM has found that:

-The WLM measures MSU for its 4-hour rolling average and

max values based on 10 second samples of "LPAR Effective

CPU Time", averaged over a five minute period.
-This value is used internally by WLM when managing (i.e.

"capping") to "Defined Capacity", but those 5-minute

data values are not written to RMF 70 records.
-SMF70LAC, IBM's 4-hr Average Hourly MSU, contains the

most recent calculation of the 4-hr average. It was

calculated within the last 5 minutes but represents four

hours of data from those 5 minute data values.

-The WLCTool uses SMF70LAC and reports at the customers

SMF interval.

-The Sub Capacity Reporting Tool uses SMF70LAC, but it

averages all values per LPAR per hour.

-The SMF 99 subtype 1 record field SMF99_SLAvgMsu has the

current WLM view of the four hour average in 48 service

buckets with the 5 minute interval data. The buckets

are broken up by service accumulated with the partition

was capped and while the partition was uncapped.
-MXG can never exactly match the IBM 10-second sampled MSU

values from WLM 5-minute buckets using RMF interval data,

especially for the maximum values, but using 15 minute or

hour intervals still provides very accurate MSU measures,

as demonstrated below. The RMFWDM command was issued at

12:43 and is compared to the 15-minute RMF interval at

12:30, and with the hour RMF interval starting at 12:00:
Hourly MSU Rate

4-hr Average 4-hr Maximum

RMFWDM snapshot 41 58

IBM SMF70LAC in 12:30 RMFINTRV 42 43

MSU4HRAV (RMFINTRV 15-min data) 41.95 55.4

MSU4HRAV (RMFINTRV hourly data) 40.28 43.8

IBM SMF70LAC (one hour RMFINTRV) 43 43
5-min max=58, 15-min max=55, hour max=44, LAC max=43
STARTIME MSUINTRV MSUPERHR MSU4HRAV SMF70LAC
08:30:00 11.48 45.93 33.93 31

08:45:00 13.84 55.37 35.88 33

09:00:00 11.08 44.35 37.01 35

09:15:00 8.78 35.14 37.57 36

09:30:00 12.66 50.55 39.07 36

09:45:02 13.16 52.62 40.56 38

10:00:03 10.17 40.77 40.91 40

10:15:01 10.73 42.94 41.57 40

10:30:01 10.88 43.48 42.30 41

10:45:02 10.58 42.35 42.99 41

11:00:02 11.18 44.65 43.66 42

11:15:04 10.93 43.81 44.48 43

11:30:02 9.75 38.98 43.78 43

11:45:02 7.89 31.58 43.89 43

12:00:02 9.55 38.20 43.54 43

12:15:02 9.79 39.20 43.18 43

12:30:01 6.65 26.61 41.95 42

(This system had SMF70WLA=50, CPCMSU=118.92)

-MXG'S MSU calculations use the total LPAR CPU time (LPAR

Partition Dispatch CPU time), because that is the MSU the

LPAR really consumed, and that is what you should use for

(conservative) capacity measurement. But because the CPU

Dispatch time is slightly larger than the CPU Effective,

and because IBM samples the Effective CPU to calculate

SMF70LAC for WLC Software Charging, MXG's MSU4HRAV can be

slightly larger than IBM's SMF70LAC (and recall that the

value in SMF70LAC is a truncated integer).
-Keith Munford's has also observed that:

-With Defined Capacity and Hard Capping both enabled:

-The value in SMF70LAC (4-hr average) is zero; IBM has

APAR OW55509 open internally and LAC should be fixed.

However, MXG's MSU4HRAV variable is always valid.

-The value in SMF70WLA is not the Defined Capacity that

you set on the HMC Management Console for that LPAR,

but instead SMF70WLA is the MSU rating of the CPC,

weighted by the LCPUSHAR for the LPAR:

Eg: WLA Set Value = 18 CPCMSU = 119

LCPUSHAR = 43 (out of 299) = 14.38%

IBM recorded SMF70WLA=17 (.1438*119=17.11).

-With Defined Capacity not enabled but with Hard Capping

enabled, SMF70LAC is still zero, and SMF70WLA is again

the CPCMSU rating weighted by its LCPUSHAR:

Eg: WLA Set Value = none CPCMSU = 153

LCPUSHAR = 85 (out of 400) = 21.25%

IBM recorded SMF70WLA=33 (.2125*153=32.51).

-The text of MXG Changes 20.046, 20.043, 19.083, 19.018

and 18.317 all had something to say about WLA and MSU;

some were revised to be accurate when read now, and to

be consistent with what is now known.

-See also Change 20.169 for associated MSU notes.
Thanks to Alan Sherkow, I/S Management Strategies, USA.

Thanks to Melanie Hitchings, British Telecom, ENGLAND.

Thanks to Andy Billington, British Telecom, ENGLAND.

Thanks to Keith Munford, British Telecom, ENGLAND.

Change 20.167 Using BLDNTPDB with the KEEPERS= option failed, with an

BLDNTPDB "Apparent symbolic reference SUFX not resolved." message.

Aug 23, 2002 First two references to &SUFX should have been &DDDDDD.

Aug 29, 2002 Similar error with _S&KEEPS1X then was exposed and fixed.

-A new value for RUNDAY=PDB, can be used if you just want

to create a PDB from an NTSMF file and put it in the PDB

libname (you want to suppress the normal Daily, Weekly,

Monthly and Trending process that are executed when the

default of RUNDAY=YES is used).

Thanks to Andrzej Dabrowski, CSIR, SOUTH AFRICA.

Change 20.166 Variable RDPERCNT was not input in the EDGRDEXT dataset,

VMACEDGR causing the subsequent variables to be misaligned.

Aug 19, 2002

Thanks to Reinhard Nitsch, Provinzial Versicherungen, GERMANY

Change 20.165 Support for EMC's Catalog Solution user SMF record

EXEMCASO (earlier from Softworks, and even earlier that product

IMACEMCS was named VSAM Mechanic) creates new EMCATSOL dataset.

TYPEEMCS

VMACEMCS

VMXGINIT

Aug 17, 2002

Thanks to Lawrence Jermyn, Fidelity, USA.