COPYRIGHT (C) 1984-2021 MERRILL CONSULTANTS DALLAS TEXAS USA
MXG NEWSLETTER THIRTY-EIGHT
****************NEWSLETTER THIRTY-EIGHT*********************************
MXG NEWSLETTER NUMBER THIRTY-EIGHT DATED FEBRUARY 12, 2001
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS Page
I. MXG Software Version 18.18.
II. MXG Technical Notes
III. MVS Technical Notes
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. Incompatibilities and Installation of MXG 18.18.
See member CHANGES and member INSTALL.
X. Online Documentation of MXG Software.
See member DOCUMENT.
XI. Changes Log
Alphabetical list of important changes
Highlights of Changes 18.001 thru 18.356 - See Member CHANGES.
COPYRIGHT (C) 2000 MERRILL CONSULTANTS DALLAS TEXAS USA
I. MXG Software Version 18.18, the 2001 annual version, was sent to
all MXG licensees in February, 2001.
1. Major enhancements added in MXG 18.18:
II. MXG Technical Notes
1. See Change 18.338 for discussion of the new _Vdddddd macro that lets
you specify KEEP= A B C ... if you want to use KEEP= logic instead
of the old _Kdddddd DROP= syntax.
III. MVS Technical Notes.
14. DFHSM R140 APAR OW46309 has PTF UW76741 to correct invalid negative
values for FSR CPU time in HSM records. Bad fields were added by
APAR OW05988 and corrected by this APAR.
13. NPM NRT segment is documented as 204 bytes, but actual segment size
is 208 bytes; the document was correct and APAR OW47872 will fix
the code so the record is written correctly.
12. Syncsort's product PROC SYNCSORT corrupts output datasets because
they assumed that all numeric floating point fields (i.e., all SAS
numeric variables!) were 8 bytes long, whereas MXG stores many
variables in 4 bytes. This error is not in their Syncsort's SORT
product, so you can circumvent the PROC SYNCSORT error by instead
using just the SORT product, or you can use SAS's internal SORT.
PROC SYNCSORT now has a correction, their PTF EW5422-0. BUILDPDB
errored with: DATASET SPJB30TD DATASET IS NOT SORTED right after it
was sorted; PROC PRINTs showed the variable JOB was good before but
corrupted after the sort, allowing Syncsort technicians to iterate
to their final solution.
I had this same error with Syncsort's Sort product in 1972, when I
first used SAS with Syncsort; SAS stores all numerics as floating
point numbers, but permitted any length from 2-8 bytes, but that
version of Syncsort only supported lengths of 4 and 8 (because the
FORTRAN programs only had REAL*4 and REAL*8 lengths available!).
That old error is one of the reasons I generally keep fields as
either 4 or 8 bytes and don't use those unexpected values, but it
didn't help their current oversight!
11. APAR OW42945 also has lots of RMF problems fixed, 5.1 to 2.9.
ABENDS in both data collectors and report writer, high CPU time
in RMFGAT, invalid system name in Monitor III Coupling Facility,
CF reports effective CPUs is one-tenth correct value, etc. Lots!
High RMFGAT CPU also recommends DFSMS APARS OW43249 and OW43250,
and references Information APAR II12313.
10. APAR OW46825 also corrects many RMF ABEND problems, including ABEND
when the RMF post processor attempts to read Type 103 or Type 108
records with SPE OW44845 for OS/390 2.7. The PTF for this APAR
only fixes the report ABEND if there are NO 103/108 SMF records,
(and suggests you use IFASMFDP to exclude dumping those records
until a later APAR, OW47050 exists). MXG has no problem with those
changed 103/108 records. Dec 5: PE OW47050 hold on this fix!
9. APAR OW45418 corrects many problems in RMF reports, and some data
errors (although it's hard to tell whether some corrected errors
were only in the reports, or in the data records!).
- IBM field SMF70VPA, MXG's variable LCPUADDR in TYPE70PR can have
invalid values of '1n'x or '2n'x when the number of processors in
an LPAR is changed.
- Type 72 Subtype 4 (Monitor II) records can have DB Delay wrong.
- Channel Path Partition and Total Utilization (I presume PCHANBY
PNCHANBY in TYPE73, but might include PCTPTHBY in TYPE78CF?)
sporadically invalid.
- Wrong values in TYPE71 when SMF71ISC is not zero.
- Type 74 data for PAV devices is wrong when RMF retries
initialization of its internal device tables. A retry takes
place when during initialization, listen events arrive for device
state changes, DDR activity, storage group configuration changes,
CMB data state changes, VARY device commands, or when channel
paths become available or unavailable.
This APAR is pervasive: PTFs for MVS/ESA 5.1 thru OS/390 R2.10!!
Dec 1, 2000.
8. RMF Monitor III can consume large amounts of CPU time capturing
DASD CACHE control unit data for its delay reporting. On a CPU
with SU_SEC=2700, the RMFGAT CPU time dropped from 5 to 1 minute in
a 15 minute interval (from 33% to 6 % of an engine) when RMF III
NOCACHE was specified. Even on a SU_SEC=8000 machine, RMFGAT used
2 minutes (13% of one CPU) with RMF III CACHE.
This complex has 129 Logical Control Units, 8,092 DASD Volumes,
on 4 IBM SHARKs, 17 HDS 7770Es and 4 Amdahl PLATINUMs! BIG!
Since all Cache DASD can be measured from a single system, it makes
sense to run RMF III Cache measurement on only one system (easily
implemented by using an automated operations tool to disable it on
all but a single system).
Running RMF Monitor I Cache measurement, which creates SMF type 74
subtype 5 records for TYPE74CA dataset, on only one system also
saves CPU time, but the CPU cost, and hence savings, are much less.
But by running Monitor I Cache on only one system, you will reduce
the SMF data volume (as well as reducing TYPE74CA size and the MXG
CPU and run times!). With 8,092 volumes that's a savings of 2.6MB
of SMF data per RMF interval per system, or 250 MB per day with 15
minute intervals, and TYPE74CA would be 500 MB smaller per day.
This CPU increase has been observed in both OS/390 2.7 and 2.8, but
is likely to apply to all releases. Dec 1, 2000.
To disable CACHE the following commands can be used to modify RMF:
Monitor I - F RMF,MODIFY ZZ,NOCACHE
Monitor III - F RMF,MODIFY III,NOCACHE
7. APAR OW46585 for OS/390 2.6 and above, Goal Mode. Comments that
cap delays for service classes with long response time goals,
even when the service class is missing its goals, and suggests
that a velocity goal may be better than a long response time goal.
6. APAR OW44517 for OS/390 is involved with an increase in CPU wit
Release 2.8. The CPU increase can be as much as 10% and shows
up as uncaptured CPU time. High LPAR overhead, increased CPU by
system address spaces such as CATALOG, GRS, etc., SRM problems
that caused SWAPUS in TYPE71 to be high, etc. 13Nov2000.
5. APAR II12548 states that "FICON channel reports incorrect RMF data
for tape. In the case where the first CCW in the chain gets
initial status of CMD Retry, SFI is not being called, causing
incorrect function pending and device disconnect times. 13Nov00
4. APAR OW45083 corrects one byte error in SMF type 94 record.
3. APAR OW44870 corrects High CPU usage in VLF Module COFMTRIM.
2. APAR OW45192 corrects negative service unit values for enclaves, if
APAR OW40548 has been installed, in TYPE72GO dataset. 03Nov2000.
1. APAR OW40458 corrects negative service unit values (which MXG would
see as large positive values) in TYPE72GO for second period, if a
multi-period server address space stops being a server. 3Nov2000.
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
4. Error message about I/O ERROR on the SAS log and a partial SYSMSG
text about SOURCLIB, READ, OUT OF EXTENTS, BPAM ... results if you
mix PDS and PDSE libraries in your SOURCLIB concatenation. Using
all PDSs solved the error. This was a 2001 note and is probably
no longer accurate in 2006; many sites concatenate PDS and PDSE
without any problems under SAS V8.2 and V9.1.3.
3. The old-style substitution type macros, MACRO macroname ... %
are now documented by SAS on their homepage in technote ts-289, at
http://ftp.sas.com/techsup/download/technote/ts289.txt.
2. Under Version 8, a tape format dataset on disk should ALWAYS have a
BLKSIZE=27798 specified on the DD statement for that dataset, so
that space is not wasted:
- If the SAS V8 sequential engine is in use, it will always force a
32K blocksize if no BLKSIZE was specified on the DD statement in
your JCL;
- A BLKSIZE=27798 can be specified on the LIBNAME statement but it
prints a warning message and the BLKSIZE will STILL be 32K;
- A BLKSIZE of 27798 cuts the space requirement by 42 percent!
- And even if compression is specified, the 'super blocking' is
done by the compression engine, so there the BLKSIZE=27798 has
no negative impact.
This BLKSIZE=27798 should be specified where you are using the
//TAPETEMP DD as in your weekly and monthly jobs, and the MXG JCL
examples now have the BLKSIZE=27998 specified.
1. Summary of ALL important SAS V8.1 Issues. 17Dec2000.
This list was shown at the MXG User Group Session at CMG 2000:
See the prior newsletters' text for more details.
a. Remove MEMSIZE=64M from CONFIG member (use MXG CONFIGV8 member),
and let your REGION= parameter control virtual storage. Must do!
b. USE SEQENGINE=V6SEQ instead of V8SEQ or install Z8002651.
The error is fixed in SAS 8.2.
c. Use SAS member (BATCH) instead of (BATCHXA) in the //CONFIG
concatenation in your JCL, (or use MXGSASV8 JCL procedure
example).
d. Do not use Secondary Allocation and Guaranteed Space for SAS Data
Library on DASD. G.S. is no longer required to get multi-volume
DASD SAS data libraries, but can be used; the existence of G.S.
AND a secondary allocation causes the error (which will eventually
be fixed by SAS).
e. Error with PROC COPY IN=WORK OUT=PDB; if the PDB is a V6 SAS data
library on disk, while copying the WORK.REGSTRY(MEMTYPE=ITEMSTOR),
with this SAS Error message:
ERROR: REQUESTED FUNCTION IS NOT SUPPORTED.
or if the PDB is a V6 Sequential data library, with this message:
ERROR: UNABLE TO OPEN CATALOG PDBTAPE.SASMACR(MEMTYPE=CATALOG)
FOR WRITE ACCESS. ENGINE V6SEQ DOES NOT SUPPORT WRITE
ACCESS.
You must add MEMTYPE=DATA to your PROC COPY statement:
PROC COPY IN=WORK OUT=PDB MEMTYPE=DATA;
because SAS V8 now used MEMTYPE=ALL as the default.
Revised 23Jan2001.
f. SAS V8 ABEND S01D when HSWORK is used. SAS zap Z8001639 fixes.
g. SAS V8 8 does not support V5 data libraries:
- Use V6 to PROC COPY from V5 to V6 lib (DISP=NEW)
- Then use V8 to PROC COPY from the V6 library.
h. What level of MXG is needed for SAS V8.1?
MXG 16.16 ran with SAS V8, with a warning note that the SAS
options CODEPCT and BLKSIZE(TAPE) don't exist.
MXG 17.01 provided new CONFIGV8 without those two options to
remove the warning note on MVS.
MXG 17.07 exploits 32000 byte length of character variables, but
only if COMPRESS=YES was specified, and only for SQL
text variable in TYPE102.
MXG 17.08 exploits the new INHERIT option of PROC MEANS in
VMXGSUM, to skip a data step that is now unneeded.
MXG 18.04 changed V8 default to SEQENGINE=V6SEQ.
MXG 18.05 removed MEMSIZE from CONFIG, (and reinstated options
S=72,S2=72 that had been removed in 17.17).
VII. CICS Technical Notes.
2. APAR PQ42713 fixes CICS/TS 1.3 error that lost significant CPU time
in CICSTRAN variable TASCPUTM (IBM fields USRCPUT), for transactions
that make use of the RMI, and when an MCT with user EMPs is used.
(Using an MCT without the EMPs appears to cause correct CPU time to
be captured). CPU capture in TS 1/3 was changed to cater for the
introduction of OPEN TCBs, and an error in that change caused the
CPU time used from when the task is either dispatched or resumed, up
to the point when processing of an EMP begins, to be not included.
The APAR mentions 50% CPU was lost, but I suspect use of EMPs is not
common.
1. APAR PQ41392 corrects wrong TERMID in type 110 SMF records for non-
terminal transactions. CICS/TS 1.3. Dec 1, 2000.
VIII. Windows NT Technical Notes.
IX. Incompatibilities and Installation of MXG 18.04.
1. Incompatibilities introduced in MXG 18.04 (since MXG 17.17):
a- No changes in MXG architecture were made between 17.17 and 18.04
that introduced incompatibilities.
2. Installation and re-installation procedures are described in detail
in member INSTALL (which also lists common Error/Warning messages a
new user might encounter), and sample JCL is in member JCLINSTL.
X. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
XI. Changes Log
--------------------------Changes Log---------------------------------
You MUST read each Change description to determine if a Change will
impact your site. All changes have been made in this MXG Library.
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
The CHANGES selection on our homepage at http://www.MXG.com
is always the most current information on MXG Software status,
and is frequently updated.
Important changes are also posted to the MXG-L ListServer, which is
also described by a selection on the homepage. Please subscribe.
The actual code implementation of some changes in MXG SOURCLIB may be
different than described in the change text (which might have printed
only the critical part of the correction that need be made by users).
Scan each source member named in any impacting change for any comments
at the beginning of the member for additional documentation, since the
documentation of new datasets, variables, validation status, and notes,
are often found in comments in the source members.
Alphabetical list of important changes after MXG 17.17 now in MXG 18.04:
Dataset/
Member Change Description
See Member CHANGES or CHANGESS in your MXG Source Library, or
on the homepage www.mxg.com.
Inverse chronological list of all Changes:
Changes 18.265 thru 18.001 are contained in member CHANGES.