COPYRIGHT (C) 1984-2021 MERRILL CONSULTANTS DALLAS TEXAS USA
MXG NEWSLETTER SIXTY
***********************NEWSLETTER SIXTY*********************************
MXG NEWSLETTER NUMBER SIXTY, August 6, 2012
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 2012 Annual Version MXG 29.29 was dated Jan 23, 2012.
1. The current version is MXG 30.05, dated Aug 8, 2012.
You can always use this form
http://www.mxg.com/Software_Download_Request
to request the ftp download instructions for the current version.
See CHANGES member of MXG Source, or http://www.mxg.com/changes.
II. MXG Technical Notes
3. Processing DB2 compressed data using MXG EXITCICS vs IBM DSNTSMFD:
On z/OS, compressed DB2 data can be processed in a two-step job
using the IBM DSNTSMFD program to first decompress the SMF data,
which is then read with MXG's TYPEDB2 as the second step, or the
the EXITCICS (Version 2) "CICSIFUE Infile Exit" can be used by the
MXG TYPEDB2 program to decompress records as they are read.
The DB2 SMF file contained 2 million DB2 records:
The two-step process took: 142.76 TCB Seconds CPU
6 min 10 seconds Elapsed
138,000 EXCPs
The MXG one-step EXITCICS took 140.83 TCB Seconds CPU
3 min 55 seconds Elapsed
76,466 EXCPs
So the CPU times are essentially the same, but the one step had
half the I/O activity. While elapsed times are notoriously hard to
compare, pretty clearly, the one-step process is faster due to the
elimination of the write-then-read time of the two-step process.
2. Does MXG do any date/time checking while reading the SMF data?
Specifically, if the dump time for my SMF data is not midnight but
some other arbitrary time will I lose any data?
First, no, MXG NEVER "loses" any data.
Second, I've NEVER recommended running MXG exactly at midnight:
- the evening batch processing often extends beyond midnight, so
delaying the dump/BUILDPDB until later in the morning will give
you more information on "yesterday's" batch job processing.
- often, there is a significant flurry of activity right after
midnight. Some applications run programs to store the new "day"
in a date file, and operations often runs backups at midnight,
so BUILDPDB would be competing with (or impacting) those jobs.
Instead, I suggest that BUILDPDB should be run N hours prior to
when the reports are required, where N/2 is the typical run time
of the daily job and its reports!
MXG does NO date selection by default; you can select times in your
IFASMFDP dump process, or you can use MXG's IMACFILE/MACFILE exit
to select by SMFTIME, but without that tailoring, MXG simply reads
the input SMF file(s) to create a PDB data library from all of the
SMF records in that input.
If you dump SMF data at 6AM, then your daily PDB will contain the
only the interval data (e.g., RMF) from 6AM yesterday until 5:59AM
today, but it will contain the event data (e.g., job completions)
for more of yesterday's batch processing. If management wants the
interval RMF reports to cover midnight to midnight, you can read
two adjacent PDBs to select only yesterday's twenty-four hours:
DATA RMFREPORT;
IF PUT(TODAY(),WEEKDATE3.)='MON' THEN DO;
SET SUN.RMFINTRV MON.RMFINTRV;
IF PUT(DATEPART(STARTIME),WEEKDATE3.)= 'SUN';
END;
ELSE IF PUT(DATEPART(STARTIME),WEEKDATE3.)='TUE' THEN
SET MON.RMFINTRV TUE.RMFINTRV;
IF PUT(DATEPART(STARTIME),WEEKDATE3.)= 'MON'
. . .
But for the PDB.JOBS data, you would first have to define what you
mean as "yesterday": all jobs that were read in, or all jobs that
started execution, or all jobs that started and ended execution, or
all jobs that were read in, executed, printed, and purges? What
about jobs that were read in two days ago and are still running?
A "Job" is only output into PDB.JOBS when the job has purged, i.e.,
when ALL of the SMF records for that job (30s, 6s, and 26s) have
been read, since only then are we guaranteed we have all of the
records for a job. But each BUILDPDB also outputs "inflight jobs"
into the PDB.SPUNJOBS dataset, for all jobs that are still
incomplete. So, if you want a tactical report of all jobs,
completed or inflight, that INITIATED and COMPLETED EXECUTION,
you would use this logic:
DATA JOBSREPORT;
IF PUT(TODAY(),WEEKDATE3.)='MON' THEN DO;
SET SUN.JOBS MON.JOBS MON.SPUNJOBS;
IF PUT(DATEPART(JINITIME),WEEKDATE3.)= 'SUN';
END;
because the JINITIME variable comes from the 30-5 Job Terminate SMF
record. If you wanted all jobs that INITIATED, you would use the
variable INITTIME, since it is the minimum initiate time from the
30-4 step records. The complete documentation of which datetime
variables in PDB.JOBS come from which SMF records is to be found in
the DOCPDB member.
1. Processing compressed DB2 V10 SMF Data on ASCII.
A comparison of the cost of processing compressed DB2 SMF data on
ASCII (Windows Seven Ultimate), decompressing with the internal SAS
code algorithm (which has to be use because INFILE exits are not
supported on ASCII platforms, so the EXITCICS exit cannot be used)
shows the decompression elapsed time and CPU time is about 2.8 more
than the cost to process uncompressed records; compression reduced
the size of the file by a factor of 5, so, as always, compression
is a tradeoff between space and time (in seconds, below).
(Note that Newsletter 57 reported the internal SAS algorithm is
VERY expensive on z/OS, compared with the EXITCICS exit.)
One Million ID=101 records
2500MB 500MB
UNCOMPRESSED COMPRESSED
ELAPSED CPU ELAPSED CPU
57 3 19 1 DATA _NULL_;INFILE SMF;INPUT;
107 100 284 282 %INCLUDE SOURCLIB(TYPEDB2);
50 97 265 281 Difference (Processing - Read)
III. MVS, a/k/a z/OS, Technical Notes.
10. An IBM-Main posting noted that DFSORT supports large format data
sets for sortworks, so each can use more than 64K tracks. DFSORT
dynamically allocates them as large format, or for //SORTWKnn DD's
allocated in JCL allocated, you need to specify DSNTYPE=LARGE on the
DD statements and DFSORT will support that.
9. Using FTP to Transfer a VB files between two z/OS Systems.
You must specify the EBCDIC and BLOCK attributes
type e
mode b
or the transferred data file will be corrupted/unreadable.
Item 20 in MXG Member FTPING has detail documentation and examples
(from an IBM tech note) for moving VB files between z/OS systems,
either directly z/OS-to-z/OS, or indirectly through an ASCII
platform, using either HFS or TSO TRANSMIT/RECEIVE to create an
intermediate file that can be sent z/OS-???-z/OS. If you do have to
use and ASCII platform, I think the better choice that is not in the
IBM note would be to use TERSE/UNTERSE to create that intermediate
file, since it would reduce the transfer times to/from/between the
ASCII systems.
8. APAR OA38430 reports RMF CF Activity Report can show the CF
utilization (% busy) is very low, the service times are high and
the standard deviations are large. Where a low % busy around 1%,
the service times are in the thousands of microseconds and the
standard deviation may be in seconds. The CF engines were
dedicated.
7. APAR PM57383 reports SMF 120 subtype 9 user name field in variable
SM1209ES can sometimes be blank, while that name field is correct
in subtype 1 records.
6. APAR PM58287 reports SMF 117 field IMFLMFNM, which is MXG variable
S17FMFNM (MESSAGE*FLOW*NAME), is too short at 32 characters. When
corrected, this will require an MXG change since the field can not
be increased in its current place in the middle of the record.
5. APAR PM57680 reports changes to SMF 64 record causes the DSD record
DSNAME field to be incorrect for VSAM datasets.
4. Observed: PGM=ADRDSSU, DFDSS backup program does NOT write SMF 42
subtype 6 records for the INPUT datasets that were backed up; only
the OUTPUT dataset created SMF records, so there is no tracking of
which datasets were backed up. Whether this is intentional or an
oversight is under query to IBM support.
3. APAR PM49660 reports Waiter Information is missing in SMF 79
Subtype 15.
2. APAR PM55328 reports SMF 118 Records with Subtype=0 are written
even though SMFCONFIG TYPE118 keywords are all set to NO.
1. In 2042, the current 8-byte STCK (TODSTAMP8.) datetime value will
wrap, with a value '17SEP2042:23:53:47.370495'. In z/OS 1.11, IBM
introduced the STCKE instruction with a 16-byte output.
Note: the SMFSTAMP and RMFSTAMP formats will NOT wrap in 2042,
or ever, as they have a separate date-part with the century bit.
SAS will eventually provide an extended TODSTAMP16. (?) informat to
read the STCKE value, but until then, if a vendor creates a record
with the extended TODSTAMP value, this code can be used to decode
STCKE now and after 2042. This example STCKE value is 1.04 seconds
after the 8-byte STCK would have wrapped:
'01000000010000000000000000000000'x
and this code
FFTOD=INPUT('FFFFFFFFFFFFFFFF'x,TODSTAMP8.)+
INPUT('0000000000000001'x,&PIB.8.6)/4096;
INPUT STCKE1ST &PIB.1. STCKE2ND &PIB.8.6 +7 @;
IF STCKE1ST=0 AND STCKE2ND=0 THEN STCKE=.;
ELSE STCKE=STCKE1ST*FFTOD+STCKE2ND/4096;
FORMAT STCKE DATETIME25.6;
LENGTH STCKE 8;
produced the value of STCKE=17SEP2042:23:53:48.419071
IV. DB2 Technical Notes.
4. Comparisons of creating DB2ACCT, DB2ACCTP and AUDIT records.
All tests read the same 1787MB SMF file, creating 400,755 DB2ACCT
observations and 456,617 DB2ACCTP observations, both on tape with
no sorting, and all T102S140-T102S145 Audit datasets were created,
but only T102S145 had 4 observations. A tailored KEEP kept only
145 variables in DB2ACCT (559 without tailoring) and kept only
113 variables in DB2ACCTP (168 without tailoring):
Test Compress KEEP Used CPU Seconds
1 no yes 133.8
2 no no 151.4
3 yes yes 183.4
4 yes no 198.8
As might be expected, reducing variables and disabling COMPRESS
is the cheapest for the CPU resource (but MAXIMUM for DASD space!),
and enabling COMPRESS and keeping ALL variables is the most costly
for CPU, with an increase of 50% over the minimum CPU time.
3. Changes to STATIME and SYNCVAL parameters in DB2 Version 10.
In DB2 Version 10, the interval when statistics records are created
was changed. The subsystem parameters STATIME and SYNCVAL apply
only to IFCID 0105 (T102S105), IFCID 0106 (T102S106), and IFCID
0199 (T102S199) records. All other interval statistics records,
IFCID 0001 (DB2STAT0 and DB2STATR), IFCID 0002 (DB2STAT1, DB2STATB,
and DB2GBPST), IFCID 0202 (DB2STAT2), IFCID 0217 (T1020217), IFCID
0225 (DB2ST225) and IFCID 0230 (DB2GBPAT) are no longer controlled
by STATIME and SYNCVAL, and the corresponding trace records are
written at fixed, one-minute intervals.
2. APAR PM54177 reports that QWACBSC and QWACESC in DB2ACCT dataset
for Distributed Transactions can contain zero. APAR text is:
DB2 accounting logic expects to be called to start an accounting
interval to record transaction begin times. Some distributed
client behavior can result in accounting begin being skipped. The
case is when SET statements are followed by a COMMIT without
additional SQL. Without the begin accounting call, an accounting
IFCID3 record will be written with zero begin times upon COMMIT.
PROBLEM CONCLUSION:
Accounting has been changed to reject accounting intervals where
no begin times have been collected. This will eliminate the
IFCID3 records with QWACBSC and QWACBJST equal to zero.
1. APAR PM51653 reports IFCID 239 Class 7 Package Accounting Time is
incorrect when fetching from a stored procedure result set; the
error is in QPACTJST or QPACCLS7_ZIIP.
V. IMS Technical Notes.
3. APAR PM27227 reports IMS V12 can fill SMF with type 79 records.
2. APAR PM36273 added zAAP/zIIP CPU Usage time in TYPE56FA and TYPE07
log records; the APAR was supported in MXG 29.29 Change 29.307,
(DLRZAAP in 07s, TPEZAAP in 56FA).
1. APAR PM33465 reports STRTTIME is incorrect in IMS 56FA log record
for IFP Transactions and PWFI and WFI Full Function Transactions.
VI. SAS Technical Notes.
7. Changing the length of MXG variables.
There are many long-length character variables created by MXG,
primarily due to open systems text fields, but you can change
the length of any MXG CHARACTER variable created from SMF data by
adding a LENGTH statement in your IMACFILE member, or by passing
that LENGTH statement with the &MACFILE macro variable:
//SYSIN DD *
%LET MACFILE=
%QUOTE( LENGTH
VAR1 VAR2 VAR3
$8 ;
);
%INCLUDE SOURCLIB(whatever);
The IMACFILE exit places that LENGTH statement so it is seen first
by the SAS compiler, prior to the MXG default LENGTH statement; for
character variables, SAS uses the FIRST instance of LENGTH.
You can NOT change the LENGTH of a NUMERIC variable in the IMACFILE
exit nor with &MACFILE, because SAS uses the LAST instance of a
LENGTH statement for numeric variables, but you can a LENGTH
statement in the EXdddddd exit member for that record to change a
numeric variable's length, since that code is seen AFTER the MXG
LENGTH statement by the SAS compiler.
6. SAS WARNING about NLSCOMPATMODE Option.
This z/OS-only SAS Warning is harmless, including SAS V9.3 in 2012:
SAS HAS BEEN STARTED IN NLS COMPATIBILITY MODE WITH THE
NLSCOMPATMODE OPTION. THIS OPTION WILL BE DEPRECATED IN A FUTURE
RELEASE OF SAS AND NLS COMPATIBILITY MODE WILL NO LONGER BE
SUPPORTED. FOR MORE INFORMATION, CONTACT A SAS REPRESENTATIVE OR
TECHNICAL SUPPORT.
The NLSCOMPATMODE option is set in MXG's CONFIGV9, which is used in
the MXGSASV9 and MXGSAS92 JCL Procedure Examples, primarily for all
non-USA sites, as was documented in Change 22.129 (text below).
However, it is now the "official" recommendation to NOT use either
of those "old" JCL Procedure Examples, but instead, as contained in
the MXGSAS93 and INSTALL members, to use the new "MXGNAMES"
NEW, and documented in Change 27.356, with SAS V9.2 or later:
YOUR SITE'S standard SAS JCL Procedure can be used for MXG:
// EXEC SAS,CONFIG='MXG.SOURCLIB(CONFIMXG)'
//MXGNAMES DD DSN=MXG.USERID.SOURCLIB(MXGNAMES),DISP=SHR
instead of using the MXGSAS92 JCL Procedure example.
in part because that new JCL example eliminates the need for the
NONLSCOMPATMOD option to be set. Here is the text of 27.356:
Change 27.356, Jan 17, 2010:
-The standard SAS JCL procedure can now be used for MXG on z/OS.
You do not need a separate MXGSASVn JCL procedure; instead, use
this JCL example (in member JCLMXG), after you EDIT the DSNAMES
of your MXG Source, MXG "USERID" and MXG Formats datasets into
your MXGNAMES member in your MXG "USERID" tailoring library:
// EXEC SAS,CONFIG='MXG.SOURCLIB(CONFIMXG)'
//MXGNAMES DD DSN=MXG.USERID.SOURCLIB(MXGNAMES),DISP=SHR
or you can provide the names in the jobstream, with:
// EXEC SAS,CONFIG='MXG.SOURCLIB(CONFIMXG)'
//MXGNAMES DD *
%LET MXGUSER1=HLQ.MXG.USERID;
%LET MXGSOURC=HLQ.MXG.SOURCLIB;
%LET MXGFORMT=HLQ.MXG.FORMATS;
-In addition, the VMXGCNFG macro that was designed by Rich
allocates the //SOURCLIB with OPEN_ED-1047 encoding; by doing so,
the setting for NLSCOMPATMODE is moot, and by doing this, all NLS
sites running with a locale that is non-ENGLISH_UNITEDSTATES will
never need to worry about NLSCOMPATMODE, so MXG never has to
worry about those SAS language encoding issues again.
Change 22.129, Jun 15, 2004, which originally set NONLSCOMPATMODE:
In SAS V9, the NLSCOMPATMODE option was changed to default to
NONLSCOMPATMODE, which doesn't fail if your LOCALE option is
ENGLISH or blank, but with a LOCALE=GERMAN_GERMANY or other
non-blank and non-ENGLISH value, with the new NONLSCOMPATMODE
option, every "@" causes this error at compile time:
ERROR: The name 'A7'x49 is not a valid SAS name. where that
'A7'x is a funny looking printed symbol. (in the VMXGINIT code
at statement INPUT @49 ....).
Changing the NONLSCOMPATMODE option back to the V8.2 default of
NLSCOMPATMODE eliminated the error, so I have added option
NLSCOMPATMODE to the CONFIGV9 member, as it appears to be safer,
and I've listed the SAS help note about the option for you to
read, below. This note is was added so MXG 22.06 could be
completed, but it may be revised when I know more about these
options.
Specifying LOCALE=GERMAN_GERMANY and NONLSCOMPATMODE did not
cause a failure using SAS 9.1.2 under Windows/XP.
The SAS help documentation for NLSCOMPATMODE:
"NLSCOMPATMODE provides compatibility with previous releases of
SAS in order to process data in languages other than English,
which is the default language. Programs that ran in previous
releases of SAS will continue to work when NLSCOMPATMODE is set.
When NONLSCOMPATMODE is in effect, SAS does not support
substitution characters in SAS syntax. If you run SAS with
NONLSCOMPATMODE, you must update existing programs to use
national characters instead of substitution characters. For
example, Danish customers who have substituted the 'Å' for the
'$' character in existing SAS programs will have to update the
SAS syntax to use the '$' ("national character") in their
environments.
Note: NLSCOMPATMODE might affect the format of outputs that are
produced using ODS. If you are using ODS, set the option value to
NONLSCOMPATMODE."
There is additional, extensive, documentation of LOCALE and NLS
in SAS Technical Note TS-653 at www.sas.com.
5. Copying and backing up SAS data libraries on z/OS.
Disk to disk copy - full library copy of all members:
-PROC COPY always works, but IEBGENER uses much less CPU time than
SAS. However, with IEBGENER you lose the audit in the SAS log
that shows which datasets and how many observations were copied.
And SAS validates that all MXG-created formats do exist in the
//LIBRARY DD during the copying. GENER just copies blocks.
-Copying a 185 cylinder PDB, IEBGENER used 2.71 CPU seconds while
PROC COPY used 41.99 CPU seconds for the same data library copy.
A second test of a single member disk dataset with 100,000 obs in
DB2ACCT showed a larger disparity between GENER and PROC COPY
where GENER took .5 seconds and PROC COPY 8.7. It is likely that
the time consumed by PROC COPY is a function of the number of
members in the library being copied, the number of variables in
each member, and the number of OBS in each member.
-However, PROC COPY is expensive only when COMPRESS=YES is enabled
(it is the MXG default), AND ONLY IF the CLONE default is used,
because CLONE compresses again the already compressed data.
Instead, specifying PROC COPY NOCLONE for the same PDB took only
12.1 seconds, and copying that library to another took only 2.81
seconds, not much different than IEBGENER. This investigation
suggests that you should ALWAYS use NOCLONE when you are copying
within the same SAS platform; only if you are copying from one
platform to another would CLONE perhaps be required.
-But neither COPY nor IEBGENER support concatenated data libraries,
and the output dataset can NOT use DFSMS hardware compression nor
striping: either will create unreadable output that causes this
error when the SMS compressed/striped dataset is read:
ERROR 11 READING LIBRARY DATA SET x TO RETRIEVE LAAS
LIBRARY x IS NOT IN A VALID FORMAT FOR ACCESS METHOD
-PROC COPY to an SMS compressed dataset will cause a 213-B8 ABEND
for every SAS dataset in the library, then followed by error
ATTEMPT TO OPEN SAS DATA LIBRARY x FAILED
OPEN TYPE=J FAILED TO POSITION LIBRARY DATASET x TO VOLUME 1
-DFHSM MIGRATE/BACKUP can also be used to copy SAS data libraries,
and the recalled dataset will be readable by SAS.
Disk to tape copy - full library copy of all members:
-You must use PROC COPY if the library is to be used by SAS, or you
can use DFHSM to back up the library on tape, but you can NOT use
IEBGENER to copy a disk SAS data library to tape.
-Using IEBGENER to copy a disk SAS data library to tape doesn't
fail during writing, but reading the tape copy causes error:
LIBRARY x IS NOT IN A VALID FORMAT FOR ACCESS METHOD V9SEQ
4. SAS Note 45711. Reported for SAS 9.2, an intermittent ABEND or a
CPU loop can occur. Observed with ANALDB2R execution that had
produced reports correctly and successfully on z/OS, but then the
job went into a CPU loop that required manual cancellation.
3. SAS has opened a defect for LIBNAME using the VOLSER option. The
circumvention is to put single quotes around the VOLSER value, so
VOLSER='123456' syntax will resolve correctly. When the VOLSER
value is specified without those quotes, the error message is
ERROR: Libname OUTDD is not assigned.
ERROR: Error in the LIBNAME statement.
with no other clue that VOLSER is the culprit.
2. Use of the new JCL to execute the SAS PROC using MXGNAMES/CONFIMXG
generated this true error message
ERROR: INSUFFICIENT AUTHORIZATION
TO ACCESS SYS3.MXG.V3001.LOCAL.SOURCLIB(VMXGINIT).
but that DSNAME was not the culprit; the site's MXGNAMES had
%LET MXGUSER1=SYS3.MXG.V3001.LOCAL.SOURCLIB;
%LET MXGUSER2=XYZ.PERSONAL.SAS.SOURCE;
%LET MXGSOURC=SYS3.MXG.V3001.SOURCLIB;
%LET MXGFORMT=SYS3.MXG.V3001.FORMATS;
and it was actually the MXGUSER2= DSNAME for which this user didn't
have read access. With concatenated DSNAMEs, SAS (incorrectly?)
reports the DSNAME of the FIRST dataset in the concatenation as the
cause of the error, so if you get this error, just check ALL of the
DSNAMEs in the concatenation (and with MXG, check both the SOURCLIB
and SASAUTOS DDs, since SAS also doesn't include the DDNAME in its
error message.
1. SAS Version 9.3 REQUIRES SAS HOT FIX E80004, noted in the CHANGES
member, but the symptoms were not listed, and it impacts ALL SAS
platforms. The macro compiler fails with messages like these:
ERROR: EXPECTING A VARIABLE NAME AFTER %LET.
ERROR: SYMBOLIC VARIABLE NAME .... MUST BEGIN WITH A LETTER
OR UNDERSCORE.
ERROR: MACRO PARAMETER CONTAINS SYNTAX ERROR.
See SAS Problem Note SN43828 to install the Hot Fix.
VI.A. WPS Technical Notes.
1. Text
VII. CICS Technical Notes.
1. CICS SMF 110 Subtype 1 (CICSTRAN) records are created automatically
with OMEGAMON, as that product forces MNPER=ON for you.
VIII. Windows NT Technical Notes.
1. Text
IX. z/VM Technical Notes.
1. Text
X. Email notes.
1. Text
XI. Incompatibilities and Installation of MXG vv.yy.
1. Incompatibilities introduced in MXG 30.02 (since MXG 30.01):
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 VV.RR in MXG VV.RR+1:
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 30.yyy thru 30.001 are contained in member CHANGES.