* copyright (C) 1984-2010 merrill consultants, dallas, texas *


Download 179.51 Kb.
Name* copyright (C) 1984-2010 merrill consultants, dallas, texas *
page1/3
A typeDocumentation
  1   2   3
/* COPYRIGHT (C) 1984-2010 MERRILL CONSULTANTS, DALLAS, TEXAS */

Last Updated: Jan 20, 2010, for MXG 27.27.
***********************NEWSLETTER FIFTY-FIVE****************************

MXG NEWSLETTER NUMBER FIFTY-FIVE, JAN 20, 2010
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
I. MXG Software Version.

II. MXG Technical Notes

III. MVS, aka z/OS, Technical Notes

IV. DB2 Technical Notes.

V. IMS Technical Notes.

VI. SAS Technical Notes.

VI.A. WPS Technical Notes.

VII. CICS Technical Notes.

VIII. Windows NT Technical Notes.

IX. z/VM Technical Notes.

X. Email notes.

XI. Incompatibilities and Installation of MXG.

See member CHANGES and member INSTALL.

XII. Online Documentation of MXG Software.

See member DOCUMENT.

XIII. Changes Log

Alphabetical list of important changes

Highlights of Changes - See Member CHANGES.
COPYRIGHT (C) 1984,2010 MERRILL CONSULTANTS DALLAS TEXAS USA
I. The 2010 Annual Version MXG 27.27 is dated Jan 20, 2010.
All sites were mailed a letter with the ftp download instructions.

The availability announcement was posted to both MXG-L and ITSV-L.

You can always request the current version using the form at

http://www.mxg.com/ship_current_version.
1. The current version is MXG 27.27, dated Jan 20, 2010.
See CHANGES member of MXG Source, or http://www.mxg.com/changes.
II. MXG Technical Notes

3. SAS option COMPRESS=YES impact on z/OS MXG Execution.
The MXG default for all platforms is COMPRESS=YES. For all ASCII

platforms benchmarks have proven that IS correct and desirable: on

ASCII systems, COMPRESS=YES minimizes both disk space and CPU time

needed to create MXG datasets.
On z/OS, while COMPRESS=YES does minimize disk space required, it

does require additional CPU time. So, like most performance issues,

it all depends - on whether your disk space is the limiting factor

(in spite of the incredible reduction in the real costs for disks)

or if the CPU Time consumption is of more concern (at 3am??).
At CMG 2009, Chuck Hopf reported an MXG tailoring that set option

COMPRESS=NO for the SMF/SORT processing to a TEMPPDB to save CPU

time, followed by a PROC COPY with COMPRESS=YES to minimize the

size of the output PDB data library. But then I discovered that in

SAS V9, COMPRESS=YES can be specified on a LIBNAME statement, which

eliminated the tailoring, the TEMPPDB and the PROC COPY. Chuck then

reran these tests, reading an 11GB SMF file, always compressing the

the output PDB library:

Compress Option CPUTM WORK PDB CICSTRAN DB2ACCT PDBTEMP TOTAL

sec cyl cyl cyl cyl cyl cyl
YES, GLOBAL 2745 2441 1813 1223 2765 8242

NO, PROC COPY 1867 6934 1816 5114 10046 6006 29916

NO, LIBNAME YES 2376 6934 1816 1223 2765 12737

NO, TAPE 2061 6934 1816 TAPE TAPE 8750

The COMPRESS=YES option minimizes the total disk space for all of

the output data libraries AND for the WORK library, but at a cost

of 15 minutes more CPU time, from 31 to 46, a 48% increase.
To save those 15 CPU minutes using COMPRESS=NO+PROC COPY for only

the PDB library, the total disk space for the job increased from

8242 to 29,916 cyls, nearly four times, and the output libraries

increased nearly three times, from 5801 to 16976 cylinders.
The intermediate choice, using COMPRESS=NO for WORK library with

COMPRESS=YES on the three output LIBNAMES, saves 8 minutes CPU Time

(or an increase of 27% from the minimum); the total disk space for

the job increased only by 50%, from 8242 to 12,737 cylinders, and

that increase was all in the uncompressed temporary WORK library

//SYSIN DD *

