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



Yüklə 28,67 Mb.
səhifə131/383
tarix17.01.2019
ölçüsü28,67 Mb.
#98988
1   ...   127   128   129   130   131   132   133   134   ...   383

Dec 31, 2008 -PDB=SMF option had not been fully tested and caused a

180 underscoring a percent sign; the UTILBLDP logic is

revised to read only required SMF records and subtypes.

-zPCR support worked fine when SCP='z/OS V1R10' was set,

but I discovered XML doesn't tolerate extra blanks, so

SCP='z/OS V1R9 ' created an XML file that caused zPCR

configuration errors "UNKNOWN SCP". Now, trailing

blanks in the generated XML text are removed.

-The XML text is very case sensitive, so the ANALZPCR

member is also, and it must NOT be case-changed.

-Support for SELECT=CECTIME is now implemented. To be

valid, all SYSTEMs in each CEC must have the same RMF

Interval Duration, and must all have the same SYNC(0)

or the same SYNC(59) value. The CPU Dispatch Time for

all CP engines in the CECSER is summed and the interval

with the largest total is created for each CECSER as

the input. The file name has the CECSER value instead

of the SYSTEM name.

-MXG will create the external study file for any CPU type

but the zPCR tool will only accept data from a z9 or

above (CPUTYPE 2094, 2096, 2097, 2098). If you attempt

to load a file with an earlier CPU model, zPCR will not

accept it, and a zPCR warning box will display

Host LPAR Definition errors exist, please refer to

file "configuration errors" and correct the errors.

That configuration.errors file is in the \CPSTOOLS\ZPCR\

directory, and for this error condition will state

The following errors were found in the study file:

C:\CPSTOOLS\zPCR\s1942.d17dec08.t0130.zpcr

Unsupported Host processor specified;

It must be a z9 or above (2094, 2096, 2097, 2098)

Report any other error messages to support@mxg.com.

-The zPCR tool uses the TYPE70 CPU Utilization and the

TYPE74 DASDIOrate to select "workload" type for the

model. If there is no TYPE74 data, then zPCR will set

the workload type to "unknown" and you will have to then

manually change the workload type after you load the

MXG-created external study file.

Thanks to Warren Hayward, TJX, USA.

Thanks to David J. Schumann, Blue Cross Blue Shield of Minnesota, USA
Change 26.282 APPLID could be blank in PDB.ASUMUOW if the first part

VMXGUOW of a Unit of Work came from MQ rather than CICS. This

Dec 19, 2008 could also cause blank APPLID in PDB.CICS when ASUMCICX

Dec 23, 2008 is used.

Thanks to Douglas G. Wells, First National Bank of Omaha, USA.
Change 26.281 Variables IFAUNITS and IFEUNITS are now added to both

BUILD005 the PDB.STEPS and PDB.JOBS datasets from the SMF 30s.

BUIL3005 They should have been added with ZIP units were added.

Dec 19, 2008

Thanks to Jansson Ingegerd, Volvo IT, SWEDEN.
Change 26.280 Support for Open Connect user SMF record. New dataset

EXOPCNCL OPENCONN is created, but with these problems:

FORMATS - Records with DISP=00 have completely different format

IMACOPCN that the other records.

TYPEOPCN - Records with DISP GT 0 have hex text where JOB should

TYPSOPCN be, and JCTJOBID is not populated.

VMACOPCN - Value of DISP=4 occurs, but is not documented; guess

VMXGINIT is that it is NEW.

Dec 19, 2008

Thanks to Robert Brosnam, Goldman Sachs & Co., USA.


Change 26.279 Enhancement/correction to support for Nigel's Monitor.

VMACNMON -DISKSERV and DISKWAIT records supported and same named

Dec 18, 2008 variables are added to NMONDISK dataset:

DISKSERV='DISK*SERVICE*TIME*MSEC/XFER'

DISKWAIT='DISK*WAIT*QUEUE*TIME*MSEC/XFER'

-MEMPAGES4KB,MEMPAGES64KB,MEMPAGES16MB and MEMPAGES16GB

records are now supported, adding four sets of those

variables to NMONINTV dataset.

-Short AAA record protected.

-Invalid JFSFILE and JFSINODE records that have fewer

counters that described are detected and diagnostics

and print of the defective record is printed on the

log so you can send to and resolve with Nigel.
Change 26.278 Example analysis program joins DB2ACCT and DB2ACCTP, but

