COPYRIGHT (C) 1984-2008 MERRILL CONSULTANTS DALLAS TEXAS USA
Newsletter FIFTY-ONE
**************************NEWSLETTER FIFTY-ONE*************************
MXG NEWSLETTER NUMBER FIFTY-ONE, December 6, 2007.
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. 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) 1984,2007 MERRILL CONSULTANTS DALLAS TEXAS USA
I. The 2007 Annual Version MXG 24.24 was dated February 5, 2007.
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/ship_current_version.
1. The current version is MXG 25.11, dated DEC 7, 2007.
See CHANGES member of MXG Source, or http://www.mxg.com/changes.
II. MXG Technical Notes
III. MVS, a/k/a z/OS, Technical Notes.
7. APAR OA22991 documents why RMF III XCF DELAY REPORT may present
misleading information:
RMF III XCF Delay report may show jobs in a 100% XCF Delay when in
fact they do no XCF signalling. RMF III in its display uses the
home asid at the time an XCF signal was sent as passed from XCF in
field AMDHOME (initialized from SIOCB_HomeAsidF) as passed from XCF
module IXCA1MG. This is misleading because a function/routine may
be driven via a timer pop and do an IXCMSGO while executing under
any job in the system. XCF is known to do this for transport layer
signals. For signals issued while in Timer SLIH mode, XCF should
not indicate a AMDHOME asid of the current dispatched job, but
rather the signal sender. VERIFiCATION STEPS:
a. In a svcdump requested while RMF III is reporting XCF
DELAYS for a particular job, do a XESDATA SIGNAL DETAIL report.
b. Max down to the bottom of the report and examine the
measurement data for MSGPEND. There should be entries that
show MASID=0006 and MHOME=xxxx where xxxx is the asid of
the job that is invalidly being report in an XCF Delay.
6. APAR OA22958 documents, with no correction, why the RMF WLMGL WKLD
Activity report has lower SSCHRT than expected when Device Pend
Time is zero:
RMF Workload activity reports may report a lower than expected
DASD Start Subchannel Rate (SSCHRT) value as compared to the
actual dasd activity rates for the system. This will occur as
the calculated PEND and control unit queue times are zero. IOS
does not capture measurements when the wait time (PEND + CUQ)
is zero for an individual i/o interrupt.
VERIFICATION STEPS:
a. Lower than expected SSCH Rate on Workload activity report.
when comparing TOTAL dasd activity to TOTAL reported
workload. Anything greater than 10% can be explained
by this phenomenon.
b. Also review overall pend time for dasd. If zero, then this
is supporting evidence.
5. APAR OA22388 reports and corrects SMF64BUF and SMF64CB flags in the
SMF64RSC byte which were not turned on for biases other than DO with
SMB processing.
4. HIPER APAR OA21884 - JES HANGS DURING ALL-MEMBER WARMSTART
ERROR DESCRIPTION: z/OS 1.8 ONLY:
During an all member warm start, JES2 can $wait in HASPMISC near
ENFP9200. This happens when there is a new or different WLM Policy
defined that doesn't match the policy last in effect when JES2 was
shut down. The $WAIT will not be resolved because the checkpoint
processor is not dispatchable during warmstart -- meaning JES2 will
not start.
The problem reported by OA21884 occurs only if an all-member JES2
warmstart is performed **and** a new WLM service definition was put
into place while JES2 was not running.
The fixing PTF for z/OS 1.8 is UA35883.
3. CICS Transactions from LU 6.2 devices may all have the same UOWID
value. A possible explanation:
One possible source of these transactions was found with CA's
CommBridge software, related to CA's recommended implementation
using Microsoft SNA Server, which creates the problem, instead
of IBM's SNA Server solution, IBM Communication Server (CS),
which includes FTP server/client and other TCP/IP related
tools/services, including SNA over TCP/IP, references below.
One test server was changed to use the IBM solution, apparently
free with z/os, and the UOWIDs are all unique, so they can be
used to correlate to other related transactions/threads/tasks.
Thus when all transactions have the same UOWID, it's likely
that there's some software sitting on a Windows Server using a
transaction spawner which is supplying an FMH-5 header package
in the transaction (possibly the last boot time for the server
box), which is causing CICS not to generate a unique UOWID
string.
z/OS Communications Server:
http://www-306.ibm.com/software/network/commserver/zos/features/
visual of IBM CS enabled environment:
ftp://ftp.software.ibm.com/software/network/commserver/
brochures/commservspec.pdf
IBM Redbook...Modernizing the SNA Environment:
http://www.redbooks.ibm.com/redbooks/pdfs/sg247334.pdf
2. SYNCSORT can page fix many pages when many concurrent SORTs are
running with the 64-bit version of SYNCSORT. A new fix from them
will limit memory to 64M per sort (which covered 98% of the sorts
at the reporting site). The problem is that the 64-bit version
changed the meaning of VSCORET; originally the upper limit on
memory, now is the lower limit. The SYNCSORT enhancement, XXXXXXX
now provide the missing upper limit.
1. SMF 30 interval records are NOT written for GDPS HyperSwap Address
Spaces GEOHSWP, GEOXCFST, and XCFAS. The IBM claim is that the SMF
recording must be stopped otherwise the HyperSwap tasks can be left
hanging, which in turn may result in production systems being
shutdown because the HyperSwap cannot complete. At the present
time, this appears to ONLY be documented in an explanation
provided by a GDPS support specialist (PMR 31381,070,618).
We turn off SMF interval recording in three address spaces
(GEOHSWP, GEOXCFST and XCFAS), for the following reason. SMF
interval processing is done by scheduling an SRB to run in each
address space. This SRB gets the CMS and local lock of the address
space and then builds the SMF interval record. In the process of
building the interval record the SRB code references SMF control
blocks in the address space that are not page fixed. On systems
that have real storage contention these control blocks are going to
be paged out, because they don't get referenced very often. If we
are in the process of doing a HyperSwap where we have I/O suspended
to all of the PPRC volumes and the paging volumes are included in
these volumes, this SMF SRB effectively dead locks the address
space because it has the CMS and local lock and has taken a page
fault that can not complete until the HyperSwap completes. The
HyperSwap process is completely dependent on these three address
space functioning. In our testing before we created this capability
to turn off SMF interval processing in an address space, we
certainly saw hangs in the HyperSwap process because of this
problem in the GEOHSWP and GEOXCFST. I don't believe that we saw a
hang because of this problem in the XCFAS address space, but I just
wanted to make sure that it would not happen. Based on this you
will not get the interval records.
Thus, at the present time, the only way to track the resource
consumption of these address spaces, especially XCFAS, is to set up
a separate Service Class for each ASID, and use the RMF Type 72
records instead of type 30 records; while this provides some of
the information, it is only a subset of the type 30 data.
IV. DB2 Technical Notes.
2. DB2 usage of zIIP Engines. From APAR PK18454:
The DB2 accounting trace records provide information related to
application programs including processor resources consumed by the
application. Accumulated zIIP CPU time is not accumulated in the
existing class 1, class 2, and class 7 accounting fields. New
accounting fields are defined to let users know how much time is
spent on IBM zIIPs, as well as how much time zIIP eligible work
overflowed to standard processors. CPU time eligible for offload to
a zIIP processor is provided in the accounting records even if a
zIIP is not online or DB2 is not running on a z9 mainframe.
Changes to IFCIDs 0003, 0231, 0239, 0147 and 0148 as mapped by the
following macros:
DSNDQPAC - PACKAGE/DBRM ACCOUNTING DATA MAPPING MACRO
DSNDQWAC - ACCOUNTING DATA MAPPING MACRO
DSNDQWHU - IFC CPU HEADER MAPPING MACRO
DSNDQW01 - IFCID HEADER MAPPING MACRO
DSNDQW02 - IFCID HEADER MAPPING MACRO
DSNDQW03 - PARALLEL GROUP TASK TIME TRACE MAPPING MACRO
1. Blank Package Names with ACCUMAC GE 2:
A user reported blank package names to IBM when they upgraded to V8,
in DB2PM reports, and received this reply from DB2 Support:
This is working as designed, because you have rollup ON (which you
do if ACCUMACC GE 2), the only valid fields in accounting records
will be documented at the top of the external mapping macros.
For example, in your case you may want to refer to DSNDQPAC which
maps package information. Clearly text cannot be rolled up, so
textual fields are excluded from the list (attached below) of valid
data fields.
DDF and RRSAF threads:
A rollup record is written with accumulated counter data for an
end user when the number of occurrences of the end user on the
thread reaches the Zparm value for ACCUMACC. End user is defined
as the concatenation of the following three values:
- End user userid (QWHEUID, 16 bytes)
- End user transaction name (QWHCEUTX, 32 bytes)
- End user workstation name (QWHCEUWN, 18 bytes)
QPACSCT QPACTJST QPACARNE QPACAWTI QPACAWTL QPACAWTR QPACAWTW
QPACAWTE QPACALOG QPACARNL QPACARNR QPACARNW QPACARNS QPACALCT
QPACARND QPACAWDR QPACAWCL QPACARNC QPACAWAR QPACANAR QPACAWTP
QPACARNH QPACAWTG QPACAWTJ QPACARNG QPACARNJ QPACAWTK QPACAWTM
QPACAWTO QPACAWTQ QPACARNK QPACARNM QPACARNN QPACARNO QPACARNQ
QPACCLS7_ZIIP
By rolling up accounting data, there is some loss in detail.
Users will have to weigh the cost/benefit of rollup.
We are sorry that we can't make everything work as you may want,
but we will try.
The DSNZPARM ACCUMACC parameter, new with V8, defaults to ‘10’.
The user set a ACCUMACC to ‘NO’ and no longer saw the problem.
V. IMS Technical Notes.
VI. SAS Technical Notes.
1. Memory shortages might cause SAS jobs to end abnormally.
SAS Note SN-V9-018401 is repeated in its entirety:
If SAS jobs end abnormally on a sporadic basis, you should review
the SAS log for memory-related termination codes such as 878, 80A,
or 0F9. You might encounter these termination codes whenever you
run system routines.
The abnormal endings that are referenced above might occur when a
previous SORT procedure uses a very large amount of memory. In
particular, the IBM product DFSORT 1.13 and later has a block-mode
sorting feature that enables a SAS job to use very large amounts of
memory. When a SAS job attempts to use this memory, the abnormal
endings might occur.
SAS Technical Support recommends three steps that you should follow
if your SAS job ends abnormally due to memory-related problems:
1. Ensure that your SAS job does not use an unlimited value for the
REGION= option (for example, REGION=0M). SAS Technical Support
strongly recommends that you limit the memory that is available to
SAS jobs. Some SAS procedures will use as much memory as you make
available. Such a situation can adversely affect the performance of
your system. Most SAS@ 9.1.3 jobs can run efficiently within a 64MB
region, but you might need to increase the region size for some
jobs.
2. Set the MEMLEAVE= system option so that you reserve a portion of
the available region that SAS will not use. This precaution helps to
ensure that some memory will be available for running system
routines. The MEMLEAVE= option defaults to 512K. If your SAS job has
memory-related problems, a general guideline is to set the MEMLEAVE=
option to 10% of the size of your region. For example, if
REGION=128MB, then set MEMLEAVE=13MB.
3. If your SAS job uses DFSORT, you might observe in the SAS log
that a prior PROC SORT used a large amount of memory. If your SAS
job ends abnormally with a termination code such as 878, 80A, or
0F9, as a last resort you should turn off DFSORT's block-mode
sorting feature by specifying the NOSORTBLKMODE system option.
VI.A. WPS Technical Notes.
1. Current status of MXG testing under WPS Betas in November, 2007.
a. What has been tested successfully:
MXG QA compile-only (dummy INFILEs) TYPExxxx and TYPSxxxx members
This exercised the MXG DATA-step Code for compile errors,
and created DOCVER to compare the contents of WPS-built
datasets (variables, LENGTHs, LABELs, FORMATs).
Steps 1 thru 36 of the QAJOBXX were tested.
Default BUILDPDB with 480MB SMF File
Tailored BUILDPDB with IMACEXCL with 480 MB SMF File
TYPETPMX with small file - verified 72 position FORMATs worked.
TYPENTSM with test file - verified open-system-style MXG code.
b. WPS Betas are often updated daily, and as errors were encountered in
MXG tests on z/OS and Windows/XP, a new Beta was generated which did
correct each error that could be fixed short-term. The current Beta
tested is World Programming System 2.02 (02.02.00.08458) of Nov 27.
Subsequently, the GA Release 2.2 (02.02.00.08460) was also tested.
c. MXG Version 25.11 is required for testing under WPS; its updates
eliminate the need for user modifications to MXG Software, and new
WPS-specific members (CONFIGW2, MXGWPSV2, JCLINSTW, AUTOEXEW) were
added.
d. Facilities used by MXG Software not yet in WPS for z/OS:
INFILE CCHHR option - needed only for TYPEEREP (EREP, SYS1.LOGREQ)
VIEWS - for CPU & I/O performance, used in VMXGSUM
invoked over 60 time in QA BUILDPDB, and in
all ASUMxxxx and TRNDxxxx members.
eliminates a full pass of the input data.
PROC CONTENTS - minor, does not report High Block Used size.
e. Facilities used by MXG Software not yet in WPS for z/OS and Windows:
INFILE with ftp access method - performance slower, more disk space
SAS/GRAPH, SAS/STAT, SAS/ETS, etc.
Currently WPS supports the Base DATA Step Support and a few PROCs,
including PRINT, MEANS, CONTENTS GPLOT, GCHART, with more planned.
f. Output differences - minor
PROC MEANS printed output - some values printed with one digit more
resolution by WPS.
- no error in output values spot checked
- prevents automated output comparisons
g. Untested - most due to complexity or time to set up multiple inputs:
The WPS Workbench and its Workspace(s) and Projects.
The WPS interactive human interface, was not used.
It is VERY different than the SAS Windows or TSO interfaces.
I didn't have the time to learn another human interface.
But if you know Eclipse platform stuff, might be familiar.
DATA Libraries on TAPE
WEEKBLDT, MNTHBLD special TAPE format to DISK, DISP=MOD, etc.
TESTTRND, TESTANAL - requires extensive test data
ANALxxxx - requires test data
ASUMxxxx - except ASUMJOBS, ASUM70PR were tested.
UTILxxxx - specialized utilities for MXG Tech Support
Internal SORT - on z/OS, internal SAS SORT may be required
when BY list variables don't fit in first
4096 bytes.
NFS Files - not tested.
Broken VBS files - not tested.
h. Migration issues - see WPS Migration Instructions:
On z/OS, copy all archived SAS Data Libraries on DASD (including
HSM migrated) to tape (Sequential) format with the SAS System
first.
WPS can read SAS Data Libraries in SEQUENTIAL format on tape or
DASD.
WPS cannot read DASD format SAS Data Libraries
i. Customer reports:
Several MXG customers have been running their BUILDPDB on z/OS.
Early tests had to make source-level-changes to a few MXG members.
Most had relatively simple BUILDPDBs with minimal tailoring.
j. MXG Support Position for testing of WPS Release:
MXG 25.11 and WPS 2.2 or later are required.
Your current MXG Software License Agreement states:
Merrill agrees to provide continuous product support for MXG in
the following areas:
When error conditions
(i.e., the SAS® execution of MXG code produces either a
return code or an ABEND)
are the results of errors in MXG Code, they will be corrected.
If you encounter an error testing MXG under WPS:
You should report the error to WPS Technical Support for
initial investigation.
If WPS support believes the error is an MXG problem, they can
contact MXG, or may choose to refer you to MXG Support.
MXG Support may then request you to send data to MXG:
- the raw data file that caused the error
- your site's USERID.SOURCLIB (tailoring) source library
If the error can be replicated under the SAS System, it will
be corrected per our license terms.
2. Run time comparisons:
All tests were run as batch commands or batch jobs, with inputs and
outputs read from and written to disk files, using -autoexec to
point to autoexew.sas.
BUILDPDB,ASUMJOBS,ASUM70PR with 448 MB SMF File
z/OS Comparison
CPU TCB Elapsed ----------- Compressed ----------------
minutes minutes Work Size PDB Size CICSTRAN Size
SAS: 3.88 5.20 209 MB 55 MB 59 MB
WPS: 10.67 18.50 233 MB 59 MB 67 MB
Windows/XP Comparison
SAS: 1.20 2.18 Note 1 65 MB 63 MB
WPS: 1.93 2.71 Note 1 78 MB 70 MB
z/OS tests were executed on IBM 2094 CPU Model S08, SU_SEC=9708.
Windows tests executed on Intel Duo Core T5500 @ 1.66 GHz.
Note 1: Neither WPS nor SAS provide a way to track maximum work
space on ASCII
3. Revisions to SAS Clones article in MXG Technical Newsletter FIFTY:
WPS is no longer vapour-ware.
The company has bent over backwards to provide corrections.
Performance of WPS, when written in JAVA, was so poor (run times
were at least ten times worse than the current Beta) that the
product no longer uses JAVA, so it cannot exploit zAAP engines.
Items listed in sub-paragraphs i, ii., iii., and iv. have all been
addressed to my satisfaction, with the exception of the items that
are listed above in this note.
Pricing is significantly reduced from those original IBM prices.
As an example, an MXG site in the USA was quoted an IBM price for
a 21 Value Unit system (about 1000 MIPS) of $42,000 first year and
$8,400 for renewals. WPS can be licensed through IBM or through
World Programming; their home page is at http://www.teamwpc.co.uk
4. Summary:
Most of MXG has compiled successfully under WPS on both z/OS and
Windows/XP.
BUILDPDB has compiled and processed SMF data on both z/OS and
Windows/XP.
A lot of MXG still needs to be tested with data.
WPS is still in development.
WPS will roll this Beta into a GA release of WPS 2.2 this week.
WPS on z/OS requires thrice the CPU and Elapsed Run Time of SAS.
WPS on Windows/XP CPU and run times are similar to SAS run times.
Disk Space required on both platforms are similar.
So, it is your choice at this time to test MXG under WPS.
And, it's your evaluation of your MXG programs that should
determine if you believe that WPS is "Ready for Prime Time",
at your site, with your current CPU and run times and with the
MXG programs and SAS facilities that you utilize.
5. QA Steps successfully compiled and executed with dummy input.
STEP 3. CREATE FORMAT LIBRARY
STEP 4. RUN TESSNT
STEP 5. RUN TESSIBM
STEP 6. RUN TESSIBM1
STEP 7. RUN TESSIBM2
STEP 8. RUN TESSIBM3
STEP 9. RUN TESSUSER
STEP 10. RUN TESSUSR1
STEP 11. RUN TESSOTHR
STEP 12. RUN TYPSCMHM
STEP 13. RUN BUILDPD3+ASUMS
STEP 14. RUN BUILDPDB+ASUMS
STEP 15. RUN TYPERMFV
STEP 16. RUN TYPECMFV+TYPEMVCI
STEP 17. RUN TESSHSM
STEP 18. RUN TESSFACO
STEP 19. RUN TESSDOS
STEP 20. RUN TESSVM
STEP 21. RUN TESSCRAY
STEP 22. RUN TESSHPCS
STEP 23. RUN TESSUNIA
STEP 24. RUN TESSUNIK
STEP 25. RUN TESSQAPM
STEP 26. RUN TESSQACS
STEP 27. RUN TESSTUX
STEP 28. RUN TESSPW
STEP 29. RUN ASUMPRTR
STEP 30. RUN TYPEIMS7
STEP 31. RUN TESSIMSD
STEP 32. RUN COPYSTEP
STEP 33. RUN TESSTRND - partially completed, not WPS fault.
STEP 34. RUN TESSMNTH
STEP 35. RERUN TYPE-S FOR NON PROC SORT FOR DATASET LABEL
STEP 36. RUN CROSSREF
STEP 37. RUN DOCVER - output DOCVER file is identical.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. z/VM Technical Notes.
X. Incompatibilities and Installation of MXG vv.yy.
1. Incompatibilities introduced in MXG 25.yy (since MXG 24.24):
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 JCLINST9 for
SAS V9.1.3 or JCLINST8 for SAS V8.2.
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 24.24 now in MXG 25.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 25.yyy thru 25.001 are contained in member CHANGES.