OPTIONS COMPRESS=NO;

%LET PDB2ACC=DB2ACCT;

LIBNAME PDB COMPRESS=YES;

LIBNAME DB2ACCT COMPRESS=YES;

LIBNAME CICSTRAN COMPRESS=YES;

%INCLUDE SOURCLIB(BUILDPDB);
The last choice, writing the CICSTRAN and DB2ACCT datasets to TAPE

LIBNAMEs, compressing only the output PDB library, increased the

CPU time from minimum by only 3 minutes, to 34, with only 8750 cyl

required for the uncompressed WORK and compressed PDB libraries.
Note that for TAPE output on z/OS, again, it all depends!!

With the Global COMPRESS=YES option, TAPE output is NOT COMPRESSED;

this makes complete sense, since ALL tape control units compress at

that hardware level, at NO CPU cost. However, if COMPRESSS=YES

is specified either as a dataset option or as a LIBNAME option, SAS

does compress tape output datasets. I'm not sure why you would want

to, but it is an available option.
Additionallly, compression of datasets in a libref are always at

the dataset level. For example, if you use COMPRESS=YES option on

a LIBNAME, all created datasets will be compressed, but you could,

later, add an uncompressed dataset to that data library.
So, my recommendation for z/OS is to still use the MXG default of

Global COMPRESS=YES. I think the exposure and cost of running out

of disk space, causing a BUILDPDB job to ABEND, is far higher than

the small increase in CPU time, especially if the BUILDPDB is run

in the slack time of day. But, the above tests do quantify the

possible CPU time savings, if that truly is the limiting factor.
2. Removal of duplicate observations from MXG's PDB.JOBS.
A "job" is a unique instance of READTIME JOB JESNR, but a PDB.JOBS

observation is created from multiple SMF type 6, 26 and 30 records

which might be created in several days' SMF datasets.
-There are several sources of possible duplicates in PDB.JOBS:
a. Duplicate records have NEVER been created in the VSAM SMF dataset,

but design errors in the SMF VSAM dumping procedures, human errors

or hardware or software failures in the SMF processing jobstream

have created actual duplicate records in the SMF datasets that MXG

processes. If you have a well designed SMF dumping procedure,

and never experience a job failure, you cannot have duplicates.
b. If duplicated SMF records do exist in the input SMF file that MXG

reads (e.g., same SMF dataset concatenated to itself), BUILDPDB

will NOT create duplicates in PDB.JOBS, because the NODUPRECS SORT

option is used to remove duplicates from the datasets MXG creates

in the BUILDPDB program. These sorts require BY lists that span

all possible sequences so that duplicates are physically adjacent,

and that is why sometimes, the MXG BY list has had to be changed

to guarantee that adjacency for duplicate removal.
c. But "pseudo-duplicates" can be created by BUILDPDB that we do NOT

want to remove: PDB.JOBS observations with the same READTIME JOB

and JESNR, but that are not actual duplicates. The SPINCNT value

in IMACSPIN sets the number of BUILDPDB executions (days) when

records for inflight (incomplete) jobs are held; jobs are "spun"

until the job's Purge record is read. When SPINCNT is exceeded,

whatever records happen to be in that SPIN library will be output

to that PDB.JOBS. Then, when more of that job's records are read,

another observation with the same READTIME JOB JESNR is output, in

a different day's PDB.JOBS. But these are not duplicates; each

will have different sets of variables populated from the different

SMF records that were read. For example, if SPINCNT=0, a job that

executed today, but was in the held output queue when SMF VSAM was

dumped, will create a PDB.JOBS observation with the CPU/EXCP/etc

execution resource variables populated, but all of the scheduling

datetimes (JSTRTIME,JPURTIME,etc) from the Purge record will have

missing values. Then, tomorrow, when the print/purge SMF records

are read, a second observation for that job will be output with

that same READTIME JOB JESNR, but with only the print lines and

scheduling datetime variables populated. We do NOT want to delete

these pseudo-duplicate observations from our PDB.JOBS dataset.
d. But "real" duplicate observations can be created, if

SMF records that were read "yesterday" are accidentally reread

again "today". This would create separate PDB.JOBS observations