ANALDBJO must be used with extreme caution, as the resources to

Dec 18, 2008 sort both datasets first for the merge, can be extreme.
Change 26.277 Support for APAR OA24208 adds new subtype 15 to ID=92

EXTY9215 SMF record. The new subtype audits changes to USS file

IMAC92 security attributes for APF Authorized, Program Control,

VMAC92 and Shared Library that are maintained by USS and thus

VMXGINIT were not audited by RACF.

Dec 18, 2008


Change 26.276 CPUUNITS value of minus one in TYPE72GO has resulted in

VMAC7072 type 72 subtype 3 records for service classes that used

Dec 16, 2008 only a zIIP engine. The raw CPUUNITS field contains the

sum of CP, zIIP, and zAAP units, but MXG calculates the

ZIPUNITS and subtracts it from the raw CPUUNITS to store

only the CP engine units in CPUUNITS variable that is

output. These cases have a calculated ZIPUNITS that is

exactly one unit larger than the raw CPUUNITS, causing

the negative value. This is clearly not a real error,

and may be related to Change 26.222 in which IBM noted

small problems with IFAUNITS. So, to avoid confusing

negative values for CPUUNITS (and CPUTM and CPUTCBTM

for these cases) I have reset CPUUNITS to zero if the

value after removal of zAAP and zIIP units is -3 to 0.

Thanks to Douglas C. Walter, CITIGROUP, USA.
Change 26.275 There was a conflict in parameters between VMXGALOC and

BLDSMPDB BLDSMPDB. BLDSMPDB uses WEEKKEEP MNTHKEEP to specify the

Dec 16, 2008 datasets to be kept in the WEEK/MONTH PDB library, but

VMXGALOC uses those parameters to specify how many weeks

or months to keep. BLDSMPDB is modified with two new

parameters to resolve the conflict:

WEK2KEEP=12 KEEP 12 WEEKS

MTH2KEEP=100 KEEP 100 MONTHS


Additionally, BLDSMPDB now supports concatenated SMF

INPUT files on an ASCII platform, internally. Now, they

can be specified as

SMFIN=FULLYQUALIFIEDDSN1 FULLYQUALIFIEDDSN2 ...

Up to 99 SMF datasets can be named to be read in.

Thanks to Lisa Lawver, Land's End, USA.


Change 26.274 DB2 V9-only variables added by Change 26.210 were INPUT

VMACDB2 when they should not have been, causing very large and

Dec 16, 2008 very wrong values for these 11 variables:

QWACSPZI QWACUDZI QWACSPZE QWACSPZC QWACUDZE

QWACUDZC QWACSPC1 QWACSPC2 QWACUDC1 QWACUDC2

QWACTRSE


These variables should have had a missing value with V8.

Thanks to Roger A. Webster, State of Oregon, USA.


Change 26.273 Statement ELSE IF MRHDRDM=8 and MRHDRRC=1 was relocated

VMACVMXA to preceed the LABEL statement; WPS got confuses, but the

Dec 15, 2008 location was inconsistent with the normal ELSE location.
Change 26.272 Variable SIZE in XAM dataset HSTMEM was incorrectly INPUT

VMACXAM as PIB4., but it is a floating point (RB4.) value.

Dec 15, 2008

Thanks to Roger Stock, Boston University, USA.


====== Changes thru 26.271 were in MXG 26.10 dated Dec 21, 2008=========
Change 26.271 INVALID THIRD ARGUMENT TO FUNCTION SUBSTR in RMF 77 is

VMAC77 harmless, but resulted when there was no RNAME value.

Nov 27, 2008 Change 26.159 (MXG 26.06) decoded RNAME into RNAMHX but

didn't test for a non-zero length in MINORQCB (SMF77RLN).

Thanks to Barbara Nitz, Deutsche-Boerse, GERMANY.
Change 26.270 NRCPUS in PDB.TYPE70 is redefined for HiperDispatch/IRD

VMAC7072 as the AVERAGE NUMBER OF ONLINE, NON-PARKED CP ENGINES

Nov 27, 2008 during the interval. For IRD, it was redefined as the

average number of online engines, but now, any CP parked

time CPUPATTM/SMF70PAT is subtracted from the online time

SMF70ONT, so the NRCPUS will be smaller if any CP engines

were parked during the interval, i.e., if HiperDispatch

is active. These variables are recalculated/impacted

NRCPUS PCTCPUBY PCTCPUEF CPUUPTM

