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

Change 22.331 Support for hIOmon File I/O Performance Monitor.

VMACHIOM This Windows family I/O monitor records activity at the

Dec 30, 2004 individual file for each process for each user, with both

I/O activity counts, Bytes read/written, and duration of

the I/O. A special export option MXGall creates a csv

file of all 117 I/O metrics, with nulls for those fields

that are not being monitored, and that file is the file

supported in the TYPEHIOM code. Only a single dataset is

presently created, for both files and devices, but that

may change, based on user feedback. The inexpensive I/O

monitor can be downloaded at http://www.hyperio.com, and

a free trial is offered.

Thanks to Tom West, hyperI/O LLC, USA.
Change 22.330 Documentation. The CPUxxxTM variables created from SMF

ADOC30 30 records were not fully documented; they are updated

Dec 30, 2004 and identify what's included in which variables.

Thanks to Michael Bouros, Morgan Stanley, USA.

Change 22.329 Major enhancement to "PC Job Streams" for running MXG on

BLDNTPDB ASCII systems to create "SMF" or "NTSMF" PDB Libraries.

BLDSMPDB Uses the new VMXGALOC utility macro to allocate daily,

VMXGALOC weekly, and monthly PDB Directories, creating directory

VMXGSUM names that contain the DATE of the data, and logic to

Dec 30, 2004 read the correct directories for the MONTH PDB.

Jan 16, 2005 -UPCASE(KEEPALL) was added in VMXGSUM for pc execution.

UTILBLDP -Note: Only VMXGSUM was updated in MXG 22.13; the other

TRND70 three members were not revised until Jan 16, 2005.

ANALSHCP -UTILBLDP now supports OUTFILE=INSTREAM, needed for the

BLDSMPDB enhancement that lets you specify BUILDPDB= to

use the tailored UTILBLDP output for your BUILDPDB code.

-UTILBLDP now has an internal table of SMF records that

are automatically created by MXG's default BUILDPDB, so

that your USERADD= list can be compared and errors

prevented if you list a record that's already in PDB.

-UTILBLDP/BLDSMPDB logic for OUTFILE argument is robusted.

If the name is a PC dataset name it has to be inside