in two different daily PDBs that WOULD have identical values for

all resources. Those duplicate observations differ ONLY in their

ZDATE/ZTIME values (the "run date" of the BUILDPDB execution), so

if you do then combine the daily PDBs into the same WEEKs PDB,

you CAN use this PROC SORT to delete these true duplicates.
PROC SORT NODUPKEY DATA=WEEK.JOBS OUT=WEEK.NODUPJOB;

BY READTIME JOB JESNR INBITS JINITIME JTRMTIME INITTIME

PRINTIME JPURTIME CPUTM EXCPTOTL EXCPTODD EXCPNODD PRINTLNE;
Option NODUPKEY must be used here, instead of MXG's normal NODUP,

because ZDATE/ZTIME are NOT identical in each pair of duplicates.
e. BUT: if only some of the job's records are repeated, or if the job

already is "SPINing" (has some records held in the SPIN library),

then the re-reading of only some of a job's SMF records is much

more insidious, and the above PROC SORT would not likely detect

that kind of duplication.
1. Search Arguments.
Some examples of search arguments for MXG and related information:
Using Google to keyword search at a specific site, for example, at

www.mxg.com or at www.ibm.com:
+websphere +db2 +wlm +classification site:mxg.com
+websphere +db2 +wlm +classification site:ibm.com
Alternatively, this url is the Google Advanced Search page:
http://www.google.com/advanced_search?q=site:www.mxg.com&hl=en
For mxg.com, you can also use the SITE SEARCH option (on left) at
http://www.mxg.com/newsletters/
But the MXG-L ListServer Postings Archive is not at www.mxg.com,

so the above site searches will not find MXG-L postings. The link

to search all MXG-L postings, since its Oct, 1996, inception, is:
http://peach.ease.lsoft.com/scripts/wa.exe?A0=MXG-L

III. MVS, a/k/a z/OS, Technical Notes.
13. APAR OA30974 reports that if you use SMF Logger AND have removed all

MANx datasets from SMFPRmxx, but have LASTDS(HALT) specified there,

an IPL will fail, as it enters a WAIT DOD RSN01 wait state. Remove

the LASTDS(HALT) to circumvent until IBM has a PTF for the APAR.
12. APAR OA31547 reports that SMF 89 records can stop being written if

they change SMF recording from NOACTIVE to ACTIVE. APAR Still Open.
11. APAR PK86020 reports A REPORTING PROBLEM WITH THE RMF WORKLOAD

ACTIVITY REPORT WITH RESPECT TO THE TRANS-TIME

ERROR DESCRIPTION:

A reporting problem with the RMF Workload Activity report with

respect to the Trans-Time. Here is a sample report that shows the

TRANS-TIME values that are not correct:

TRANS-TIME HHH.MM.SS.TTT

ACTUAL 973

EXECUTION 875

QUEUED 97

USERS AFFECTED: All users of IBM WebSphere Application

Server V6.1.0 viewing RMF diagnostic

reports.

The RMF Workload Activity report shows an incorrect queued

value under the TRANS-TIME values.

PROBLEM CONCLUSION:

Because the queue times are reported based on the values in the

thread at the time of capture, the values presented may be incorrect

if the thread has switched during the course of processing. This

may occur if SSL or webservices are active. The problem is resolved

by copying these values through the java portion to circumvent the

loss of the values during thread switching.

APAR PK86020 is currently targeted for inclusion in Service Level

(Fix Pack) 6.1.0.29 of WebSphere Application Server V6.1
10. APAR OA31088 reports Z/OS 1.11 B10 INCORRECT FREE SPACE AND LARGEST

FREE EXTENT IN SMS VOLUME CONTROL BLOCK IMMEDIATELY AFTER VARY

ONLINE

ERROR DESCRIPTION:

In z/OS 1.11 environment, free space and largest free extent are

incorrect for new volumes that have been varied online and have not

had any datasets allocated to it. The incorrect statistics are in

the volume statistics control block (IGDVLD) which feeds downstream

systems such as RMF. Beginning in Z/OS 1.11, an additional call is

now being made such that the volume statistics will be updated when

the volume is varied online eliminating the need to allocate a small