but ONLY IF HIPERDISPATCH IS ACTIVE.

-SHORTCPS in PDB.TYPE70PR was protected for erratic large

value when online and parked times were almost identical,

by requiring 10 seconds of CPUACTTM to be calculated.
Change 26.269 -Missing value messages for CPUWAITY-CPUWAIYC and for

VMAC7072 MVSWAITY-MVSWAIYC, wait times for CPUID/LPARADDR 33-63

Nov 26, 2008 WERE true errors, as those variables were not properly

set when support for more than 32 engines was added; for

systems with more than 33 engines, the MVSWAITM, CPUWAITM

could have been understated causing PCTMVSBY to be higher

that was correct.

-Missing value messages for OMVSWAIT were only cosmetic,

but are eliminated by test prior to calculation.

-Missing value messages for PERFINDX were also only

cosmetic, occurring when ACTELPTM was missing, as for

R723TYPE=2 or when TRAN=0, and are eliminated.

Jan 12 2009: This last part of this change was wrong;

see Change 26.299.

Change 26.268 Circumvention for defective NDM-CD CT user SMF record.

VMACNDM The Accounting Data length (bytes 969-970) is '00B9'x,

Nov 25, 2008 decimal 185, but the record is only 1020 bytes long.

This circumvention uses the MIN of NDMLENSA,LENLEFT

to only input what's left in the record while the

vendor is contacted to resolve their error.

Thanks to Arthur Sy, Depository Trust, USA.
Change 26.267 Hardcoded "PDB" DDNAME/LIBREF in the old-style macro refs

ASUMMIPS were changed to the dataset's Pdddddd macro variable, and

Nov 21, 2008 the reads changed to use the old-style macro reference:

MACRO _RMFIN &PDBRMFI..RMFINTRV %

MACRO _RMF72GO &PTY72GO..TYPE72GO %

MACRO _SMFIN &PDB30UV..SMFINTRV %

MACRO _RMFOUT &PDBRMFI..RMFMSUSE %

MACRO _SMFOUT &PDBRMFI..SMFMSUSE %

for easier building of RMFMSUSE/SMFMSUSE under ITRM.

But since the MSU-to-MIPS factors are also hardcoded,

MACRO _MIPSMSU MIPSFACT=5.8; %

MACRO _MIPSIFA IFAFACT=5.8; %

MACRO _MIPSZIP ZIPFACT=5.8; %

sites using different factors (for different hardware)

can override them "instream", using MACKEEP:

//SYSIN DD *

%LET MACKEEP=

%QUOTE(


MACRO _MIPSMSU MIPSFACT=5.8; %

MACRO _MIPSIFA IFAFACT=5.8; %

MACRO _MIPSZIP ZIPFACT=5.8; %

)

;



%INCLUDE SOURCLIB(ASUMMIPS);

_RMFMIPS


_SMFMIPS

to create both RMFMSUSE and SMFMSUSE in the same data

library where RMFINTRV lives.

Minor note: since the MACKEEP text contains semicolons,

the %LET MACKEEP= %QUOTE ( text ) ; syntax is required.

Thanks to Nicholas Ward, Centrelink, AUSTRALIA.


Change 26.266 Reserved Change Number.
Change 26.265 Change 20.112 corrected instances of '1A'x in ASCII MXG

PROCSRCE source, which are translated to '3F'x in EBCDIC source.

Nov 20, 2008 That hex character shows up as non-printable text, and in

some cases, caused a SAS syntax error. But eight more

have slipped in over time, all now manually removed.

This change to he PROCSRCE program used to build the MXG

master source adds detection of '1A'x characters, along

with other invalid data and long line tests, to eliminate

future re-occurrences of these invalid text.

Thanks to Chris Weston, SAS ITRM Development, USA.


Change 26.264 Support for IBM zPCR capacity tool to use MXG PDB data.

ANALZPCR MXG creates an "External Study File", a new zPCR feature

Nov 25, 2008 that can be used as input in zPCR Version C5.2b or later.
Implemented as %MACRO, %ANALZPCR reads MXG RMF datasets

PDB.TYPE70 and PDB.TYPE70PR and PDB.TYPE74 (or optionally

will read SMF data to create only those datasets) and

creates one ".zpcr" output text file of XML tags/values

for each SYSTEM and STARTIME interval that you select.
The default selection, SELECT=PEAK, will select the

interval with the highest PCTCPUBY for each SYSTEM.


