COPYRIGHT (C) 1984-2021 MERRILL CONSULTANTS DALLAS TEXAS USA
MXG NEWSLETTER FIFTY-EIGHT
***********************NEWSLETTER FIFTY-EIGHT***************************
MXG NEWSLETTER NUMBER FIFTY-EIGHT, Oct 1, 2011.
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
I. MXG Software Version.
II. MXG Technical Notes
III. MVS, aka z/OS, Technical Notes
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VI.A. WPS Technical Notes.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. z/VM Technical Notes.
X. Email notes.
XI. Incompatibilities and Installation of MXG.
See member CHANGES and member INSTALL.
XII. Online Documentation of MXG Software.
See member DOCUMENT.
XIII. Changes Log
Alphabetical list of important changes
Highlights of Changes - See Member CHANGES.
COPYRIGHT (C) 1984,2011 MERRILL CONSULTANTS DALLAS TEXAS USA
I. The 2011 Annual Version MXG 28.28 was dated Jan 18, 2011, but it was
replaced by MXG 29.01 dated Feb 4, 2011.
You can always use this form
http://www.mxg.com/Software_Download_Request
to request the ftp download instructions for the current version.
1. The current version is MXG 29.06, dated Sep 8, 2011.
See CHANGES member of MXG Source, or http://www.mxg.com/changes.
II. MXG Technical Notes
1. Daily BUILDPDB on 8GB 64-bit Intel Duocore E7500 2.93 Ghz,
Windows Seven Professional 64-bit,
SAS V9.2 64-bit.
SMF read: 19,803,835,294 Bytes @7345KByte/Sec 9,819,991 records
MXG BUILDPDB "Big data" step:
1:08:00 elapsed 13:50 total CPU (12:42 User, 1:08 System)
Total daily run including some reports
1:27:00 elapsed 22:08 total CPU (20:21 User, 1:47 System)
Output PDBs:
CICSTRAN CICSTRAN 4,677,295 obs 3.00 Gigabytes
PDB 3.35 Gigabytes
DB2ACCT 867,135 1.30 Gigabytes
DB2ACCTP 1,267,153 0.60 Gigabytes
TYPE42DS 2,057,402 0.50 Gigabytes
SMFINTRV 275,725 0.20 Gigabytes
STEPS 260,484 0.20 Gigabytes
Rest of PDB 0.55 Gigabytes
III. MVS, a/k/a z/OS, Technical Notes.
14. CA TSO/MON V6.2 CAUSES MXG JOBS TO FAIL ON z/OS 1.12.
DO NOT RUN z/OS 1.12 WITH TSO/MON 6.2 WITHOUT THESE APARS.
IMPACTS ALL APPLICATIONS THAT USE FLOATING POINT INSTRUCTIONS.
MXG jobs that ran fine on z/OS 1.10 failed when run on z/OS 1.12
because TSO/MON corrupts the floating point instructions.
Errors in three separate jobs processing different SMF records:
- INVALID DATA FOR SMFTIME IN LINE 85041 3-10.
- ***ERROR. INVALID DB2 PRODUCT HEADER ID=101 QWHSLEN=50370
- INVALID ARGUMENT TO FUNCTION DATEJUL
There is no clue in any of these errors that TSO/MON is involved.
These two APARs for TSO/MON are required to correct:.
TSO/MON HIPER APAR RO34278 (8/25/2011, was test APAR T5QV357 8/11)
documents that "Applications using Floating Point registers will
experience a series of data exceptions followed by an S059 abend.
SAS applications using 2 dimensional arrays may run into
subscripting problems Customers experiencing these problems were
migrating to z/OS 1.12."
TSO/MON APAR R029589 (Apr 27, 2011), corrects PTF R022614 states:
"When moving to the z/OS 1.12 operating system, you will experience
various abends in the TSO user address spaces, as well as other
applications. This can sometimes be observed during the data
recording phase or when TSO users are logging on or off, and when
batch TSO jobs start. The problem is exacerbated when system
control blocks are overlaid, which causes the system to become
unstable."
Both of these CA APARs are HIPER - which means that if your TSO/MON
"guru" has signed up for alerts, he/she will have been notified by
CA of the critical need for these corrections.
SAS Problem Note 44042 also documents this TSO/MON error.
13. IBM APAR OA24074, documented in MXG Newsletter FIFTY-TWO, changed
the RMF Report calculation of Percent MVS Busy, by subtracting the
Hiperdispatch Parked Time SMF70PAT, and MXG's PCTMVSBY was revised
to match IBM since the Parked Time is NOT a part of capacity.
But, that APAR did NOT document that IBM chose NOT to also revise
their calculation of LPAR Busy (PCTCPUBY), but MXG has always
correctly calculated PCTCPUBY and PCTMVSBY by NOT including the
parked time in the denominator of capacity. IBM's choice was just
recently restated in a PMR which stated:
With hiperdispatch, RMF changed the way it calculates the MVS busy
to not take into account parked engines. This is described in the
text of APAR OA24074 with an example there of how parked engines
can affect the MVS BUSY calculation. However LPAR BUSY does not
consider whether engines are parked. This can throw people off,
especially if there are a large # of engines. It is one reason
that you will still want to define some reasonable number of
logical engines for your LPAR, not necessarily the max possible.
For example, if you had 32 physical engines on the box, and an
LPAR that only ever used a weight equivalent of 4 engines, then
you might define 8 engines to the LPAR (some number larger than 4
for a buffer), and let hiperdispatch park some of them. But you
might not want to define all 32 to that LPAR. Even though
hiperdispatch would park most of them, the reporting which
includes the parked engines can confuse people if they are not
expecting it.
In other words, IBM RMF REPORTS ARE WRONG and do not match the
more-correct MXG calculations of both PCTCPUBY and NRCPUS, both
of which take into account the parked time as "not available".
12. APAR OA36831 corrects negative (or very large) values in SMF 74
fields SMF74SSC, SMF74MEC, SMF74CNN, SMF74PEN and SMF74ATV, in an
interval with Hyperswap activity.
11. APAR OA35175 new SMFPRMxx SMF parameter DSPSIZMAX for SMF Logstreams
allows you to specify the maximum amount of storage that each SMF
logstream data space will consume. This parameter applies to any
logstreams specified with the LSNAME or DEFAULTLSNAME keyword which
does not have this keyword specified as a suboption. This option
can not be changed when SMF is active. If it is attempted to be
changed message IFA760I will be issued. The default is 2 GigaBytes.
See MXG Change 29.177 and APAR OA35175 which add data to SMF 23.
10. APAR OA36761 reports correction to variables SM42GRW and SMA2GRW in
SMF 42 subtype 16 records (TYPE42D1,TYPE42D3 MXG datasets).
9. Tabulation of IBM Created SMF Records that contain JOB name, with
list of other accounting fields that are needed or present; Cheryl
Watson proposed a series of SHARE requirements for each owner of
SMF records that are used for accounting and cost recovery to add
the z/OS ACCOUNT fields. I reviewed and suggested that SYSPLEX is
now needed for accounting, since you can have multiple instances of
the same SYSTEM name in a CEC, and that JCTJOBID has always been
required to fully match JOB-level accounting information, because
JOB and READTIME are not necessarily unique. This table shows all
of the IBM-created SMF records that contain JOB name, with their
status with regard to the other requested fields, for Cheryl to
rank for importance and submit to SHARE:
RECORD JOB READTIME JCTJOBID ACCOUNT SYSPLEX
6 YES YES YES NEED NEED
10 YES YES NEED NEED NEED
14/15 YES YES NEED NEED NEED
16 YES YES NEED NEED NEED
17/18 YES YES NEED NEED NEED
21 NEED NEED NEED NEED NEED
24 YES YES NEED NEED NEED
25 YES YES NEED NEED NEED
26 YES YES YES YES NEED
30 YES YES YES YES YES
32 YES YES YES NEED YES
32 YES YES NEED NEED YES
36 YES YES NEED NEED NEED
40 YES YES NEED NEED NEED
41 YES NEED NEED NEED NEED
42 YES YES YES NEED NEED
57 YES NEED YES NEED NEED
59 YES NEED YES YES NEED
60 YES YES NEED NEED NEED
61/65/66 YES YES NEED NEED NEED
62/64 YES YES NEED NEED NEED
79 YES NEED NEED NEED YES
80 YES YES NEED NEED NEED
83 YES YES NEED NEED NEED
84 YES NEED YES NEED NEED
85 YES NEED NEED NEED NEED
90 YES NEED YES NEED NEED
91 YES YES YES NEED NEED
92 YES YES NEED NEED NEED
99 YES NEED NEED NEED NEED
103 YES NEED NEED NEED NEED
110 YES YES NEED NEED NEED
111 YES NEED NEED NEED NEED
112 YES NEED NEED NEED NEED
113 YES YES NEED NEED NEED
114 YES NEED NEED NEED YES
119 YES YES NEED NEED YES
120 YES NEED YES NEED YES
122 YES NEED YES NEED NEED
123 YES NEED NEED NEED NEED
8. DSNTYPE=LARGE or Extended Format support in SAS V9.2:
All the DSNTYPE=LARGE does is allow more than 64k tracks per volume
to be allocated. The support could not be put in place till z/OS
1.7 when EXCP had the ability to address beyond the 64k track limit
through the TTR, but DSNTYPE=LARGE can be used; see SAS Note 17038.
Extended Format, Striped, Hardware Compressed z/OS datasets have
always been useable, but ONLY for "single dataset data libraries in
sequential format", i.e., your CICSTRAN.CICSTRAN dataset can be
hardware compressed if written to an EF dataset, but you can't
really write multiple SAS datasets to that sequential data library,
since it must be tape format, i.e., with NO directory, so you would
have to read the entire first dataset to get to or to start writing
a second dataset to that library. SAS also refers to these
datasets as "sequential access bound libraries (tape format) on
disk", and SAS Note 17038 specifically states that DSNTYPE=LARGE
can NOT be used for those datasets.
SAS does not have extended format for a SAS bound library on disk
because it is not supported by EXCP which is the access method
service used for SAS I/O for the bound library. The tape engine
can be used (and stored on DISK) because this is using BSAM as the
access method. SAS thinks that IBM does not intend to extend the
support to EXCP either, but IBM also said that before DSNTYPE=LARGE
support existed, but that was then delivered in z/OS 1.7.
7. APAR OA35989 corrects a HiperDispatch problem when processors are
not unparked. On a large test system that was idle, except for a
small test partition that is running with HiperDispatch=YES, low
polarized processors may not be unparked, even though there is
sufficient demand on the small partition and there is a large
amount of free capacity on the CEC.
In module IRABAADJ the free CEC capacity in variable
VCM_CecCapFree is checked against a limit. The variable is of
type Fixed(31) and is multiplied by 256 for the compare. If the
amount of free CEC capacity is very large, an overflow may occur
due to this multiplication. As a result, a very large free CEC
capacity value may not be recognized and a vertical low processor
will not be unparked.
6. In Nov 2010, APAR OA25831 was installed, PTF UA56641 for z/OS 1.10.
After the IPL of each LPAR, the total frames (SMF71TFC + SMF71FIN)
was 261 frames less than the total storage assigned to the
partition. Eventually IBM created APARs to correct the problems,
APAR OA35901 only for z/OS V1.10 (fixed in base of z/OS V1.12)
APAR OA35898. The fix for APAR OA35901 is in the base of z/OS
V1.12 and the ++APAR fixtest for OA35898 restores the correct total
frame count. Most users will probably never notice the error since
the total number of frames was so small. SMF71TFC is PVTPOOL and
SMF71FIN is PVTFPFN in MXG TYPE71 dataset.
5. APAR OA33307 is needed for z/OS 1.11; it corrects high CPU time in
MASTER address space and increased paging.
4. APAR PM35809 corrects Average CPU Time in SMF 120 subtype 6 and 8
interval records, variables SM120WJ4 and SM120JMQ, which w
accurate because integer arithmetic was losing the remainder.
3. There no SMF 30 interval records for the BPXAS address space.
From a posting to IBM-Main in 2011, an IBM answer, from a prior PMR
stated:
Since address space BPXAS creates the spawn or forked address
space, it will not write any SMF interval records. The interval
record will be generated in the name of the forked or spawned
address space during the processing of that job. BPXAS is like
the initiator with no job running in it at that time.
2. IBM 'Driver 79' maintenance has affected SMF70CSF (Central Storage)
with zero values for all LPARs on the physical 2097 CEC, while the
values on the new z196 LPARs appear to be correct. IBM's response
was "open a hardware record indicating SMF70CSF is zero and you
will need hardware MCL N24404.008 in Bundle 37. The hardware
record is the delivery method for the fix."
1. APAR OA31856 reports TYPE42DS Read Disconnect Time and Read count
(S42DSRDD/S42DSRDT) were invalid if an EXCP Channel Program was
built using a Locate Record Extended, because any writes were
considered to be reads.
IV. DB2 Technical Notes.
5. APAR PM17542 enables DB2 Performance Improvements with z/OS 1.12,
one of which was to eliminate EXCP/IOTM counting at the DD level in
DB2 SMF type 30 records by eliminating the DD segments, losing the
EXCPDASD,EXCPTAPE,EXCPTODD counts at the device-type level.
However, OA37361 reports that "after PM17542, SMF IO counting at the
Address Space level are no longer available", which was NOT IBM's
intention, so this newer APAR reinstates ASID counts, which are the
EXCPTOTL/IOTMTOTL variables in MXG.
The Media Manager only records SMF IO counts if the caller
requested it and a DD token exists. A data set allocated via
dynamic allocation with the S99DASUP bit set on, will not
generate a DD token. Any EXCP/IOTM to those dynamic allocation
with S99DASUP on will be seen in EXCPTOTL and EXCPNODD but
will NOT be counted in EXCPTODD.
4. APAR PM39194 corrected zero values in QWACBSC and QWHSSTCK in
SYSPLEX Query Parallel Rollup SMF 101 DB2ACCT records.
3. APAR PM27872 announces sample program DSNTSMFD that decompresses
DB2 SMF 100, 101, and 102 compressed records (and DSNTEJDS JCL to
ASM/LKED/run). There is a limit of 512 DB2 Subsystems, because
the program reports detail statistics on each subsystem, and the
program will fail on the 513rd subsystem, but that limit is set
in DB2_ARRAY_MAX in the sample ASM source code. Of course, this
utility is not needed by MXG users on z/OS, since EXITCICS will
decompress not only the DB2 100,101,102 but also CICS 110 and 112.
2. APAR PM30468 reports that DB2 zIIP usage for DB2 V10 Prefetch and
for Deferred Write zIIP direct, is erroneously reported under MSTR,
instead of DBM1.
1. APAR II07124 discusses problems in DB2 pausing for 1 to 5 minutes
while writing SMF records when the (now known to be STUPID default)
DDCONS=YES is in use, and recommends DDCONS=NO (See item 3.g in MXG
NEWSLETTER SIXTEEN, "No EXCP data for type 30 subtypes 4 and 5...."
for MXG's extensive discussion of DDCONS and DETAIL vs NODETAIL
But this Information APAR adds this note:
If the DB2 address space is run as a batch job, then the INTERVAL
and NODETAIL options will have no effect. If the DB2 address space
is run as a started task (STC) then either the INTERVAL and NODETAIL
options must be put on the SYSSTC parameter, or the SYSSTC parameter
must inherit those options from the SYS parameter.
V. IMS Technical Notes.
1. Text
VI. SAS Technical Notes.
3. If using Enterprise Guide and you choose a device driver for
graphics routines you may get a message:
Insufficient authorization to use yadayada
Circumvention according to SAS knowledge base is to make the first
statement
ODS LISTING CLOSE;
2. Some TYPE70 variables cannot be dropped when TYPE70 is created,
because they are used internally in the MXG logic in VMAC7072
to create the TYPE70PR dataset. In particular, this error message
ERROR: VARIABLE LPARWLMG and PARTNCPU IN THE DROP KEEP RENAME LIST
HAS NEVER BEEN REFERENCED will occur if you drop those variables.
a. You could create WORK.TYPE70 with your tailoring, and then use
PROC SORT NODUP IN=TYPE70 (DROP=LPARWLMG PARTNCPU)
OUT=PDB.TYPE70;
BY _BTY70;
to DROP those variables from your final PDB.TYPE70 dataset.
b. However, there is an alternative, for this case, where the MXG
code that references these two variables is the statement
MERGE SORT70SP (IN=IN70SP DROP=LPARWLMG PARTNCPU)
FROM70PR (IN=FROMPR) ....
You can specify OPTIONS DKRICOND=NOWARN; to prevent the error
message where these variables are dropped from an INPUT.
c. To be compete, MXG defaults the OPTIONS DKROCOND=NOWARN; for
variables in the OUTPUT with Drop/Keep/Rename, because there are
specific cases where variables are in the KEEP= list that may or
may not exist. (In CICSTRAN, there are optional segments and
their variables are in the KEEP= list, but they only exist if
you have tailored their corresponding IMACICxx member to create
them, and the DKROCOND=NOWARN value prevents a similar error
message.
d. The above case for DKRICOND=NOWARN is the first instance where
that has been needed, but I'm not prepared to make it also an
MXG default, at least not from this one instance.
1. Install of SAS V9.2 for z/OS is rumored to be difficult, but by just
following the SAS Install Instructions at:
http://preview.tinyurl.com/443mlpd
we found that the upload and install of the (7.5 GB) z/OS SAS Depot
V9.2 SAS/BASE Component (which is all that is required for MXG)
took less than two hours for a competent systems programmer, even
one who had not done a z/OS SAS install in many years (BUT ONLY if
everything needed is already in place!).
What might be needed to be in place prior to the SAS upload? The
size of the depot itself will typically vary between 5GB and 17GB
depending on the mix of products to be installed. Given that the
SAS Depot will likely be uploaded to a ZFS filesystem (the other
option is NFS attached), and with the z/OS restriction of 4GB for
the size of a (normal) zFS mount point, you will either need the
authority to define a larger zFS mount point, or be able to use an
existing zFS mount point(s) large enough for the SAS Installation.
Either must be created with the SMS Data Class EXTENDED attribute.
In fact, if you take the most straight forward approach you will
need two zFS directories of 5GB to 17GB because the SAS Depot stages
into a second zFS directory (SASHOME) which is used during the
actual install to z/OS datasets.
Once the needed zFS space (with EXTENDED attribute) and commensurate
z/OS space needed for the target DSNs is available it should be
clear sailing.
But, one last note, do NOT use that EXTENDED attribute for the Data
Class of your SAS Data Libraries on z/OS; it is not supported due
to SAS's use of the EXCP access method.
VI.A. WPS Technical Notes.
1. Text
VII. CICS Technical Notes.
1. Text
VIII. Windows NT Technical Notes.
1. Text
IX. z/VM Technical Notes.
1. z/VM MONWRITE data from two z/VM LPARs was compared with RMF 70 data
(SMF70CIN=IFL data for both "IFL LPAR" and "IFL PHYSICAL") for this
four shared-IFL system with 23 hours of matching data.
RMF only has IFL Utilization for SHARED IFLs WITH WAITCOMPLETE=NO,
in TYPE70PR,ASUM70PR,ASUM70LP,ASUMCEC, and ASUMCELP datasets.
For DEDICATED IFL, or SHARED with WAITCOMPLETE=YES, the RMF 70 LPAR
IFL Utilization is always 100% Busy; for these environments, z/VM
MONWRITE (TYPEVMXA) must be used to measure IFL utilization.
The RMF "IFL BUSY" time was 87.31 hours (so the IFLs were busy 94.7%
of those 23 hours). Those 87.31 hours of IFL BUSY time are 5239
minutes, and MONWRITE captured 5182 minutes (98.9%) of that hardware
busy time. And of the 57 minutes not captured in MONWRITE, 49
minutes were the z/OS IFL Management Time. Or, MONWRITE captured
all but 7 minutes of the 5189 minutes of the "Effective Dispatch
Time" recorded by z/OS.
COMPARISON OF RMF 70 IFL CPU TIME AND MONWRITE CPU TIME
VMCPU = MONWRITE CPU (PFXUTIME+PFXSYSTM)
IFLACTTM = RMF Partition CPU Dispatch Time, SMF70CIN='IFL'
(both LPAR and PHYSICAL for IFL)
*****ONLY VALID FOR SHARED IFLs*****
DIFF = IFLACTTM minus VMCPU
LCPUMGTM = LCPUPDTM minus LCPUEDTM
LCPUPDTM = Logical/Physical LPAR Partition Dispatch CPU Time
LCPUEDTM = Logical/Physical LPAR Effective Dispatch CPU Time
HR VMCPU IFLACTTM DIFF LCPUMGTM LCPUPDTM LCPUEDTM
hh:mm:ss hh:mm:ss hh:mm:ss hh:mm:ss hh:mm:ss hh:mm:ss
0 3:45:32 3:48:37 0:03:05 0:02:41 3:48:37 3:45:56
1 3:31:17 3:34:15 0:02:58 0:02:37 3:34:15 3:31:38
2 3:52:58 3:55:15 0:02:17 0:02:00 3:55:15 3:53:15
3 3:57:03 3:58:57 0:01:54 0:01:39 3:58:57 3:57:18
4 3:56:34 3:58:25 0:01:51 0:01:36 3:58:25 3:56:49
5 3:47:43 3:49:55 0:02:12 0:01:55 3:49:55 3:48:00
6 3:38:32 3:41:11 0:02:39 0:02:19 3:41:11 3:38:52
7 3:39:53 3:42:27 0:02:35 0:02:15 3:42:27 3:40:12
8 3:44:08 3:46:29 0:02:20 0:02:02 3:46:29 3:44:27
9 3:45:52 3:48:14 0:02:21 0:02:02 3:48:14 3:46:11
10 3:52:52 3:54:56 0:02:04 0:01:48 3:54:56 3:53:08
11 3:54:01 3:56:04 0:02:03 0:01:47 3:56:04 3:54:17
12 3:48:54 3:51:14 0:02:20 0:02:02 3:51:14 3:49:12
13 3:41:47 3:44:20 0:02:32 0:02:13 3:44:20 3:42:07
14 3:43:33 3:46:12 0:02:40 0:02:20 3:46:12 3:43:53
15 3:33:38 3:36:26 0:02:48 0:02:27 3:36:26 3:33:59
16 3:34:50 3:37:50 0:03:00 0:02:37 3:37:50 3:35:13
17 3:47:36 3:49:56 0:02:20 0:02:02 3:49:56 3:47:54
18 3:48:37 3:50:55 0:02:18 0:02:01 3:50:55 3:48:55
19 3:28:17 3:31:28 0:03:11 0:02:48 3:31:28 3:28:40
20 3:44:45 3:47:22 0:02:37 0:02:18 3:47:22 3:45:05
21 3:47:22 3:50:02 0:02:40 0:02:19 3:50:02 3:47:43
22 3:56:37 3:58:38 0:02:02 0:01:46 3:58:38 3:56:53
======== ======== ========= ======== ======== ========
86:22:20 87:19:09 0:56:49 0:49:33 87:19:09 86:29:36
2. MONWRITE does not provide synchronized interval records (yet???).
The below procedure is only run a IPL time or any situation the
requires a recycle. This procedure holds the Monitor START command
until the next hour boundary, with the hour padded with a zero if
had only one digit, as the WAKEUP command doesn't support a single
digit hour.
/* Make the monitor intervals start on the hour */
'CP MONITOR STOP'
Parse value time('N') with hh ':' mm ':' ss .
hh=hh+1 /*Wait for the next hour*/
If ss=59 then mm=mm+1 /*May need a bit more time*/
If mm>60 then do /*Overflow to the hour*/
mm=mm-60
hh=hh+1
end
If hh<10 then hh = '0'hh
'WAKEUP' hh':00:00' /*Wait*/
'CP MONITOR START' /*Start the monitor*/
X. Email notes.
1. Text
XI. Incompatibilities and Installation of MXG vv.yy.
1. Incompatibilities introduced in MXG 29.05 (since MXG 28.28):
See CHANGES.
2. Installation and re-installation procedures are described in detail
in member INSTALL (separate sections for each platform, z/OS, WIN,
or *nix), with examples of common Errors/Warnings messages a new MXG
user might encounter, and in member JCLINSTT for SAS V9.2 or member
JCLINSTW for WPS. INSTALL also shows how to read SMF data on PCs/nix
using the FTP ACCESS METHOD.
XII. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
XIIV. Changes Log
--------------------------Changes Log---------------------------------
You MUST read each Change description to determine if a Change will
impact your site. All changes have been made in this MXG Library.
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
The CHANGES selection on our homepage at http://www.MXG.com
is always the most current information on MXG Software status,
and is frequently updated.
Important changes are also posted to the MXG-L ListServer, which is
also described by a selection on the homepage. Please subscribe.
The actual code implementation of some changes in MXG SOURCLIB may be
different than described in the change text (which might have printed
only the critical part of the correction that need be made by users).
Scan each source member named in any impacting change for any comments
at the beginning of the member for additional documentation, since the
documentation of new datasets, variables, validation status, and notes,
are often found in comments in the source members.
Alphabetical list of important changes after MXG 27.27 now in MXG 29.07:
Dataset/
Member Change Description
See Member CHANGES or CHANGESS in your MXG Source Library, or
on the homepage www.mxg.com.
Inverse chronological list of all Changes:
Changes 29.yyy thru 29.001 are contained in member CHANGES.