COPYRIGHT (C) 1984-2021 MERRILL CONSULTANTS DALLAS TEXAS USA
MXG NEWSLETTER FORTY-EIGHT
*********************NEWSLETTER FORTY-EIGHT*****************************
MXG NEWSLETTER NUMBER FORTY-EIGHT, Feb 20, 2006.
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 z/VM Technical Notes.
X. Incompatibilities and Installation of MXG.
See member CHANGES and member INSTALL.
XI. Online Documentation of MXG Software.
See member DOCUMENT.
XII. Changes Log
Alphabetical list of important changes
Highlights of Changes - See Member CHANGES.
COPYRIGHT (C) 2005 MERRILL CONSULTANTS DALLAS TEXAS USA
I. The Annual MXG Version, 23.23, dated February 20, 2006, was sent
on CD-ROM to all sites shortly thereafter.
1. The current version is MXG 23.23, dated Feb 20, 2006.
See CHANGES member of MXG Source, or http://www.mxg.com/changes.
II. MXG Technical Notes
2. ASCII to ASCII translations.
These ASCII "text" characters, received in emails from international
customers, must be translated into their "MXG expected" ASCII hex
value, so MXG source can execute on all EBCDIC and ASCII platforms:
Description Received in Emails MXG Expected ASCII
single-quote '92'x '27'x
double-quotes '93'x,'94'x '22'x
dash '96'x '2D'x
at-sign 'F5'x '40'x
1. How can I count the DB2 IFCIDs in my SMF file?
You can use this tailored execution of %READDB2:
%LET MACKEEP=
%QUOTE(
MACRO _E102SSSS OUTPUT T102SSSS;
KEEP QWHSSSID QWHSIID;
DELETE;
%
);
%READDB2(IFCIDS=0-350);RUN;
PROC FREQ DATA=T102SSSS;
TABLES QWHSIID*QWHSSSID;
TITLE DB2 IFCIDS FOUND FOR EACH SUBSYSTEM;
RUN;
The %LET MACKEEP= is used to re-define the _E102SSSS old-style macro
so that after the T102SSSS dataset observations are output with only
the two variables in the KEEP statement, the DELETE statement will
cause no other T102xxxx datasets to be output, so there will not be
and disk space required for those data.
But this only will show the IFCIDs that were actually created; you
could have other IFCIDs enabled for events that didn't happen in
the specific SMF file you read with that program.
III. MVS Technical Notes.
27. APAR OA14557 corrects very high SMF73TUT/SMF73PUT values in error
when a channel is cycled offline and back online in one interval.
26. APAR OA14557 corrects errors in SMF73TUT/SMF73PUT when a channel is
taken off line and back on line within one RMF interval.
25. APAR OA14131 changes the SRM IEAOPTxx option IFAHONORPRIORITY=YES
processing, and points to WSC FLASH10432 for additional information
as to why IBM recommends that option; the APAR also notes that the
IFACROPSSOVER option is no longer required to be specified to use
IFAHONORPRIORITY=YES. If IFACROSSOVER and IFAHONORPRIORITY are both
specified YES, they operate independent of each other. The intent
of the APAR is to allow more zAAP eligible work to run on zAAP
processors while still remaining responsive to the zAAP demand.
24. Specifying REGION=0M in the JCL is equivalent to specifying
MEMLIMIT=NOLIMIT. Options for altering this behavior include:
- Using IEFUSI to set MEMLIMIT ceilings for your system, since
IEFUSI settings override the JCL, or,
- Use SMFPRMxx system default settings, but this works only if
there is no REGION or MEMLIMIT specification in this JCL.
However, APAR OA14391 reports the wrong MEMLIMIT is assigned for
jobs started with REGION=0 that have an IEFUSI exit controlling the
REGION, but that IEFUSI exit does NOT control the MEMLIMIT, if
MEMLIMIT was specified in the JCL or SMF.
23. RMF/CMF type 70 records with no PHYSICAL segments are created if the
"Global Performance Data Control" on the Security Panel (Customer
Image Profiles) is changed from checked (default) to unchecked.
When checked, an LPAR can view CPU utilization and IOP data for all
LPARs in the configuration. When unchecked, the LPAR can view only
its own information. But this field MUST be checked when running
RMF at a level that supports FICON, even if no FICON hardware is
installed. See pages 3-71 to 3-73, z9 109 PR/SM Planning Guide.
22. APAR OA14365 corrects negative values in CPUUNITS variable in SMF 72
records when IFA Processors are used. The APAR lists R723IFAT and
R723CCPU as impacted, and states "The IFA times that WLM returns are
not always in sync with the IFA times WLM returns as part of the TCB
time in the IWMWRCAA fields. This can result in the IFA time being
slightly larger than the TCB times for an address space at a time
where it has little activity". 13JAN2006.
21. APAR OA14282 corrects JES 2 SMF 26 records to include WLM data even
when there are no JOB account fields.
20. APAR OA14674 corrects SMF 42 subtype 19 SMF42JRA and RMF III VSAM
LRU report; the buffer size high field did not include all storage
cells. 04JAN2006
19. APAR OA14652 reports SMF 30 subtype 2 interval records not recorded
after apply of APAR OA08702. 04JAN2006.
18. APAR OA14124 for Unix System Services reports certain instructions
in the file system layer of USS cause excessive CPU cache misses,
which results in a degradation of performance. But the APAR text
RECOMMENDATION: Maintaining certain statistics counters in the file
system causes writing to storage3 that is outside the CPU cache is
PROBLEM CONCLUSION: The internal statistics for the Lookup Look
Aside (LLA) table will no longer be maintained. The number of file
system reads and writes will no longer be maintained unless SMF
accounting is active for SMF type 92 Subtype Unmount records!!!
17. MXG's example JCL Procedures MXGSASVn have always had //SORTWKnn DD
statements (static allocation), which prevent dynamic allocation by
the sort product for the work space needed for each individual sort.
Part of this was historic: SAS releases a decade or more ago didn't
properly support dynamic allocation by all existing sort products.
But use of dynamic allocation may now be wiser, since sort products
now get the file size from SAS, so they allocate only the workspace
needed for that sort, and then free the disk space, whereas with the
static allocation, your step holds all of that work space for the
entire life of the step. And, that static allocation must be large
enough for the very largest sort in the step.
The SAS option FILSZ is the default for many versions; it passes
the file size to the host sort package. Originally SAS had to
provide an alternative (OPTIONS NOFILSZ) to disable passing, as
it took a few years for all sort packages to support FILSZ.
(SAS believes that all sort packages now support FILSZ.)
To see what values SAS passed to your host sort, you can use the
OPTIONS SORTLIST; statement to get lots of details on each sort
printed on the SAS log.
But there ARE cases where static //SORTWKnn DDs are required:
- Really big sorts, that require more than 6 Sort Work Areas; as
documented in SAS Note 8750:
With DYNALOC and SORTPGM=SORT, allocation will be done by the
non-SAS sort utility, and in this case, the number of
sortwork data sets which will be allocated is limited to the
number specified in the SORTWKNO= option. The maximum value
for the SORTWKNO= option is 6.
Instead, when manually allocated, the sort package will use all
that you choose to allocate; I've seen massive DB2 sorts require
32 sort work DDs. This paragraph added April, 2008.
- A critical job that does multiple sequential sorts in one step
(like a daily BUILDPDB), with the static DDs, you are guaranteed
to keep the work space for all of those sorts; with dynamic
allocation, you can get halfway thru the sorts, and then fail when
there is not enough work space in your pool (because other jobs
have now allocated that work space that you just freed!).
You might blame the ABEND on poor storage administration, but using
static DDs could get you through the night!
Like most technical answers, "it all depends....".
16. APAR OA11469 corrects impossible values for Low Impact Frames, when
running in 64-bit mode; errors in IRARMSTM, the UIC Update process,
incorrectly counts some address spaces more than once when it gets
interrupted. Low Impact Frames are CSFRLOxx variables in TYPE71,
and all of the "Impact" frame metrics are documented in ADOC71.
== Notes below were included in MXG 23.08 ==
15. APAR OW45020 discusses delays in varying DASD devices offline if the
SMF type 69 record has NOT been turned off. The IBM recommendation
is to NEVER specify TYPE(69) and ALWAYS specify NOTYPE(69).
14. APAR PK13643 documents a caution that Application SYNCH TO OS THREAD
option can significantly increase the number of SMF type 80 RACF
records for security auditing.
13. APAR OA10814 has something to do with WLM Managed Initiators not
starting when you thought they should have.
12. APAR OA13570 corrects zeros in RLS Cache Statistics in both RMF 74
and SMF 42 subtype 15; the error was introduced by APAR OA05619.
11. APAR OA06476 added Raid Rank and other new data to RMF 74 subtypes
5 and 8; those new data were not fully supported until MXG 23.04,
Change 23.023, although the original attempt was Change 22.141.
10. Kathy Walsh's Latest zAAP information listed these APARs:
OA11794 - SMF30ENC (enclave CPU time) may contain zeroes
OA12009 - IFA CPU fields in SMF 72 have incorrect values
OA12550 - IFA Using and Delay Samples - documentation APAR.
9. Don Deese reports these PR/SM enhancements in z9 109:
* PR/SM treats CP, ICF, IFL, and IFA as separate individual pools of
resources.
* PR/SM allows weights and capping to be specified individually for
CPs and IFAs assigned to an LPAR (IFAs no longer inherit the
specifications from the CP specifications).
* PR/SM allows individual specification of reserved CPs and IFAs
(the new LPAR Processor definition panel allows the same options
for IFAs as for CPs....interestingly, although IRD doesn't support
this as yet, the panel also has a check box for "enable WLM
manager" for both CPs and IFAs).
* The new panels also allow many of these specifications for ICF and
IFL LPARs (e.g., initial and reserved ICF and IFL).
8. APAR OA11469 reports an error in internal MCVUIC4S field can cause
RMF to report a larger-than-possible-value for the number of low
impact frames (MXG variables CSFRLOAV CSFRLOMN CSFRLOMX).
7. APAR OA12361 corrects variable R723SCSR, (IBM field R723SCS#), which
can have negative values if the Classes Served array changed between
two invocations.
6. APAR OA10346 adds the User Specified Partition Number, UPID, to the
RMF 70 record.
5. APAR OA07320 "AVT CORRECTIONS FOR WLM OFFLOAD SUPPORT" has changes
to correct IFA CPU times, which could be higher than the total time
in service units, and other IFA-related corrections.
4. APAR OA09978 reports Peer Wait Subchannel Counts and Times, MXG
variables R744SPST and R744SPTC, can have invalid values.
3. Information APAR II13941 documents why the IEFACTRT exit (which is
normally used to print step and job end statistics on your joblog)
can have a negative elapsed time for very short jobs.
2. APAR OA11207 documents that SMF 89 recording is lost if SMF is
switched from ACTIVE to NOACTIVE and back to ACTIVE with a SET
command, and an IPL is required to restore creation of SMF 89s,
although the APAR also states "Closed SUG ... A solution to this
problem will be delivered from IBM in a Release (if any) to be
available within 24 months."
1. APAR OA10091 reports that SMF 42 records may not be written for PDSE
libraries, beginning with DFSMS/MVS Release 1G0.
V. IMS Technical Notes.
VI. SAS Technical Notes.
9. The THREADS option in SAS V9 may or may not help MXG jobs perform:
-Use of THREADS is bypassed when BY statements are used. Only when
you use a CLASS statement (instead of a BY statement) will the
PROC SUMMARY/MEANS consider using THREADS.
-THREADS requires more than one CPU engine for any real benefit.
-For MEANS/SUMMARY, the REGION size completely controls whether
THREADS are used, and there is no way to know if threads were
enabled and/or used, with the default SUMSIZE=0 option value.
The SAS System option SUMSIZE=0 default allows all of your REGION
to be used for summarization, but if you specify a non-zero value
for SUMSIZE, you are restricted to that portion of your REGION size.
If you use a value for SUMSIZE that is larger than your REGION size,
you will get a message:
AN ERROR HAS OCCURRED WHILE SORTING A CLASS INTERACTION TYPE.
-When the REGION size is not large enough, THREADS does all its I/O
to DISK; at least it does tell you that has happened with this note:
NOTE: PROCESSING ON DISK OCCURRED DURING SUMMARIZATION.
PEAK DISK USAGE WAS APPROXIMATELY 98 MBYTES.
ADJUSTING SUMSIZE MAY IMPROVE PERFORMANCE.
but it's impossible to predict; you must iterate REGION size to find
the minimum value for that specific set of CLASS variable's values.
The NOTHREADS EXCP count of 3,469 jumped to 76,060 with THREADS when
compared in an 80 MB REGION; we had to increase the REGION size to
180 MB to drop the EXCP count back to the NOTHREADS value. However,
with that large region, the CPU time was very significantly reduced,
from xxxx to yyyy.
The below paragraph was written in 2006, and the virtual memory
issues may be history now, since you can use the NWAY option to
only create the lowest CLASS level, and the new-in-SAS-V9.2 TYPES
statement allows you to select some but not all CLASS combinations.
Not that MEANS and SUMMARY are now identical so any past notes that
they were different (which they were) are not true for a long time.
As for the last sentence, your mileage may vary:
However, my dislike of the CLASS statement for summarization is due
to its exposure to causing erratic and unpredictable OUT OF MEMORY
ABENDS in your production job. The virtual storage needed by CLASS
statements increases exponentially with the number of subgroups and
intersects in the input data, which can vary widely from day to day
and grows over time, and can have a step increase when new things
are added. As a result MXG has rarely ever to maybe never ever
used CLASS statements in its mainline summarization.
And past benchmarks showed that using a PROC SUMMARY with a CLASS
statement was always more CPU-expensive than a PROC SORT plus a
PROC SUMMARY with a BY statement.
8. SN-014771 reports errors "NOTE: Semantic dump disabled" and 0C4
ABEND if the incorrect release of PROC SYNCSORT is used with SAS V9.
You must use PROC SYNCSORT release 2.3.b. Note that this is only
for the separate "PROC SYNCSORT" product and is not an error in the
SYNCSORT "sort" product. 26Jan2006.
7. Syntax errors for variant characters (brackets, exclamation mark,
the dollar sign, the at-sign, the English pound sign, exclamation
mark, CRLF) may be fixed by turning off the scanner-translation
table (by setting the 6th position of the TRANTAB= to a zero).
See SN-015485 for the exact (and less-than-obvious) syntax.
But the NLSCOMPATMODE option, required for MXG so that a single text
file of SAS code executes on all SAS systems worldwide, which is
set in CONFIGV9, to override the default NONLSCOMPATMODE value,
can also impact these variant characters. The MXG override is ONLY
required when creating it's SAS datasets; once they exist, that
option can be reset for reporting and printing, etc. One European
site found that the exclamation mark and CRLF that were not being
created in ods output with the MXG default, were created with the
SAS default. NEWSLTRS and CHANGESS have more on NLSCOMPATMODE.
6. SN-016064 documents that System C03 and USER U998 ABENDS may occur
on z/OS SAS when external files (i.e., non-SAS data libraries) are
opened using BPAM and BSAM access methods. "This is especially
likely to occur when using %INCLUDE or an autocall macro. The
likelihood of failure increases as more files are opened.
5. PATTERN DSCB NOT FOUND with SAS Version 9.1.3 when creating an MXG
weekly PDB as a new member of an MVS GDG (Generation Data Group)
with z/OS should not happen, since the requirement that your JCL
has a "MODEL DSCB" went away when SMS came to manage our datasets.
However, this site found that ERROR because, buried deep in their
ACS Rules, was logic that if PROGRAM=SAS, then do not SMS manage
the dataset, with a comment that this was done for SAS Version 5!!
(SAS V5 datasets were a problem for SMS management).
Removing that condition from SMS eliminated the errors.
4. SAS will offer LPAR-Size-in-MSU-based pricing for SAS Version 9.1.3,
more properly called "Sub-Capacity Licensing", starting in January,
2006. Previously, only "CEC-size-based" pricing was available.
Pricing will start at 30 MSU. This technical description of MSU and
LPAR was taken from a July 2005 post to MXG-L by Dan Squillace:
MSU capacity is a term specific the IBM z/OS and OS/390 operating
systems. It is a processor-speed-independent way of stating the
computing capacity of a system. Each processor on a machine is
capable of generating a given number of 'service units' per
second of work. One MSU is one Million Service Units per hour.
There are multiple MSU values associated with a given machine.
The MSU capacity of the entire physical system, or Central
Electronic Complex, is known as the 'CEC Capacity'. Each LPAR
running an OS on the CEC has its own MSU capacity, known as its
'image capacity'. This image capacity is the value used in SAS
Software sub-capacity licensing. Note: In the simplest case, a
machine may have just one LPAR in which case the image capacity
equals the CEC capacity.
PLEASE don't expect your SAS Salesperson to know all about this at
this time, as the prices and details are still being finalized by
SAS Institute. Instead, take this note as a "heads-up" of whats
coming, and watch http://www.sas.com for the official announcement
later this year.
3. +INVALID VALUE SPECIFIED FOR OPTION SEQENGINE IN CONFIG FILE and an
USER ABEND U0999, but with no SAS log printed, has occurred at two
sites, and in both cases, they were using SAS Version 8.0, which was
never a production release from SAS, and which was never supported
by MXG, because of flaky errors like this one.
2. SAS note SN-015716 reports that using the TIME() or DATETIME()
function to get the time of day has always been wrong on "MVS",
by 44 seconds; they were adding leap seconds instead of subtracting
them. Only these FUNCTIONs are impacted, and they are not used in
MXG Software to populate any datetime variables.
1. New SAS Version 9 OPTIONS MAUTOLOCDISPLAY can be used to identify
autocalled library from which a %macro was compiled.
VII. CICS Technical Notes.
1. You cannot change DFHMCT (i.e., change the INCLUDE/EXCLUDEs) by
turning the monitoring off and back on, even though that does write
a dictionary record (CEMT SET MON NOPERF, CEMT SET MON PERF).
You must recycle the region in order to change the MCT.
VIII. Windows NT Technical Notes.
IX. z/VM Technical Notes.
X. Incompatibilities and Installation of MXG vv.yy.
1. Incompatibilities introduced in MXG vv.yy (since MXG 22.22):
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.
XI. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
XII. 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 22.22 now in MXG 23.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 23.yyy thru 23.001 are contained in member CHANGES.