The name of the .zpcr file identifies each SYSTEM and its

STARTIME, and contains the LPAR Configuration for all of

the LPARs in the same SYSPLEX, including engine counts,

z/OS SCP, utilizations and z/OS DASDIOrates.


The .zpcr files can be created on Windows or on z/OS and

copied to your zPCR Windows system, since they are simple

text files. You start zPCR, select LOAD option from the

FILE pulldown and you will be presented with each of the

file names, so you can select the specific system and

interval to be modeled.


You can then examine the configuration, by opening the

Configure LPAR option from the Function Selection page,

and then opening Detail under Reports. For all LPARs for

which utilization and DASDIOrate were found, you will see

their WORKload column will be populated; you will have to

enter your workload choice for those with "unknown".


The %ANALZPCR program has these execution parameters:
PARAMETER DESCRIPTION/SYNTAX
PDB=PDB USE PDB.TYPE70 AND PDB.TYPE70PR for INPUT.

PDB=SMF UTILBLDP READ SMF TO CREATE TYPE70,TYPE70PR.


SELECT=PEAKTIME

CREATE a .zpcr file for each STARTIME for each

SYSPLEX-SYSTEM with the highest total CPU

Dispatch Time for CP engines in a full interval.

THIS IS THE DEFAULT.
SELECT=PEAKPCT

CREATE a .zpcr file for each STARTIME for each

SYSPLEX-SYSTEM with the highest percent CPU busy,

based on the average number of online, non-parked

CP engines in a full duration interval.
SELECT=CECTIME

Select the STARTIME for each LPAR in a CECSER with

the highest total CPU Dispatch Time across all

LPARs and all engines. Not yet implemented.


SELECT=PEAK Create a .zpcr file for each system for the

interval with peak PCTCPUBY in PDB.TYPE70.

SELECT=PEAK is the default.
SELECT=ALL CREATE a .zpcr file for each RMF interval

for each SYSTEM in PDB.TYPE70.


SELECT= If non-blank and NOT PEAK nor ALL, text is

use as SAS CODE FOR SELECTION. For example:

IF (SYSTEM='9K01' AND

'01APR2008:07:44:00.00'DT LE STARTIME

'01APR2008:07:44:00.00'DT );

OR (SYSTEM='DL08' AND

'02APR2008:12:59:00.00'DT LE STARTIME

'02APR2008:12:59:00.00'DT );


PCDIRNAM For ASCII execution of %ANALZPCR, the name

of the directory to which the .zcpr files

will be written.

Default=C:\CPSTOOLS\ZPCR\


The dsnames/filenames of MXG's .zpcr files

are structured to display the variables:


SYSTEM.DDMONYY.HHMM.zpcr
sprd1.d02apr08.t0959.zpcr

ssysa.d02apr08.t2359.zpcr


so that the zPCR "LOAD" pulldown presents

the list of configuration's descriptive name

for this zPCR model's configuration.
ZOSDSN For Z/OS, the high-level qualifier of the

DSNAME to be created.

Each (very small) .zpcr file is created as a

sequential file, so that the full name with

system and date/time can be seen when these

MXG-created .zpcr files are ftp/downloaded

and then viewed in the zPCR "LOAD" Window.
DSN=MXG.Ssyst.Dddmonyy.Ttime.zpcr
DSN=MXG.SPRD1.D02APR08.T0959.zpcr

DSN=MXG.SSYSA.D02APR08.T2359.zpcr


-Additional note:

Sorting TYPE70 by SYSTEM STARTIME DESCENDING PCTCPUBY to

select the maximum CPU Busy percent interval sometimes

found max in an interval with short (2-3 min) duration,

which were the initial interval of an IPL, not the real

workload peak interval, so the SELECT=PEAK algorithm now

finds the MAX(DURATM) for each system, and then selects

only the peak PCTCPUBY with DURATM GE 95% of MAXDUR

( 95% = 14:15 for 15:00 interval) to be modeled.
For each z/OS LPAR, the Number of Logical CPs is the

average number of online-not-parked engines:

ONLCPUS=(SMF70ONT-SMF70PAT)/DURATM;

and Utilization also accounts for IRD and HiperDispatch:

ZPCRCPBY=100*LCPUPDTM/(SMF70ONT-SMF70PAT);

The MXG variable LPARCPUS, the count of engines that

were online for any part of an interval, is used for non

z/OS LPARs. %ANALZPCR prints reports with these details

