COPYRIGHT (C) 1984-2021 MERRILL CONSULTANTS DALLAS TEXAS USA
MXG NEWSLETTER TWENTY-FIVE
****************NEWSLETTER TWENTY-FIVE**********************************
MXG NEWSLETTER NUMBER TWENTY-FIVE March 26, 1994
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS Page
0. IBMs MVS Version 5 Workload Manager & Parallel Sysplex Processors 2
I. MXG Software Production Version 11.11 enhancements 3
II. MXG Technical Notes 6
1. Executing MXG on PCs and Workstations under WINDOWS,OS2, & UNIX 6
2. MXG Version 11.11 requires SAS Version 6, but will run with 5.18. 13
3. Running the MONTHBLD program on a day other than the 1st day. 13
4. "PHYSICAL FILE DOES NOT EXIST, hlq.SOURCLIB.SAS" message. 13
III. MVS Technical Notes 13
1. Impact of VSAM CI Size on DASD Space and SMF Write Activity 13
2. An increase in CPU TCB time with MVS/ESA 4.2 and LPARs 18
3. APAR OY65101 adds a new JES2 option (NEWPAGE=1/ALL) 18
4. APAR OY61331 corrects wrong/impossible values in type 14 records 19
5. APAR OY65854 reports errors in RMF STARTIME (SMF7xIST). 19
6. APAR OY65280 corrects invalid data in TYPE24. 19
7. APAR OY66531 corrects erratic values in TYPE74 Disc and Pend 19
8. APAR OY67681 reports that TYPE62 variable DSNAME may be wrong 19
9. Boole and Babbage CMF type 70 records under Amdahl's MDF 19
10. MVS/ESA allocates secondary extents differently than MVS/XA 19
11. After installing PUT 9332, invalid type 70 records are created 19
12. Type 6, 24, and 26 SMF records READTIME later than REND time 19
13. PTF UY91040 corrupts the Cache RMF Reporter data 19
14. APAR OW01141 reports SMF/RMF records are not synchronized 19
15. IBM Washington System Center Flash 94-06, (Internal Use Only), 20
16. APAR PN52658 corrects the wait times in BatchPipes/MVS 20
17. APAR PN49692 corrects type 96 (TIRS) SMF record 20
18. APAR OW02571 reports invalid DCOLLECT values for 3390-9 20
19. SMF Interval records are not written for swapped out tasks. 20
20. IBM Cache RMF Reporter Version 1.5 required for MVS/ESA 4.3 20
IV. VM Technical Notes 20
1. Testing status of MXG under CMS 20
2. SAS Version 6 libraries cannot be shared between CMS & MVS 20
V. CICS Technical Notes 21
1. Truncated type 110 Statistics records written by CICS/ESA 21
VI. SAS Technical Notes 21
1. CRITICAL ZAP Z6088203 REQUIRED for MVS sites at TS405 or TS407. 21
2. Erratic series of SAS errors (NOTSORTED, HEADER LENGTH WRONG) 21
3. Must use PROC GREPLAY to move SAS Graphics catalogs. 21
4. SAS 6.08 ABEND 0C4 in Function VG2LD at OFFSET 00009A 22
5. Invalid VBS segment causes SAS to enter SVC Wait or CPU loop 22
6. SAS USER ABEND 315 has occurred in an SMS environment for tape 22
7. SAS ZAP Z6087095 required to use MVS PDSE instead of a PDS 22
8. 'FORMAT MGxxxxx UNKNOWN' due to insufficient MEMSIZE. 22
VII. IMS Technical Notes 22
1. MXG position on using IBM IMS log records 22
VIII. Incompatibilities and Installation of MXG 11.11 24
IX. Documentation of MXG Software. 25
X. Changes Log 27
Alphabetical list of important changes 27
Changes 11.347 thru 11.141 30-70
COPYRIGHT (C) 1994 BY MERRILL CONSULTANTS DALLAS TEXAS
0. IBMs MVS Version 5 Workload Manager and Parallel Sysplex Processors
IBM presentations at the recent SHARE meeting provided early insight
into the expected announcement of new mainframe hardware using CMOS
technology, and a new MVS/ESA 5.1 with its Workload Manager component
that will revolutionize the measurement and management of MVS.
For the first time in any computer system, the operating system will
operate in concert with its subsystems to not only measure the service
objectives, but also to react when those service goals are not being
met, and MVS will assign resources (for example, dispatching priority)
so that the service goal is met!
Previously, only resource consumption was measured, and delivery of
resources was managed by MVS without regard to response times or
workloads, but now, workloads are defined (eg., CICS transactions
starting with PAY*) and their service goals are measured (eg., 90%
completed in 1 second) so that your business plan controls the
delivery of computer resources.
This feedback loop from the application to the operating system in
terms of business purpose is truly unique, and there is even more
power to come in this new world, because the Workload Manager's
measurements and decisions apply not just to a single MVS image, but
across the sysplex, so that multiple CPUs in multiple boxes can
operate in concert!
And the new Parallel Sysplex mainframes are multiple CPUs in
multiple boxes! These new CMOS technology parallel processors
will be driven by the new MVS component. Previous MVS hardware used
BiPolar technology which was fast, but was also expensive, and it
generated lots of heat that had to be cooled, often with water. The
CMOS technology of PCs and workstations has been harnessed into small,
inexpensive, air cooled CPUs that, while individually a little slower,
can deliver the same total power as the BiPolar technology because
they operate in parallel, to dramatically reduce the cost of mainframe
computing, while providing all of the industrial strength, security,
management, economy of scale, backup, and control that will always be
missing in networks of independent workstations and PCs.
While some of what MVS used to do really does belong on workstations
or PCs, many workloads were moved off the mainframe only because of
the disparity between BiPolar and CMOS costs; the CMOS platforms and
the workload measurement and management aspects of the new MVS will
stem the tide of irrational downsizing, and decisions of what platform
will service what workload will be based on location of data and the
appropriateness of the technology instead of short term false economy!
A VP of DP at an oil company was required to supply workstations to
his petroleum engineers because of only hardware cost savings, but he
now laments that his engineers spend half of their time looking for
oil, and the other half of their time looking for disk space on their
workstations! Each engineer's productivity was diluted as each became
half-time engineers and half-time data center managers.
That is unlikely to occur again with CMOS mainframes and MVS 5.1!
I am tremendously impressed by IBM's forward thinking design of this
new world of mainframes in which company business goals direct the use
of computer technology, and not vice versa.
I. MXG Software Production Version 11.11, dated March 26, 1994, was
shipped with MXG Newsletter TWENTY-FIVE.
Critical notes about MXG Version 11.11:
- Products that require MXG 11.11 because of incompatible records:
DB2 Version 3.1.0.
Landmark's CICS/ESA Version 1.1.
LEGENT's TPX Release 3.5.
Software AG's COM-PLETE Release 4.5
Sterling's NDM, now Connect Direct 1.7.01.
- ANALDB2R users must use MXG 11.11 because of report corrections.
- You MUST use member CONFIG from this MXG SOURCLIB or you will get
many strange errors! (If you are still stuck at SAS 6.06, see Change
11.187 and use CONFIG06). Member CONFIG executes %VMXGINIT with
INITSTMT='%INCLUDE SOURCLIB(VMXGINIT); %VMXGINIT;' to initialize the
internal macro variables introduced in Change 11.150.
- If any of these members exist in your USERID.SOURCLIB(s) libraries:
ASUMDBDS ASUMDB2A ASUMDOS ASUMHPCS ASUM70PR
DAILYDSN GRAFDB2 GRAFLPAR TRNDDB2A
or if you use %VMXGSUM in your own report/summarization programs,
then you MUST read the incompatibility details in Section VIII and
in Change 11.309 and you will need to re-tailor your changes.
- MXG 11.11 requires SAS 6.08 at maintenance TS407 plus Zap Z6088203
to correct all known SAS errors. See Section VIII.
(Note: the online NEWSLETTER was revised - the original text also
listed Z6086442 as required, but later input from SAS
Institute Tech Support indicated that 6442 was already
included in Maintenance TS407).
MXG Version 11.11 was shipped along with Newsletter TWENTY-FIVE, and it
should be installed immediately as it provides these major enhancements:
These major enhancements were added in MXG 11.11 dated Mar 26, 1994
Support for STK's ICEBERG device user SMF record.
Support for Boole & Babbage CICS/Manager Type 110 Statistics records.
Support for Candle's Omegamon II for SMS user SMF record
Support for ISOGON's SoftAudit product's externalized files.
CICS/ESA Shutdown Statistics Report (DFHSTUP) now produced by MXG.
Sterling's NDM, now Connect Direct 1.7.01 incompatible changes.
Partial support for LEGENT's MIM Release 4.0.
Enhancements and corrections to ANALDB2R DB2PM-like reports.
Enhancements to VMXGSUM summarization routine.
Feedback that ASMIMSLG does not fail with IMS 4.1 log records.
These major enhancements were added in MXG 11.10 dated Feb 14, 1994
Support for IBM's OPC/ESA Release 2.1.
Support for LEGENT's NETSPY Release 4.4.
Support for CA's ACF2 Releases 6.0 and 6.1.
Support for Candle's Deltamon SMF record.
Performance improvements for VMXGSUM (used in most ANALxxxx members).
The ANALSMF "Simulator" analyzes SMF VSAM CI Size impact on your site.
These major enhancements were added in MXG 11.09A dated Jan 10, 1994
Support for Landmark CICS/ESA Version 1.1 (incompatible) records.
Summarization of Amdahl's APAF in ASUMAPAF.
Support for ZARA Release 1.1.
Corrections to ANALDB2R reports.
Performance enhancements in VMXGSUM execution.
These major enhancements were added in MXG 11.09 dated Dec 17, 1993
Support for DB2 Version 3.1.0 incompatible changes to DB2 SMF records.
Support for NPM Version 2.1.0.
Support for AS/400 Version 2.3 Performance Data.
Support for Memorex Telex LMS Version 2.17
Support for BatchPipes/MVS type 91 SMF record.
Support for Mobius' INFOPAC-RDS user SMF record.
Support for Integris UniKix records (both ASCII and Binary format).
Support for Novell Network Navigator User SMF record.
Support for Softwork's Performance Solution I/O Plus & Hiperload SMF.
Support for NETWISE RPC EXEC type 33 SMF record.
Performance enhancement of VMXGSUM algorithm
Utility to count type 110 records by application.
These major enhancements were added in MXG 11.08 dated Nov 1, 1993
Support for Amdahl APAF Version 2.1
Support for FOCUS MSO Release 6.8.
Support for IBM's ADSM subtype 14 type 42 SMF record.
CICS "Requested Reset Statistics" now processed into PDB.CICRRTRV.
These major enhancements were added in MXG 11.07 dated Oct 4, 1993
Support for DFSMSrmm (Removable Media Manager) two SMF records.
Support for DFSMSrmm Extract Files created by IBMs EDGHSKP utility.
Support for AS/400 Release 2.2, all records, labels, formats, etc.
Support for SAP's IMS log record type 'AE' for SAP IMS Accounting.
Support for AICorp Central Server SMF record.
Support for Type 42 Subtype 4 Concurrent Copy & Extended Sequential.
Support for Sterling's NDM, Network Data Mover SMF record.
Support for 4th Dimension's CONTROL-D Release 3.0.0 SMF record.
Support for NETVIEW APAR OY66237 change to TYPE37 SMF record.
Graphics enhancements for consistency, better pictures, in GRAFxxxx.
These major enhancements were added in MXG 11.06 dated Oct 1, 1993
Support for TCP/IP 2.2.1 APAR PN40511 (API Calls, FTP/TELNET Client)
Support for ASTEX Release 1.7 SMF record
Support for Software AG's COM-PLETE Release 4.54 SMF record
Support for Laser Access Corp's Optical Disk System's 3 SMF records
Support for LEGENT's SAR product User SMF record.
MXG 11.05 was a checkpoint version after Change 11.150.
MXG 11.04 was a checkpoint version before Change 11.150.
These major enhancements were added in MXG 11.04 dated Aug 20, 1993
Support for LEGENT's SAR product's User SMF record.
Support for Laser Access's Optical Disk System User SMF records.
Final (?) correction to ASUM70PR.
These major enhancements were added in MXG 11.03 dated Jul 26, 1993
Asynchronous Data Mover Facility APAR OY65142 for SMF type 30.
OMEGAMON/CICS VSAM,DLI,IDMS,ADABAS,SUPRA,DATACOM SPE QOC0553
These major enhancements were added in MXG 11.02 dated Jul 6, 1993
Support for VM/ESA Release 2.1.
Support for Top Secret Release 4.3.
Support for NPM APAR OY54370.
Support for RMF APAR OY64585.
Support for SAP Releases 4.3.J and 5.0.
Support for DOS/VSE POWER 5.1.
Support for OMEGAMON 2.60 Audit Record changes.
Support for APPC Deaccumulation APAR OY63634.
These major enhancements were added in MXG 11.01 dated May 20, 1993
Support for ZARA, The Tape Media Manager from Altai.
Support for SYNCSORT Release 3.5 SMF record.
Support for HMF, Host Monitoring Facility user SMF record.
Support for Corporate TIE user SMF record.
Support for STOPX37 Release 3.5 mis-documentation.
Enhanced ANALRMFR for RMF look-a-like reports from MXG.
Validation of Candle's ITRF (Omegamon/IMS Version 110).
Validation and correction of SMSDATA operand of DCOLLECT
Each of those enhancements are described in the Change Log, below.
Table of availability dates for the IBM products and MXG version:
Availability MXG Version
Product Name Date Required
RMF 4.1.2 (for MVS/ESA 3.1.3) Sep 7, 1990. 8.8
RMF 4.2 (for MVS/ESA 4.1) Oct 26, 1990. 8.8
MVS/ESA 4.1 Oct 26, 1990. 8.8
MVS/ESA 4.2 Mar 29, 1991. 9.9
RMF 4.2.1 (for MVS/ESA 4.2) Mar 29, 1991. 9.9
MVS/ESA 4.2.2 Aug 1991. 9.9
RMF 4.2.2 (for MVS/ESA 4.2.2 Aug 1991. 9.9
MVS/ESA 4.3 Mar 23 1993. 10.10
RMF 4.3.0 (for MVS/ESA 4.3) Mar 23 1993. 10.10
MVS/ESA 5.1.0 ??Summer 1994?? 12.??
CICS/ESA 3.2 Jun 28, 1991. 9.9
CICS/ESA 3.3 Mar 28, 1992. 10.01
DB2 2.2.0 1990 8.8
DB2 2.3.0 Oct 28, 1991. 10.01
DB2 3.1.0 Dec 17, 1993. 11.09
VM/ESA 1.1.1 Dec 27, 1991. 10.1
VM/ESA 2.0 Dec 23, 1992. 10.4
VM/ESA 2.1 Jun 27, 1993. 11.02
These products were not completed in time for MXG 11.11. Contact us
if you want to be shipped support when completed (2nd quarter):
TYPEZRB - RMF III VSAM file for MVS/ESA 4.2 and 4.3 is not correct.
Huron - Huron SMF record is not supported yet; no sample data SMF
data was provided, and the printed DSECTs were massive and
needed in machine readable form. Planned for 2nd quarter.
EPIC - LEGENT has not provided the format of their tape catalog;
instead, they want you to use the output of their extract
program, which means double processing and kludgy coding.
Nothing planned until LEGENT supplies needed formats.
II. MXG Technical Notes
1. Executing MXG on PCs and Workstations
a. Non-portability of SAS data libraries with $HEX variables.
SAS data libraries are currently not completely portable between EBCDIC
and ASCII platforms, because SAS Transport Procedures (UPLOAD, DOWNLOAD,
etc.) convert all character values from EBCDIC to ASCII. Thus character
variables that contain binary data (i.e., those with $HEX format) are
corrupted when moved between platforms. An MVS '40'X value is changed
to a '20'X under ASCII versions, causing bit tests to fail and wrong
values to be printed.
SAS Institute recognizes the unilateral conversion as a design problem,
and had considered changing the Transport Procedures so they would NOT
translate any variable with the special INFORMAT name of $NOTRAN. Code
was added to MXG to assign the $NOTRAN informat to all MXG character
variables that contain binary data, in anticipation of the SAS design,
and member FORMATS creates a $NOTRAN informat. However, SAS Institute
has now decided that the informat attribute is inappropriate for this
usage, and is investigating alternative solutions for SAS Version 7.
Note: Aug 2, 2004: See Change 22.192. All INFORMAT xxx $NOTRAN. ;
statements were removed from MXG source code.
Until SAS Institute resolves this design issue, you must be aware of any
character variables that contain binary ($HEX) data, and convert their
values back to the original value after downloading the SAS Data Sets
on the ASCII platforms, using the new MXG utility UTILCVRT.
b. Datasets SORTed BY character variables are unsorted after download.
Datasets that were sorted BY character variables under EBCDIC will not
be sorted under ASCII (and vice-versa), because the EBCDIC collating
sequence is different than ASCII. You will have to re-SORT the data.
c. SAS Source code changes made so that MXG executes under ASCII SAS:
- All numeric informats whose interpretation depends on the execution
platform were replaced with a macro variable whose value is now set
in VMXGINIT (which is now automatically invoked by the INITSTMT= in
the CONFIG member). The numeric informats macro variable names and
their values under EBCDIC and ASCII platforms are:
Macro variable EBCDIC value ASCII value
&PIB PIB S370FPIB
&IB IB S370FIB
&PD PD S370FPD
&PK PK PK
&RB RB S370FRB
&NUM null S370FF
- All character variables that contain printable data were changed to
be INPUT with $EBCDICn. informat instead of $CHARn.
- All character variables that contain hexadecimal data (i.e., have
format $HEX) were changed to be input with $CHAR informat, and all
were also explicitly assigned the informat named $NOTRAN.
- All date variables input as DDMMYY, MMDDYY, or YYMMDD and all time
variables input as TIME or HHMMSS were replaced with individual
inputs of DD MO and YY or HH MM and SS using the &NUM macro variable
and then dates are created with the MDY function. All dates are now
formatted DATE7 (to avoid confusion between USA and European date
formats).
- Character variables whose length had been set in a FORMAT statement
were instead declared in a LENGTH statement for consistency.
- Use of INPUT(string,format) were examined, and if the format item
expected EBCDIC representation, the input of the string was $CHAR,
but if the format item expected printable character/numeric date, the
string was input with $EBCDIC.
- Formats that test for hexadecimal data values were identified (in
member FORMATS) and variables using those formats were changed to be
INPUT $CHAR with INFORMAT $NOTRAN.
- Numeric variables minimum LENGTH is 3 under ASCII SASs. Previously,
length 2 could be used.
- Obscure input informats $PHEX and $CHARZB have no exact equivalent
for processing MVS data under ASCII platforms. Each case has to be
modified with unique coding.
- The algorithm used to identify EBCDIC numerics from alphabetics:
IF var LT '0' ==> alphabetic IF var GE ='0' ==> numeric
is invalid under ASCII. EBCDIC numbers are 'F0'x->'F9'x, which is
greater than EBCDIC alphabetics ('81'x->'E9'x), but ASCII numbers are
'30'x->'39'x, which is smaller than ASCII alphabetics ('41'x->'7A'x).
Only VMACVMXA's building of the INSTREAM format used this algorithm.
- Use of $VARYINGnnn must be examined individually. $VARYINGnnn acts
like $CHAR instead of $EBCDIC, so strings input with $VARYING that
are printable characters must be converted with:
INPUT variable $VARYINGnn. lenvar @;
variable=INPUT(variable,$EBCDIC.);
variable=TRANSLATE(variable,' ','80'x);
Note: the TRANSLATE was required because the INPUT function was
used. SAS Institute pointed out that the INPUTC(str,val,len)
function would have eliminated the need for TRANSLATE().
For character variables that do not contain printable characters, the
INPUT and TRANSLATE are not required, but the variable must be FORMAT
with $HEX, and INFORMAT with $NOTRAN.
- Statistics about Change 11.150: The 244 members starting with 'V'
were PROC SOURCEd into a single text file of 128,144 lines (10MB).
Three TSO sessions totalling 40 hours across three days issued 11,810
commands (typical: CHANGE X Y ALL NX across all 128,000 lines) used
1187 CPU 3090-400S seconds. A total of 30,167 lines were changed in
194 members. Testing found spelling/syntax errors in seven lines.
PDB.JOBS shows those TSO sessions resources totalled:
EXECTM =148,894 sec PAGEINS = 22,824 ==> 100MB
ACTIVETM= 4,161 sec SWPAGINS= 50,645 ==> 200MB
RESIDTM = 4,065 sec STOLPAGE= 645,672 ==> 2500MB
CPUTM = 1,187 sec SWAPS = 11,800
IOTMTOTL= 625 sec NRTRANS = 11,810 = 285/hour
(line speed 14.4-16.8qwpts)
This was a fairly intense TSO EDIT session for 40 session hours!
As a result of these changes, MXG 11.11 Software can now be executed
on ASCII platforms (i.e., on PCs with WINDOWS or OS/2, or on
workstations with UNIX) to read raw data records (i.e., SMF,
VM/Monitor, etc.) that were downloaded, and MXG will create the same
MXG datasets that you have been using all along on your EBCDIC
platforms (i.e., MVS or VM)!
d. Downloading the MXG Source Library from MVS to ASCII PC Platforms.
This example shows how you can use IND$FILE to convert the MVS PDS
into one ASCII file per member.
The MXG members must be unnumbered to execute correctly under the SAS
ASCII versions, and each ASCII file must be named "member.SAS".
First, create MXG.IEBUPDTE.NUMBERED, an 80-byte numbered sequential
file in IEBUPDTE format from your MXG.SOURCLIB PDS. (Since this is
an exact copy of the MXG IEBUPDTE distribution tape, so you could
alternatively just copy the tape into MXG.IEBUPDTE.NUMBERED.)
Sample JCL for these steps is in member JCLDOWNL.
//IEBUPDTE EXEC SAS608
//IN DD DSN=MXG.MXG.SOURCLIB,DISP=SHR
//OUT DD DSN=MXG.IEBUPDTE.NUMBERED,
// DISP=(NEW,CATLG),SPACE=(CYL,(69,5)),UNIT=DASD,
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=32720),VOL=SER=MXGNNN
PROC SOURCE INDD=IN OUTDD=OUT;
Second, create MXG.IEBUPDTE.UNUMBERD, a 72-byte unnumbered copy of
the IEBUPDTE-format sequential dataset, by truncation:
//TRUNCATE EXEC SAS608
//IN DD DSN=MXG.IEBUPDTE.NUMBERED,DISP=SHR
//OUT DD DSN=MXG.IEBUPDTE.UNUMBERD,
// DISP=(NEW,CATLG),SPACE=(CYL,(65,6)),UNIT=DASD,
// DCB=(RECFM=FB,LRECL=72,BLKSIZE=23400),VOL=SER=MXGNNN
DATA _NULL_; INFILE IN; FILE OUT;
INPUT @1 CARD $CHAR72.; PUT @1 CARD $CHAR72.;
(Or you could use SPF 3.3 (COPY) to copy with truncation.)
Since ASCII versions of SAS require unnumbered source code, we want
to truncate on the mainframe before we download, as that will reduce
the download time. Furthermore, unnumbered files require less space
on the PC than the same file if numbered, because ASCII source files
are stored as a variable-length, delimited string, with trailing
blanks removed. Note that the DIR command shows the size of the PC
Source directory as only 25MB, but actually 39MB of disk space is
needed for that directory, because of space waste at the end of each
of the 2500+ individual files in that directory!
Source Library PDS on MVS 54,146,400 51MB
Numbered IEBUPDTE on MVS 48,520,800 46MB
Unnumbered IEBUPDTE on MVS 43,598,400 43MB
Downloaded IEBUPDTE on PC 31,366,594 27MB
PC Source Directory - DIR size 26,935,736 25MB
Actual space required on PC 41,804,347 39MB
PK Zip of PC Source Directory 5,766,824 5MB
Note that the zipped MXG Source Library now fits on only four
"stiffie" disks - the Australian nickname for 3-1/2 floppies.
Third, on the PC, create directories:
MD \MXG\SOURCLIB MD \MXG\PDB
MD \MXG\USERID MD \MXG\CICSTRAN
MD \MXG\SMFDATA MD \MXG\SPIN
MD \MXG\FORMATS MD \MXG\DB2ACCT
Fourth, use IND$FILE to download mainframe's MXG.IEBUPDTE.UNUMBERD
into the PC's \MXG\SOURCLIB\IEBUPDTE.UNU, specifying ASCII and CRLF
options for the download. Depending on line speed, this can take
from seventeen minutes to seven hours. The mainframe file is about
44MB; coax moves at 1 MB/min, a 4 MBit LAN moves at 2.25 MB/min,
while 19.2KB dial-up can only move about 5-6MB/hour!
Fifth, download member IEBUPDTE of the MXG SOURCLIB PDS using
IND$FILE into \MXG\SOURCLIB\IEBUPDTE.BAS, using ASCII CRLF.
Sixth, use BASIC to execute IEBUPDTE.BAS to read IEBUPDTE.UNU, which
splits that sequential file and creates a separate PC file for each
member of the original PDS. For example:
CD \MXG\SOURCLIB
BASICA IEBUPDTE.BAS
and reply with filename IEBUPDTE.UNU
IEBUPDTE.BAS creates each file with the name of "member.SAS", so that
the %INCLUDE statements in MXG, of the form:
%INCLUDE SOURCLIB(XXXXXXXX);
are recognized by the ASCII SAS version.
The Basic program to split the sequential file into individual PC
files took about 48 minutes on a 486/33..
e. Downloading raw SMF, VM/Monitor, etc. data from MVS with IND$FILE,
or with ftp.
You can use IBM's IND$FILE under TSO to an SDLC link (Barr Systems
BARRSNA or Extra's ATTACHMATE), or to an ASYNC link (IBM's INPCS),
or you can use ftp (binary) to download V, VB, or VBS files.
First, the data file to be downloaded must have DCB attributes of
RECFM=U and BLKSIZE=32760. You can make a copy of the original SMF
data with the changed DCB using this JCL:
// EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSUT1 DD DSN=MXG.SMFDATA.ORIGINAL,DISP=SHR,
// DCB=(RECFM=U,BLKSIZE=32760)
//SYSUT2 DD DSN=MXG.SMFDATA.RECFMU,DISP=(NEW,CATLG),
// UNIT=DASD,VOL=SER=MXGNNN,SPACE=(CYL,(60,5)),
// DCB=(RECFM=U,BLKSIZE=32760)
and then download MXG.SMFDATA.RECFMU. If you cannot afford the DASD
space, and if no other job will try to access the original SMF file
for the duration of the download, you could simply change its DCB
attributes, using this JCL:
// EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSUT1 DD DSN=MXG.SMFDATA.ORIGINAL,DISP=SHR
//SYSUT2 DD DSN=MXG.SMFDATA.ORIGINAL,DISP=MOD,
// DCB=(RECFM=U,BLKSIZE=32760)
and then download the changed ORIGINAL file (and then reset the DCB).
We have to either make a copy or change the DCB attributes because we
cannot override the DCB attributes used by IND$FILE. If you instead
use SAS/CONNECT, or any other file transfer protocol that allows you
to preallocate or respecify the DCB attributes of the file to be
downloaded, the extra step can be avoided. The important aspect is
that the downloader must see its input as RECFM=U,BLKSIZE=32760.
Second, now that you have copied or reset your SMF raw data in a
dataset with DCB=(RECFM=U,BLKSIZE=32760), you can then use IND$FILE
to download the SMF data set into \MXG\SMFDATA\SMFDATA.U on your PC.
You must have the NOCRLF and NOASCII options in effect (i.e., do not
specify CRLF nor ASCII) so that NO carriage return/line feed
('13'x,'26'x) is inserted in the data, and so that NO conversion from
EBCDIC to ASCII is done. We want the PC file to be a serial stream of
unmodified blocks of mainframe data, including BDWs and RDWs.
You cannot point to a VBS file on the mainframe and bring it down to
the PC; you MUST have the downloading program see RECFM=U, so that
the raw SMF data is brought down as a complete block, including both
the BDW and the RDW. Nothing else will work!
If you are direct connected, you can expect a 200MB file to take from
40 minutes (5MB/min) to 100 minutes (2MB/min), depending on speed and
contention. Using dial-in at 19.2KB, it will take 33 hours (6MB/hr)
to download the 200 MB SMF file!
This download time for SMF data may be reducible with PKZIP/MVS. On
the PC, PKZIP reduced the 200MB SMF file to only 30MB, an actual
compression factor of nearly 8:1, taking only 65 elapsed minutes to
compress on the Model 95, so downloading and rebuilding a ZIPed file
at 19.2KB might take only 6 hours after compression. PKZIP/MVS uses
the same algorithms and should be suitable for reduction of download
time of large SMF files, as well as the MXG Source. Benchmarks are
planned. (PKZIP/MVS is available from Scott Avera at ASI, Dayton,
OH, 513-222-9012).
f. Moving the raw data and source libraries from PC to UNIX with ftp.
You can also use ftp if you have a TCP/IP connection. This example
shows the ftp commands to copy the MXG SMF and Source data from a
PC to UNIX; a similar sequence could be used to download directly
from MVS with TCP/IP.
- FTP to the machine that has the data and log on:
%ftp trinity
name(trinity,sasaws):mxgdemo
password:
- Change directories to where the data is:
cd SMFDATA
ls
- Make sure download is binary
bin
get SMFDATA
- Change directory to source library and mode to ASCII:
cd SOURCLIB
ascii
mget *.SAS
quit
g. Environmental options (CONFIG.SYS,AUTOEXEC.SAS,etc) required.
SAS For Windows 6.08 at TS405 or later maintenance is required.
Remove any Disk Caching Software, notably Microsoft's SMARTDRV:
No problems were encountered whatsoever with an 85MB SMF file and
its BUILDPDB, but when the 200MB file was executed, using a 1700MB
SCSI disk volume for input, work, swap, and PDB output, that 1700MB
disk was completely destroyed by SMARTDRV. ("INVALID MEDIA TYPE"
and total corruption of data). I believe the error is encountered
when the total file size being written exceeds 524MB, the limit for
an IDE partition; it appears that hardware limit is somehow
embedded in SMARTDRV in DOS 5.0.
Removal of SMARTDRV eliminated the overwrite of the SCSI disk, but
the run time was now increased by 50%! Disk caching is still under
investigation!
CONFIG.SYS requires this additional specification:
FILES=255
The FILES parameter is needed to prevent an "OUT OF FILE HANDLES"
condition.
AUTOEXEC.BAT requires this additional specification:
SHARE /L:200 /F:10264
The SHARE parameters are required if you use SHARE (required with
some LANs and by SPFPC) to prevent "OPERATING SYSTEM ERROR 36."
The /F parameter defines how many bytes are available to store
file names. Since the full path and file name is stored, if you
use more sub-directories and/or longer directory names, you may
still have to increase the /F: value.
AUTOEXEC.SAS changes required:
Member AUTOEXEC.SAS was downloaded into your \MXG\SOURCLIB
directory. It needs to be copied into your \SAS directory, as it
sets up both the required file names, and invokes the %VMXGINIT
member that defines the &PIB and other macros described earlier.
/* for all environments */
FILENAME SOURCLIB ('d:\MXG\USERID'
'd:\MXG\SOURCLIB');
LIBNAME LIBRARY 'd:\MXG\FORMATS';
FILENAME INSTREAM 'd:\MXG\USERID\INSTREAM.SAS';
/* for SMF and BUILDPDB processing */
FILENAME SMF 'd:\MXG\SMFDATA\SMFSMALL.U'
RECFM=S370VBS LRECL=32760 BLKSIZE=32760;
LIBNAME PDB 'd:\MXG\PDB';
LIBNAME CICSTRAN 'd:\MXG\CICSTRAN';
LIBNAME SPIN 'd:\MXG\SPIN';
LIBNAME DB2ACCT 'd:\MXG\DB2ACCT ';
/* for VM/ESA processing */
FILENAME MWINPUT 'd:\MXG\VMDATA\MONWRITE.U'
RECFM=S370VBS LRECL=32760 BLKSIZE=32760;
OPTIONS MAUTOSOURCE SASAUTOS=SOURCLIB;
%INCLUDE SOURCLIB(VMXGINIT); %VMXGINIT;
Note: UNIX will not tolerate blanks inside quotes for
\path\dir\filename, while WINDOWS will. AUTOEXEC.SAS
for UNIX requires the UNIX syntax for path and filename.
h. Performance benchmark results:
BUILDPDB has successfully executed under SAS for Windows, and SAS for
OS/2 on a 486, and under SAS for Unix on a Hewlett Packard 710 & 720.
FIRST TEST:
Input: 85MB MVS/ESA SMF file
MVS/ESA on 3090 400S: 9 min 42 sec
Windows on 486DX 33: 1 hour 9 min
Windows on 486DX 50: 52 minutes
Unix on HP 9000 710: 31 minutes
But this was not a representative daily SMF file.
SECOND (REAL WORLD) TEST:
The Case 1 500MB SMF file was used, but only these SMF records types:
IDs= 0,2,3,6,21,26,30,70,71,72,73,74,75,78,100,101,102,110
read by the BUILDPDB algorithm were selected, resulting in an SMF file
with 189,239 records, totalling 201MB of data, or 300 Cyl of 3380.
Reading the 201MB SMF file on the 486-33 with the TYPE0 program (which
decodes only the SMF header and created no output observations) took:
With SMARTDRV 10 min 36 seconds
Without SMARTDRV 15 min 45 seconds
The full BUILDPDB for the 201MB SMF file on a 3090/400S showed:
Space Requirements Timings for
four repeated runs:
DDname Blocks MB 3380 CPU Elapsed
cyl mm:ss mm:ss
SMF 9000 201 300 12:25 31:25
WORK 5178 114 172 12:18 31:00
PDB 6039 132 201 12:23 31:40
CICSTRAN 2574 57 88 12:24 31:02
total space 504 761
A 1700MB SCSI Drive was used for input SMF and output MXG datasets.
The Windows Run on a PS/2 Model 90 (486DX 33MHz)
took 6 hours 23 minutes (without SMARTDRV) elapsed run time,
and should take 4 hours 30 minutes (with SMARTDRV) elapsed run time.
The UNIX Run on an HP 9000 Model 720
took 48 minutes 13 seconds elapsed run time.
Conclusion:
Yes, you CAN execute MXG under SAS on ASCII platforms;
on PCs with much longer run times, on Workstations quite comparably.
But just because you CAN does not mean you SHOULD!
Does a corporate resource (the PDB) belong on a single-user platform?
Backup and Archiving of PDB directories will require manual management
of tapes, a process which is automated on MVS.
Large volume transfer will impact other LAN users during prime time.
Nevertheless, the economic motivation for downsizing may be strong,
if MXG is the only SAS user on MVS; the HP 720 costs $25,000, the
PS/2 is a $5,000 box, and SAS is much cheaper on ASCII than EBCDIC!
2. MXG Release 11.11 requires SAS Version 6, but it is still possible
to run MXG 11.11 under SAS 5.18, with these considerations:
a. You need member SASOPTV5 from MXG 11.11, and the first statement of
your program must be: be %INCLUDE SOURCLIB(SASOPTV5);
(This now invokes %VMXGINIT and defines the &PIB++ macros.)
b. You must change all occurrences of $EBCDIC to $CHAR in the entire
MXG sourclib. (Version 5 does not recognize $EBCDIC.)
c. You must change all occurrences of double-exclamation-points "!!",
('5A'x) with double-solid-vertical-bars " " ('4F'X).
d. If there are any other problems, let me know. None of my test sites
still have SAS 5.18, and truly, everyone should be on Version 6 now!
3. Running the MONTHBLD program on a day other than the 1st day of the
month requires these modifications in member MONTHBLD:
a. If the rerun day is within the same week as the first day of the
month, it is only necessary to change MONTHBLD and rerun:
In the DATA _NULL_ step, replace TODAY=TODAY(); with the specific
date of the first day of the month: TODAY='01APR94'D;
This will calculate _BEGIN and _END dates correctly and will avoid
the USER ABEND 1111 condition.
b. If the rerun day is in the week after the week of the first day of
the month, you will need to change both the TODAY= and the DAY=
statements in the DATA _NULL_ step to read:
TODAY='01DEC93'D;
DAY='MON';
as that will cause none of the Daily PDBs to be read; instead, the
five previous weekly datasets will be read and selected from to then
create the monthly dataset. You will need to point the five DD's in
your JCL for //WEEK1 - //WEEK5 to the five specific weekly PDBs that
span the month that you are recreating.
c. Note added August, 1996.
If you have to recreate a month PDB well after the fact: Assume you
are missing one weekly PDB from FEB. Yesterday you created the week
PDB, but its observations have ZDATE=13AUG96 (for example). You can
modify the SET statement in the heart of MONTHBLD, below) as shown
- remove the _D1._DSET thru _D2._DSET text from the SET statement
(so the Daily PDBs won't be read)
- change the test for _BEGIN and _END to the explicit dates to be
selected from the five WEEKly PDB's being read, remembering that
the ZDATE selection is from the 2nd of the Month to the 1st of
the next (because on the 2nd of this Month is when you process
the work of the 1st, etc.).
DATA TAPETEMP. _DSET ; /* CREATE IN TAPE FORMAT ON TEMP DISK */
SET
WEEK1._DSET WEEK2._DSET WEEK3._DSET
WEEK4._DSET WEEK5._DSET ;
BY _BYLIST ;
IF ('02FEB96'D LE ZDATE LE '01MAR96'D) OR ZDATE='13AUG96'D;
4. "PHYSICAL FILE DOES NOT EXIST, hlq.SOURCLIB.SAS" following "SAS NOTE
THE INITIALIZATION PHASE will occur if there is no //SOURCLIB DD
in the job.
III. MVS Technical Notes
1. Impact of VSAM CI Size on DASD Space and SMF Write Activity
I have recommended setting the CISIZE of SMF VSAM data sets to
half-track value (26K for 3390), because that should minimize the
number of physical blocks read or written, and reducing the number
of blocks always reduces both the CPU and the elapsed time to read
or write SMF data to/from the VSAM file. Or so I thought!
One site increased its CISIZE from 8K to 26K and found that they had
to double the size of their SMF VSAM data set from 500 to 1000 cyl,
but the size of the 450 cylinder SMF dump output data set did not
change! Lawrence Jermyn and Tim VanderHoek at Fidelity opened a
problem with IBM. Kathy McEwen at SMF Support replied in her ETR
3E902, which provided me with insight into the internal architecture
of the SMF writer; that ETR precipitated this analysis.
Because the SMF writer does not write true VBS records, lots of VSAM
space can be wasted; the amount wasted depends on both the CI Size
and the number of logical records that are greater than the CI Size.
This is not really new; SMF has always worked this way since the
1978 rewrite that introduced VSAM files, but the combination of the
now-possible larger CI size of 26624 on 3990s, combined with lots of
CICS/ESA type 110 records (which are typically close to 32760 bytes
long) can dramatically increase the wasted DASD space.
The SMF writer uses a "pseudo-VBS" algorithm to write records to the
VSAM data set. New variable-length records are put into the current
CI as long as the new record fits. If there is not enough room for
the new record in the current CI, the new record is normally NOT
spanned; instead, the new record is written into the start of the
next CI. Record spanning only occurs when the new record's LRECL is
greater than the CI size of the VSAM data set. In that case, the
new record starts in the next CI and fills as many CIs as are needed
to span the long record, but then any space remaining in the final
CI for the long record is never used. Consider this example with
records of 1000, 32760, 1000, and 32760 bytes using a 26624 CI size:
------track 1------ ------track 2------ ------track 3------
CI=1 CI=2 CI=3 CI=4 CI=5 CI=6
AA------- BBBBBBBBB BBB------ CC------- DDDDDDDDD DD-------
Data: 1000 26624 6136 1000 26624 6136
Waste: 25624 0 20488 25624 0 20488
Thus 67,520 data bytes were written, but the 6 CIs (159,744 bytes)
required THREE full 3390 tracks for the four SMF records.
If a CI size of 8192 is used, these 4 SMF records are written in 10
10 CIs (81,920 bytes) on less than TWO tracks, using less space:
--------------------------track 1--------------------------
CI=1 CI=2 CI=3 CI=4 CI=5 CI=6
AA------- BBBBBBBBB BBBBBBBBB BBBBBBBBB BBBBBBBB- CC-------
Data: 1000 8192 8192 8192 8184 1000
Waste: 7192 0 0 0 8 7192
--------------------------track 2--------------------------
CI=7 CI=8 CI=9 CI=10
DDDDDDDDD DDDDDDDDD DDDDDDDDD DDDDDDDD- --------- ---------
Data: 8192 8192 8192 8184 available available
Waste: 0 0 0 8
Why does SMF not span all records? It all goes back to the original
SMF BSAM architecture introduced in OS/360 in 1969. The SMF dump
program would fail with an ABEND 002 when it encountered broken VBS
records. If records were always spanned, a system crash would cause
the SMF dump program to ABEND 002, because the last block written to
DASD before the crash would have indicated spanning, but the next
block found would be the new IPL record that was written after the
crash! So as to minimize the probability of the 002 abend, the
original SMF writer only spanned when the LRECL was greater than the
BLOCKSIZE. Since records written by BSAM were still truly variable
records, whether spanned or not, there was no wasted space. This
pseudo-VBS algorithm was repeated in the 1978 VSAM- based redesign,
but that implementation fixed the CI size at 4096, so wastage was
small. Now, with many long SMF records and the now-possible larger
CI sizes, the pseudo-VBS algorithm of the SMF writer not only wastes
DASD space, it also causes the SMF Writer to issue many more VSAM
physical writes than would be if ALL records were spanned.
So what is the right CI size? It depends mostly on how many records
are greater than the CI size, and also on the order in which records
are written. It also depends on whether you want to minimize the
DASD space required, or whether you want to minimize the number of
write operations performed by the SMF writer (i.e., the overhead of
the SMF writer). Only by reading your SMF file to simulate the VSAM
write activity of the SMF Writer with different CI Sizes, can you
determine the CI size impact on your installation. MXG's ANALSMF
program now contains "The SMF Simulator" which reads your input SMF
file and analyzes the impact of various CI sizes at your site.
Two case studies show these results:
Case 1 - Moderate CICS Activity (125K Trans/day) Two 3090-200S
Daily SMF Volume = 500MB (624 Cyl when dumped)
CISize CI's 3390
Written Cyls
4096 142,329 792
8192 69,373 762
16384 34,220 761
22528 25,823 861
26624 22,277 744<==Min DASD and Min CIs written
Here, the 26K CI Size minimizes VSAM space, but the 26K savings is
only 6% less than 4K, so the CI Size impact on DASD is small.
However, the 26K CI Size reduces the number of SMF Write operations
to one-sixth the number at 4K; clearly the large CI Size here
benefits both DASD Space and SMF Writer operations.
Case 2 - Massive CICS Activity (10000K Trans/day) Four 9021 941s
Daily SMF Volume = 12,843MB (15,588 Cyl when dumped)
CISize CI's 3390
Written Cyls
4096 3,451,701 19,179<==Min DASD Space
8192 1,769,542 19,664
16384 893,113 19,848
22528 809,346 26,981
26624 777,664 25,924<==Min CIs written
Here, the 4K CI Size minimizes DASD space, using 6745 fewer cyls
(26% less) than the 26K CI size, but that 4K CI Size maximizes the
CI writes (over 4 times as many writes than the 26K CI size), so the
minimization of both DASD space and CIs written here is mutually
exclusive! The best compromise here is the 16K CI size, as 16K uses
only 3% more DASD space than the minimum DASD, and 16K writes only
15% more CIs than the minimum write activity.
The IBM ETR recommended a CI Size of 8K (based upon the average SMF
record length of 28000 reported by the SMF Dump program); while 8K
does require slightly less DASD space, the Simulator provides better
basis for optimizing both DASD Space and Writes than average size!
The SMF development team has been made aware of these results, and
is investigating the feasibility of spanning all records so as to
minimize both the size of the VSAM file and the number of writes.
a. Frequency of SMF Write Activity
The SMF VSAM datasets are NOT high activity in most sites. We can see
in these statistics from the two Case Studies
---Case 1--- -----------Case 2------------
--500MB SMF- ---------13,000MB SMF--------
SYS1 SYS2 CPUA CPUB CPUC CPUD
Seconds with writes 6210 11143 67807 79241 28589 56075
Avg Secs between writes 13 7 1.5 1.6 3.1 1.4
Max CIs in one second 10 13 318 184 276 157
Max SMF Buffers Used 42 55 525 135 342 127
SMF record count 376K 676K 1126K 1952K 1686K 1303K
Total SMF data volume 174MB 321MB 1933MB 2853MB 3773MB 4118MB
Note: As there are 86,400 Seconds in one day, SMF on SYS2 only wrote
during 1 out of every 8 seconds. Even on the massive systems, writes
occur seconds apart (and devices can handle tens of I/Os per second!)
The peak SMF writer activity always occurs during the second when the
RMF interval expires. For the 500MB case 1 site, the ten peak seconds
of the day show how little activity actually occurs; furthermore, no
task is waiting while SMF writes asynchronously from its buffers:
Endtime Databytes CIs Written Seconds since prior record
13:29:00 215414 13 3.2
04:29:00 205606 12 9.8
05:44:00 195969 10 20.7
15:44:00 194901 10 3.2
00:44:00 186474 10 6.9
21:59:00 185746 10 1.9
03:14:00 183893 10 25.4
13:44:00 183853 10 3.4
19:14:00 181112 10 22.4
00:59:00 174962 9 6.4
b. Contents of the input 500MB SMF File from Case 1.
Record ID Record Count Byte Count Percent of Bytes
2 12 168
3 10 140
6 513 57,456
9 7 216
11 5 120
14 151,202 45,987,728 8.8
15 83,888 24,160,720 4.6
17 13,270 1,273,960 .2
18 320 44,800
21 5,757 333,906 .1
23 46 4,876
24 23 5,175
26 7,593 2,870,154 .6
30 104,823 110,965,648 21.4
36 3 630
37 8,289 1,699,236 .3
41 185 31,080
47 31 2,666
48 31 2,201
50 154 10,692
52 6 348
53 1,120 90,720
57 3,897 389,700 .1
60 96,097 51,806,735 10.0
61 15,022 4,632,591 .9
62 38,264 5,697,122 1.1
64 71,894 28,235,144 5.4
65 12,421 3,831,009 .7
66 16,598 13,693,557 2.6
70 187 216,172
71 186 188,232
72 43,524 14,548,176 2.8
73 187 415,140 .1
74 558 12,539,748 2.4
75 1,399 290,992 .1
78 372 1,478,784 .3
80 39,391 9,804,727 1.9
90 13 928
100 370 463,240
101 19,308 18,204,480 3.5
102 307 626,368 .1
110 1,775 43,131,798 8.3
138 9,038 14,292,536 2.8
175 Local 26,188 916,580 .2
187 TPX 12,244 1,548,062 .3
200 16,947 1,425,854 .3
201 114 9,522
214 14,987 1,423,765 .3
217 TSO/MON 1,169 3,804,477 .7
218 TSO/MON 1,609 739,891 .1
230 Local 2 216
242 180 91,320
249 IMFprog 107,434 27,288,236 5.3
250 IMFtran 122,301 68,594,601 13.2
251 Local 901 38,220
255 846 1,805,591 .3
Contents of Output Daily PDB built from the 500MB SMF site:
Dataset -Number of- obs ---Size in---
Name Description obs vars len blocks MBytes
ASUMDB2A Summarized DB2ACCT 2,863 225 985 126 2.7
ASUM70PR Summarized TYPE70PR 186 218 836 8 .2
CICS Summarized CICSTRAN 3,564 21 89 38 .8
CICSTRAN CICS Transactions 123,444 110 475 2574 56.6
JOBSKED Summarized JOBS 133 18 70 1 .0
DB2ACCT DB2 Transactions 19,305 312 1484 1248 27.4
DB2STAT0 DB2 Intervals 183 320 1298 14 .3
DB2STAT1 DB2 Intervals 183 448 1799 18 .4
JOBS Job resources 7,857 214 1071 368 8.1
NJEPURGE NJE Job events 1,242 61 356 20 .4
PRINT Printer events 513 47 339 8 .2
RMFINTRV RMF Interval 186 398 1593 16 .4
STEPS Step terminations 34,082 187 921 1366 30.0
TAPES Tape volume dismounts 5,754 28 124 32 .7
TSOMCALL TSO/MON CALL executions 1,609 101 553 38 .8
TSOMCMND TSO/MON Commands 29,103 8 45 58 1.3
TSOMDRU TSO/MON DRU 5,644 13 56 14 .3
TSOMDSNS TSO/MON DSnames 1,609 26 171 13 .3
TSOMSYST TSO/MON User Intervals 8,771 168 722 280 6.2
TYPE0203 SMF Dump Starts/Stops 22 5 27 1 .0
TYPE70 RMF CPU interval 186 361 1341 14 .3
TYPE70PR RMF PR/SM interval 1,860 32 105 9 .2
TYPE71 RMF Paging/Swap interval 186 281 1136 12 .2
TYPE72 RMF Performance Groups 10,856 76 327 156 3.4
TYPE73 RMF Channel interval 17,856 42 180 141 3.1
TYPE74 RMF Device interval 96,886 95 375 1590 34.9
TYPE75 RMF Page Datasets 1,399 38 209 13 .3
TYPE78CF RMF I/O Configuration 15,499 30 115 79 1.7
TYPE78CU RMF Control Units 3,897 19 86 15 .3
TYPE78IO RMF I/O Processors 372 21 91 2 .0
TYPE78VS RMF Virtual Storage 186 443 2414 22 .0
Total Storage Required: 8613 blocks (@ 23040), or 183 MB.
2. An increase in recorded CPU TCB time and total CPU Busy time has
been found when sites have installed Microcode Level SEC 228150 plus
MVS/ESA 4.2, and are running in an LPAR Environment. Sites that had
measured CPU TCB time variability in the range of 0-7% before the
changes, found the variability range was now from 0-15%. When these
sites upgraded to MVS/ESA 4.3, the CPU variability returned to the
earlier, lower, values. This turns out to be yet another LUE, or
Low Utilization Effect, even though the PR/SM hardware was running
at 100% CPU busy!
What happens, according to IBM's Gary Hall, at the SHARE 1994 Winter
Meeting, is that while "SEC150" is best known for giving us EMIF, it
also revamped the microcode for the LPAR Dispatcher, aiming to
minimize the LUE, of PR/SM. However, that microcode level, plus
changes in the MVS dispatcher (to make it more event driven, so as
to reduce SIGPs, for example) conspired together, and ole MVS/ESA
4.2 hammered the LPAR environment, causing the recorded CPU time to
increase!
Consider a PR/SM machine with several production LPARs, and with
a nearly-idle 3090-600 LPAR for SYSPROGs: even though the rest
of the LPARs are driving the real engines to 100% busy, and even
though nary a SYSPROG is logged on to this LPAR (so this LPAR's
utilization is very low), ole 4.2 in this LPAR frequently wakes
up each of the 6 CPUs it thinks it's got, to see if there is any
work for 4.2 to do! That means each of the 6 Logical CPUs have
to be dispatched on a real CPU, so LPAR management now has to
steal a real engine from your online system, and that engine then
has to invalidate lines in its HSB, the High Speed Buffer (also
called the CPU cache), to make room for the SYSPROG LPAR's MVS
instructions, so that that MVS can execute instructions, to find
out that there is still nobody logged on and nothing to do! And
this happens every time MVS wants to enter the wait state, which
is very frequent in a machine that's waiting most of the time!
The big difference between MVS waking up in a native machine and
MVS waking up in an LPAR machine is that the HSB is not shared in
a native machine, so there is little cost and no contamination
for the wake up, but in LPAR machines, with their shared HSB, any
logical machine wake up can contaminate the current contents of
the HSB, causing additional overhead to reload the replaced line.
Since LPAR management has to execute each logical engine on a real
engine, the overhead increases with the total number of logical
engines that are defined, and the LPAR management time primarily
contributes to uncaptured CPU time. The TCB time effects primarily
result from the changing of lines in the HSB (or CPU cache), which
cost more CPU time when the production LPAR is re-dispatched, since
it now has to reload the HSB from real storage.
MVS/ESA 4.3 makes the problem go away because the MVS Dispatcher was
redesigned (and uses what is now called Alternate Wait Management);
MVS now looks at its own utilization, and when utilization is low,
MVS stops waking up the extra logical CPUs until new work arrives!
This problem was originally reported by a Gartner Group "FLASH", but
that alert did not mention that the problem only occurs in LPARs.
3. APAR OY65101 adds a new JES2 option (NEWPAGE=1/ALL) to choose if a
new page is counted only for "skip-to-channel-one" (NEWPAGE=1), or
if a new page is counted for "skip-to-any-channel" (NEWPAGE=ALL, the
default, and the old way). This APAR addresses a long standing need
to make variable PAGECNT more accurate; however, you should read the
discussion in Newsletter 23, "MVS/ESA Resource Accounting- PRINTERS"
on page 22, because PAGECNT is still a poor choice for accounting.
4. APAR OY61331 corrects wrong/impossible values in type 14 SMF records
for multi-volume datasets in fields (SMF14RIN,SMF14NEX,SMF14NER,
SMF14NTA,SMF14NTR,SMF14NTU,SMFTIOE4,SMFSRTES) which caused values
like 168 extents allocated, 1 track allocated, false PDSE flag, etc.
That APAR went PE, so see also OY63627.
5. APAR OY65854 reports (without a fix) errors in STARTIME (SMF7xIST)
in RMF after applying OY59552. The error is that STARTIME contains
the interval end time instead of the interval startime! Also, the
DURATM (SMF7xINT) may be very small ('0000010F'x = 10 millisec).
6. APAR OY65280 corrects invalid data in TYPE24 when a multi-destinated
SYSOUT data set followed by a normal SYSOUT data set are offloaded.
7. APAR OY66531 corrects erratic values in TYPE74 Disconnect and Pend
Times. While the APAR mentions only Monitor II (i.e., type 79 RMF
record), and only for Serial Channels, installing this APAR did in
fact correct bad values for both Parallel and Serial channels in the
type 74 RMF record (i.e., Monitor I).
8. APAR OY67681 reports (without PTF yet) that TYPE62 variable DSNAME
is incorrect when the component/cluster being opened is the catalog
itself. The first 12 bytes of the name are overlaid in that case.
9. Boole and Babbage CMF type 70 records under Amdahl's MDF contain
incorrect CPU utilization that is fixed by their correction BAM3760.
10. MVS/ESA allocates secondary extents differently than MVS/XA. A site
running BUILDPDB under SAS Version 5, with //WORK block-allocated
SPACE=(6144,(100,50)), found the job ran under XA but failed with
insufficient work space under ESA. It turns out that under XA the
secondary allocation of 50 blocks used the DCB blocksize, and not
the JCL block parameter. The DCB blocksize after open was 32760,
and the job got the space it needed in secondaries of 50*32760 per
secondary. However, ESA (correctly, I believe) always uses the JCL
block size for secondaries, and the job only got 50*6144 per
secondary, and thus failed for insufficient space!
11. After installing PUT 9332, invalid type 70 records are created with
no PR/SM section (and thus no observations in MXG TYPE70PR dataset),
and with invalid data for WAIT times in the TYPE70 data set, and
these invalid type 70 records caused IBM's RMF Report program to
ABEND 0C9. These errors are corrected by APAR OY67002 for MVS/ESA
4.2.0 thru MVS/ESA 4.3.0.
12. Type 6, 24, and 26 SMF records READTIME can be later than REND time
when using the sysplex timer with a non-zero leap second value until
APAR OY67004 is installed. IBM uses STCK instruction for READTIME,
and the TIME macro for reader end time, but only the TIME macro had
proper support for leap-seconds. APAR OY67004 now causes the STCK
instruction to now factor leap seconds into conversion to local.
This APAR also indicates that timestamps that used to be all nulls
are now going to be formatted as a zero-value packed field; this may
cause problems since SAS has always input all nulls as a missing
value (i.e., the event did not occur), but a zero-value packed field
would be input as 01Jan1960:00:00:00!
13. PTF UY91040 corrupts the Cache RMF Reporter data (size of cache is
wrong). APAR AW01787 corrects the error.
14. APAR OW01141 reports SMF/RMF records are not synchronized when they
should be, but no PTF is yet available. (4/12/1994: PTF does exist).
15. IBM Washington System Center Flash 94-06, (Internal Use Only),
"Release to Release Migration Software Performance Impact" provides
an excellent, open discussion of how the recorded CPU time was
changed by upgrading several products at one time. Get your IBM SE
to share it with you.
16. APAR PN52658 corrects the wait times in the BatchPipes/MVS Product's
type 91 SMF record. Without the APAR, those times are invalid.
17. APAR PN49692 corrects type 96 (TIRS) SMF record; subtype was 36 vice
2, and CPU times were five times too large.
18. APAR OW02571 reports (no PTF yet) invalid DCOLLECT values for 3390-9
devices; values in DCVFRESP/DCVALLOC are overreported.
19. Type 30 interval records are not written for swapped out tasks.
This is not new, but just a reminder of a typical TSO session:
INTBTIME INTETIME SMFTIME Subtype
8:23am 8:30am 8:30am 2
8:41am 9:00am 12:14pm 2
12:14pm 12:15pm 12:15pm 3
This TSO user logged on at 8:23, worked until before 8:30, and was
swapped out. At 8:41 he did something and was swapped in briefly,
but then slept until 12:14 and logged off at 12:15.
But no records were written between 9:00am and 12:14, because the
task was swapped out, and no task is swapped in just to write the
type 30 interval accounting records; only when the task has come
back into memory will the SMF interval record be written.
And note that the INTETIME End Time of the second record was 9:00,
the true end of that interval, but the record was not written until
12:14 when the user did something and the task was swapped back in
and could write that interval record.
20. IBM Cache RMF Reporter Version 1.5 is required with MVS/ESA 4.3; if
Release 1.4 is used, binary zeros are in configuration data fields.
21. APAR OW03158 implies a new 4-byte Date Opened Field (finally!) will
be added to type 14/15 records, but there is no PTF yet, and I can't
write the MXG code change to support it until there is!
Online only update Aug 24, 1994: APAR OW00484 actually added the new
field, which was supported by MXG Change 12.036, in MXG 12.01.
IV. VM Technical Notes
1. MXG 11.11 has been partially tested under CMS versions of SAS, but
the standard BUILDPDB may not compile in a 12MB machine. The
REXXTES6 example was also revised to supply the VMXGINIT invocation.
Currently, BUILDPDB with the recommendation of Change 11.067 to
remove CICS and DB2 processing does successfully execute under CMS
SAS. The installation instructions have not been rewritten for CMS.
2. SAS Version 6 data libraries created by MVS SAS cannot be read
directly by CMS SAS from a volume shared between MVS and CMS. CMS
SAS sites who want to build their PDB under MVS and then access the
PDB from CMS for reports/graphs must build the PDB in Version 5
format (by specifying LIBNAME PDB ENGINE=V5). Alternatively, build
the PDB under Version 6 in Xport format, (by specifying LIBNAME PDB
ENGINE=V6SEQ;), and then import the library into CMS, creating a
separate CMS file for each data set in the library, and obviously
requires twice the DASD space:
LIBNAME PDB V6SEQ 'C';
CMS FD PDB C DSN SYS1.MXG.PDB;
The only other alternative is to use SAS/SHARE on both MVS and CMS
to share the PDB. See SAS Usage Note V6-SYS-SASIO-2172 for details.
V. CICS Technical Notes
1. Truncated type 110 Statistics records written by CICS/ESA are now
corrected by APAR PN39841. They were detected by MXG and deleted.
VI. SAS Technical Notes
1. CRITICAL ZAP Z6088203 REQUIRED for MVS sites at TS405 or TS407.
Sites with SAS 6.08 at TS405 or TS407 Level (under MVS only) must
immediately install Critical Zap Z6088203. Without this ZAP, very
large Data steps (specifically, BUILDPDB's SMF-reading data step)
can generate specious MXG ERRORs, such as INVALID OMVS TRIPLET
messages, and/or INPUT STATEMENT EXCEEDED RECORD LENGTH conditions,
and/or fractional/wrong values for integers. In all reported
occurrences thus far, the job ABENDed, but that is not guaranteed.
SAS Maintenance installed in TS405/TS407 for MVS did not initialize
numeric variables correctly, and the text of 8203 reads:
"when the sum of the lengths of the constants in a DATA step are
between 32K and 40K and the number of non-retained numeric
variables exceeds 160, it is possible that the numeric variables
may contain garbage values when they should be missing."
Thus far, the error has occurred only when BUILDPDB has been
"tailored" to read additional SMF records. My untailored BUILDPDB
did not produce any error, but adding just one SMF record (albeit
complicated) increased the program size enough to cause the failure.
Nevertheless, I strongly recommend installation of this ZAP at all
MVS sites with TS405/TS407 - the cure is easy, the disease fatal!
*****THIS IS AN ABSOLUTELY CRITICAL ZAP - DO NOT OVERLOOK THIS NOTE****
The ZAP became available for download from SAS Institute on Feb 2,
and has corrected the problem at 6 sites, with no induced problems.
The logic error in the compiler has been fixed in source in time for
automatic inclusion in SAS Maintenance Level TS410, due out later
this year, so this ZAP will not be needed when TS410 is available.
2. The erratic series of SAS errors (NOTSORTED condition when the data
had just been sorted, HEADER LENGTH wrong, etc.), that ABENDed once,
and wouldn't fail again, has finally been nailed down by techs at
SAS Institute, because one user, ??? ???????????, at Iowa State
University, was finally able to create a repeatable failure! Zaps
Z6076442 or Z6086442 are now available for down loading from SAS
and they were on the "second" maintenance tape, TS407. The actual
error was the overlay of bit maps used by SAS to describe where data
elements were located in the WORK file.
3. When moving SAS Graphics catalogs, the only way to keep the graphs
in the same order is to use PROC GREPLAY. If instead you use PROC
DOWNLOAD or CPORT, your graphs will be reordered based on the NAME
of the graph, and we can only partially control the name of a graph.
While you can specify NAME= parameter on the graphics procedure, the
name you specify is given only to the first graph produced, If more
than one graph is produced, the name of subsequent graphs is your
NAME suffixed with a number. PROC DOWNLOAD and CPORT sort graphs in
collating sequence before moving, so if you have more than 10 graphs
of the same NAME=, the order becomes NAME NAME1 NAME10 NAME11 NAME2.
Using PROC GREPLAY to move graphics catalogs is thus recommended!
We need to be able to control the names of graphs. Left padding of
the numbers with zeros, and numbering all names would work, but
the ability to specify a GROUP at the same time as the NAME would
also help; these suggestions have been made to SAS Institute.
4. SAS 6.08 ABEND 0C4 in Function VG2LD at OFFSET 00009A has SAS ZAP
Z6087606 now available that corrects the ABEND.
5. SAS 6.08 and 6.07 can enter an SVC Wait state if an invalid VBS data
record is found as the last record at a concatenation boundary. SAS
Usage Note 6810 discusses, and suggests to circumvent by a) making
the file with the bad record the very last concatenation, or b)
processing the individual files separately, or c) specifying on each
DD statement DCB=BUFNO=1. The last circumvention is probably the
best, as it inhibits the SAS read-ahead which is the real culprit
here, but you do not want to normally specify only one buffer, as it
will slow down normal processing. This SAS error is a high-priority
item, and a ZAP was to be available soon from SAS Institute.
6. SAS USER ABEND 315 has occurred in an SMS environment in which Tape
Mount Management saw a request for UNIT=TAPE, but converted that
request to a DASD allocation (because the data set was expected to
be small, and would be copied with many other small data sets from
DASD to TAPE later by SMS). A problem is open at SAS Institute, but
it's not clear to me that this is a SAS problem, because in adding a
SPACE=(CYL,(XX,YY)) parameter to the UNIT=TAPE DD works, and thus it
appears that SMS is not properly allocating the data set! A better
alternative solution is to specify your Storage Class for tape
(i.e., the one that will bypass SMS Tape Mount Management). Still
another choice is for your SMS guru to exclude program name SAS*
from Tape Mount Management. This note will change if more is known.
7. Using an MVS PDSE library instead of an MVS PDS library for your MXG
SOURCLIB requires SAS ZAP Z6077095 for 6.07, Z6087095 for 6.08 thru
TS0405 maintenance; otherwise, you will get ERROR 180s.
8. One site received a 'FORMAT MGxxxxx UNKNOWN', even though the job
had the //LIBRARY format library properly built and connected. It
turns out the real problem was insufficient memory - increasing the
MEMSIZE in CONFIG made the error go away!
VII. IMS Technical Notes - Newsletter TWENTY-FIVE
MXG Position on using only IBM IMS Log Records, updated 28Oct2010
1. MXG has always stated that IMS sites must install an IMS monitor to
accurately capture resources and responses for IMS transactions; the
IMS log data written by IBM records only program resources and does
not record transaction data for IMS accounting or capacity planning.
2. MXG currently supports three IMS monitors: BMC's MVIMS, Mainview for
IMS, previously Boole's IMS Measurement Facility, "IMF", product
(supported in MXG member TYPECIMS, from its original name of
Control/IMS), and ASG-Landmark's The Monitor for IMS, (member
TYPETIMS), and IBM/Candle's IMS Transaction Reporting Facility,
"ITRF" product (member TYPEITRF). These IMS monitors "hook" IMS to
capture and record both resource and response measurements for each
transaction that are legitimate for accounting, performance tuning,
and capacity planning.
3. To IBM, the IMS log exists only for recovery of databases; it is not
designed for transaction accounting nor response measurement. What
little resource accounting there is (only CPU and DL/I count, no I/O
counts), exists only in the Program record, written when a program
is de-scheduled, and each Program record contains totals for all of
the transactions that were executed by that program schedule. (IMS
Wait-for-Input, WFI, programs can stay up all day and execute many
thousands of transactions in one program record!)
Some IMS log records are at the transaction level, but only for the
response time, and as there is no unique token in those records that
associates records with specific transactions, post-processing to
assemble transaction events from log records is not guaranteable.
This is the heart of the exposure in the post-processing-algorithms
of ASMIMSL6.
In contrast, in batch and TSO we have the READTIME-JOB token,
and in CICS and DB2 we have the NETSNAME-UOWID token with which
to identify all records caused by a specific transaction, but
no such token is provided in IBM's IMS log records.
4. In addition to full support for the three IMS monitors' records, MXG
has also provided algorithms that attempt, successfully so far, to
reconstruct IMS transactions using only the IBM-provided IMS log
records, with the ASMIMSL6 Assembly Language program and JCLIMSL6
multi-step job.
Only a handful of sites ever reported any discrepancies in ASMIMSL6,
and they tended to be the sophisticated IMS sites with very complex
transaction sequences, and they have questioned response measures,
and not the resource measures. (And without an independent measure
of response, it's hard to show that ASMIMSL6 is actually at fault!)
Total CPU time, DL/I calls, and the count of transactions have been
correct and usable. These sites simply discard the transactions
with unrealistic response measures (too large or negative), tracking
to see that the number of discarded transactions is small.
Furthermore, IMS SAP accounting and IMS059 Fast Path datasets come
from independent log records, and are thus independently usable.
Officially, I do NOT have a legal obligation to modify the existing
ASMIMSL6 program's post-processing algorithms until IBM provides an
auditable and unique per-transaction token in each IMS log record
that eliminates the need for that ASM program. And, even with a new
unique transaction token, until IBM also provides per-transaction
level counts of CPU time, DL/I calls, and physical I/O, even with
ASMIMSL6/JCLIMSL6, the IBM IMS log records will never be completely
accurate for billing or response investigations.
Fortunately, this has not been issue, since JCLIMSL6/ASMIMSL6 have
worked with every IMS Version, including IMS Version 11 in 2010.
HOWEVER: ADDED SEP 2014: ASMIMSL6/JCLIMSL6 was replaced by the new
IMS56FA IMS log transaction record. See TYPEIMST and Newsletter
FIFTY-NINE IMS Technical Notes.
VIII. Incompatibilities and Installation of MXG 11.11.
1. Incompatibilities
a. MXG's summarization member, %VMXGSUM was changed incompatibly, but
it should affect only the very small number of (sophisticated) users
who have tailored MXG summarization/trending members:
If any of these members exist in your USERID.SOURCLIB(s) libraries:
ASUMDBDS ASUMDB2A ASUMDOS ASUMHPCS ASUM70PR
DAILYDSN GRAFDB2 GRAFLPAR TRNDDB2A
or if you use %VMXGSUM in your own report/summarization programs,
then you MUST read the details in Change 11.309 and you will need to
re-tailor your changes.
The incompatibility is somewhat obscure; to reduce CPU time and to
minimize temporary DASD space used during summarization, %VMXGSUM
now determines which variables are needed, and keeps only the needed
variables from the input data set. The problem arises only if you
use the INCODE= parameter (it lets you insert SAS code into the
summarization logic, and is used in those nine members), and even
then, only if you reference variables in your INCODE= logic that are
not going to be kept in the output summarized dataset. In that rare
case, you must list those un-kept variables in the new KEEPIN= parm.
The above members in MXG 11.11 contain the needed KEEPIN= statement.
(If you overlook this note, you still should detect the problem in
your testing, because you will normally see UNINITIALIZED VARIABLE
messages on the SAS log to alert you to your error!)
b. Make sure you are using the CONFIG member from the MXG 11.11 library
in your JCL, either with the MXGSAS JCL Procedure, or on your EXEC:
// EXEC SAS,CONFIG='MXG.V1111.SOURCLIB(CONFIG)'
You will get many, strange syntax errors (ERROR 180 or 200) if you
do not use the MXG 11.11 CONFIG member.
If you are migrating to MXG Version 11.11 from MXG Version 9.9 or
earlier, AND you have tailored your MXG installation (with EX... or
IMAC.... members), you must read the MXG 10.10 compatibility section
in member CHANGESS; find the text "member=CHANGE10" and read on!
c. MXG Version 11.11 requires SAS Version 6.08 at maintenance TS407,
plus SAS Zaps Z6088203 and Z6086442 for MVS and CMS. For WINDOWS,
SAS 6.08 at TS407 is required. For all UNIX, except for AIX, SAS
6.09 is required. For AIX, the second maintenance to 6.09 will be
required. For OS/2, SAS 6.10 will be required. (Both AIX and OS/2
do not currently properly support VBS record processing; their fixes
are due out this summer.) MXG has been tested error-free with the
above SAS versions, and I strongly suggest you ensure that your SAS
System is at the above level of SAS maintenance. (While most of MXG
may execute successfully with lower maintenance, you may encounter
known errors if you are not at the above level.)
d. Observation counts may change in PDB.JOBS and PDB.NJEPURGE because
of Change 11.226. More observations may be seen in PDB.TYPE74 due
to Change 11.170.
2. Installation and re-installation procedures are described in detail:
in member INSTALL, and sample JCL is in member JCLINSTL. Summary:
a. Install member MXGSAS as JCL Procedure MXGSAS in your PROCLIB.
b. Allocate a 78-cyl PDS: MXG.V1111.MXG.SOURCLIB, and use IEBUPDTE
to read the MXG tape to create the 2000+ member Source Library.
c. Allocate a 1-cyl PDS: MXG.V1111.USERID.SOURCLIB for your site
"Installation Tailoring" Source Library. Installation specific
tailoring (like telling MXG your shift hours, which performance
groups are TSO, CICS, etc.) is done by copying and modifying MXG
source members into V1111.USERID.SOURCLIB.
d. Allocate a 1-cyl SAS Data Library: MXG.V1111.MXG.FORMATS and
execute SAS to create the library of Formats required by MXG.
e. If this is the initial install of MXG, tailor these members into
your MXG.V1111.USERID.SOURCLIB tailoring library:
IMACACCT (Account Length),
IMACSHFT (Shift Definitions),
IMACWORK (Performance Group to Workload mapping), and
IMACSPIN (for BUILDPDB).
Each IMAC member is self-documenting, and IMACAAAA is the index
of all of the IMACs. You should at least scan IMACAAAA to see
the acronyms MXG uses for the many products MXG supports.
e. If re-installing MXG, copy your existing USERID.SOURCLIB library
members into the MXG.V1111.USERID.SOURCLIB. Then compare your
IMACs with those that were changed (see the alphabetical list of
changed members in member CHANGES). If any members in your
MXG.V1111.USERID.SOURCLIB were changed, you must reinstall your
site's tailoring for that IMAC, starting with the IMAC member
from the MXG 11.11 Source Library.
f. EDIT and submit member JCLTEST6 to verify that your tailoring
did not create any errors.
g. EDIT and submit JCLPDB6 to create a Daily PDB for testing. Or
use the TYPE.... members to process specific data sources, use
the ANAL.... members for report examples, the GRAF.... members
for SAS/GRAPH reports.
You have now installed MXG 11.11 in its own set of libraries. When
parallel testing is complete and are ready to implement MXG 11.11
in production, rename your three current MXG Production Libraries
(MXG.MXG.SOURCLIB, MXG.USERID.SOURCLIB, and MXG.MXG.FORMATS) to
(MXG.BACK.MXG.SOURCLIB, MXG.BACK.USERID.SOURCLIB, MXG.BACK.MXG....)
and rename the MXG.V1111.x.y libraries to their Production names!
Again, detailed installation instructions are in member INSTALL
Always read comments in the CHANGES member for compatibility issues, as
well as for any last minute changes.
Whenever you install changes or test a new version of MXG (or even your
own reports), be extra careful to look on the SAS log for any real error
conditions. Search for all occurrences of "ERROR:" and "ERROR :" and
"UNINITIALIZED" and "NOT CATLGD", as they may indicate a serious error.
A PROC PRINT and a PROC MEANS of each new MXG-built SAS dataset can help
you to understand their contents, and should be used to examine any
unusually large, negative, or suspicious values. Print all variables in
the dataset, and read the variable's descriptions in its ADOC member.
IX. Documentation of MXG Software.
Member CHANGES identifies the Version and Release of MXG Software, and
describes all changes made in that Release. The text of each change
names the members that were added or altered by that change. Member
CHANGES is designed to be read online (with SPF BROWSE), so that you can
search for specific product name references (CICS, MVS/ESA, etc.), or
the MXG member name or product acronyms.
Member CHANGESS contains ALL changes in ALL versions of MXG.
Member NEWSLTRS contains the text of all newsletters. You can search
NEWSLTRS for product name or acronym to find the technical notes, APARs,
etc., from all MXG newsletters. Since the Change Log portion of each
newsletter is in member CHANGESS, they are not repeated in NEWSLTRS.
The MXG Technical Newsletter is typically published twice a year, with
one printed copy sent to each licensed site, and it describes changes
and enhancements to the software, provides APARs and PTFs affecting MXG
users, and provides technical papers of interest to MXG users.
Member DOCVER lists alphabetically ALL datasets and variables that are
built by this MXG Software Version.
Members DOCVERnn are the "delta-documentation" between MXG versions, and
list only those datasets and variables that were added/deleted/changed
by version "nn".
Members ACHAPxxx are the text chapters from the 1984 MXG Guide and the
1987 MXG Supplement, to which the text of newsletters and changes has
been added. At present, these chapters are very rough; in a few cases
the chapter has actually been completed and revised, but most of these
chapters delivered in MXG 11.11 are little more than a concatenation of
the original text, and there are no figures nor tables. This is clearly
work in progress, but at least the old books are now machine readable!
When all 42 chapters are completely revised and updated in the source
library, I will decide if any will also be made available in printed
form, but the primary source of all future documentation will be the MXG
source library itself, which can now be updated when changes occur!
Members ADOCxxxx are what were in Chapter FORTY, and should be the first
place you look for information about MXG variables and/or datasets. The
ADOCxxxx members alphabetically describe each dataset and all variables
that are created by product xxxx, the instructions on how to enable that
product, bibliography of the vendor documentation, sample PROC PRINT and
PROC MEANS of real datasets, references to MXG reports that use these
datasets, and the MXG member names that you use to process that product.
There is an IMACxxxx member for every product supported by MXG. Once
you know the xxxx suffix for a product, you then know the names of all
of the MXG members for that product:
IMACxxxx - Defines record IDs, and "_K,_L" macros for product xxxx.
ADOCxxxx - "Chapter FORTY" style dataset and variable documentation.
VMACxxxx - The "real" source code member, often extensively commented.
TYPExxxx - Standalone member to test or process product xxxx records.
ASUMxxxx - Summarization example (only for some products)
TRNDxxxx - Trending example (only for some products)
ANALxxxx - Reporting/analysis example (only for some products)
GRAFxxxx - SAS/GRAPH report example (only for some products)
EXyyyzzz - OUTPUT exit for each dataset. There can be more than one
dataset per product. The EX member name suffix yyyzzz is
the same as the suffix of "_L" and "_K" macros defined in
IMACxxxx for the product. See further discussion under
"Using the MXG Exit Facilities" in ACHAP33.
Member IMACAAAA is an index of all IMACs, and is the best place to begin
to find what xxxx suffix Merrill chose for which product! You can often
find additional documentation by searching members NEWSLTRS or CHANGESS
for the xxxx suffix.
Finally, remember that MXG is source code, so you can often find your
answer by BROWSING the source members, especially the VMACxxxx, ANALxxxx
members. The MXG Variable name is often the DSECT's field name, and if
not, the vendor's field name is often in adjacent comments in the INPUT,
so you can cross reference to the vendor's documentation of their data!
X. 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 of the MXG SOURCLIB will always be more accurate than
the printed changes in a Newsletter, because the software tapes are
created after the newsletter is sent to the printer!
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
The actual code implementation of some changes in MXG SOURCLIB may be
different that described in the change text (which might have printed
only the critical part of the correction that can be made by paper).
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 since MXG 10.10:
Member Change Description
All 11.150 Rewrite to support execution under ASCII SAS versions
ANALCISH 11.329 CICS/ESA DFHSTUP Shutdown Statistics Reports added.
ANALDASD 11.288 Sample prime-time cross-system DASD report.
ANALDB2R 11.007 Fails with PDB=SMF if account reports suppressed.
ANALDB2R 11.036 Suspension counts twice actual value.
ANALDB2R 11.037 Total Read IOs miscalculated on Statistics Summary
ANALDB2R 11.042 DB2 PMACC02 count of OPENS actually counted FETCHES.
ANALDB2R 11.043 DB2 PMSTA02 count of SUSPENDS usually zero.
ANALDB2R 11.143 OVERFLOW HAS OCCURRED, OUT OF MEMORY errors.
ANALDB2R 11.286 Continued enhancement and error corrections.
ANALDB2R 11.330 DB2 Audit Detail Report Completion Code still wrong.
ANALDSET 11.048 ERROR 455-185 for dataset TYPE30OM.
ANALDSET 11.291 TYPE64 records now sorted consistent with non-VSAM.
ANALRACF 11.260 UNINITIALIZED variable due to SAS Usage note 6886.
ANALRMFR 11.024 Report fails with PDB=SMF, works with PDB=PDB.
ANALRMFR 11.069 Continued enhancement of RMF look-a-like reports.
ANALRMFR 11.231 Additional RMF report enhancements and corrections.
ANALRMFR 11.256 Correction of CPU percentages and type 74 reports.
ANALSMF 11.300 The "Simulator" analyzes SMF VSAM CI Size impact.
ASMIMSLG 11.157 IMS log processing type 36 changed.
ASMTMNT 11.154 0C4 abend in MXGTMNT at one site.
ASMVTOC 11.257 No output records under MVS/ESA 4.2 and earlier.
ASUM70PR 11.022 PDB.RMFINTRV may be corrupted by ASUM70PR.
ASUM70PR 11.027 LP0MGTTM not in RETAIN list (affects only MDF)
ASUM70PR 11.041 ASUM70PR new variables, and mini-tutorial.
ASUM70PR 11.087 LP0MGTTM (Amdahl MDF only) incorrect.
ASUM70PR 11.145 ASUM70PR still wrong in MXG 11.03.
ASUMAPAF 11.290 Summarization of MDF APAF records similar to PR/SM.
ASUMDB2A 11.038 QTXAIRLM omitted from SUM= list
BUILD006 11.320 PDB logic enhanced for APPC tasks (no purge record).
BUILDPDB 18.094 Building your PDB on tape.
BUILDPDB 11.089 Purge records lost if PRPRTY=4-7 or 12-15.
BUILDPDB 11.226 JES2 NJE Purge records for JT were mis-recognized.
BUILDPDB 11.228 Open Edition/MVS (OMVS) TYPE30OM added to PDB.
BUILDPDB 11.269 PDB.JOBS ACCOUNTn/RESTARTS wrong for MULTIDD jobs.
BUILDPDB 11.320 PDB logic enhanced for APPC tasks (no purge record).
CHANGESS 11.074 New member CHANGESS contains ALL changes ALL Versions
CICINTRV 11.224 CICS "Requested Reset Statistics" now processed.
CLTIMER 11.035 STOP statement required by SAS Version 6.
CONFIG 11.306 For MVS, MEMSIZE=32MB now default value.
CONFIG07 11.129 SAS Error 76-322 with numbered + unnumbered lines.
DAILYDSN 11.076 Typos misspelled output datasets.
DIFFDB2 11.282 New dataset PDB.DB2STATS now created for reports.
DIFFHSM 11.019 Member did not use the "_L" macro names.
Doc 11.013 Change 10.175 typo, two _KTY0 should be _LTY0
FMXGUCBL 11.088 Archaic UCBL function corrected.
GRAFLPAR 11.079 Error "OUT OF MEMORY" due to SAS Error 6719.
GRAFTRND 11.216 Not all workload data was plotted if workload unused.
GRAFWORK 11.311 Workload graphs enhanced with memory frames in use.
GRAFxxxx 11.173 Enhancements, common structure for GRAFxxxx members.
IMACACCT 11.104 "VARIABLE SACCT1 NOT FOUND" can occur.
IMACCICS 11.224 "CICRRTRV NOT FOUND" errors using old IMACCICS
IMACICBB 11.347 Support for Boole & Babbage CICS Manager Statistics.
IMACICDL 11.268 Omegamon CICS/ESA type 110 may have wrong DL/I counts
IMACICSA 11.110 Support for SAP Releases 4.3.J and 5.0.
IMACICSA 11.148 SAP Release 4.3 requires one change to MXG.
IMACICSA 11.211 CICS SAP variables STCDB1-STCDB5 should be CHAR.
IMACPDB 11.155 ACCOUNTn variables no longer limited in IMACPDB.
IMACPDB 11.214 JES3 variable CLASS added to JES3 PDB.JOBS.
IMACPDB 11.258 Variables ACTDLYTM,DSPDLYTM,RESDLYTM now in PDB.JOBS
JCLIMSLG 11.109 MXG 10.10 had wrong JCL in this example JCL member.
JCLTEST 11.012 SAS 5.18 WORK.#DIRMACR is out of space condition.
JCLTEST6 11.093 0C4 ABEND in SASXKERN if IBM exit IFGOEXOB used.
MONTHBLD 11.040 Error "DATASET TAPEMNTS NOT SORTED".
MONTHBLD 11.206 DATA SET TAPEMNTS IS NOT SORTED error.
Many 11.302 Additional ASCII/EBCDIC differences resolved.
RMFINTRV 11.008 TYPE74 tape counts in AVGRSPMS, DEVACTTM, etc.
RMFINTRV 11.264 Variable PGPERBLK in RMFINTRV is incorrect.
SPIN 11.184 SPIN library can fill if Change 11.060 not installed.
TRND70 11.240 Trended variables READY12-READY15 have wrong value.
TRND71 11.222 Variable VIO value incorrect in TRND71.
TRNDDB2A 11.038 QTXAIRLM omitted from SUM= list
TRNDVMXA 11.235 VM/ESA Trending had logic errors.
TRNDxxxx 11.227 Trending now includes the MVS/ESA 4.3 variables.
TYPE102 11.085 Variables QW0145SC/QW0145LL not input.
TYPE102 11.107 IFCID 53 and 58 records may have been dropped.
TYPE110 11.023 Omegamon V550 APAR QOC0451/QOC0534 bad record error.
TYPE110 11.080 STARTIME in CICINTRV dataset is actually ENDTIME.
TYPE110 11.138 Skip over SAP Journal Records circumvention.
TYPE1415 11.266 Variable TEMP in dataset TYPE1415 may be misset.
TYPE28 11.116 Support for NPM APAR OY54370.
TYPE28 11.246 Support for NPM Version 2.1.0
TYPE30 11.002 INVALID OMVS TRIPLET message, no observations.
TYPE30 11.003 Type 30 Interval INTBTIME/INTETIME wrong in MVS 4.3.
TYPE30 11.004 Variable DSSIZHWM is incorrect.
TYPE30 11.033 Small negative values for ACTDLYTM.
TYPE30 11.060 JELAPSTM and others large (positive or negative).
TYPE30 11.126 Type 30 APPC fields accumulation corrected OY63634.
TYPE30 11.140 Asynchronous Data Mover read/writes in APAR OY65142.
TYPE30 11.199 Variables INTBTIME/INTETIME off by 100 seconds.
TYPE30 11.229 GMT Offset was still wrong sometimes, by 100 seconds.
TYPE33 11.243 Support for NETWISE RPC EXEC type 33 SMF record.
TYPE37 11.001 INPUT STATEMENT EXCEEDED RECORD LENGTH
TYPE37 11.031 Undocumented LAN variables BRFSMADR BRFSMNAM added.
TYPE37 11.119 INPUT STATEMENT EXCEEDED RECORD LENGTH.
TYPE37 11.202 Support for NETVIEW APAR OY66237 (Hardware Log).
TYPE39 11.280 TYPE39_8 variables all incorrect.
TYPE42 11.021 New TYPE42DS has GMT values in INTERVAL record.
TYPE42 11.179 Support for Concurrent Copy & Extended Sequential DS.
TYPE42 11.235 Support for IBM's ADSM subtype 14 type 42 SMF record.
TYPE42 11.325 TYPE42 subtype 6 STOPOVERs if VSAM SMF data is read.
TYPE57 11.215 Type 57 ESS variables non-blank if no ESS installed.
TYPE60 11.203 Storage and Data Class missing in NVR TYPE60 records.
TYPE6156 11.223 INVALID DATA for OWNEXPDT corrected.
TYPE7072 11.016 TYPE72MN dataset contains only one PERFGRP.
TYPE7072 11.152 TYPE70 dataset now supports CPUIDs of 0 thru 15.
TYPE7072 11.229 GMT Offset was still wrong sometimes, by 100 seconds.
TYPE7072 11.265 Boole CMF Type 72 Subtype 2 INPUT STATEMENT EXCEEDED.
TYPE7072 11.275 IBM APAR OY67002 corrupts TYPE70,TYPE70PR,ASUM70PR
TYPE72 11.177 SERVICE can be zeroed if it overflows ==> zero obs!
TYPE72MN 11.171 Zero obs in TYPE72MN for MVS/ESA 4.2 or earlier.
TYPE73 11.015 TYPE73 contains observations for dummy CHPIDs
TYPE73 11.102 Zero observations in TYPE73.
TYPE73 11.114 PNCHANBY (EMIF Partition Channel Busy) added.
TYPE73 11.195 Variable PNCHANBY propagated into inactive records.
TYPE74 11.170 TYPE74 not output if only allocated but not used.
TYPE80 11.117 Support for Top Secret Release 4.3.
TYPE80 11.207 Support for TOP-SECRET records written to log.
TYPE80A 11.017 INPUT STATEMENT EXCEEDED error.
TYPE80A 11.054 TYPE80A fails with INPUT STATEMENT EXCEEDED.
TYPE90 11.158 TYPE90 variable ACTIVE renamed to ACTIVEMN.
TYPEACF2 11.315 Support for CA's ACF2 Releases 6.0 and 6.1.
TYPEAICS 11.180 Support for AICorp Central Server SMF record.
TYPEAPAF 11.225 Support for Amdahl APAF Version 2.1
TYPEAPAF 11.267 APAF V2.1 dataset APAFCHAN was trashed.
TYPECIMS 11.073 INVALID VALUE FOR TH corrected.
TYPECOMP 11.156 COM-PLETE Release 4.5 SMF record supported.
TYPECOMP 11.209 Variable ULOGCPUT incorrectly input.
TYPECTLD 11.174 Support for 4th Dimension's CONTROL-D Release 3.0.0.
TYPEDB2 11.005 INVALID 3rd ARGUMENT IN SUBSTR, variable JOB blank.
TYPEDB2 11.006 Variable QDSTQDBT is incorrect.
TYPEDB2 11.050 DB2ACCT variable NETSNAME incorrectly padded.
TYPEDB2 11.255 Support for DB2 Version 3.1 incompatible changes.
TYPEDCOL 11.057 DCOLLECT SMSDATA (SMS constructs) cause STOPOVER.
TYPEDCOL 11.151 Variables DCUSYSID/DCUTMSTP not kept in constructs.
TYPEDLMN 11.308 Support for Candle's Deltamon SMF record.
TYPEDMON 11.162 Support for LEGENT's ASTEX Release 1.7.
TYPEDOS 11.106 Support for DOS/VSE POWER 5.1.
TYPEDOS 11.149 Variables STARTIME/STOPTIME may be wrong.
TYPEEDGR 11.190 Support for DFSMSrmm Extract Files (EDGHSKP utility).
TYPEEDGS 11.189 Support for DFSMSrmm SMF Audit and Security records.
TYPEEDGS 11.209 Several MVT... variables incorrectly input.
TYPEF127 11.210 FACOM pseudo-RACF type 127 FUNCTION CHAN IS UNKNOWN.
TYPEFOCU 11.219 Support for FOCUS MSO Release 6.8.
TYPEHMF 11.049 Support for HMF, Host Monitoring Facility product.
TYPEHSM 11.078 New HSM dataset HSMFSRBO, IMACHSM changed.
TYPEICE 11.340 Support for STK's ICEBERG SMF record.
TYPEIMS 11.181 Support for SAP's IMS log record type 'AE'.
TYPEIPAC 11.252 Support for Mobius' INFOPAC-RDS user SMF record.
TYPEMEMO 11.032 New variables TRANTIME TRANCOST added.
TYPEMIM 11.317 Partial support for LEGENT's MIM Release 4.0.
TYPEMON8 11.230 INVALID ARGUMENT TO FUNCTION MDY TIESDATE INVALID.
TYPEMON8 11.270 Support for Landmark CICS/ESA Version 1.1 INVALID DO.
TYPEMON8 11.278 ERROR3.LANDMARK.MONITOR due to invalid record.
TYPEMON8 11.327 INVALID DATA FOR TIAPREQ with MXG 11.0x-11.10.
TYPENDM 11.175 Support for Sterling NDM Network Data Mover 1.4.0.
TYPENDM 11.326 Sterling's NDM, now Connect Direct 1.7.01, incompat!
TYPENSPY 11.009 INVALID ARGUMENT TO FUNCTION DATEJUL error.
TYPENSPY 11.029 Variable SNITIME incorrect.
TYPENSPY 11.130 LEGENT LANSPY #DGL249 circumvention.
TYPENSPY 11.159 NETSPY fix changed again by LEGENT.
TYPENSPY 11.316 Support for LEGENT's NETSPY Release 4.4.
TYPEODS 11.147 Support for Laser Access Corp's Optical Disk System
TYPEOMAU 11.092 Omegamon 2.60 Audit Record moved OMSUBSID.
TYPEOMCI 11.115 OMEGAMON V550 SMF record INPUT STATEMENT EXCEEDED.
TYPEOMCI 11.136 OMEGAMON/CICS VSAM,DLI,ADABAS,IDMS,SUPRA,DATACOM.
TYPEOMCI 11.313 OMEGAMON user SMF record INPUT STATEMENT EXCEEDED.
TYPEOMSM 11.332 Support for Candle's Omegamon II for SMS user record.
TYPEOPC 11.122 Variables added to OPC24_6 and OPC24D_C datasets.
TYPEOPC 11.304 Support for OPC/ESA Release 2.1.
TYPEPOOL 11.141 INPUT STATEMENT EXCEEDED LENGTH with POOL/DASDSMF.
TYPEPRFS 11.262 Support for Softworks' Performance Solution SMF data.
TYPEQAPM 11.166 Support for AS/400 Release 2.2, all records now!
TYPEQAPM 11.254 Support for AS/400 Version 2.3 Performance Data.
TYPEQAPM 11.319 AS/400 system name AS400SYN was blank.
TYPESAR 11.146 Support for LEGENT's SAR product SARSRQU3 SMF record.
TYPESFS 11.250 Xerox SFS accounting record INVALID ARGUMENT error.
TYPESFTA 11.321 Support for ISOGON's SoftAudit externalized files.
TYPESTC 11.124 Missing values for several variables corrected.
TYPESYNC 11.056 Support for SYNCSORT Release 3.5 new variables.
TYPETAO 11.034 "INVALID DATA FOR TAOSTYP" messages.
TYPETCP 11.028 TCP/IP addresses reformatted.
TYPETCP 11.163 Support for TCP/IP 2.2.1 APAR PN40511 new fields.
TYPETPX 11.167 Support for LEGENT's TPX Release 3.5 (incompatible).
TYPEVM 11.113 Support for VM/ESA Release 2.1 Accounting record.
TYPEVMXA 11.047 VM/ESA "UNEXPECTED/INVALID CONTROL RECORD" message.
TYPEVMXA 11.112 Support for VM/ESA Release 2.1 Monitor records.
TYPEVMXA 11.142 VM/ESA duration variables could be truncated.
TYPEVMXA 11.261 VXSYTCPU dataset variable LCUCLPTM not kept.
TYPEVVDS 11.103 Blank values for SMS Storage, Data, etc., Classes.
TYPEVVDS 11.204 Variable VVRBSENM can be blank.
TYPEX37 11.070 STOPX37 Release 3.5 records incorrectly documented.
TYPEX37 11.091 Variable MESSAGE not decided in STOPX37 Rel 3.5.
TYPEX37 11.133 STOPX37 undocumented VOLSER,MSGCODE found.
TYPEZARA 11.059 Support for ZARA, The Tape Media Manager from Altai.
TYPEZARA 11.276 Support for ZARA Release 1.1 (incompatible)
UCICSCNT 11.244 Utility to count type 110 records by application.
VMACDB2H 11.242 DB2 variable NETSNAME can still mismatch CICSTRAN.
VMXGHSM 11.131 HSM BCDS dataset MCB incomplete, too few obs.
VMXGHSM 11.194 Not all observations output in dataset DSR.
VMXGHSM 11.259 HSM BCDS and MCDS data value errors.
VMXGSUM 11.281 Performance enhancement of MXG summarization
VMXGSUM 11.309 Execution improved by creating KEEP= for input.
VMXGSUM 11.309 INCOMPATIBLE exposure if you have tailored members.
VMXGVTOF 11.030 Variable DS4IVTOC was not kept.
WEEKBLD 11.040 Error "DATASET TAPEMNTS NOT SORTED".
WEEKBLD 11.206 DATA SET TAPEMNTS IS NOT SORTED error.
WEEKBLDT 11.172 WEEKBLD with no rewinds/remounts of WEEK tape.
Inverse chronological list of all Changes:
==Changes 11.347 thru 11.141 were printed in Newsletter TWENTY-FIVE==
==Changes 11.140 thru 11.001 were printed in Newsletter TWENTY-FOUR==