COPYRIGHT (C) 1984-2005 MERRILL CONSULTANTS DALLAS TEXAS USA
Newsletter FORTY SIX
/* COPYRIGHT (C) 1984-2005 MERRILL CONSULTANTS, DALLAS, TEXAS */
*********************NEWSLETTER=FORTY-SIX*******************************
MXG NEWSLETTER NUMBER FORTY-SIX, Dated February 1, 2005.
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 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.
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 - See Member CHANGES.
COPYRIGHT (C) 2004 MERRILL CONSULTANTS DALLAS TEXAS USA
I. The Annual MXG Version, 22.22, dated February 1, 2005, was sent
on CD-ROM to all sites by Feb 2, 2005.
1. Major enhancements added in MXG 22.22:
See CHANGES member of MXG Source, or http://www.mxg.com/changes.
II. MXG Technical Notes
1. You can use the SAS FTP access method to directly read MVS SMF data
on your execution platform (another MVS or an ASCII pc/unix system!)
without first downloading the SMF file, and without converting the
data file to RECFM=U:
- read with ftp access takes no disk space to store the SMF data
- run time is faster with ftp-access than the sum of the time to
ftp-download plus read the downloaded data:
- MVS to ASCII direct read took 82 seconds ET, ftp download took
200 seconds ET and then 27 seconds ET to run TYPE30 on ASCII.
- MVS to MVS direct read took 1 min 11 sec ET (17 CPU seconds),
ftp download took yyy ET (zzz CPU), plus 35 seconds ET (14 CPU)
to read the downloaded file. And the ftp access job had only
903 EXCPs (those must be the output writes, with none of the
ftp access I/O being counted!), while reading the downloaded
file recorded 12,000 EXCPs.
This FILENAME statement syntax will read your MVS data using the
ftp-read-access, and prompt for password:
FILENAME SMF FTP "'MVS.DSNAME'" USER='USERNAME' HOST='FTP HOST'
S370VS RCMD='SITE RDW' LRECL=32760 PROMPT;
or you can use this syntax and supply the password:
FILENAME SMF FTP "'MVS.DSNAME'" USER='USERNAME' HOST='FTP HOST'
S370VS RCMD='SITE RDW' LRECL=32760 PASS='password';
To use the ftp access on MVS, you will need MXG 22.12 or later, and
as documented in Change 22.300, you will need to use
%LET MXGJFCB=;
as your first //SYSIN DD statement.
III. MVS Technical Notes.
12. APAR PQ98850 corrects the values of variables QESTMNUS,QESTMLUS in
MXG dataset MQMCFMGR, from SMF 115 MQ-Series Coupling Facility Data.
11. APAR OW19569 changes the Message Identifiers for SMF Data Set name
messages, if you choose to use new SMF dataset names. Formerly,
you could only have SYS1.MANn as the DSNAME of your VSAM SMF file,
but you can now choose any 44-character name in your SMFPRMnn member
of SYS1.PARMLIB. But, if you do, the old messages (IEE360I,IEE362A,
IEE362I,IEE364I,IEE949I-IEE953I,IEE960I and IEE966I) are now change
to new numbers listed in the APAR. This would be very important if
your Automated Operations product does any management of SMF data
based on Message ID.
10. Information APAR II13668 documents that the LPARNUM (SMF70LPN) is no
longer what it used to be! Prior to the 2084, machines used to use
the customer input value for what was called 'partition number', and
those old machines used it to identify both the logical partition
number and the MIF image ID number for its I/O. Beginning with the
2084 and all future machines, that input control for HCD/IOCP
applies only to the I/O for the partition, in concert with the CSS.
There is no customer control over the number (SMF70LPN/LPARNUM) that
identifies the logical partition number itself. The customer does
specify the MIF image ID number to identify its I/O in the 2084
IOCDS, built the 'partition number' in SMF70LPN is internally
generated, alphabetically, but CSS. The changed terminology is
documented in the z990 IOCP User's Guide (SB10-7037).
In the PDB.ASUM70PR and PDB.ASUMCEC MXG datasets, the set of LPnXXXX
variables for each LPAR is based on the LPARNUM, so with 2084s what
used to be in LP3XXXXX variables can be in any of the LPnXXXXX set
of variables, and that could change again tomorrow. Instead of
using the PDB.ASUM70PR dataset for PR/SM LPAR analysis, you should
use the PDB.ASUM70LP dataset, that has only one set of variable
names, and one observation for each LPARNAME, which should be used
in your reporting/selection, instead of LPARNUM, now.
9. APAR PQ98201 fixes several internal defects for WebSphere 5.2.3,
including incorrect values in X500Name information in SMF Audit
records.
8. APAR PQ98850 corrects SMF MQ-Series for z/OS Version 5.3 SMF record
data fields QESTMNUS and QESTMLUS (Max Elements and Max Entries)
that had extremely large values, sometimes.
7. APAR OA10164 (finally - I reported this to IBM in 1993!) changes the
Internal Clock Times of IBM's VTS device so they match the mainframe
clock; previously, the VTS clock ran on its own time, and was hours
away from reality when I first tried to match SMF 94 with internal
log data from the VTS device.
6. A question posted to MXG-L regarding the difference between SMF30AIS
(25,000) and EXCPDASD (400) for an IMS BMP was answered by my best
guess:
SMF30AIS is an Address Space total count of SSCHs, the number
of I/O operations caused by this address space to DASD devices,
and is captured at the hardware level, and includes I/O operations
that this address space performed via cross memory services to
any other address spaces, plus any I/O from dependent enclaves.
EXCPDASD is the sum of SMF30BLK, the Block Count for each DASD DD
in this address space's TIOT, and those Block Count values depends
on the Access Method:
- for "well behaved" sequential Access Methods, QSAM/BSAM, it will
be the count of blocks, i.e., "EXCPs"
- for VSAM it will be the count of SSCHs
- for EXCP Access it is whatever the Access Method programmer
chose to pass to the IFASMFEX routine that updates the DD segment
in the TIOT, and will be zero if IFASMFEX is not called from that
I/O Driver.
And, of course, there is nothing in the TIOT segment that indicates
what access method was used for that DD!
Especially when the Access Method is EXCP, the I/O coder may not
even call IFASMFEX, since there is no requirement that he/she do so.
This is why there are zero EXCPs for your //SORTWKnn DD's, whether
you use SYNCSORT or DFSORT.
Years ago, SYNCSORT published benchmarks in advertisements showing
that their sort program performed many fewer I/Os than IBM's sort.
I was asked by a third party to examine their veracity, and found
that I/O counts existed only for //SORTIN and //SORTOUT DDs, and
that SYNCSORT was passing the number of SIOs to IFASMFEX, while IBM
was passing the (larger) number of Blocks/EXCPs to IFASMFEX.
This caused SYNCSORT to have to "fess up", and they had to create a
"Special Core ZAP" that allowed you to chose to count EXCPs rather
than SIOs, because of the false impact on existing billing systems.
With regard to IMS, I have a vague recollection that OSAM does not
normally call IFASMFEX when I/O is performed, but, rather, only when
IMS files were closed, and that that caused the EXCP count in RMF 72
to only be updated at the "end of day", but I was unable to find any
reference, and that may no longer be true.
5. SYNCSORT Early Warning Notice EW5981-0 was required for z/OS 1.5 to
resolve WER061A Equip Check (HDS DASD) ABEND 1188 RC 094B96104 error
messages.
4. A large number of IsUserInRole SMF 80 records are created with CA's
Top Secret Security Product that are not errors. IBM APAR PQ96045
eliminates these "false" SMF 80 AUDIT records, but CA fix BEA6729
for Top Secret V5.2 is also required for their product.
3. APAR OA08887 reports incorrect values in RMF 74.4 variables R744PNU,
R744PBSY, and R744PWAI (MXG variables CFNUMnn,CFBUSYnn,CFWAITnn.
2. As of z/OS 1.3, the Media Manager is used to do all I/O for the CAS
(Catalog Address Space), causing the number of CAS I/Os to increase;
before z/OS 1.3, CAS used VSAM to do Catalog I/O and the Media Mgr
was only used for VVDS I/O, but VSAM specifically omitted the
collection of StartIO or block counts when running under the CAS.
So there really was no increase in I/O with z/OS 1.3, but rather a
significant underreporting of CAS I/Os prior to 1.3.
1. Striping enhancements to extended-format sequential datasets made in
z/OS 1.5 now allow a maximum of 59 stripes, and thus 59 volumes, and
so an extended-format striped sequential dataset now supports up to
4GB of blocks (not bytes!). Since each volume can have 123 extents,
the dataset can have a maximum of 7257 extents.
IV. DB2 Technical Notes.
3. DB2 APARs PQ91101, PQ86477, PQ85650, PQ87440, PQ87783, PQ87848,
PQ88889, PQ90547, PQ91544, PQ73385, PQ74506, and PQ65302 all have
references to IFCID 225 or 217, and without some (or maybe all?)
of those APARs installed, enabling either (or both) of those DB2
IFCIDs can corrupt data in all SMF 102 trace records.
2. My understanding of some DB2 objects; please correct if wrong:
Plans can call packages.
Packages can call stored procedures.
Packages can be bound into collections.
But not all packages call stored procedures, so there is no real
relationship between the count of observations in DB2ACCTP
(each obs in DB2ACCT is the execution of a package)
and the value of QPACSPNS, the count of stored procedures that
were called by that package execution.
So in a DB2ACCTP observation, QPACSPNS is zero if the package
did not call a stored procedure, or non-zero if it did.
1. If you run DB2 under "MVS" running as a VM guest when in z/Arch
mode, Hiperpools will not function under DB2 without APAR PQ87231.
V. IMS Technical Notes.
1. APAR PQ65904 documents problems with excessive number of false IMS
Scheduling Messages, each of which showed .01 CPU seconds in IMS 07
Log records; these false schedules can be recognized by IBM field
DLRGUMES (which is MXG variable CALLMSGU) being zero.
VI. SAS Technical Notes.
9. A comparison of SAS reading selected SMF records in one pass versus
using IFASMFDP to first select and write out the desired subset of
SMF data, and then SAS reading that subset appears to be a draw.
An 8989 MegaByte SMF file with all SMF records was read by IFASMFDP
selecting 30, 72, and 89 records, which totalled 3097 MB, which was
then read with MXG's BUILDPDB (tailored to read only those records).
IFASMFDP used 0.45 CPU minutes and 5.26 Elapsed minutes to read and
write, and the BUILDPDB used 12.51 CPU minutes and 21.26 Elapsed min
to read the 3GB file, for a two-step total of 12.96 CPU, 26.62 ET.
BUILDPDB's 9GB read in one step took 13.26 CPU, 33.97 ET. The two
step job issued 334,076 EXCPS to the one step total of 101,724.
8. Under ASCII platforms, if you want to see the actual statements in
the autoexec file that is being executed, sas -echoauto will do it.
7. Under SAS V9 on "MVS", new "+SAS processed" messages are printed on
the SYSMSG log, which I find useful, but which are enabled by the
option DLEXCPCOUNT, which I chose to enable in CONFIGV9, but which
can be changed to NODLEXCPCOUNT if you really don't like them!
6. Use of BUFNO=nnn, especially with large (200!) values of nnn, on the
//PDB or //SPIN or //CICSTRAN SAS data library DDs has caused very
strange out-of-memory errors, including SYSTEM ABEND 878-10, with no
SAS messages on the log, and the ABEND occurred long after those DDs
had been written to during the SMF-processing phase - the error was
deep inside the RMFINTRV logic. Remove the BUFNOs!! Benchmarks run
by Martin Kline at American Century show these results:
BUFNO: 1000 100 20 DEFAULT 2
IOTM 17:21 16:17 15:59 15:49 15:51
Elapsed 34:13 30:29 30:22 33:35 32:36
CPUTM 13:11 12:28 12:31 12:38 12:38
CPUTCBTM 13:03 12:20 12:23 12:29 12:29
TCB+IO 30:25 28:37 28:23 28:18 28:20
5. The new V9 PROC MIGRATE can convert SAS V6, V7, or V8 data libraries
to V9 format; the manual for the new procedure is available at
support.sas.com/rnd/migration/resources/procmigrate/migratebook.html
4. Yet another error in the Sequential Engine, this time in V6SEQ under
V9.1, V9.1.2, and V9.1.3. SAS Note SN-013514 has the hot fix.
The error occurs when the V6SEQ engine under those V9 versions tried
to read a SAS dataset that was sorted by more than 10 variables when
it was created, and it causes this error message:
ERROR: The format xxxx was not found or could not be loaded
('xxxx' is not a real format name, but typically unprintables).
The original V6SEQ dataset can still be read with the V6SEQ engine
in Version 8, so the dataset is not actually corrupt; it is only the
the V6SEQ engine in SAS V9 that is broken and must be repaired with
the hot fix, and then it can be read with SAS version 9's.
3. Using SYNCSORT, ERROR: SORT DID NOT COMPLETE SUCCESSFULLY. SEE
MESSAGES ON THE LOG. HOST SORT CANNOT BE USED, along with Syncsort
WER061A I/O ERR JOB,STEP,DC51,D,SASSWK02,**- OP, WRNG.LEN.RECORD,
appears to have been caused by Syncsort adding dynamic SORTWKnn DDs.
The job had 12 SORTWKnn DDs in the JCL, but the job log shows there
were DELETED messages for SORTWK13 thru SORTWK22, indicating that
SyncSort dynamically added 10 DDs. The job failed half of the time
but a rerun was successful. Adding 10 SORTWKnn DDs to the job has
apparently corrected the error.
2. "ERROR LIBREF IS NOT IN A VALID FORMAT FOR ACCESS METHOD SASE7" if
the library was externally allocated is discussed in SN-007759:
If any of the following hot fixes have been installed:
81BA50, 82BA57, 82BX01 (or its replacement),
and a direct access bound library is allocated externally to SAS
with DISP=OLD or DISP=SHER via JCL or TSO ALLOCATE command, and
assigned by SAS more than once during the lifetime of the MVS
allocation, any attempt to use the library after the reallocate
will generate that error.
The hot fix is available in that SAS note.
1. New SAS Option ERRORBYABEND is not needed in MXG's CONFIGV9 member,
because the ERRORABEND option already causes a USER 999 ABEND when
a BY list is not in order. It appears ERRORBYABEND was created for
sites that ONLY want an abend on a bad BY list, when ERRORABEND was
not desired. The SAS default is NOERRORBYABEND.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. Incompatibilities and Installation of MXG 22.02.
1. Incompatibilities introduced in MXG 22.10 (since MXG 21.21):
See CHANGES.
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 21.21 now in MXG 22.xx:
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 22.yyy thru 22.001 are contained in member CHANGES.