from TYPE70/TYPE70PR/TYPE74 so you can see what values

were found in your data.


The IFL engines require the SCP (Linux or z/VM) to be

input, but there is no indication in the TYPE70PR data

as to which SCP is in use. I considered trying to parse

the LPARNAME for "V" or "L" but neither is safe, so I've

set the SCP to z/VM
Since ANALZPCR builds a model file for each z/OS SYSTEM,

there will be multiple files created for a CEC that has

multiple z/OS systems. Using SELECT=PEAK could create

different STARTIMEs, since SYSA's peak might not be at

the same time when SYSB peak utilization occurred.

Change 26.263 Thales e-Security's Security Resource Manager for IBM

VMACSRMH MVS RG1100, HSM Device Name field S04HSM is decoded into

EXSRMHCD four new variables depending on the device type:

EXSRMHDE S04HSMCH='HSM*CHANNEL*DEVICE*NAME'

EXSRMHHS S04HSMIP='HSM*IP*ADDRESS'

EXSRMHSN S04HSMAX='HSM*IP*AUXILLARY*PORT'

EXSRMHSV S04HSMVT='HSM*VTAM*DEVICE*NAME'

IMACSRMH -Additional subtypes are now supported, with five SMF

VMACSRMH record ID's possible.

VMXGINIT RECORD ID MACRO FOR EACH OF THE FIVE POSSIBLE RECORDS:

Nov 19, 2008 MACRO _IDSRM1 237 % /*CDS PARAMETER*/

Dec 20, 2008 MACRO _IDSRM2 238 % /*DETAIL EXCEPTION*/

MACRO _IDSRM3 236 % /*SECURITY VIOLATION*/

MACRO _IDSRM4 240 % /*SUMMARY*/

MACRO _IDSRM5 239 % /*SRM SNAPSHOT*/


DDDDDD MXG MXG

DATASET DATASET DATASET

SUFFIX NAME LABEL
SRMHAP SRMHSMAP SRM HOST SECURITY MODULE APPL

SRMHCD SRMHCDSP CDS PARAMETER

SRMHDE SRMHSMDE SRM HOST DETAIL EXCEPTION

SRMHDV SRMHSMDV SRM HOST SECURITY MODULE DEVICE

SRMHHS SRMHHSMD CDS HSMD SEGMENT

SRMHNU SRMHSMNU SRM HOST SECURITY NULL RECORD

SRMHSN SRMHSMSN SRM SNAPSHOT

SRMHSV SRMHSEVI SECURITY VIOLATION

Thanks to Yves Cinq-Mars, CIE IBM Canada Ltee, CANADA.
Change 26.262 Support for WebSphere Version 7, new subtype 9 event.

FORMATS The new subtype 9 and its usage is discussed in this

IMAC120 IBM TecDocs paper

VMAC120 HTTP://WWW-03.IBM.COM/SUPPORT/TECHDOCS/

VMXGINIT ATSMASTR.NSF/WEBINDEX/WP101342

Nov 20, 2008 and its internal format is documented at

HTTP://PUBLIB.BOULDER.IBM.COM/INFOCENTER/WASINFO/

V7R0/TOPIC/COM.IBM.WEBSPHERE.ZSERIES.DOC/INFO/

ZSERIES/AE/RTRB_SMFSUBTYPE9.HTML

MXG creates four new datasets from the subtype 9 record:

dddddd dataset description

T1209E TYP1209E WEBSPHERE SUBTYPE 9 EVENT

T1209C TYP1209C WEBSPHERE SUBTYPE 9 CLASSIFICATION

T1209S TYP1209S WEBSPHERE SUBTYPE 9 SECURITY

T1209U TYP1209U WEBSPHERE SUBTYPE 9 CPU USAGE

There is one subtype 9 record for each request event, so

dataset TYP1209E contains all data from these sections

Platform Neutral Server Information Section

Platform Neutra Server Request Section

z/OS Server Information Section

z/OS Server Request Section

Network Information Section

which only exist once per SMF record. The other three

datasets can all have one or more observations for each

subtype 9 record. The "TIMESTAMPS" section is decoded

but it's variables are duplicates of the datetimestamps

in the z/OS section, so they are not kept in TYP1209E.

-Several new MG1209x formats were created in FORMATS to

decode new subtype 9 variables.

-Variables added to existing TYP120SI dataset:

SM120NPA='SIP*SESSIONS*ATTACHED AND*ACTIVE'