quotes, but if it is not (something like INSTREAM or like

SOURCLIB(MYPDB) then it must NOT be inside quotes in your

invocation. If a colon or backslash is found in your text

it will be put in quotes and treated as a PC filename.

-TRND70 now adds PCTMVSBY SHORTCPS PLCPRDQY MAXSHCPS and

MAXRDYQ to TRND70 dataset.

-ANALSHCP provides sample reports of SHORTCPs and PLCPRDYQ

for your systems.

Thanks to Chuck Hopf, MBNA, USA.
Change 22.328 Cosmetic, unless you used the _NTNG macro to null all of

VMACTNG the TNG datasets (the _NULL should have been _NULL_ in

Dec 29, 2004 each of the lines in MACRO _NTNG), or tried to use the

_KTNT015 macro to tailor NT015 (it was spelled _KTNT016).

Thanks to Freddie Arie, TXU, USA.
Change 22.327 Cleanup of BUILDPDB/BUILDPD3.

BUILDPDB -In BUILDPDB/BUILDPD3, TYPE30MR was not sorted into //PDB

BUILD002 (unless you used BUILD002, which did contain _STY30MR).

BUILDPD3 -Work datasets STEPS, STEPSIO, SPJB30T4 were created in

SPUNJOBS SPUNJOBS but were not deleted, now they are.

Dec 24, 2004

Change 22.326 Variable CPUCEPTM (CPU TIME WHEN TASK WAS ENQUE PROMOTED)

BUILD005 in what I regard as an IBM Design Error, is accumulated

BUIL3005 in the SMF 30 subtype 2 and 3 interval records; no other

ONLYINTV CPU metrics are accumulated in those records. This means

Dec 24, 2004 that the TYPE30_V dataset built from SMF is no longer

valid. But since MXG can correct IBM errors faster than

they can even acknowledge their errors (Level 2 says it's

not their problem to fix), this redesign in BUILDPDB code

deaccumulates the CPUCEPTM in the PDB.SMFINTRV dataset.

(Of course, the CPUCEPTM will be missing in the first

interval for each task that has more than one interval

record, since there is no prior interval record in

"today's" SMF file.)

Dataset PDB.SMFINTRV is automatically built by BUILDPDB.

-If you want to create PDBINTRV.SMFINTRV (and the other

interval dataset, PDBINTRV.TYPE30_6) directly from your

raw SMF file, you can use this example that uses the

BUILDPDB logic, but builds only the PDBINTRV.SMFINTRV

and the PDBINTRV.TYPE30_6 interval datasets:

//PDBINTRV DD DSN=YOUR.PDB.OUTPUT,DISP=(,CATLG),....

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

//PDB DD UNIT=SYSDA,SPACE=(CYL,(5,5))

//SPIN DD UNIT=SYSDA,SPACE=(CYL,(5,5))

//SYSIN DD *

%INCLUDE SOURCLIB(ONLYINTV);

Thanks to Tony Hirst, Wells Fargo, USA.

Change 22.325 Variable SHORTCPS=PCTMVSBY/PCTCPUBY is created in TYPE70

VMAC7072 and TYPE70PR datasets, based on Kathy Walsh's Paper that

Dec 23, 2004 was presented at SHARE in August, 2004, available at

Jan 10, 2004 http://www-03.ibm.com/support/techdocs/atsmastr.nsf/

Oct 12, 2004 WebIndex/PRS1077, titled

"Performance Impacts of Running CICS in a Shared LPAR".

The term 'Short CPs' was created by IBM WSC Performance

Staff, and is a performance effect created by the LPAR

hipervisor enforcing LPAR weights on busy processors or

capped LPARs, that can reduce the MIPS delivered by the

logical CPs to the partition. She suggested that when

the SHORTCPS ratio exceeded 2, it could be a sign of

trouble. But Don Deese pointed out that another way of

looking at the phenomenon is as a measure of the queueing

delay when the LPAR is waiting for a CP engine to be

assigned, and that a ratio of 2:1 means that for 50% of

the elapsed time, the LPAR was waiting for a CP engine.

He suggests that even a lower ratio may be the threshold

of pain; a ratio of 1.5:1 means the LPAR was 33% waiting.

Don is working on an extensive discussion of this topic

in the next release of his CPExpert product, and I have

created variable PLCPRDYQ=100*(PCTMVS-PCTCPUBY)/PCTMVSBY;

so that you can use either the ratio or the percent of

time when there was a delay in your analysis to see if

this construct is useful in measuring your LPARs.

Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.

Thanks to Dr. Robert Cross, JP Morgan, USA.
Change 22.324 Cosmetic. Missing value messages eliminated by testing

VMACTNG three NT006 fields before they are multiplied by 1024 or

Dec 23, 2004 1024*1024.
Change 22.323 Line 3624 should have named TOTSHARE TOTSHARC in KEEP=

VMXG70PR list for &OUT70LP dataset, instead of SYSSHARE CURSHARE,

Dec 23, 2004 to keep those variables in the PDB.TYPE70LP dataset.

Thanks to MaryBeth Delphia, Texas Comptroller of Public Accounts, USA

Change 22.322 Hasty creation of JCL examples for MXG under SAS V9.1.3

MXGSASV9 did not have sufficient testing; W-OH should have been

JCLTEST9 W-zero, WORKVOL was not referenced in JCLTEST9, WORK

JCLPDB9 sizes are all now 500,500, the WORK=200 in JCLPDB9 was

Dec 23, 2004 removed (with only a primary allocation, you cannot use

multiple volumes), and comments with "V8" were revised to

"V9". The instream JCL PROC in the JCLTEST9 example now

matches the symbolics in MXGSASV9.

Feb 23, 2005: This change originally changed the INSTREAM

LRECL to 72, but Change 23.012 corrected that back to 80.

Thanks to Bruce Green, MIB, Inc, USA.

Thanks to Michael Gebbia, Eddie Bauer, USA.

Change 22.321 Type 6 PrintWay records apparently come in two flavors,

VMAC6 and Change 22.302 did not protect both; in some records

Dec 21, 2004 the SMF6PQNM is always 24 bytes, and SMF6PQLN is the

number of non-blank bytes, and in other records, SMF6PQNM

is only the length of SMF6PQLN. (And, to make it more

fun, in VPS-FAX records, SMF6PQLN is always zero, but

PQNM is 24 bytes!). Additional test for blanks when

SMF6PQLN is less than 24 bytes now protects INPUT

STATEMENT EXCEEDED error that occurred even with Change

22.302/MXG 22.12 installed. And, variable SMF6PQLN is

now output in TYPE6 dataset.

Thanks to Robert Vance, Zurich Insurance Co., USA

Thanks to Reiner Luken, Zurich Insurance Co., USA
Change 22.320 This long-overdue enhancement for PDB.SMFINTRV combines

BUILD005 the MULTIDD='Y' observations from TYPE30_V into a single

BUIL3005 observation in PDB.SMFINTRV, with the correct totals for

Dec 15, 2004 EXCPxxxx, IOTMxxxx, and TAPEDRVS variables for each SMF

interval. There will be fewer observations created in

PDB.SMFINTRV, and variables EXCPNODD, IOTMNODD, and

TAPEDRVS are now correct for each interval. Variable

EXTRADD is set to zero, since those extra DDs have been

consolidated in the single observation per interval.

Note: Long ago, the MULTIDD='Y' observations were summed

into the PDB.STEPS dataset in the BUILDPDB logic. It

was only PDB.SMFINTRV that still contained MULTIDD='Y'

observations:

MULTIDD='Y' - steps with more DDs than can fit in one

SMF 30 record write multiple type 30 records; those

additional records contain only IOTMxxxx,EXCPxxxx and

TAPEDRVS values, and are flagged with MULTIDD='Y'.

See Change 23.015 if ERROR: PDB.SMFINTRV NOT SORTED is

encountered in your WEEKLY or MONTHLY PDB jobs.

Thanks to Mary Kay Pettengill, (i)Structure, USA.

Change 22.319 The R747AVFR/R747AVFT average frame size received/sent

VMAC74 in dataset TYPE747P needed to be multiplied by four; the

Dec 15, 2004 source fields are in words, and have 4 bytes per word.

Thanks to Pat Jones, DST, Inc, USA.

Change 22.318 The JCLINSTL example used the SAS V8 JCL procedure; new

JCLINST9 JCLINST9 had the minor changes to execute under SAS V9.

Dec 15, 2004 The correct CONFIGV9 member and ENTRY=SAS are now in the

example that uses the site's installed SAS JCL procedure

to create the MXG Format library during install. Once

this JCL example has been executed, the MXGSASV9 JCL proc

should be use for all subsequent MXG testing/execution.

Thanks to Burchell Williams, HIPUSA, USA.

Change 22.317 The final @; was not correctly created in the second and

UTILEXCL subsequent GRNR's, when there were optional segments; at

Dec 15, 2004 first, I blamed the conversion of CMODLENG from numeric

Dec 21, 2004 to character was the culprit, and revised that logic in

the COMDNAME='USER' code segment to

!!PUT(CMODLENG,4.)!!, but in fact the real error was a

hanging end-comment-*/ in line 745 that I had

accidentally removed during the testing of the CMODLENG

code change!

Thanks to Sally Jordan, Bear Sterns, USA.

Thanks to MaryBeth Delphia, Texas Comptroller of Public Accounts, USA
====== Changes thru 22.316 were in MXG 22.12 dated Dec 11, 2004=========
Change 22.316 Enhanced Support for RMF III VSAM files have many added

ASMRMFV features and options, all of which are discussed in the

ADOCRMFV documentation note at the beginning of ADOCRMFV member.

Dec 11, 2004 No changes are required to the CLRMFV nor TYPERMFV code.

Thanks to Jerry Urbaniak, Acxiom CDC Inc, USA.
Change 22.315 Example ASUM and TRND members for IBM SMF 94 VTS data.

ASUM94

TRND94

Dec 11, 2004

Change 22.314 Support for MainView for IMS IMF 4.1.00. DSECTS show no

TYPECIMS changes in the IMF records for IMS Version 9.1

Dec 11, 2004

Thanks to Tony Curry, BMC, USA.

====== Changes thru 22.313 were in MXG 22.12 dated Dec 10, 2004=========
Change 22.313 Optional field CMODNAME='DFHAPPL', CMODHEAD='APPLNAME'

IMACICAP had CMODIDNT='001', which tripped up MXG logic because

IMACICD6 only CMODNAME=:'DFH' (starting with) was tested; '001'

IMACICD7 generated an extra input of TRANNAME in the wrong place

UTILEXCL in IMACEXCL, which failed when it was executed.

VMAC110 -All of the CMODNAME tests were revised to test for the

Dec 10, 2004 full name (DFHTASK/DFHCICS/etc).

-New exits for optional fields and variables created:

CMODNAME CMODHEAD EXIT Variable

DFHAPPL APPLNAME IMACICAP APPLNAME

CANDEXNM CANDEXNM IMACICD6 CANDEXNM

CANDEXTY CANDEXTY IMACICD7 CANDEXTY

Thanks to Sally Jordan, Bear Stearns, USA.
Change 22.312 Support for NetSpy Version 7.0 (COMPATIBLE).

VMACNSPY -New variables in NSPYTCP.

Dec 10, 2004 NSPYAVRT NSPYINBU NSPYLOGM NSPYNROT NSPYNRTT NSPYOUBU

NSPYRCBS NSPYSGNL NSPYSOOP NSPYSSTZ NSPYTIMR NSPYTNID

NSPYTUID

-New variables in NSPYTCPS.

NSPYASID NSPYIFNR NSPYIPAE NSPYIPFC NSPYIPFD NSPYIPFF

NSPYIPFO NSPYIPFO NSPYIPHE NSPYIPID NSPYIPIR NSPYIPOD

NSPYIPON NSPYIPOR NSPYIPRF NSPYIPRO NSPYIPRR NSPYIPRT

NSPYIPSD NSPYIPUP NSPYIPVE NSPYTSSW NSPYUDDC NSPYUINE

NSPYUNOP NSPYUOUD NSPYURBS NSPYUSBS

Thanks to Leon Schiebel, IBM Global Services, CANADA.

Thanks to Nick Varvarigos, IBM Global Services, CANADA.

Thanks to Norman Hollander, CA, USA.

Change 22.311 Support for OS/400 5.3.0 for QAPMCONF, QAPMDISK, QAPMPOLL

VMACQACS and QAPMJOBL data files/data sets.

Dec 10, 2004

Thanks to Paul Gillis, Pacific Systems Management Pty, AUSTRALIA.

Thanks to Clayton Buck, UniGroup, Inc, USA.
Change 22.310 An OPTIONS SOURCE; statement inserted to circumvent a SAS

ANALRMFR V8 compiler error under Win98 caused a compiler error on

Dec 10, 2004 z/OS with SAS 9.1.3. Using a conditional test resolved.

Thanks to Steve Gear, Schneider National, INC.

Change 22.309 Change 22.302 revised the IBM File Transfer segment code

VMAC6 to support VPS, but I failed to test with IBM data after

Dec 8, 2004 the revision, causing INPUT STATEMENT EXCEEDED, on IBM

data. I was misled by IBM doc that said the SMF6PQLN was

the "length of the significant portion" of SMF6PRTQ but

it's DSECT length was 24 bytes, so I assumed 24 bytes.

It turns out that SMF6PQLN is the length of the field,

so the INPUT was restored to variable length, and code

knows that the VPS record does always have 24 bytes, and

the SMF6PQLN field is 0 in the VPS record. Both IBM and

VPS records have been tested with this change.

Thanks to George Waselus, State of Arizona, USA.

====== Changes thru 22.308 were in MXG 22.12 dated Dec 2, 2004=========
Change 22.308 Duplicate variable names in KEEP= list are detected by

VMACTDSL one of Freddie's many QA tests that read MXG source; most

Dec 1, 2004 were just duplicates, but the second instance of TDSL09PR

should have been TDSL09PN.

Thanks to Freddie Arie, TXU, USA.

Thanks to Jacky Hofbauer, Atlantica, FRANCE.

Change 22.307 MXG 22.10 & 22.11 only. Support for IRD was STILL wrong,

VMAC7072 causing PCTCPUBY, PCTMVSBY, CPUACTTM and other PCTxxxxx

Dec 1, 2004 to be wrong in ANY interval in which CPUs were varied by

Dec 2, 2004 IRD. If more than 33% of the engines were varied off,

some of those values could actually be negative values!

The revised NRCPUS calculation for IRD in Change 22.233

tested the LPARWLMG flag for the last LPAR (PHYSICAL)

instead of that flag for this MVS system's LPAR. Now,

the correct LPAR's flag is used, and variable LPARWLMG

is kept in TYPE70 dataset so you can tell when IRD is

managing this system's CPUs. This change also protects

for manual vary of engines when IRD is not in control.

The magnitude of the numeric error depended on what pct

of the engines were offline; my IRD test data had 12

CPUs, and only 1-2 were offline, masking the problem;

it took negative values to cause me to see my errors.

Thanks to Dan Case, Mayo Foundation, USA.
Change 22.306 Support for CICS/TS 3.1: INCOMPATIBLE, as ALWAYS, since

EXCICPIR IBM CICS Development continues to insert fields in the

EXCICPIW middle of the existing SMF 110 subtype 1 CICSTRAN record.

EXCICWBG -New variables added to CICSTRAN dataset:

EXCICWBR DSCHMDCN='DSCHMDLY*COUNT'

FORMATS DSCHMDTM='DSCHMDLY*DURATION'

IMACCICS ICSTACCT='LOCAL*IC*START*REQUESTS'

VMAC110 ICSTACDL='BYTES IN*START CHANNEL*REQUESTS'

VMXGCICI ICSTRCCT='INTERVAL*CONTROL*START*CHANNEL*REQUESTS'

VMXGINIT ICSTRCDL='BYTES IN*CONTAINERS*START*CHANNEL REQS'

Nov 30, 2004 L9CPUTCN='L9CPUT*COUNT'

Dec 10, 2004 L9CPUTTM='L9CPUT*DURATION'

Jan 2, 2005 MAXSTDCN='MAXSTDLY*COUNT'

MAXSTDTM='MAXSTDLY*DURATION'

MAXXTDCN='MAXXTDLY*COUNT'

MAXXTDTM='MAXXTDLY*DURATION'

PCDLCRDL='BYTES IN*DPL RETURN*CHANNEL'

PCDLCSDL='BYTES IN*DPL REQUESTS*ISSUED'

PCDPLCCT='DPL*REQUESTS*ISSUED'

PCLNKCCT='LOCAL*PROGRAM*LINK*REQUESTS'

PCRTNCCT='REMOTE*PSEUDOCONV*RETURN*REQUESTS'

PCRTNCDL='BYTES IN*PSEUDOCONV*CONTAINERS'

PCXCLCCT='PROGRAM*XCTL*REQUESTS*ISSUED'

PGBRWCCT='BROWSE*CHANNEL*CONTAINER*REQUESTS'

PGGETCCT='GET*CONTAINER*REQUESTS'

PGGETCDL='BYTES IN*GET CONTAINER*CHANNEL*COMMANDS'

PGMOVCCT='MOVE*CONTAINER*REQUESTS'

PGPUTCCT='PUT*CONTAINER*REQUESTS'

PGPUTCDL='BYTES IN*PUT CONTAINER*CHANNEL*COMMANDS'

PGTOTCCT='CHANNEL*CONTAINER*REQUESTS'

WBBRWOCT='BROWSE*HTTPHEADER*REQUESTS'

WBCHRIN1='BYTES*RCVD FOR*RECEIVE OR*CONVERSE'

WBCHROU1='BYTES*SENT FOR*SEND OR*CONVERSE'

WBIWBSCT='WBIWBSCT'

WBPARSCT='PARSE*URL*REQUESTS'

WBRCVIN1='RECEIVE OR*CONVERSE*REQUESTS'

WBREDOCT='READ*HTTPHEADER*REQUESTS'

WBSNDOU1='SEND OR*CONVERSE*REQUESTS'

WBWRTOCT='WRITE*HTTPHEADER*REQUESTS'

X8CPUTCN='X8CPUT*COUNT'

X8CPUTTM='X8CPUT*DURATION'

X9CPUTCN='X9CPUT*COUNT'

X9CPUTTM='X9CPUT*DURATION'

-New SP, L9, X8, and X9 TCBs exist in CICS/TS 3.1 and CPU

time for each TCB is in CICSDS and CICINTRV datasets. The

full list of CICS TCBs are:

TCB VAR PREFIX DESCRIPTION

QR DSG QUASI REENTRANT MODE

RO DS2 RESOURCE OWNING MODE

CO DS3 CONCURRENT MODE

SZ DS4 SECONDARY LU MODE

RP DS5 ONC/RPC MODE

FO DS6 FILE OWNING MODE

SL DS7 SOCKETS OWNING MODE (SL)

SO DS8 SOCKETS OWNING MODE (SO)

J8 DS9 J8 - OPEN MODE

L8 DSA L8 - OPEN MODE

S8 DSB S8 - SOCKETS (SSL) MODE

H8 DSC H8 - NOT IN CICS/TS 3.1+

D2 DSD D2 - DB2 MODE

JM DSE JM - JVM CLASS CACHE MODE

J9 DSF J9 - OPEN MODE

SP DSH SOCKETS PTHREAD OWNING MODE (SP)

L9 DSI L9 - OPEN MODE

X8 DSJ X8 - OPEN MODE

X9 DSK X9 - OPEN MODE

-New variables in CICCONSR Statistics Dataset (STID=52):

A14ESPCN A14ESPCS A14ESPCR A14ESTCN A14ESTCS A14ESTCR

A14ESICN A14ESICS A14ESICR

-New DS4 variables for H8 POOL statistics are added to

dataset CICDSPOO (STID=60).

-Four new Statistics Datasets are created; the full list

of all STIDs and their datasets is in ADOCCICS member:

MXG Symbolic

Dataset IBM

Name STID Description of Data Set Name

CICWBG 101 URIMAPS (Global) STIWBG

CICWBR 104 URIMAPS (Resource) STIWBR

CICPIR 105 PIPELINE (Resource) STIPIR

CICPIW 106 WEBSERVICE (Resource) STIPIW

Change 22.305 INVALID NUMERIC DATA, 'TOTALS:' AT LINE ... COL ... and

EXXAMSYT INVALID NUMERIC DATA, 'TOTAL:' AT LINE ... COL ... and

Nov 30, 2004 NOTE: CHARACTER VARIABLES HAVE BEEN CHANGED TO NUMERIC...

due to IF NOT UPCASE(NAME)='TOTAL:' THEN DO; syntax.

Using IF NOT (UPCASE(NAME)='TOTAL:') THEN DO; or

using IF UPCASE(NAME) NE 'TOTAL:' THEN DO; corrects.

Thanks to Rodger Foreman, Acxiom, USA.
Change 22.304 Support for subtype 45 (PAGE SWEEP LIMIT EXCEEDED) record

EXHRN45 in ObjectStar SMF user records.

IMACHURN The pdf documentation of this subtype is incorrect.

VMACHURN The first 64 bytes of the HU45MSG field are decoded into

VMXGINIT un-labeled variables HU45H1-HU45H5 (hex), HU45C1-HU45C3

Nov 30, 2004 (EBCDIC text) and HU45N1-HU45N5 (numeric values).

Thanks to Mark King, S.A. Dept of Human Services, AUSTRALIA.

Thanks to Robyn Mcgeachie, S.A. Dept of Human Services, AUSTRALIA.

Change 22.303 -MXG Change 21.251 added support for the optional new data

VMACSASU in the SAS user SMF record, but MXG code was off by one

Nov 29, 2004 byte, causing the last digit of JESNR to be lost.

-SAS Version 9.1.3 has SASVEREL ' 9.10', which SAS sets

for all 9.1 images (9.1.0 1MO, 9.1.0 1M2, and 9.1.0 IM3),

and that will also be the value when SAS releases the new

Service Pack levels starting with SP1.

-The ENTRY had to be changed to SMFEXIT3 in BASMF job to

create the optional 64 bytes in the SMF User Record.

//SYSLIN DD *

INCLUDE SYSLIB(SMFEXIT)

ENTRY SMFEXIT3

NAME SMFEXIT(R)

Thanks to MP Welch, SPRINT, USA.

Thanks to Wilson Chen, SPRINT, USA.

Thanks to Tom White, SPRINT, USA.

Change 22.302 Support for VPS V1 R8.0 VPS-FAX, which uses the PrintWay

VMAC6 file transfer segment to add information for TCP/IP print

Nov 29, 2004 devices. Minor revision to MXG coding for that existing

segment will populate existing variable SMF6URI with:

mailto:email address (primary recipient)

lpr://hostname/queue

lrsq://hostname:port

direct_sockets://hostname:port

Thanks to Peter Harmut, R + V Versicherung, GERMANY.
Change 22.301 Use of ZEROOBS= parameter could fail due to incorrect

UTILBLDP tests for length of operands; using MACFILEX= option did

Nov 29, 2004 circumvent the MXG coding error.

Thanks to Willy Iven, Fortis Bank Belgium, BELGIUM.

Change 22.300 Using the FTP access method to read SMF data from one MVS

VMACSMF system when MXG executes on a different MVS system fails

VMXGINIT with "ERROR 23-2: INVALID OPTIONS NAME JFCB" because MXG

Nov 26, 2004 needs JFCB=SMFJFCB on the INFILE SMF statement so that

either BSAM or VSAM SMF file can be read transparently,

but the FTP access method does not support that option.

Since that option is needed only to read VSAM SMF data,

and since the ftp access method itself does not support

reading any VSAM file, and because there is no way to

know that you have allocated your SMF filename using the

ftp access method, the solution is to create a macro

variable &MXGJFCB in VMXGINIT that is initialized to the

string JFCB=SMFJFCB by default, and use that macro

variable in VMACSMF instead of the hard-coded option.

Then, if you want to use the FTP access method to read

SMF data from a different MVS system, you can eliminate

the SAS error by using

%LET MXGJFCB= ;

to remove the JFCB option from MXG's INFILE statement.

Thanks to MP Welch, SPRINT, USA.

Thanks to Maurice Pascal, ???, ???
Change 22.299 -STORHWMH and STORHWMK were defined in both _KUOWCIC and

VMXGUOW _KUOWCICX, but they are high water marks (maxima) and so

Nov 26, 2004 should only have been maximized.

-Macro _SUOWTMO did not correctly handle max and mins;

macros _KUOWCIX and _KUOWCIN were inserted after _KUOWIDC

and _KUOWCIC as was done in _SUOWCIC.