COPYRIGHT (C) 1984-2005 MERRILL CONSULTANTS DALLAS TEXAS USA
Newsletter THIRTY NINE
/* COPYRIGHT (C) 1984-2005 MERRILL CONSULTANTS, DALLAS, TEXAS */
****************NEWSLETTER=THIRTY-NINE**********************************
MXG NEWSLETTER NUMBER THIRTY-NINE DATED JULY 26, 2001.
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS Page
I. MXG Software Version 19.03.
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 19.03.
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 19.03:
See CHANGES.
II. MXG Technical Notes
1. Using a text file of the SAS log's printed hex dump of a VSAM SMF
record as input to the UTILBHEX program will write a legitimate VBS
record, but that will still be a VSAM-format record, and under the
ASCII versions of SAS, there is no JFCB, so MXG can't automatically
recognize the input is in VSAM-format like it does under z/OS-etc.
You must set the OFFSMF=4 in member IMACZDAT to make it work.
Few outside MXG Technical Support need to know this fact.
III. MVS Technical Notes.
22. An interesting problem, since I remember when 51 hours of MVS 2.2
up time was magic: APAR OW48782 discusses address spaces not
swapping in after the system had been IPLed for 51 days, because
the SRM timing algorithms can no longer run. I also recall that
MVS 2.2 had a hard limit of 168 hours in it's earliest incarnation
and it took 2.5 years before someone hit that SEV 1, but by then
MVS 3.0 had fixed the problem!
21. If you use MULC (Measured Usage License Charges?) for DB2, after
APAR OW30153, new APAR OW16176 corrects a CICS DB2 Performance
degradation, but the zap with that APAR has a secondary effect of
the TYPE30MU Usage data being recorded as lower than actual usage.
IBM doesn't care, since actual MULC charges are in the type 89 SMF
record, which still has totals correct, but if you use the TYPE30MU
data to recover charges, you'll need to be aware of this APAR and
watch for a permanent correction.
20. APARs OW44428, OW44429, and OW47519 are required prerequisites to
creating the new FICON directory RMF type 74 subtype 7 records, and
new RMF option FCD/NOFCD in ERBRMFxx enables their creation.
19. APARs OW48603 fixes Type 6 SMF records with corrupted data values.
READTIME was corrupt and JOB contained hex zeroes. 18Jul2001.
18. APARs PQ41205 and PQ44739 address performance issues with CISCO
routers and high channel utilization. These APARS are related
to claw packing, even though the APAR text refers only to OSA
devices that tend to be LCS. Big improvements were reported on
MXG-L with these APARs.
17. APAR OW50187 for z/OS V1R2 reports incorrect values in RMF type 72
records in fields SMF72CTS and SMF72STS.
16. APAR OW50084 reports multiple RMF problems with both reports and
records. Processors never Online at interval end have no CPU Data
section in type 70; DASD response times are now reported as integer
but will now be in units of tenths of a millisecond.
16. APAR OW49733 reports missing Cache RMF 74 subtype 5 (TYPE74CA)
records after APAR OW46463 was applied; additional symptoms are
poor performance for PAV devices, visible thru RMF measurements.
15. APAR OW49744 corrects several values in variables in SMF type 85
records in subtypes 32 thru 35.
14. For the record: MXG Software does NOT issue a STIDP, Store CPU ID,
nor a STSI, nor a STAP instruction, and MXG Software DOES handle
hexadecimal characters in the CPC Serial Number fields. Both
changes were introduced in IBM z900 2064 processor family, but
have no impact on MXG Software.
13. EXCP counting for DSS was changed by IBM. DSS used to use EXCP to
read VSAM extended format datasets, so EXCP counts were recorded in
SMF (type 30, type 64), but in DFSMS 1.5.0, DSS was changed to use
the System Data Mover (ANTMAIN) component to do the reads, and it
does not use EXCP as DSS did.
12. From Pat Artis: Why are Ficon channels busy when they are idle?
Because that, even when there are no I/O's executing on the FICON
channel, the channel is still polling for work to do. This shows
up as bus utilization on the RMF report and in TYPE73. 1Jun01.
11. APAR PQ46754 reports FTP failures of all kinds due to TCP/IP acks
and nacks getting out of sequence, causing TIMEOUTS, etc.
10. APAR OW49094 reports large values in SMF30BLK (EXCP count in 30s)
and SMF15NTR always zero with OS/390 R10 and DFSMS R10 HZD11F0 was
triggered by Partial Release.
9. APAR OW48109 describes errors in Type 70 data on 2064s with ICFs,
in RMF reports, and indicates that "RMF tolerates now a dispatch
time, some milliseconds greater than the processor online time"!!
8. APAR PQ15462 for DB2 deals with very high I/O activity to the BSDS
(Bootstrap) dataset of the second member of a 2-way datasharing
group. The first member is running Capture/MVS DPROPR
Capture and is related to the way DPROPR calls DB2 and
whether there are either cdc or ur related records to
process.
7. APAR OW48402 corrects bad values in type 42 subtype 5 TYPE42DS
dataset records when SMS reads device statistics, and the error
also created a large number of LOGREC entries NEW HIT RATIO ERROR.
6. APAR OW48334 reports high disconnect times in RMF and SMF records
for 2105 ESS SHARK with PPRC when running on a G5 machine or
earlier.
5. APAR OW47895 confirms IBM's non-support for extended-format VSAM
MANx files by the SMF writer, and makes no mention of any intention
to do so. We need extended-format supported so our VSAM SMF files
can be striped and/or hardware compressed, but it's not there now.
4. APAR OW47863 corrects excessive virtual storage (SP229 Key 5) in
address space SMSVSAM when using VSAM RLS and RMF Release 10 to
display VSAMRLS statistics (RMF was not releasing storage).
3. APAR OW47827 reports and corrects problems found during internal
testing of Dynamic CHPID Management under z/OS Release 1.
2. APAR OW48124 corrects offset for S42XRVSS and subsequent fields in
the SMF 42 subtype 11 XRC Volume Data Section.
1. APAR PQ43767 corrects high CPU time, high EXCP count, and possibly
large number of dynamic allocation TYPE30_D records with Imagecopy.
IV. DB2 Technical Notes.
1. DB2 APAR UQ41459 on DB2 5.1 caused the SRB Time recorded in SMF/RMF
to drop substantially.
V. IMS Technical Notes.
1. Information APAR II12877 relating to IMS Fast Path reports that
after migrating from SMS 1.3 to SMS 1.5, I/O counts in SMF type
30 record (SMF30TEP=EXCPTOTL, the address space total EXCP count,
and "SMFIOCNT, which I think they mean SMF30IO=IOUNITS) were much
larger for a BMP job, because FastPath will use ASPACE operand on
MMCALL for SMS 1.4 and above, which (correctly) will result in the
Media Manager charging dependent region initiated I/O (i.e. reads)
to the dependent region rather than to the control region.
VI. SAS Technical Notes.
11. While OS/390 R2.10 and later now support large blocksize for tape
files (256K for 3590 tape devices, 65535 for other devices, no
change for DASD devices) SAS under OS/390 or z/OS will not be able
to read those large blocksize files until SAS Version 9. SAS now
fails with ERROR: OPEN FAILED FOR FILE SMF: SYSTEM ERROR 013-0E1
if you try to read a large blocksize file from tape. 19Jun01.
And SAS will not allow LRECL>32760 for RECFM=VBS nor BLKSIZE>32760
for RECFM=U until Version 9.
10. If creation of the MXG Format library with member FORMATS ends with
"ERROR: Cannot update record in entry MGxxxxx.FORMATC. Record length
mismatch.", the correction seems to be to erase the existing format
dataset in the directory pointed to by the LIBRARY libref and then
rerun the FORMATS step. This error has only been observed under SAS
Version 8 under Windows. You can erase the format catalog, or you
can use this step to delete it from within SAS:
PROC DATASETS DDNAME=LIBRARY MT=CAT;
DELETE FORMATS;
9. SAS Hot Fix 81BA40 corrects a number of reported SAS problems, from
FILENAME causing three mounts for one tape, 0C4 using QSAM or ISAM,
BY variable position errors, 0C1 in PROC SORT, 0C4 using DFSORT
Performance Booster, and several others.
8. Critical fix for SAS Releases V7 thru V8.2 for SMF VBS broken data.
SAS Releases V7 thru V8.2 do NOT read any subsequent SMF records
after an invalid VBS segment is detected. Messages on the log:
ERROR: INVALID VBS SEGMENT DETECTED.
FATAL: UNRECOVERABLE I/O ERROR MESSAGE
after the segment error message.
For SAS Release 8.1 TS 1M0 Hot Fix 81BA41 is available for download.
For SAS Release 8.2 TS 1M0 Hot Fix 82BA31 was available but was then
renumberd to 8.2 TS 1M0 Hot Fix 82BA39, available for download.
See SAS Note SN-004555.
Updated Dec 10, 2001: Hot Fix 82BA57 replaced 82BA31; see above.
7. Formatting a numeric variable that has stored LENGTH less than 8,
if the format is a user-defined format created by PROC FORMAT that
itself uses an existing format name as a label, OTHER=[DATE9.] in
this specific case, causes 01JAN1960 to be printed for lengths of 4
or 5, and '********' to be printed for lengths of 6 or 7. Obscure,
and unlikely to have an impact, but noted here for reference.
7May2001. SAS Usage Note SN-003430.
6. ABEND 213-B8 on PDB ddname was corrected by specifying the SMS
DATACLASS=NOCOMP on the PDB DD statement to suppress compression.
5. ABEND 613-04 on a SAS Tape DDname with OS/390 R2.10 and DFSMS/rmm
as your tape manager requires IBM APAR OW48403; RMM did not handle
multiple tape opens properly.
4. SAS V8.0 and V8.1 cause error messages if NOWORKINIT option is used
with old-style macros. The error is fixed in V8.2, and SAS Usage
Note SN-003514 lists Z8003514 and Z8013514 as available zaps to fix
the error under V8.0 and V8.1. (I strongly suggest 8.1 vice 8.0).
The error text is UNABLE TO OPEN MACRO LIBRARY and THE VALUE SASO
IS NOT A VALID SAS NAME.
3. SAS V8.0 and V8.1 Usage Note SN-003821 reports S0C4 ABEND using
DFSORT Performance Booster interface. The error will be fixed in
SAS V8.2 TSLEVEL 2M0, but the error can be circumvented by setting
the SAS system option NOSORTBLKMODE. The problem was caused by SAS
interpreting the "preferred size" passed by DFSORT as a signed
integer when it is actually an unsigned integer.
2. SAS fixes are available for SAS 8.0 and 8.1 that correct increases
in SAS CPU usage on both the new z900, which precipitated this ZAP
as the increase was very noticable in the 20-25% range, and for the
G5/G6-based processors, where only a 5-10% reduction was observered.
See SAS Note SN-004291 for SAS 8.0 and 8.1. The problem is fixed in
SAS Version 8.2 TS2M0 of the SAS System. Note that SAS 6.09 has an
associated fix in SAS Note V6-SYS.SYS-G952.
1. SAS ARRAY names cannot be the same as a SAS variable name.
1. Summary of ALL important SAS V8.1 Issues. Last updated: 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 uses MEMTYPE=ALL as the default, which attempts to
copy all data structures, which you do not want. MEMTYPE=DATA is
required to ensure that only Data Sets are copied.
Revised 23Jan2001. Revised 25Apr2002.
f. SAS V8 ABEND S01D when HSWORK is used. SAS zap Z8001639 fixes.
g. SAS V8 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.
1. With CICS and RACF, every time there is a successful or unsuccessful
signon, a RACF record is always created, because CICS issues RACINIT
with LOG=ALL, to log all attempts, intentionally. (LOG=ASIS logs
only invalid or unsuccessful sign-ons). ITEM RTA000007479 discusses
why CICS does not give an option, but that item also reminds you
that even if CICS itself does not provide a user signon record, the
RACF records can identify signons to CICS.
VIII. Windows NT Technical Notes.
IX. Incompatibilities and Installation of MXG 19.01.
1. Incompatibilities introduced in MXG 19.01 (since MXG 17.17):
a- No changes in MXG architecture were made between 18.18 and 19.01
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 18.18 now in MXG 19.01:
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 19.xxx thru 19.001 are contained in member CHANGES.