SM120BPT='BYTES*XFER*TO SERVER*FROM SIP'

SM120BFP='BYTES*XFER*FROM SERVER*TO SIP'
Change 26.261 Variables MSGSW, ='Y' or 'N', 'INPUT BY*MESSAGE*SWITCH'

TYPECIMS is now created in the _CHAIN macro to flag IMSTRAN obs.

Nov 17, 2008

Thanks to Shantha Hallett, CapGemini, ENGLAND.


Change 26.260 Variables CMF27CCU & CMF27CHN added to CMF27C93 dataset.

VMACCMF The were previously only output in dataset CMF27CAR.

Nov 17, 2008

Thanks to Shantha Hallett, CapGemini, ENGLAND.


Change 26.259 QA Stream revisions and some corrections to eliminate

ANALDB2R return codes and other issues unique to QA testing.

ANALDBTR -WARNING: VARIABLE IN DROP KEEP RENAME WAS NOT REFERENCED

ANALDMON was eliminated. Some were spelling errors for variables

ANALNPMR that should have been, and now are, kept. Some were just

ASUMAPAF spurious messages, for example, when a variable in the

JCLPDB92 KEEP= list was also (intentionally) in a DROP statement.

JCLTES92 In SPUNJOBS, a DKROCOND=NOWARN was inserted where the I/O

JCLTEST8 variables for archaic devices needed protection.

JCLTEST9 Interestingly, in the case of VMAC7072, where KEEP= list

MXGSAS92 had PCTCIBY0-PCTCIBY9 PCTCIBYA PCTCIBYB ... for variables

MXGSASV9 that were not created until the subsequent SORT/MERGE for

SPUNJOBS the SPLIT70 logic, the hyphenated variable's message was

TYPEIMSA WARNING: Not all variables in the list

TYPETNG PCTCIBY0-PCTCIBY9 were found.

TYPSTNG while the message for the individual variables was.

UNIXSAR1 WARNING: The variable PCTCIBYA in the DROP, KEEP,

UTILBLDP or RENAME list has never been referenced.

UTILXRF1 -z/OS QA job's JCL uses referbacks to eliminate PROC COPYs

VMAC112 that took time and CPU, but an error in SAS V9.2 (that

VMAC7072 is to be corrected) caused the referback to fail when a

VMAC92 LIBNAME xxx CLEAR was used (only to determine if xxx was

VMAC99 on a tape device, for performance), so the cases where

VMACBBMQ CLEAR is used in the QA stream, ANALDB2R, and VMXGTAPE

VMACBVIR (invoked by ANALDB2R and TYPECIMS) are now bypassed, but

VMACEVTA only under SAS V9.2, temporarily.

VMACIMS -Most "MXG" warnings printed MXGWARN: but now all MXG

VMACSFTA warnings print MXGWARN: instead of WARNING:.

VMACSVC -Dec 20: //TEMPSVC DD replaced //SVCTEMP DD in JCLTESxx.

VMACSVIE


VMACSYNC

VMACTMVS


VMACTNG

VMACTPF


VMACTPMX

VMACXAM


VMXGRMFI

VMXGTAPE


Nov 18, 2008

Dec 20, 2008


Change 26.258 WPS 2.3.3 failed in UTILGETM due to a WPS Error (#6276)

JCLQASAS in an ARRAY (256,512) statement; that error is corrected

JCLQAWPS in WPS 2.3.4, now the required release of WPS for MXG.

QASAS UTILGETM was originally used only in the JCLTESTx job, to

UTILGETM create the SMFSMALL file of 10 records per ID, but it was

VMXGGETM not included in the MXG QA tests until now. UTILGETM

Nov 15, 2008 invokes %VMXGGETM with JCLTEXTx defaults, but VMXGGETM

Nov 18, 2008 was previously enhanced (with no Change) to also print an

QAWPS excellent report of the SMF record ID and Subtypes found,

with both record count AND record BYTES. You can use:

// EXEC MXGSASV9

//SMF DD DSN=YOUR.SMF,DISP=SHR

%VMXGGETM(SMFOUT=,FREQ=YES);

to produce only the report.

-PROC TABULATE generated an innocuous, yet annoying


Yüklə 28,67 Mb.

Dostları ilə paylaş:
1   ...   127   128   129   130   131   132   133   134   ...   383




Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©muhaz.org 2024
rəhbərliyinə müraciət

gir | qeydiyyatdan keç
    Ana səhifə


yükləyin