1 trk dataset to the volume (APAR OA23901 included in 1.11 base).

This client saw incorrect RMF Storage Group and volume statistics

Additional symptom:

ISMF LISTSYS statistics are incorrect after the vary.

ISMF LISTVOL command statistics seem to be correct.

LOCAL FIX:

Allocate a dataset to the volume which will update the free space

and largest free extent statistics correctly.
9. APAR OA30299 reports SMF74DCI SMF74DCT BLANK FOR DEVICE FOLLOWING

HIPERSWAP

After a hyperswap or DDR device swap, IOS will issue an ENF 28 DDR

and ENF 23 Device Online for the target device of the swap. Both

ENFs are processed by RMF listen exit module ERBMFEAR. But RMF

module ERBMFIDA, which updates the DDB, is only called when

processing the ENF 23 for device online event. Since ENF 28 DDR

runs asynchronously, it can happen that the ENF 28 is processed

before ENF23 so that the call to ERBMFIDA is skipped. As result of

this the RMF DDB is not updated. Affected RMF releases: z/OS-1.9 up

to and z/OS-1.11

PROBLEM CONCLUSION: With this APAR, the ENF 28 listen exit handler

in module ERBMFEAR is changed to call ERBMFIDA when the

configuration token in EDDDB field EDDDSDCT is blank.
8. APAR OA31471 reports variable SMF75AVU, MXG variable AVGUSED,

the average number of used slots in the RMF PP PAGESP report is too

low. The problem occurs when large page datasets are used and RMF

Monitor I zz data gatherer session runs with a very small cycle time

(e.g. 100 ms).
7. APAR OA30633 reports HIGH CPU IN GRS WHEN ZFS QUERYING FILE SYSTEM

OWNER FOR RMFGAT DATA GATHERING.

When running with RMFGAT data gathering option "ZFS", RMF makes

requests to zFS to collect statistics on zFS file systems. As a

result, zFS makes ISGQUERY requests to GRS to determine the owner of

each file system. The GRS GQSCAN routine scans for enqueues across

the sysplex and can be CPU intensive. LOCAL FIX:

BYPASS/CIRCUMVENTION: The collection of ZFS data can be turned off

by specifying Monitor III data gatherer option "NOZFS".
6. APAR OS30551 reports zeros for buffer statistics above 2GB until

buffer utilization exceeds 80%. APAR OA27343 created the error.

APAR OA72343 was installed.
5. Daylight Savings Time and CMF and GMT Offset.
With BMC's CMF monitor instead of RMF, you must bounce the MVSPAS

(CMF) Address Space after the CEC Clocks were reset for DST Fall
  1   2   3

Share in:

Related:

* copyright (C) 1984-2010 merrill consultants, dallas, texas * icon* copyright (C) 1984-2010 merrill consultants dallas texas usa *

* copyright (C) 1984-2010 merrill consultants, dallas, texas * icon* copyright (C) 1984-2017 merrill consultants, dallas, texas *

* copyright (C) 1984-2010 merrill consultants, dallas, texas * icon* copyright (C) 1984-2017 merrill consultants dallas texas usa *

* copyright (C) 1984-2010 merrill consultants, dallas, texas * icon* copyright (C) 1984-2011 merrill consultants dallas texas usa *

* copyright (C) 1984-2010 merrill consultants, dallas, texas * icon* copyright (C) 1984-2013 merrill consultants dallas texas usa *

* copyright (C) 1984-2010 merrill consultants, dallas, texas * icon* copyright (C) 1984-2013 merrill consultants dallas texas usa */...

* copyright (C) 1984-2010 merrill consultants, dallas, texas * icon59th Annual Texas cpa tax Institute San Antonio and Dallas, Texas November 13 and 14, 2012

* copyright (C) 1984-2010 merrill consultants, dallas, texas * iconUniversity of Texas at Dallas

* copyright (C) 1984-2010 merrill consultants, dallas, texas * iconAll procedures that involved use of animals were approved by the...

* copyright (C) 1984-2010 merrill consultants, dallas, texas * icon[Obviously the Dallas addresses below apply only to Dallas County...




forms and shapes


When copying material provide a link © 2017
contacts
filling-form.info
search