COPYRIGHT (C) 1984-2019 MERRILL CONSULTANTS DALLAS TEXAS USA
MXG NEWSLETTER TWENTY-TWO
MXG NEWSLETTER NUMBER TWENTY-TWO July 10, 1992
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
I. MXG Version Status.
1. Production Version is still MXG 9.9, dated March 1, 1992. 2
2. There was no MXG Software tape shipped with this newsletter. 2
3. MXG PreRelease 10.1, July 10, 1992, is now available on request. 2
4. Major enhancements and new products supported in MXG 10.1 2
5. IBM Announcements and their MXG support. 3
6. What is planned in future MXG Software releases? 3
7. New MXG documentation is slowly being created. 3
II. MXG Technical Notes
1. Can I Execute MXG on a PC or a UNIX workstation? An MXG Position. 5
2. Will SAS 6.07's compress option help MXG? 6
3. How do I run the PDB if my data center runs only six days a week? 7
III. MVS Technical Notes
1.APAR OY51878 (CPURCTTM in TYPE72) is corrected by PTF UY77275. 8
2.APAR OY51053 (SYSTRNTM in TYPE72) is corrected by PTF UY77634. 8
3.APAR OY52104 (invalid JOB characters) in 4/5 fixed by PTF UY78154. 8
IV. CICS Technical Notes
1.CICS/ESA 3.3.0 was incompatibly changed by IBM. 8
2.Omegamon V550 support requires installation tailoring. 9
V. SAS Technical Notes.
1.BUILDPDB with SAS 6.07 NOTE: ADDITIONAL INTERNAL PASS message. 9
2.SAS 6.07 Error 31-185, Format not recognized, occurs if the SAS 9
3.JCLTEST6 JCL 4MB REGION too small if MEMSIZE is limited by site. 9
4.SAS 6.07 INFILE processing with END=END may not work as expected. 9
5.SAS 6.06 & SAS 6.07 require BLKSIZE=23040 override to avoid error. 10
6.SAS 6.07 error in CCHHR option causes VMXGVTOC to miss extents. 10
7.SAS 6.07 does not recognize the EPILOGC infile exit name. 10
8.SAS 6.07 may produce INVALID ALTER PASSWORD error message. 10
9.SAS 6.07 copy from SMF VSAM file to BSAM VBS creates invalid data. 10
10.SAS 6.07 entry modules SASXA1 and SASXAL may ABEND with 0C4. 11
VI. Installation, re-installation, and Space Requirements. 11
VII. Important notes from prior Newsletters: 13
VIII. Documentation of MXG Software. 15
IX. Change Log - Changes 10.104-10.001 16-39
COPYRIGHT (C) 1992 BY MERRILL CONSULTANTS DALLAS TEXAS
I. MXG Version Status.
1. Production Version is still MXG 9.9, dated March 1, 1992.
The current Production Version, (the Software Version that was sent
to all customers) is still MXG 9.9, shipped in March, 1992. We plan
to ship Production Version 10 on March 26, 1993 (because that is
when MVS/ESA 4.3 becomes available).
2. There was no MXG Software tape shipped with this newsletter.
3. MXG PreRelease 10.1, July 10, 1992, is now available on request.
MXG PreRelease 10.1 contains many significant enhancments, as shown
below. We will be happy to ship that software to you; just send us
a fax (overseas sites can fax via their local SAS office) requesting
MXG 10.1. There is no charge for a PreRelease.
4. Major enhancements and new products supported in MXG 10.1:
Required for CICS/ESA 3.3,
Required for VM/ESA 1.1.1,
Required for TYPEIMS users; major revision in IMS log processing.
Strongly recommended for DB2 sites, because it:
- has significant corrections in ANALDB2R reporting,
- has speeded up MXG DB2 processing and reduced WORK space needed,
- allows DB2ACCT direct to tape for sites with large DB2 activity,
- has new ASUMDB2A to summarize and reduce size of DB2ACCT.
- has MVS Account fields added to DB2ACCT (DB2 2.3).
Offers support for these new products or releases:
Support for AICorp's KBMS user SMF record.
Support for Amdahl's APAF replacement for MDFTRACK.
Support for Blue Line's Vital Signs for VTAM type 28.
Support for Fujitsu's FACOM MSP/EX (incompatible) SMF records.
Support for MVS/ESA 4.2 Dynamic I/O Reconfig in MXG Tape Monitor.
Support for NETSPY Release 4.2 added.
Support for NETSPY Token-Ring records added.
Support for ROSCOE Release 5.7 changes to SMF data.
Support for RSD's WSF/WSF2 Release 3.4.1.
Support for SPMS 1.2.13 incompatible changes.
Support for STOPX37 Release 3.4.
Support for Software Ag "Natural Process" SMF record.
Support for System Center's NETMASTER type 37 SMF records.
Support for The Network Director North Ridge Software
Support for UNIX iostat and vmstat commands from ULTRIX.
ASMVTOC avoids 213/314 abends reading VTOC of TPF or VM volumes.
LPAR CPU utilization reports added.
MINTIME=,MAXTIME= parameters added to VMXGSUM.
MVS/ESA 4.2.0 changed format of DEVNR/UNITADR in TYPE75.
MXG Tape Mount Monitor supports MVS/ESA dynamic reconfiguration.
New dataset TYPE40_D can be created for tape analysis
TAPE3490 (3490s allocated) added to PDB.STEPS/JOBS.
Trending with INTERVAL=MONTH members added.
MXG PreRelease 10.1 replaces MXG 9.9 with minimal effort and usually
transparently. Beta sites have been running 10.1 since May.
Each of these enhancements are described in the Change Log, page 16.
5. IBM Announcements and their MXG support.
The following table lists announced availability dates for the IBM
product, and the corresponding Version of MXG required to support
that IBM product.
Product Name Availability MXG Version
MVS/370, MVS/XA (all) long ago 8.8
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 1993. 10.?
RMF 4.3.0 (for MVS/ESA 4.3 Mar 1993. 10.?
CICS/ESA 3.1 1990 8.8
CICS/ESA 3.2 Jun 28, 1991. 9.9
CICS/ESA 3.3 Mar 28, 1992. 10.1
DB2 2.2.0 1990 8.8
DB2 2.3.0 Oct 28, 1991. 10.1
VM/ESA 1.1.0 (370 Feature) Oct 26, 1990. 8.8
VM/ESA 1.1.0 (ESA Feature) Mar 29, 1991. 8.8
VM/ESA 1.1.1 Dec 27, 1991. 10.1
6. What is planned in future MXG Software releases?
Enhancement of AS400 support is planned.
Several companies have announced plans for VTAM monitors.
TRIM for ADABAS is in planning; test data did not arrive in time.
Goal Systems EXPLORE/VM support needs corrections.
Landmark CICS Version 9 documentation/data has not been provided.
Landmark TMVS new version documentation/data has not been provided.
Boole & Babbage CICS/MANAGER is a future consideration.
JES3 Tape Mount Merge with TYPETMNT is a future consideration.
Cray UNICOS is a distant future consideration.
VAX/VMS Account/SPM is a distant future consideration.
7. New MXG documentation rewrite is in progress.
Yes, there will be new printed documentation, which will combine
the 1984 MXG Guide, the 1987 MXG Supplement, and the 700 pages of
MXG Technical Newsletters, plus the notes and text buried in the
various members of the MXG library.
No, the new books will not be completed in 1992. (In last 1991 we
re-printed both the 1984 MXG Guide and 1987 MXG Supplement to
ensure we do not run out of print until the new books are done!)
The complete re-write of MXG documentation began in the fall of 1991
and is still in progress. With over 1,000 MXG-built data sets and
over 40,000 variables, the new Chapter FORTY style documentation
would total over 4,200 printed pages, the equivalent of 6 books the
size of the 1984 Guide, just for data set documentation! This brief
analysis led to the following plan of attack.
For each "Product" or "Data Source" supported by MXG, there is a
VMAC.... member which reads those data records and creates one or
more MXG data sets. For each of these VMAC.... code members, there
will (eventually!) be an ADOC.... member that documents that data
source. Each ADOC.... member will not only contain the data set
and variable descriptions now found in sections of Chapter FORTY,
but will also document the "Product" itself. The ADOC.... format
is still being finalized, but each ADOC... will contain several
Product Information: Vendor, vendor's manuals, how to create the
data records, releases supported, etc.
Data Set Information: Contents of each data set created by MXG from
this product, like existing Chapter FORTY with
alphabetic list of all variables.
Variable clusters: Grouping of MXG variables by logical grouping
(CPU, I/O, memory, response, owner, etc.). See
page 424 in the MXG Supplement for example.
Report mappings: For important reports from the vendor (eg. IBM
RMF reports), a sample report showing which
MXG variable name creates each report value.
See page 454 in the Supplement for an example.
PRINT/MEANS An edited PROC PRINT of actual observations of
each MXG dataset shows the variable name, its
label, and actual values, (which I personally
think is the best way to understand datasets).
A PROC MEANS with minimum and maximum values
of all numeric variables is also provided.
Technical reports: Technical papers, discussions, or other useful
information relating to each product will also
be included in that products ADOC.... member.
Currently, 200+ "Products" have been identified, and thus there will
be at least that many ADOC.... members. As evidence of progress in
the documentation revision, twenty-five ADOCs now exits in MXG 10.1,
although none yet contain all of the above sections. As ADOCs are
completed, they are added to the next MXG PreRelease.
In addition to revising Chapter FORTY into the ADOC.... members, the
other 41 chapters will also be revised, combined, and indexed, and
will be made available initially online in the MXG source library.
At this time, I envision the future MXG printed documentation will
consist of three separate (potentially multi-volume) "books":
a. A "Beginners Guide to MXG Software", subtitled, "What do I do
now that my boss just told me I am the MXG Technican?". This
book will describe how to install, re-install, and use MXG and
will deal exclusively with MXG architecture, execution, etc.
The member NEWUSER is a start in this documentation.
b. A "Documentation of Products Supported by MXG", comprising the
above mentioned ADOC.... members. The IMACAAAA member is the
best index of the product's that are supported by MXG, although
searching CHANGESS for the product name or abbreviation may be
needed due to product renames.
c. A new "Advanced Guide to CPE" text consolidating all of the
other forty-one chapters, plus additional new information.
Among my other dreams to be done, maybe, sometime.
ALL FUTURE MXG DOCUMENTATION WILL ALWAYS BE PROVIDED INITIALLY IN
MACHINE READABLE FORMAT AS PART OF THE MXG SOFTWARE. Portions of
that online documentation will also be available in printed format.
II. MXG Technical Notes
1. Can I Execute MXG on a PC or a UNIX workstation? An MXG Position.
A. The building of MXG "Performance Data Bases" must be done under a
mainframe version of SAS, at least for the short-term foreseeable
future. There are several factors that inhibit the use of a PC or a
UNIX workstation to create MXG data sets from raw data records:
1. The current SAS compiler interprets INPUT statement informats
based on the execution platform. On the mainframe, $CHAR expects
EBCDIC values, but under PC/VAX/UNIX, $CHAR expects ASCII values.
Similarly, PD4, PIB4, RB4, informats expect the data format of the
executing environment; different platforms store binary data in
different formats, and using PIB4 in a PC program to read SMF data
will produce incorrect numbers. (Some mainframe-specific informats
like SMFSTAMP and RMFDUR do not yet exist on all SAS platforms.)
Additionally, sort orders, like input formats, are intrepreted for
the execution platform; ASCII vs EBCDIC and ascending/descending
differences could render some MXG algorithms invalid.
This constraint will exist at least until a SAS Version 7 exists,
(years, not months) because removing it requires a significant
change to the design of the SAS System. I have asked the SAS
Institute to remove this limitation, by providing an option that
allows us to specify the environment under which the DATA step
input formats, sort order, etc., are to be interpreted. SAS
designers agree that the limitation should be removed, and are
evaluating implementation strategies for the future SAS version.
SAS does provide some mainframe informat names (eg, the S370xxxx
informats) that do interpret mainframe data values under PC SAS,
but their use requires source changes to all 400,000 lines of MXG,
with more than just substitution - algorithms for nonexistent data
formats require insertions in multiple locations per occurrence.
A separate MXG source library would be needed for each platform on
which it would be executed, a maintenance burden for both of us!
2. A personal computer or departmental mini-computer is the wrong
place for performance data. The performance/capacity/accounting
PDB is a strategic and tactical corporate information source and
corporate asset used by technicians, managers (operations,
software, technical support), their directors, company presidents
and often by corporate executives. Asking them to walk down the
hall to your PC to look at the capacity graphs seems less
appropriate than having the PDB on a mainframe where they can all
view the single (and hence unambiguous) PDB information at their
own desk without a download and without bugging you to look over
Shared corporate data belongs on mainframes and personal data
belongs on personal or departmental machines.
3. The volumetrics are wrong for personal or departmental computers.
The daily SMF volume for a mainframe is measured in hundreds of
megabytes. 500K CICS transactions are 200MB of raw SMF data. At
9600 baud, it takes 24 hours to download 100MB! Even channel
attached PCs take hours per 100MB, and then more hours after the
download to create the SAS data libraries, which will need disk
volumes measured in hundreds of megabytes for the temporary
datasets while building the PDB. Current mainframes are 40-80
times faster for "real data processing (i.e., lots of I/O)"
workloads than are current 486 PCs and UNIX workstations.
I believe that the MXG application at your site reads more input
data bytes per day than any other (and probably more than all
other) business applications on your mainframe processor! Buying
a PC or a UNIX box for this kind of business application is a
misapplication of the present technology.
B. Building MXG data bases in the future may be different. Already we
are testing MXG programs under SAS 6.07 and OS2 Release 2 on a 400MB
Model 95 PS/2 (soon with a 3480 IDRC tape drive!), not because we
think that is the way to go, but because we want to make sure that
when it does become feasible, and when the SAS limitations have been
removed or circumvented, MXG will be ready! (Even then, I believe
mainframe SAS will continue to be the place to build your PDBs!)
C. Please note carefully that the limitations in preceding paragraphs
deal only with the BUILDING of large, shared performance data bases.
Once the "PDB" has been created on the mainframe, it can be completely
appropriate to use a personal computer for personal analysis or for
development and testing of reports. The PDB, consisting of many,
mostly small, SAS datasets, can be efficiently processed on today's
PCs. Most sites with PC devices for color plotters and printers now
use SAS/GRAPH cooperatively between their mainframes (where they build
the graph) and their PC (where they PROC GREPLAY the results).
It is possible to generate the graphs without a mainframe SAS/GRAPH
license, by downloading PDB datasets to a PC or workstation that then
does the PROC GPLOT to build graphs on the PC, but this may be a poor
choice and false economy, since a PROC GPLOT that takes only one
second on your 3090 can easily take one minute on your PC, not even
including the time to download the MXG dataset in the first place.
The savings in your time alone may well justify the costs for the
second SAS/GRAPH license, and you have the power and storage of a
mainframe to keep graphs available for replay. The generation of
graphics is a CPU-intensive process; there are times when it should be
executed on the mainframe, and there are times when it can be executed
on the PC. The best implementation is to have SAS/GRAPH available on
both platforms, and (eventually, in future SAS versions) let SAS
decide what runs where!
2. Will SAS 6.07's compress option help MXG?
Because MXG has always used LENGTH DEFAULT=4 to minimize the size of
its datasets, the COMPRESS option cannot save as much DASD space
with MXG as it will with other SAS applications which use the SAS
default length of 8 bytes for numeric variables. Nevertheless, it is
appropriate that we investigate the possible use of COMPRESS=YES.
One benchmark of BUILDPDB with 470MB input SMF data shows the cost to
compress all datasets: the CPU time increased significantly (65%, from
535 to 883 seconds) but only reduced the WORK library size by 16% and
only reduced the PDB library by 20%.
A second run compressing only CICSTRAN and DB2ACCT datasets showed the
CPU time increase was less but still appreciable (37%, from 472 to
645 seconds in the data step alone), but the CICSTRAN dataset was
reduced by 37% and DB2ACCT was reduced by 44%. Thus, if you must put
these two datasets on DASD, compression will, at some CPU cost, save
appreciable DASD. However, it has always been MXG's recommendation
to store large volume transaction datasets (like CICSTRAN and DB2ACCT)
directly on tape to avoid contamination of DASD space, and SAS 6.07
does not support compression of tape data libraries!
Compression does reduce the size of MXG datasets as shown, but the
CPU cost is appreciable. These initial benchmarks suggest strongly
that the COMPRESS option will not likely be used by default in MXG,
but for sites that have large-volume transaction datasets that must be
stored on DASD, the CPU cost of compression may be justified by DASD
savings. MXG member IMACKEEP can be used to specify COMPRESS=YES for
specific datasets, and further enhancements to MXG will make it even
easier to specify individual options, such as COMPRESS, for specific
3. How do I run the PDB if my data center runs only six days a week?
Sites which operate six days a week need to make only minor changes
to the architecture of BUILDPDB/WEEKBLD/MONTHBLD. The PDB that would
normally be built on Sunday morning and that would normally be copied
into the SAT "day-of-week" dataset will not exist if your site does
not run BUILDPDB on Sunday.
If SAS would allow it, you could use //SAT DD DUMMY but SAS Version
6, unfortunately, does not tolerate DD DUMMY for SAS data libraries.
You could modify MXG and remove all references to SAT in members
WEEKBLD and MONTHBLD and your JCL for BUILDPDB, WEEKBLD, and MONTHBLD
and I once suggested that approach. But here's Chuck's better way:
Create the SAS equivalent of DD DUMMY by allocating a one cylinder
SAS data library for your SAT or SUN PDB (or both, if you're a 5x24
instead of a 6x24 operations!). You then execute
OPTIONS OBS=0; PROC COPY IN=PDB OUT=SAT; RUN; OPTIONS OBS=MAX;
to build a valid zero-observations SAT or SUN PDB library. You can
then use the normal MXG JCLPDB6 JCL, and your MXG tailoring will be
limited to MONTHBLD, discussed below. However, there is another
big advantage of this implementation. When you do grow up again to
operate 7x24, you simply create a new and larger dataset for that
seventh day that is being added, and you keep on trucking!
However, if you operate only six days a week, you must also alter the
logic in MONTHBLD and in the logic that submits the MONTHBLD job:
The logic of MONTHBLD must be changed, because if the 1st day of the
month is a Sunday, then the monthly job must be executed on Monday
the 2nd day of the month. These specific changes must be made:
MONTHBLD - These changes are required:
a. replace IF DAY(TODAY) NE 1 THEN DO;
IF NOT (DAY(TODAY) EQ 1 OR (DAY(TODAY) EQ 2 AND DAY='MON'))
b. insert IF DAY(TODAY) EQ 2 THEN TODAY=TODAY-1;
immediately before LASTDAY=TODAY-1;
SUBMIT logic. The example on page 343-4 of the MXG Guide shows how
to use SAS to submit the monthly jobs from the daily BUILDPDB on
the first day of the month that is not a Monday using:
IF DAY=1 AND WDAY NE 'MON' THEN MONTHFLG=1;
The text points out that if the first day of the month is a Monday
the monthly job will be submitted by a "similar step attached to
the weekly job so that the monthly job uses the weekly dataset".
That "similar step" would contain only the second DATA _NULL_ step
in the example, and (for seven day operation) it would contain:
IF DAY=1 AND WDAY EQ 'MON' THEN MONTHFLG=1;
For six day operation, only that "similar step" tacked on to the
end of your weekly job needs to be changed to now read:
IF (DAY=1 OR DAY=2) AND WDAY EQ 'MON' THEN MONTHFLG=1;
Note that MXG architecture requires that the daily BUILDPDB job
complete before the WEEKBLD job is submitted on Monday, and that the
WEEKBLD job complete before MONTHBLD is submitted. This is easily
accomplished by letting the BUILDPDB submit WEEKBLD/MONTHBLD and
letting WEEKBLD submit MONTHBLD when the month starts on Sunday or
With six day operation, the data for Saturday and Sunday work will
be put in the SUN library with a ZDATE of Monday's date. Since the
selection criteria for a month are the ZDATEs of the 2nd of last
month thru the 1st of this month (inclusive), the combined weekend
data will be put in last month's PDB when the month starts on Monday
and the combined weekend data will be put in next month's PDB when
the month starts on Sunday.
III. MVS Technical Notes
1.APAR OY51878 (CPURCTTM) is corrected by PTF UY77275. As a result,
the circumvention for this IBM error (Change 9.184, which removed
CPURCTTM from CPUTM sum in TYPE72) has been removed (Change 10.064)
2.APAR OY51053 (SYSTRNTM) is corrected by PTF UY77634. SYSTRNTM is a
new concept in TYPE72; it is the execution time plus the input queue
time (i.e., from READTIME to TERMTIME), and now appears correct.
3.APAR OY52104 and PTF UY78154 correct problem with invalid characters
in JOB field in the (archaic) type 4 and 5 SMF records (and in some
IEF... messages printed on the Job's SYSLOG.
IV. CICS Technical Notes
1.CICS/ESA 3.3.0 was incompatibly changed by IBM. New data fields were
inserted in the middle of the records! MXG 9.9 does not ABEND with
CICS 3.3.0 records (it does print "UNEXPECTED DATA FOUND" notes on
the SAS log as a warning that something is wrong), but the CICSTRAN
dataset is essentially trashed; transaction start/stop/response times
are valid, but all resources (CPU time, File Control counts, etc.)
are completely wrong. MXG 10.1 is REQUIRED for CICS/ESA 3.3 records.
2.Omegamon V550 support requires installation tailoring.
a. MXG members IMACICOC, IMACICOL, and IMACICOB (for the BSC, DLI,
and DB2 additions to the transaction record) contains a comment
block which surrounds that actual code. That comment block must
be deleted to enable processing of these three Omegamon segments.
b. MXG member IMACICDA controls which CICS APPLIDs have Omegamon data
segments. If only some CICS APPLIDs have Omegamon data, you must
add a DO group for those APPLIDs around the three %INCLUDEs for
the three members above, so they are only included for the correct
c. For CICS 2.2 or earlier (SMFPSRVR=3) you must tailor member
IMACEXCL to process the excluded fields in the basic transaction
segment. You use macro _CICXLTR to name the APPLIDs writing the
Omegamon records, and you use macro _CICXCTR to specify _CICXCOM
so that the Omegamon exclude structure is used for those APPLIDs.
This step is not required under CICS/ESA, because Omegamon does
not exclude transaction fields under CICS/ESA.
d. If MCTSSDRL=496 in the MXG VMAC110 error message, you must also
update member IMACPTF and in therein enable macro QOC0109. This
note was added to the online member Aug 24, 1994.
V. SAS Technical Notes.
1.BUILDPDB (with additional SMF record processing) under SAS 6.07 has
produced "NOTE: ADDITIONAL INTERNAL PASS WAS REQUIRED TO COMPUTE
CORRECT CODE SIZE. SPECIFYING OPTION CODEPCT=102 MAY REDUCE EXECUTION
TIME.", but MXG's CONFIG07 member specifies CODEPCT=120! This appears
to be a very minor SAS bug that is under investigation, that has no
effect on the MXG execution of BUILDPDB. However, this note caused
me to benchmark a related compiler option, CODEPASS. In theory,
specifying CODEPASS=2 for large programs should be faster, since SAS
is committed to a two-pass compile, instead of starting to one-pass
compile and finding a second pass necessary, but it did not have that
effect on MXG's BUILDPDB with SASENTRY=SASHOST. With CODEPASS=2,
the CPU time (exactly repeatable) increased by 1.04 seconds (from
49.15 to 50.19), or 2% increase, and the elapsed time was a wash
(down .63, 91.85 to 91.22 in one pair, up .36, 95.54 to 96.30 in the
second pair). Since CODEPASS=1 is slightly cheaper, CODEPASS=2 is
not recommended for BUILDPDB.
2.SAS 6.06 Error 31-185, Format not recognized, occurs if the SAS
installer was sloppy and tried to create a Version 6 JCL Procedure by
modifying your existing Version 5 procedure. The Version 5 PROC has
a //LIBRARY DD DSN=&LIBRARY,DISP=(MOD,DELETE) statement that does not
belong in Version 6. Have your SAS Installer correct your problem by
installing the Version 6 JCL Procedure provided by SAS Institute.
3.JCLTEST6 JCL 4MB REGION too small if MEMSIZE is limited by site.
Two sites have reported they could not successfully execute TESTIBM3
step of JCLTEST6 in a 4MB Region with MXG's CONFIG member default of
24MB; they had to increase the REGION JCL parameter to 6MB to run.
At least one of the sites had limited the amount of virtual storage
above the line to 16MB, and thus SAS could not get the 24MB MEMSIZE
MXG expected. Increasing the REGION size is the only alternative if
you cannot get enough MEMSIZE above the line!
4.SAS 6.07 INFILE processing of concatenated files is not perfect if
END=END is specified. The JCFB= variable is incorrect and contains
the 2nd concatenation's DSNAME while still on the last record of the
1st concatenation. Additionally, the SAS NOTE: describing the next
data set is printed too early on the SAS log (before messages from
the last record in the 1st concatenation). Tracking 238735. Only if
you use the JFCB= variable (to capture DSNAME?) are you at risk. MXG
only uses the JFCB= variable initially to discern if the input data
is VSAM or BSAM, and thus this error poses no risk to MXG code.
5.SAS 6.06 and SAS 6.07 require BLKSIZE=23040 override to avoid error.
SAS 6.06 may still ABEND with the erroneous error message "DATA SET
IS NOT SORTED", indicating bit overlays in the WORK DDname. These
errors have nothing to do with the SORT program, but were thought to
be mostly fixed by SAS Oct 1991 Maintenance. There were still some
known exposures that could not be fixed by zap, that were thought to
have been fixed in SAS 6.07 (remember, 6.07 allowed SAS to corect at
source level, instead of by ZAP). A circumvention for SAS 6.06 sites
until they install SAS 6.07 has been to follow MXG's performance
recommendation of BLKSIZE=23040 for WORK DD because it appears that
the bit overlay error is eliminated by the larger block size (instead
of the 6144 SAS default)!. See page 35, MXG Newsletter TWENTY-ONE,
for the JCL example to override WORK DD. One SAS 6.07 site reported,
without confirmation, a similar failure that was seemingly also
eliminated by large blocksize for WORK DD.
6.SAS 6.07 error in the CCHHR option causes VMXGVTOC to miss extents
and produce "CRITICAL ERROR IN VTOC PROCESSING" if there are more
than three extents. SAS ZAP V6-SYS-FILE-4673 is available on the
June 1992 SAS Usage Notes Tape. This error was apparently only in
the CCHHR option, and not the similar but different CCHHR= option.
This error did not affect the recommended alternative to VMXGVTOC,
the ASMVTOC/VMXGVTOF members which are faster, better, and do not use
either CCHHR or CCHHR= options.
7.SAS 6.07 does not recognize the EPILOGC infile exit name, used to
processing Candle's (archaic) EPILOG compressed records, while SAS
6.06 did. Fortunately, the current EPILOG V550 product writes data
to SMF records without compression, so few sites should encounter
this SAS error.
8.SAS 6.07 may produce INVALID ALTER PASSWORD error message. Two SAS
usage notes, V6-SYS-SASIO-4267 and -4147, discuss separate problems
related to the PROTECT option and Version 5 or 6.06 datasets.
One site had a SPIN library that had been originally created by SAS
5.18. Their SAS 6.07 BUILDPDB failed when it started to write out
the new day's SPIN data sets, because that Version 5 SPIN library had
been built with PROTECT enabled. (PROTECT was removed in 6.06 but
apparently causes SAS 6.07 to unexpectedly fail!). By creating a
6.07 SPIN library and using PROC COPY to copy the SPIN datasets to
the 6.07 SPIN library, this site's problem was circumvented with no
loss of data:
//SPIN607 EXEC SAS607,CONFIG=MXG.SOURCLIB(CONFIG07)
//SPIN DD DSN=OLD.SPIN.LIBRARY,DISP=OLD
//NEWSPIN DD DSN=NEW.SPIN.LIBRARY,DISP=(,CATLG),...
PROC COPY IN=SPIN OUT=NEWSPIN
One site failed in WEEKBLD when it went to overwrite the WEEKly
library. The PROC CONTENTS showed the ENGINE=TAPE, indicating the
library had been created with SAS 6.06's Tape engine, and usage note
4147 indicates that cannot be done without error under 6.07. In this
case, simply by scratching and re-allocating the WEEKly library
(since the weekly data had already been copied to tape) circumvented
9.SAS 6.07 copy from SMF VSAM file to BSAM VBS file creates invalid SMF
records; error is fixed by SAS ZAP MV313550. See Change 10.030.
10.SAS 6.07 entry modules SASXA1 and SASXAL may ABEND with 0C4 at SAS
initialization. The culprit appears to be IBM's IEBCOPY option
COPYMOD, used to build and re-block these "bundled" programs. The
COPYMOD option seems to create double RLD entries (they can be seen
in an AMBLIST of the ABENDing module). Using IEBCOPY option COPY
instead of COPYMOD did not create double RLDs and SAS did not ABEND.
The COPYMOD statement which needs to be changed is found in member
CPYBA2 of the SAS install library; see step BACOPY2 in SASUPDTE job.
This has hit two sites, and research is still in progress. The ABEND
only occurs in batch execution. Tracking 244913, still open.
VI. Installation, re-installation, and Space Requirements.
Over 20 Beta sites have been running MXG 10.1, some since mid May,
with no reported problems, either in execution or migration from
9.9. There are no changes in the external (JCL) environment for MXG
10.1, and the installation instructions are unchanged from MXG 9.9.
Sites migrating to 10.1 from an MXG version earlier than 9.9 must
read the compatiblity section of the installation instructions in
MXG Newsletter TWENTY-ONE.
Always read comments in the CHANGES member for compatibility issues, as
well as for any last minute changes added after Newsletter composition.
The MXG Installation instructions are found in Chapter 32 of the MXG
Supplement for both new installation and for version replacement, and
those instructions, as modified herein, are still valid.
The MXG tape is distributed as a Non-Labelled (NL) tape containing a
single file with DCB=RECFM=FB,LRECL=80,BLKSIZE=32720. The MXG tape is
an unloaded Partitioned Dataset in IEBUPDTE format. Note that the tape
blocksize was changed to 32720 (it had been 6160 in prior versions). You
will receive I/O errors if you specify the incorrect blocksize.
Under MVS use IEBUPDTE utility to build the MXG.SOURCLIB PDS library.
Under CMS use TAPPDS command to build the SOURCLIB MACLIB library.
Allocate MXG.SOURCLIB for MXG 10.1 with SPACE=(CYL,(54,1,299)), using
DCB=(RECFM=FB,LRECL=80,BLKSIZE=23440) on 3380 devices, or
DCB=(RECFM=FB,LRECL=80,BLKSIZE=27600) on 3390 devices.
Under CMS, approximately the same space (54 cylinders) will ultimately
be required by the MXG SOURCLIB MACLIB, but during the CMS installation
process you will need at least 108 free cylinders on your minidisk.
MXG is tailored and extended by "Installation Macro" members (members
beginning with IMAC....), and by "MXG Exit Facility" members (members
beginning with EX....) that are copied and edited into the installation
"USERID.SOURCLIB", the name of the "MXG Tailoring" library, that you
create and concatenate ahead of MXG.SOURCLIB to the SOURCLIB DDNAME:
//SOURCLIB DD DSN=USERID.SOURCLIB,DISP=SHR --> site tailoring (yours)
// DD DSN=MXG.SOURCLIB,DISP=SHR --> never changed (mine)
If this is an MXG re-install, there should already be a USERID.SOURCLIB.
If not, then allocate one using the same attributes as the MXG.SOURCLIB,
with SPACE=(CYL,(1,1,99)). Under CMS create an equivalent MACLIB.
Tailor by editing members that you copy from my library to your library.
IMAC.... members are self-documenting, and member IMACAAAA indexes all
IMAC members. Most MXG sites have only a few tailoring members in their
USERID.SOURCLIB (typically, IMACACCT, IMACSHFT, IMACWORK).
VMAC.... members contain the actual processing code, and normally should
not exist in your USERID.SOURCLIB, and should always be removed when you
install a new version of MXG. However, if you have installed printed
changes from an MXG Newsletter, you might have copied VMAC member(s)
from MXG.SOURCLIB into your site's USERID.SOURCLIB and then modified the
VMAC member. (Alternatively, you could have created an MXG.CHANGLIB in
which you put those in-between-version changes.) In either case, if
you made temporary changes, they must be removed now. Delete all of the
VMACs members from your USERID.SOURCLIB (or delete the MXG.CHANGLIB).
Otherwise, your modified VMAC member would be used instead of MXG's.
You should record all tailoring changes in your USERID.SOURCLIB so the
next MXG technician will know what you have done. You should create a
member named CHANGES in your USERID.SOURCLIB, similar to member CHANGES
in the MXG.SOURCLIB which documents all MXG changes.
If there are IMAC.... members in your USERID.SOURCLIB, you must look at
the alphabetic list of changed IMACs in the Change Log, below, and must
retrofit your tailoring on the new member in this library. MXG 10.1
changed IMACPDB to add TAPE3490 device count.
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 Chapter FORTY.
Summary of critical actions to be taken in installing new version:
a. All VMAC.... members in your USERID.SOURCLIB must be examined
and, in general, must be deleted.
b. All IMAC.... members in your USERID.SOURCLIB must be compared
with the IMAC.... members that have been changed in this MXG
version (see alphabetic list at beginning of Change Log). You
MUST start with the IMAC in this version and retrofit your
installation's tailoring. Member IMACAAAA indexes all IMAC's.
c. It is always wisest to PROC PRINT the first 50 observations of
important datasets, especially PDB.JOBS, which can be affected
by user tailoring in IMACPDB. A visual scan of that PROC PRINT
serves as an excellent validation of correct installation, and
will almost always detect any serious problems BEFORE you begin
your production MXG runs! See also the MXG utility UTILPRAL.
VII. Important notes from prior Newsletters:
1. SAS OPTIONS REQUIRED under version 5.18, 6.06, or 6.07.
Please read this section carefully. MXG execution will fail if you
do not pay attention to these (potentially incompatible) changes:
SAS options that are MANDATORY with all SAS Versions:
NOIMPLMAC MAUTOSOURCE SASAUTOS=SOURCLIB ERRORABEND MACRO DQUOTE
NOIMPLMAC should ALWAYS be used; never use IMPLMAC.
MAUTOSOURCE and SASAUTOS=SOURCLIB are required by MXG to
resolve %MACRO references without extra I/O by using autocall.
ERRORABEND ensures SAS stops on any error condition.
MACRO enables SAS to recognize %MACROs.
DQUOTE is needed to extract values of certain string %MACROs.
SAS options MANDATORY under SAS Version 5.18 (do not exist in V6):
MWORK was needed in large %MACROs (like %ANALDB2R).
GEN=0 was needed to eliminate unnecessary I/O and CPU time, and
is discussed in the 1984 Guide (see Index).
SAS options MANDATORY under SAS Version 6 (did not exist in 5.18):
Previously, MXG recommended MEMSIZE=12M, but programs that build
many datasets concurrently (like BUILDPDB, VMACVMXA, etc.) will
need more of this virtual storage above the line, because of the
new MXG recommended value for BLKSIZE='half-track'. The MEMSIZE
option only works under MVS/XA and MVS/ESA, and since it is not
a real resource, and only used when needed during the "building"
phase in MXG processing, the new default of MEMSIZE=24M should
not cause any problem, and will avoid unnecessary ABENDs.
If you are using MXG and SAS 6.07 under MVS/370 or CMS/370, you
will have to reduce this MEMSIZE= parameter to no more than 6M,
and must reduce the BLKSIZE (try 4096, or the minimum 1024).
Small BLKSIZE will allow your program to compile, but the DASD
work space you will need will significantly increase, as will
the run-time, IOs, and CPU requirements for the same job.
SAS options STRONGLY RECOMMENDED for SAS 6.06/6.07 performance:
BLKSIZE=23040 BUFNO=2 -- for 3380's
BLKSIZE=27648 BUFNO=2 -- for 3390's
MXG now uses BLKSIZE(DASD)=HALF in CONFIG/CONFIG07 members to set
the blocksize for new permanent data sets, but that option will
not work if the BLKSIZE was specified in the JCL. The //WORK DD
contains an explicit BLKSIZE=6144 parameter, which must either be
changed in your SAS procedure or overridden in your JCL, using:
// EXEC MXGSASV9
//WORK DD DCB=BLKSIZE=23040
See "SAS Benchmarks" in Newsletter TWENTY for resource savings.
SAS options recommended with either SAS Version 5.18, 6.06 or 6.07:
NOSOURCE NOSOURCE2 NOMACROGEN NOMPRINT NOMLOGIC
So how do you specify these recommended/required MXG options?
In Version 5.18, MACRO and MWORK=28000 must be specified on the EXEC
statement, but all other options could be specified on an OPTIONS
statement right after your SYSIN DD * statement. However, so you do
not have to remember them nor type them, MXG member SASOPTV5 has all
of the recommended options in an OPTIONS statement, so you need only
%INCLUDE SOURCLIB(SASOPTV5); as your first SAS statement:
//stepname EXEC SAS518,OPTIONS='MACRO MWORK=28000'
//SYSIN DD *
... the rest of your program ...
For SAS Version 6, options can be set with an OPTIONS statement, or
with the OPTIONS= JCL parameter, or (as is MXG's recommendation) via
the CONFIG= JCL parameter on the EXEC statement. MXG member CONFIG
contains the MXG required and recommended options for SAS 6.06, and
member CONFIG07 contains the SAS 6.07 recommendations. The BLKSIZE
and MEMSIZE options were increased in MXG 9.9, and the new CONFIG07
member was added with new SAS 6.07 options. (You could also supply
options by overriding the CONFIG DD in the SAS JCL procedure, but
using the CONFIG= parameter is safer and simpler.).
// EXEC SAS606,TIME=10,
// EXEC SAS607,TIME=10,
IF YOU DON'T HAVE THE RIGHT OPTIONS IN EFFECT, YOU WILL RECEIVE
RUDE AND INSULTING SAS ERROR MESSAGES, INCLUDING 180 ERRORssss!
2. Format libraries are different in MVS SAS Version 6 and Version 5.
The MXG-built "SASLIB" formats are built by the first step of either
JCLTEST (for SAS 5.18) or JCLTEST6 (for SAS 6.06).
Under SAS Version 5.18, formats are members of a PDS load library
which must be allocated as SPACE=(CYL,(3,1,99)). SAS 5.18 formats
are always referenced using the DDNAME of SASLIB.
Under SAS Version 6 formats are members of a SAS data library, which
must be allocated as SPACE=(CYL,(1,1)). Note there is NO third SPACE
parameter (for PDS directory blocks), because data libraries in SAS
Version 6 are physical sequential files. SAS Version 6 format
libraries are always referenced using the DDNAME of LIBRARY.
In either version of SAS, the blocksize is set by the PROC FORMAT.
MXG always requires the appropriate DDNAME (SASLIB or LIBRARY).
You will fail with SAS 170 FORMAT NOT FOUND errors if you do not
have the correct format library pointed to by the correct DDNAME.
VIII. Documentation of MXG Software.
Member CHANGES always contains the version number of MXG Software, and
it lists changes that were installed in that version. The members named
CHANGEnn have the contents of CHANGES when that "nn" MXG version was
created. Description of enhancements will be found in the text of the
Change description that made the enhancement (in those CHANGES and
CHANGEnn members). The CHANGE members can be scanned online (with SPF
BROWSE) to search for specific product name references (CICS, MVS/ESA,
etc.). The text of each Change identifies the member(s) that were added
or altered by that change. Documentation (especially for new product's
support) is usually also found in comments at the beginning of those
members listed in the change entry.
Member NEWSLTRS contains the text of all newsletters (up through the
newsletter that accompanied that MXG release). You can search NEWSLTRS
for product name or acronym to find the technical notes, APARs, etc.
from all MXG newsletters. (The Change Log of each Newsletter is not
replicated in member NEWSLTRS, since that text will be in CHANGES).
Member DOCVERnn is the "delta-documentation" (in abbreviated Chapter
FORTY style) of only those variables and datasets that were changed
between successive MXG Versions. There is a DOCVERnn "delta" member in
the MXG library for each version.
Penultimately, member DOCVER contains abbreviated Chapter FORTY format
that documents all of the variables names in all of the MXG data sets
that are created by that MXG Software Version (alphabetically by data
set name and variable name).
Finally, MXG is a source distributed system, so you can often find your
answer by BROWSE/EDIT of the source member, especially the VMACs that
actually create the data set, or ANALs that analyze the MXG data sets.
In many instance, the MXG Variable name is the IBM or Vendor's field or
DSECT field name. In other cases, the DSECT field name is carried as a
comment beside in the MXG INPUT statement to map field name to MXG's
variable name. MXG expects you to also have access to the vendor's
documentation of particular data records you are using for analysis.
IX. Change 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 is 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 easily installed, critical part of the correction).
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.
Changes thru 10.104 were contained in MXG Beta 10.1 Jul 10, 1992.
Changes thru 9.229 were contained in MXG Version 9.9 Mar 1, 1992.
Alphabetic INDEX of significant changes in MXG 10.1 (after MXG 9.9):
Member Change Description
ADOCAAAA 10.087 Twenty-Five ADOCs documentation members now exist.
ANALDB2R 10.001 DB2 Report truncated character values.
ANALDB2R 10.034 SORTBY= operand parsed only the first SORT variable.
ANALDB2R 10.046 LIBRARY SMF IS NOT VALID message with PMSQL04 report.
ANALDB2R 10.047 DBID/OBID hex values printed instead of name.
ANALDB2R 10.055 Date/time selection in PMSACC01/02 produced no report
ANALDB2R 10.094 ANALDB2R Accounting report uses ASUMDB2A if exists.
ANALDSET 10.097 VSAM data sets may have wrong PROGRAM name.
ANALMONI 10.066 TMON/CICS sample report filled WORK file.
ASMIMSLG 10.084 Major revision in IMS log processing algorithms.
ASMTMNT 10.012 MXG Tape Mount Monitor supports Dynamic I/O Reconfig.
ASMVTOC 10.073 Avoid 213/314 abends reading VTOC of VM/TPF volumes
ASUMDB2A 10.090 DB2 Account "transactions" summarized into ASUMDB2A.
EXTY72 10.064 CPURCTTM now valid, circumvention removed.
GRAFLPAR 10.052 LPAR CPU utilization reports added.
GRAFTRND 10.049 Graphic trending reports were not always correct.
IMACFACO 10.100 Fujitsu's FACOM MSP/EX SMF records now supported.
IMACPDB 10.053 New macro _DB2ACCT added. Compatibility exposure.
IMACPDB 10.068 TAPE3490 (3490s allocated) added to PDB.STEPS/JOBS.
JCLTEST6 10.030 INVALID DATA FOR SMFTIME, SAS zap MV313550 required.
MNTH.... 10.091 Trending with INTERVAL=MONTH members added.
READDB2 10.045 TRACECLS= parameter does not select all IFCIDs.
TRNDDB2A 10.093 TRNDDB2A Account Trending uses ASUMDB2A if exists.
TYPEMON8 10.020 Landmark CICS "INVALID OFFSETS" message.
TYPEMON8 10.067 MONITASK variables STRTTIME/CREATIME now equal.
TYPETMS5 10.082 TMS.TMS had DSNB fields, TAPEFEET calculation changed
VMAC102 10.072 DB2 SQLCODE can be negative, MXG read as positive.
VMAC110 10.017 Invalid type 110 subtype 2 could cause MXG to loop.
VMAC110 10.038 Omegamon error causes INVALID DATA FOR SMFPSRSN.
VMAC110 10.059 Type 110 STOPOVER due to bad record eliminated.
VMAC110 10.061 Support for CICS/ESA 3.3.0 monitor (CICSTRAN) data.
VMAC110 10.062 Support for CICS/ESA 3.3.0 statistics datasets.
VMAC24 10.037 Spool off-load type 24 can cause STOPOVER abend.
VMAC28 10.095 Blue Line's Vital Signs for VTAM type 28 supported.
VMAC30 10.031 Variables ACTDLYTM, RESDLYTM, DSPDLYTM created.
VMAC37 10.098 System Center's NETMASTER type 37 SMF record support.
VMAC39 10.040 INPUT STATEMENT EXCEEDED for subtype 5.
VMAC40 10.065 New dataset TYPE40_D can be created for tape analysis
VMAC41 10.015 DIV type 41 SMF record timestamps mis-documented.
VMAC42 10.005 Type 42 SMF record causes STOPOVER ABEND.
VMAC6 10.003 PSF type 6 record had FORM truncated.
VMAC7072 10.010 TYPE70PR variable NRPRCS corrected.
VMAC7072 10.042 PCTRDYWT variable now created.
VMAC71 10.014 SWAP counts corrected.
VMAC75 10.099 MVS/ESA 4.2.0 changed format of DEVNR/UNITADR.
VMACAPAF 10.078 Support for Amdahl's APAF replacement for MDFTRACK.
VMACAICO 10.048 Support for AICorp's KBMS user SMF record.
VMACCIMS 10.063 IMF flag variables wrong if multiple bits are on.
VMACDB2 10.024 MVS Account fields added to DB2ACCT!
VMACDCOL 10.071 INVALID VALUE FOR FUNCTION DATEJUL message.
VMACHSM 10.080 FSTTRKR/W large values are actually negative values.
VMACNATP 10.033 Support for Software Ag "Natural Process" SMF record.
VMACNETP 10.039 NETPACTM was total response, should be average.
VMACNRS 10.075 Support for The Network Director North Ridge Software
VMACNSPY 10.015 Support for NETSPY Token-Ring records added.
VMACNSPY 10.057 Support for NETSPY Release 4.2 added.
VMACRMDS 10.102 RMDS messages INVALID DATA FOR RMDSMXVR eliminated.
VMACROSC 10.022 Support for ROSCOE Release 5.7 changes to SMF data.
VMACROSC 10.101 ROSCOE ADSFUN.. variables values corrected.
VMACSMF 10.019 Header/Trailer messages on log were not always right.
VMACSPMS 10.011 SPMS R2.1.4 invalid record circumvented.
VMACSPMS 10.069 SPMS 1.2.13 inserted four byte field, causing errors
VMACTMS5 10.060 TMS inactive DSNBs now deleted, caused wrong VOLSER.
VMACTMVS 10.058 TMON/MVS "INVALID DATA for WKLCPURF" message.
VMACTPX 10.007 TPX variable TPXELAP has wrong value.
VMACVMXA 10.036 VM/ESA 1.1.1 additions now supported.
VMACVMXA 10.071 VM/ESA VXSYTCUP dataset has only 49 observations.
VMACWSF 10.081 Support for RSD's WSF/WSF2 Release 3.4.1.
VMACX37 10.013 STOPX37 Release 3.4 is supported.
VMXGSUM 10.089 MINTIME=,MAXTIME= parameters added to VMXGSUM.
VMXGVTOC 10.018 CRITICAL ERROR IN VTOC if DSORG=PS-SUL data found.
VMXGVTOC 10.054 ISAM index space not recognized in VTOC.
WEEKBLD 10.008 NOT SORTED when implementing MXG 9.9
WEEKBLD 10.009 TYPE70PR,DB2ACCT/STAT0/STAT1 added to weekly/monthly.
XMAC7072 10.023 344 Compiler circumvention causes UNINITIALIZED msg.
XUNIX 10.076 Support for UNIX iostat and vmstat commands.
Inverse chronological list of all Changes:
Changes 10.104-10.001 were printed here in Newsletter TWENTY-TWO
See member CHANGE10 for actual change text.
End of Changes Log in Newsletter TWENTY-TWO.