COPYRIGHT (C) 1984-2021 MERRILL CONSULTANTS DALLAS TEXAS USA
MXG NEWSLETTER FIFTY-SIX
***********************NEWSLETTER FIFTY-SIX*****************************
MXG NEWSLETTER NUMBER FIFTY-SIX AUGUST 18, 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 or www.mxg.com/changes
COPYRIGHT (C) 1984,2010 MERRILL CONSULTANTS DALLAS TEXAS USA
I. The 2010 Annual Version MXG 27.27 was 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/Software_Download_Request
1. The current version is MXG 28.05, dated Aug 18, 2010.
See CHANGES member of MXG Source, or http://www.mxg.com/changes.
II. MXG Technical Notes
2. The OPTION USER=PDB (or USER=ANYTHING) should not be used with MXG.
If you set that option in tailoring code that is executed AFTER the
VMXGINIT has initialized MXG, WITHOUT REINVOKING %VMXGINIT; there
can be strange errors (like obs to PDB.ZZxxxxxx temporary datasets)
because MXG doesn't see that you have changed the option.
While resetting the USER= option might work most of the time, there
are MXG programs (especially reports) that will fail if USER=WORK
(the default) is not in effect.
1. Using ASUMUOW can cause a Condition Code 4 Return Code 4 if you do
not have MQ data. You MUST modify your ASUMUOW member to
- deleting the line with _SUOWMQ
- adding statement %LET MXGMQADD=NO;
III. MVS, a/k/a z/OS, Technical Notes.
26. APAR OA29367 - Gryphon Support, Websphere Portal for z/OS.
New support is provided for the IBM zEnterprise 196 (z196) processor
family with D/T2817 models M15, M32, M49, M66, M80.
Characteristics:
- New channel path types OSX and OSM for the data transfer and
management with the BladeCenter zBX.
- Support of an additional subchannel set, SCHSET 2.
- Support of 128 coupling facility channels.
- Support of 32 hipersocket channels.
In addition to this function, the following enhancements are
shipped:
- The possibility to over-define CF CIB channel path connections
between a stand-alone CF CEC and an OS CEC.
25. APAR OA32935 provides SRM Support for greater than 64 physical
processors on a CEC, citing all users of an IBM zEnterprise 196.
Support for OA32935 was delivered in MXG 28.04 in Change 28.143.
24. APAR OA33358 reports slow zIIP assisted IQDIO transfer speed, for
users running zIIP_assisted IQDIO Multiwrite (SIGA-wm) traffic.
23. APAR PK72057 reports SDSF reporting of CPU Usage for Individual
Address Spaces is incorrect; the MVS CPU% in the DA panel may not
add up to the CPU usage shown in the DA title line; the error is
only for the "DA panel using RMF" (ISFDAR/ISFDAR1). SDSF gets CPU
usage for individual address spaces from RMF and then normalizes the
value based on total CPU usage. The problem is SDSF is using the
LPAR CPU usage and not the MVS CPU usage. As a result, the
individual CPU% values may not add to be equal to or close to the
DA title line CPU usage. Corrected in the SDSF in base z/OS 1.11.
22. APAR OA33049 reports high CPU consumption in GRS Address Space while
RMF III ZFS option is on; after RSU 0910, CPU consumption by GRS was
doubled.
21. APAR PM18254 (WebSphere) reports SMF 120 Subtype 9 records can be
missing the Security Data if a self-contained WEB Module (.war file)
was not packaged within an .ear file.
20. APAR OA33399 reports the NOHONORIEFUSIREGION option only works for
the first step in a multi-step STC or JOB.
19. APAR OA33696 will permit IFASMFDP to run unauthorized. Two recent
APARS, OA29894 and OA32258, have forced IFASMFDP user exits to run
in APF authorized mode; with this APAR, it is possible to run
IFASMFP non-authorized, and thus the user exists also run as such.
18. APAR OA33523 reports SMF 42 subtype 16 records sometimes indicate
GT4KNOTACTIVE when >4K Caching is enabled.
17. APAR OA32169 reports invalid values ("negative" for SMF30OST, MXG
variable OMVSOST, CPU TIME ACCUMULATED BY SYSCALLS if the USS
parameter SYSCALL_COUNT is toggled.
16. Change 11.338 added these new fields to TYPE42DS (SMF 42 subtype 6):
S42AMZRB Number of directory reads
S42AMZWB Number of directory writes
but they were not yet populated, because "The directory counts do
not include STOW or BLDL yet, and there's more design ongoing to
capture as much as possible (eg., VIO and PDSEs)."
Now, 17 years after those fields were added, an ETR was opened with
IBM Support because those fields were still zero; their replies:
Action taken:
Reviewed ETR, no known issue in this area.
Reviewed source code, but, could not locate where these values
are updated.
Action plan: Discuss with defect support.
...
I was able to locate this Q&A item:
RTA000142416
IBM STATUS:
Could you tell me when we should expect to see any value in the
field S42AMZRB of the SMF TYPE42 subtype6 records? This customer
finds that this field is always zero, even for pds's.
IBM STATUS:
CMM only builds the SMF42 record from information supplied by
other components.
...
IBM STATUS:
As it turns out it was significant that I couldn't find where this
field gets updated. It doesn't. There are plans to put code into
BLDL (for directory reads) and STOW (for directory writes), but it
hasn't been done yet. Sorry for the confusion in the
documentation. I have marked this PMR for inclusion in the ASKQ
data base so at least if someone else has the same problem they
will be able to find it.
...
I am still waiting for a confirmation from the change team that
this is still valid.
This Technical Note will be updated if/when an APAR exists that
populates those fields.
15. APAR OA31800 reports RMF monitoring metrics prefixed with CPC_ are
no longer zeros when RMF is stopped or restarted.
14. APAR OA32286 reports z/OS 1.11, ONLY with HiperDispatch, has high
LPAR Management CPU time and/or high Uncaptured Time, and most
noticeably on systems where processors are frequently in "no work"
waits. The presence of undispatchable asynchronous exit WEB blocks
on an otherwise quiet WUQ magnifies the problem. The APAR text has
verification instructions to confirm the error exists.
The current status local fix: Turn Off HiperDispatch.
13. APAR OA31417 corrects the Average Used Slots variable SMF75AVU,
which was too low when large page datasets are used and Monitor I
runs with a very small CYCLE time (e.g., 100 milliseconds).
12. APAR PM05716 corrects SMF119 datetime variable TIESTCK in dataset
TYP11902 to now include Leap Seconds, so that end time is greater
than the TISSTCK start time.
11. APAR OA32123 reports RMF Monitor III SYSWKM report does not
correctly report the address spaces that are serving the particular
service class. Pending a PTF, refreshing the WLM policy will cause
the control blocks to be correctly rebuilt.
10. APAR OA31325 reports RMF Monitor III (ASMRMFV/TYPERMFV) DEVR report
shows invalid DSC$, CON%, with both greater than 100%.
9. APAR PK87712 for SMF 120 Subtype 9 records corrects the Process ID
of the Servant PID.
8. APAR OA31055 reports Concurrent Copy in z/OS 1.10 causes system-
wide performance degradation, longer run times, etc., and claims
the problem is fixed by disabling the creation of SMF 42 subtype 4
records for CC, Snapshot, and VCC. The APAR is HIPER.
7. Current 8-byte TODSTAMP format will wrap in year 2041; in 1998, IBM
defined a 16-byte "ETOD" datetimestamp to support dates beyond 2041,
now required in the RACF Database for Certificate End dates, but the
RACF DataBase will store the first 8 bytes of "ETOD" into existing
8-byte TODSTAMP field. The first byte of the 16-byte ETOD format
will contain '38'x if the actual field is in ETOD format, or will
be less than '38'x if the actual field value is in TOD format.
6. APAR OA31072 reports High CPU used by CPM, Capacity Provisioning
Manager, due to Java garbage collections in CPM ASID, and this
excess CPU demand can cause significant overflow of zAAP eligible
work to CP engines. The PTF changes the REGION and HEAP SIZES.
5. APAR PK95003 indicates the zAAP CPU time will be added to the
SMF 120 records "in a future fix pack". No clue when or where.
4. APAR OA31856 reports TYPE42DS (type 42 subtype 6) Average Read
Disconnect Time (S42DSRDD) and the total number of read operations
(S42DSRDT) were invalid. Any EXCP channel program built using a
Locate Record Extended command was counted as a Read operation and
any disconnect time was included in S42DSRDD. Any read or write
channel program built using the Media Manager I/O Driver using a
Locate Record Extended command was considered a write operation by
the code that collects data set I/O statistics. The APAR corrects
all these errors.
3. EAV volumes, Extended Address Volumes, permit VSAM and Extended SEQ
Format datasets to exceed 62520 cylinders in size; the format of EAV
CCHH is now represented as CCCCcccH and the cylinder address is now
cccCCCC. That is, the high 12 bits of the old HH are appended to
the front of the old CC, relying on the fact that no current DASD
requires 16 bits to specify the head. Further information on EAV
internal CCHH representation is in IBM documentation for the TRKADDR
macro. MXG Version 27.02 contained the updates to DCOLLECT support
which was the only data source that contained cylinder counts.
SAS Note 35858 discusses their support for EAV, delivered in SAS
Version 9.2. EAV was first released in z/OS 1.10.
2. APAR OA31055 reports CONCURRENT COPY causes SYSTEM-WIDE Performance
degradation in z/OS 1.10.
"Client reported that, after upgrading to z/OS 1.10, DFSMSdss DUMP
jobs using Concurrent Copy were taking longer than expected to
complete, or not completing at all.
The client also observed higher than normal system CPU utilization,
prolonged contention on the SYS.ANT.QUEUE.ELEMENT latch, and
increased ECSA usage in subpool 241 (from storage containing
eyecatcher SDMSIV). This combination of symptoms significantly
degraded overall system performance.
System performance problems became worse after the jobs were
cancelled, due to fragmentation associated with orphaned common
storage.
Cancelling the Concurrent Copy jobs may also cause storage control
sessions to be left on the storage subsystem. This can eventually
use up all available sessions on the control unit and prohibit the
creation of new Concurrent Copy sessions.
ANTMAIN GRS LATCH CONTENTION HIGH CPU
This APAR is still Open, Jan 26, 2010.
1. APAR OA31624 reports z/OS 1.11 IEFACTRT exit in SYS1.SAMPLIB uses
the field that gets displayed in the job log (total service units)
it is using the new SMF30SRB_L field instead of the SMF30SRV_L field
for total Service Units printed on the "flower box" or Banner page.
The APAR contains the corrected ASM code for the EXIT.
IV. DB2 Technical Notes.
2. APAR PM06953 reports that CP Query Parallelism can now run as a
single enclave.
Problem Description:
When a parallel query is offloaded to the zIIP engines, each
parallel task is scheduled in its own enclave and managed by Work
Load Manager as such.
As a result, there is no way for a user to consistently define
periods to distinguish between, for example, individual enclaves of
a high-consumption query from a single enclave of a low-consumption
query. This limits a user's ability to utilize WLM to favor
low-consumption workloads.
Because z/OS did not initially provide a TIMEUSED support to include
a time-on-CP function vs. time-on-zIIP for multiple SRBs in an
enclave, each parallel task needed to be scheduled in its own
enclave in order to extract the correct accounting information.
However, that created a problem where WLM could not make the
distinction between one of many enclaves belonging to a
high-consumption query from a single enclave belonging to a
low-consumption query. As such, a user cannot define periods that
consistently favor low-consumption queries.
PROBLEM CONCLUSION:
DB2 code has been modified to create only one enclave for all
parallel tasks under a query. This allows WLM to manage each query
as a whole, and properly distinguish between high-consumption
queries and low-consumption queries so that users can define periods
to consistently favor one set or the other.
1. PM02853 reports incorrect CPU times for RRS threads for both CP and
zIIP specialty engines. Specifically, QWACAJST could be greater
than (QWACEJST-QWACBJST), or QWACCLS2_zIIP (MXG QWACZIS1) could be
greater than QWACCLS1_zIIP (MXG QWACZIS2). The APAR text describes
the scenario when a dissociated agent commits a TCB not associated
with that agent, and, if the accounting interval for the dissociated
agent is set to COMMIT, the current accounting interval will end and
a new one will begin at the time of a commit, BUT only class 2 time
is counted during the commit, AND those class 2 CP and zIIP engine
CPU times during the commit may be wrong!
V. IMS Technical Notes.
1. Variable DLRMSCH/LINTMSCH, the Elapsed Time for Schedule Processing
can have extremely large values in IMS Version 11. Two APARs are
relevant:
IMS 10 APAR PK87069 (PTF= UK55674) seems relevant. It was put in IMS
11 with APAR PM10048. It closed in Mar 2010 (PTF UK55640). It's
Abstract has: IMS TYPE08 LOG RECORD HAS INCORRECT SCHEDULING
STATISTICS IN TWO SITUATIONS
ERROR DESCRIPTION:
During processing of a V10 log record, it was found that under 2
circumstances the scheduling statistics in the 08 log record are
incorrect.
-The first is if the 08 record is the result of a quick reschedule.
In this case, the fields are binary zeroes instead packed zeroes,
causing post processing programs to abend.
-The second case is after a false schedule, which is most likely to
happen in a shared queues environment. In this case, the next 08
record has an abnormally high value, which does not reflect the
actual scheduling times.
IMS 10 APAR PK89913 (PTF = UK51145). It was put in IMS 11 by APAR
PK98858. It closed in Oct 2009 (PTF= UK55639). It's Abstract has:
VALUE IN THE LINTMSCH FIELD IN X'08' LOG RECORD TOO LARGE FOR FIRST
TRANSACTION
VI. SAS Technical Notes.
7. The Windows 64-bit SAS Version 9.2 can NOT read or update a FORMATS
catalog that was created by 32-bit SAS Version 9.2. Previously, a
single FORMATS file created with 8.2, 9.1.3, or 32-bit 9.2 could be
used or updated by any of those releases. Now, separate LIBNAMES
and separate directory for 32-bit SAS and for 64-bit SAS is needed.
The error message you get is
ERROR: File LIBRARY.FORMATS.CATALOG was created
for a different operating system.
6. SAS V9.2 has an (obscure) Compiler Error with a Date Literal that
has a null value (e.g. ""D). Changing the string to " "D, i.e.,
inserting a blank, circumvents the error. SAS Note 35161.
5. SAS V9.2 Warnings when combining datasets with different lengths.
As previously noted, SAS V9.2 TS2M0 and TS2M2 print new WARNINGs:
WARNING: Multiple lengths were specified for the variable XXXXXXX
by input dataset(s). This may cause truncation of data.
when datasets with different length variables are combined, i.e.
with SET, MERGE, UPDATE, etc., or when /INHERIT is not used when
data sets are created with PROC MEANS and subsequently combined.
MXG History of dealing with this WARNING (that sets CC=4):
Apr, 2008. MXG 26.03. Internal code changes in MXG eliminated
the warnings, but, also
Added VARLENCHK=NOWARN to VMXGINIT
Aug, 2008. MXG 26.07. Removed VARLENCHK=NOWARN to VMXGINIT,
because Hot Fix F9BA07 restored behavior to 9.1.3.
BUT: Hot Fix F9BA07 is ONLY for (ancient) 9.2 TS1M0.
Apr, 2010 SAS 9.2 TS2M0 and TS2M2 reinstated the WARNINGs by
default, eliminating the Hot Fix change, and instead
documented OPTION VARLENCHK=NOWARN as the solution
you should enable to eliminate the warning.
MXG 28.03 reinstated VARLENCHK=NOWARN in VMXGINIT,
so that the WARNING will NOT be printed nor will the
condition code be set. This protects future MXG
versions when MXG has to change a variable's length
but also protects user code from the WARNING.
SAS Note SN-031850 discusses the warning for both
TS2M0 and TS2M2, but incorrectly says to install
Hot Fix F9BA07 for TS2M0, whereas that Hot Fix is
ONLY for the old 9.2 TS1M0 release.
4. Change 12.153 from 1994 documented that JCLTESTx, Step TESTOTHR will
abend with 213-04 for //DISK DDname if your site sends temporary
allocations to VIO, so VOL=SER=XXXXXX was added in the JCL example
so the allocation would be made to real DASD.
SAS Note 19273 documents VIO restrictions for SAS Data Libraries:
Any library that is allocated to Virtual Input/Output (VIO) must
have a data set name that is system generated. The data set name
must be configured as &name, where name is a string of 1 to 8
characters. IBM supports no other nomenclature for data sets
allocated in VIO. Due to this restriction by IBM, the following
two examples are NOT valid for SAS data libraries that are
allocated to VIO:
Example 1
//TEMPLIB DD DSN=USERID.MY.SASLIB,DSN=(NEW,DELETE)
// UNIT=VIO,SPACE=(CYL,(5,5))
Example 2
libname templib2 '.my2.saslib' disp=(new,delete)
unit=vio space=(cyl,(5,5));
The following two examples ARE valid for SAS data libraries that
are allocated to VIO:
Example 3
//TEMPLIB DD DSN=(NEW,DELETE)
// UNIT=VIO,SPACE=(CYL,(5,5))
Example 4
libname templib2 '&temp' disp=(new,delete)
unit=vio space=(cyl,(5,5));
3. ABEND 40A with Reason Code 008 occurs when SAS V9.1.3 is executed
without a //CONFIG DD.
2. I was unaware that ASCII wildcards can be used in input FILENAMEs:
FILENAME SMF 'D:\SMFDATA\SMF*.RECORDS.U' RECFM=S370VBS LRECL=32760;
will read all files that match smf*, in ASCII ascending order.
I was also unaware that LIBNAME statement supports concatenation
for input. This LIBNAME opens the first directory as read/write,
and any subsequent directories as read only:
LIBNAME PDBS ('D:\PDBLIBS\PDB\' 'D:\PDBLIBS\SPIN\');
Using DATA;SET PDBS.SPIN6; reads the SPIN6 dataset from the "SPIN"
directory. SAS stops in the first directory that has the dataset,
so you can't use this SAS facility to concatenate daily PDBs to read
all of the "JOBS" datasets in those seven PDB libraries. That is,
however, supported in the VGETDDS/VMXGSET utilities in MXG; see the
comments in those members, recently enhanced.
1. SAS documents in SAS Note 10483 that a DD DUMMY in the middle of a
concatenated input causes SAS to stop reading that INFILE. I was not
aware that this "expected" behavior existed, and not sure I think it
is righteous, but the behavior is based on the IBM JCL Reference:
"12.1.6.8 Do Not Concatenate Data Sets after a DUMMY Data Set.
If you define a data set using the DUMMY parameter, do not
concatenate other data sets after it. When the processing
program asks to read a dummy data set, the system takes an
end-of-data set exit immediately and ignores any data set that
might be concatenated after the dummy."
However, there are exceptions; both IDCAMS REPRO and SEARCHFOR will
read all DDs in a concatenation and do not stop at a DD DUMMY, and
I believe that all DDs in a //SORTIN are read by all SORTs.
This also applies to DSNAME=NULLFILE.
VI.A. WPS Technical Notes.
1. X
VII. CICS Technical Notes.
1. APAR PM06737 corrects the optional OMEGAMON data segments that are
missing section length header fields in Release 801 in TDSZ. The
offset for MQ_TOT_CNT appears to be off by four bytes, so the
contents of column MQ_TOT_CLCK appears to be what should be the
contents of MQ_TOT_CNT. The same problem will occur with the
OMEGDB2, OMEGDLI, OMEGMQ and OMEGUEVNT sections within the
SMF_CICS_T record. The problem is that a 4 byte section length
field is missing from the top of these sections, which means all the
resulting fields within the section are off by 4 bytes.
Please contact support@mxg.com if you install this APAR to see if an
MXG Change exists - I need data with the APAR before I can update.
VIII. Windows NT Technical Notes.
1. Microsoft Security Essentials (1.0.1611.0), the anti-virus product
that replaced One Care, causes SAS ERRORs on Windows 7 and XP:
ERROR: User does not have appropriate authorization level
for library WORK.
FATAL: Code generation error detected during BY compare
generation.
(That second "FATAL" message is not always present).
Changing the MSE settings to exclude the sas.exe process and to
exclude scanning SAS7BDAT-suffixed files eliminates the error.
SAS Development is in discussion with MicroSoft to resolve.
IX. z/VM Technical Notes.
1. APAR VM64728 reports z/VM Monitor User Share Data by Processor Type
is incorrect. The five sets of user share data collected (one for
each processor type) in the MRMTRUSR (Domain 1 Record 15), MRUSELON
(Domain 4 Record 1), MRUSELOF (Domain 4 Record 2), and MRSCLSHR
(Domain 9 Record 2) CP MONITOR records are not valid. That is, the
user share data for CP, zAAP, IFL, ICF, and zIIP CPU types is not
correct. The specification of an address being used as a pointer to
the share data in the modules HCPMNE, HCPMOD, and HCPMXL to collect
the data and move it into the appropriate fields in the monitor
records is incorrect.
X. Email notes.
1. X
XI. Incompatibilities and Installation of MXG vv.yy.
1. Incompatibilities introduced in MXG 28.04 (since MXG 27.27):
See CHANGES.
2. Installation and re-installation procedures are described in detail
in member INSTALL (separate sections for each platform, z/OS, WIN,
or *nix), with examples of common Errors/Warnings messages a new MXG
user might encounter, and in member JCLINSTT for SAS V9.2 or member
JCLINSTW for WPS. INSTALL also shows how to read SMF data on PCs/nix
using the FTP ACCESS METHOD.
XII. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
XIIV. 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 27.27 now in MXG 28.05:
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 28.yyy thru 28.001 are contained in member CHANGES.