* copyright (C) 1984-2019 merrill consultants dallas texas usa

USER SMF record, but you can create your own description

of USER SMF record that will be added to $MGSMFID format

by using the IMACSMFF member in your tailoring library,

following it's comments for syntax of your USER records.

After you SAVE your IMACSMFF member into your tailoring

library, you then need to update the MXG format library

by running

//LIBRARY DD DISP=OLD

%INCLUDE SOURCLIB(FORMATS);

which will update the MXG Format Library.

If you can not update the site's format library, you

can create this new format in a separate dataset and

use OPTIONS FMTSEARCH=(MYLIB LIBRARY); in the ANALID job.

-Macro variable SMFAUDIT is defined in VMXGINIT.

-To summarize the overall options:

READSMF=YES read SMF, create WORK.ID or PDB.ID, create

PDB.SMFRECNT, delete WORK.ID or keep

PDB.ID.

READSMF=NO read WORK.ID/PDB.ID, create PDB.SMFRECNT,

delete WORK.ID or keep PDB.ID.

PRINT=ONLY read only PDB.SMFRECNT to print report.

-This rewrite of the _RPTID report was precipitated by:

The previously posted error that caused LARGE INCREASE

in elapsed run time when BUILDPDB had any output "PDB"

data libraries (//PDB, //CICSTRAN, //DB2ACCT, etc.) on

on tape or in sequential format.

That error is corrected in this change.

But, to document the error and a circumvention:
VERY long elapsed times in BUILDPDB if output PDB data

libraries (//PDB, //CICSTRAN, //DB2ACCT) are on TAPE:

PROC SQL reads the DICTIONARY.COLUMNS internal dataset,

but if any LIBNAME is on tape, the ENTIRE tape is read.

Site with 35 million CICSTRAN observations on tape took

3.5 hours to read SMF and then spend 3.1 hours in this

PROC SQL, just to create the report of ID counts; this

problem was introduced in MXG 29.03, Change 28.089.

If you do not have MXG 30.02 with this Change 30.042,

this Circumvention eliminates long elapsed times:

Insert this statement

%LET MACKEEP= MACRO _RPDBID _RPDBIDO % ;

in your //SYSIN DD input, or this macro definition

MACRO _RPDBID _RPDBIDO %

in your IMACKEEP tailoring member. This will revert

the SMF TYPE report to only count records.

-This change replaced PROC SQL with %VMXGOBS to correct

the elapsed run time error, and all other uses of PROC

SQL with DICTIONARY.COLUMNS have a specific LIBNAME, so

they had no exposure.

Thanks to Jim Hayes, Huntington National Bank, USA.

Thanks to Marty Pruden, Purina Nestle, USA.

Thanks to Michael Rhoades, Purina Nestle, USA.

Thanks to Michael Oujesky, Bank of America, USA.

Thanks to MP Welch, SAS Institute, USA.
Change 30.041 Support for EMC EzSM (z/OS Storage Manager) SMF record.

EXEZSM01 Preliminary support - problems in record have opened a

EXEZSM02 discussion with the vendor, but still no response when

EXEZSM03 MXG 30.02 was created.

EXEZSM04

EXEZSM05

EXEZSM06

EXEZSM07

IMACEZSM

TYPEEZSM

TYPSEZSM

VMACEZSM

VMXGINIT

Mar 7, 2012

Change 30.040 -Variable DOWNTM was a missing value in PDB.IPLS dataset

VMAC0 after Change 29.032 used only ID=90 ST=8/10 to identify

VMAC90A a true system IPL; the DOWNTM=IPLTIME-PREVTIME was not

VMACSMF calculated for subtype 10 and the operator entered DTIME

Mar 9, 2012 value was incorrectly used for the subtype 8 IPL PROMPT.

-Examination of events at a true IPL show that SMF records

0 8 22 90 are written prior to the IPL event, and ID 2,3

can be written on other systems at other times, so these

records are all NOT used to set PREVSYS/PREVTIME.

-VMAC90A was updated to contain DOWNTM and IPLTIME in the

TYPE9008 and TYPE9010 datasets, for consistency.

-Dataset PDB.IPLS was revised to contain the old variables

from the ID=0, even though it is created from ID=90/8-10.

Thanks to Jorge Fong, NYC Information Technology, USA.

Change 30.039 NDM-CDI record 'XO' caused "UNKNOWN SUBTYPE" log messages

VMACNDM because 'XO' was not in the test for supported subtypes,

Mar 6, 2012 but code was in place to output them in NDMDT dataset, as

it is the same record structure. Now, they are output.

Thanks to Betty Wong, Bank of America, USA.
Change 30.038 Support for DB2 IFCIDs 357 and 358; those datasets are

VMAC102 now populated with the IFCID-specific variables.

Mar 6, 2012

Thanks to Terry L. Berman, DST Systems, USA.

Change 30.037 Support for BMC APPTUNE V6R3 SMF 102 records (INCOMPAT).

VMAC102 These numeric variables were increased from 2 to 4 bytes

Mar 6, 2012 causing mis-alignment of all subsequent variables:

QBMCSCTN QBMCSTMT QBMCSOPN QBMCOPNN

and these two new variables are inserted and now input:

QBMCTXTH='SQL*TEXT*HASH'

QBMCIMPK='IMPLICIT*QUALIFIER*KEY'

and QBMCSQID QBMCIMPQ contain ASCII rather than EBCDIC.

BMC APPTUNE ID=102 IFCIDS are 8004x-800Bx & 8133x-8136x.

Only the 8133x record has been validated.

Thanks to Christa Neven, KBC, BELGIUM.
Change 30.036 On the first day of the month, the MTD value was

VMXGALOC calculated correctly but the MONTH value was the prior

Mar 2, 2012 month.

Thanks to Ruth Larsen, Computer Associates, USA.

Change 30.035 RSD/FOLDERS name fields were increased to $250, causing

VMACRSDA the AUDDNAME and other AUDDxxxx fields to be missing as

Mar 2, 2012 those fields were located after the AUDFxxxx variables.

Thanks to Christa Neven, KBC, BELGIUM.

Thanks to Marc Heremans, KBC, BELGIUM.
Change 30.034 VMXGGETM is used to select SMF records by ID and SUBTYPE,

VMXGGETM but only supported 512 subtypes; BMC's APPTUNE product

Mar 2, 2012 creates SMF 102 records with IFCIDS 8000x to 8136x which

caused VMXGGETM to fail with ARRAY ERROR. This change

increases the array to support 33078 (8136x) to protect

the BMC records, keeping the REGION size to about 84MB.

(VMXGGETM is also used in JCLTESTx to create SMFSMALL, so

I don't want new users to die with insufficient REGION in

their first MXG test job. Setting the array size to the

max possible 65536 for the two-byte field needed 150MB.)

Thanks to Christa Neven, KBC, BELGIUM.

Thanks to Wim Hermans, KBC, BELGIUM.

Change 30.033 Cosmetic. Missing value calculation for PHSTARTM when it

VMAC110 was missing is protected for ID=110 MNSEGCL=5 Resource

Mar 1, 2012 Record (dataset CICSRDS).

Thanks to Tom Buie, Southern California Edison, USA.

Change 30.032 -Stored LENGTH of QWHxxxxx variables now $128 in DB2ACCT.

VMACDB2 This text was re-written Mar 27, but no code was changed.

VMACDB2H These DB2 Variables are all now stored as LENGTH $128:

Feb 29, 2012 QLACLOCN QLSTLOCN QMDALOCN QPACAANM QPACASCH QPACCOLN

Mar 4, 2012 QPACLOCN QPACPKID QWHCAID QWHCCTKN QWHCEUID QWHCOAUD

Jun 8, 2012 QWHCOPID QWHCROLE QWHCTCXT QWHDRQNM QWHDSVNM QWHSLOCN

Oct 3, 2012 because IBM has increased those lengths (history below)

Mar 28, 2013 and now many of these variables do contain more than

eight bytes, especially if you have distributed systems

with those long open-system name fields.

But with the (MXG DEFAULT) COMPRESS=YES option enabled,

these stored lengths can be increased, so no data values

are truncated, without significant DASD space increase,

since most of those nine-plus bytes are still blank.

-However, you can change those lengths if, for example,

the CPU cost of compress is more expensive than the DASD

disk space cost. See NEWSLETTER SIXTY, Section VI.7,

in member NEWSLTRS for the complete documentation in

"Changing the length of MXG variables", which shows

this syntax can be used (only) for character variables.

//SYSIN DD *

%LET MACFILE=

%QUOTE( LENGTH

VAR1 VAR2 VAR3

$8 ;

);

%INCLUDE SOURCLIB(whatever);

Some History:

In 2004, IBM increased the length of several fields and

MXG Change 22.196 in 2004 increased INPUT to $128 for

QWHSLOCN QWHCAID QWHCOPID QWHCEUID QWHDRQNM QWHDSVNM

but that change noted that they were not stored as $128,

because in 2004 some MXG sites still had SAS V6 that did

not support COMPRESS=YES, which is required to increase

stored length without DASD increases (as most bytes are

still blanks).

Sometime after 2004, IBM increased header variables

QWHSLOCN and QWHDSVNM and MXG increased INPUT length.

MXG Change 24.136 in 2006 increased these INPUTs to $128

QWHCAID QWHCOPID QPACCOLN QPACLOCN QPACPKID

QLACLOCN QLSTLOCN QMDALOCN QWACNID

This change, 30.032 increased these INPUTs to $128

QWHCEUID QWHCTCXT QWHCROLE QWHCOAUD QWHDRQNM

QPACASCH QPACAANM

This change, 30.032 increased the stored lengths of all

of the DB2 variables listed above that were not already

kept as $128.

-Note added Jun 8: Some DB2 fields can contain an IP

address, Port Number, and a timestamp in this format:

162.123.25.218.44485.120605112901

-------------- ----- ------------

| | |

| | |-- Unique field ( timestamp real

| |

| |-- Port address

|

|- Requester IP Address

One example is QWHCCTKN the new Correlation Token in V10.

-Note added Oct 3, 2012: QWHCCV was restored to $12 by

Change 30.200.

-DB2 variable QWHDRQNM can now contain an ipv6 address,

which is longer than the default kept $16 length, causing

right-most characters to be truncated. Change 22.196 in

Thanks to Fred Wondra, Balboa Insurance, USA.

Thanks to Mark Nakatani, WiPRO, USA.

Thanks to Jim Meurer, Transamerica, USA.
Change 30.031 Requesting IFCIDS=ACCOUNT with IFCIDS from SMF 102 could

READDB2 cause zero observations in some or all of the T102Snnn

VMXGDEL datasets that were requested. This error was in 29.29

Feb 24, 2012 and probably earlier MXG READDB2s.

Mar 4, 2012 -Cosmetic. READDB2 accepts IFCIDS=1 or 2 for STATISTICS

and 3 for ACCOUNT and prints all selected IFCIDS in its

feedback list of what will be selected by READDB2.

Requesting ACCOUNT processes IFCIDs 3 and 239.

Requesting Statistics processes IFCIDs 1 2 202 225 230.

-A strange compiler error, only in SAS V9.2, inserted a

blank when MACRO _LDB2PAT &PDBOUT..DB2GBPAT % was at the

bottom of that list of macro definitions, causing compare

of WORK .DB2GBPAT with WORK.DB2GBPAT to be different, so

VMXGDEL incorrectly deleted that dataset. Relocating that

one line to the top of the list of MACROs happened to

circumvent the error, but that was far too fragile, since

another line relocation could reinstate the error, and as

VMXGDEL is the only part of MXG that does exact compares

of dataset macro tokens that could be impacted by a blank

after the DDNAME/LIBNAME, it now removes the blank.

Thanks to Christopher Bray, Experian Information Solutions, USA.
Change 30.030 Variable VMDSTATE is now decoded by $MGVXADS format.

FORMATS VALUE $MGVXADS

VMACVMXA '00'X='00X:IDLE'

Feb 23, 2012 '08'X='08X:SUSPENDED'

'2C'X='2CX:UNKNOWN'

'37'X='37X:TEST IDLE'

'42'X='42X:READY FOR SELECTION'

'4D'X='4DX:SELECTED FOR PROCESSING'

'58'X='58X:REVIEW IDLE'

'63'X='63X:REVIEW SUSPENDED'

OTHER=?< $HEX2. ?>

;

Thanks to Joseph J. Faska, Depository Trust, USA.

Change 30.029 ODS macro enhanced with USERTEXT= argument so you can add

VMXGODSO options to the generated ODS statement.

Feb 23, 2012
Change 30.028 RMF III dataset ZRBASI Report Class Name/Description vars

VMACRMFV ASIRNM and ASIRDE can have hex zero values, because IBM

Feb 23, 2012 relocated the fields; SVPDCL is now 144 vs the documented

and expected length of 76. Now, ASIRNM is tested for hex

zero and the INPUT moved when found true.

-Same change made for ZRBENC for ENCRNM and ENCRDE.

Change 30.027 Variable SM1209BM, WebSphere Version Number, defaulted to

VMAC120 length $7 from the original equation, but as it can now

Feb 22, 2012 have a value of '7.0.0.15', its length is now set to $8.

Thanks to Rudolf Sauer, T-Systems International GmbH, GERMANY

Change 30.026 %UTILCPLG will copy your .LOG and .LST files, adding the

UTILCPLG date-time into the new file name, when you run MXG on

Feb 17, 2012 Windows or Unix platforms in BATCH execution, so you can

archive and identify each MXG job's log/list files.

The %UTILCPLG; statement must be the last statement in

your xxxxxxxx.sas batch program; the log filename will be

xxxxxxxx-16FEB12-19-51.LOG. The new named files are kept

in the execution directory by default, but arguments let

you store them in other destinations.

Thanks to Chip Parsons, Ingram Books, USA.

Change 30.025 Support for TMON for MQ Version 2.2/2.3/2.4 INCOMPATIBLE.

VMACTMMQ All three version's LMRKVRSN field changed from binary to

Feb 16, 2012 EBCDIC. Version 2.4 changed the fixed offset of @37 to

Feb 24, 2012 @81 but that was NOT documented. The actual data segments

Mar 1, 2012 content was not changed in these three iterations, and

Mar 5, 2012 only Version 2.2 and 2.4 have been validated with data.

-ASG TMON for MQ variables REGNTIME,QAINTS,QAINTE,QAOPENTM

and QACLOSTM were all on the GMT clock, while all other

datetimestamps are on the LOCAL clock. This change uses

the ENDTIME (LOCAL) and the REGNTIME (GMT) to calculate

the GMT offset (REGNTIME can be scores of milliseconds

later than ENDTIME due to differing resolutions):

GMTOFFTM=100*FLOOR((REGNTIME-ENDTIME+10)/100);

and then the GMT datetimes are converted to LOCAL using

REGNTIME=REGNTIME-GMTOFFTM;

-The label for REGNTIME was wrong; it is corrected to be:

REGNTIME='DACLK*WHEN RECORD*WAS WRITTEN'

Thanks to Homayoun Riazi, UHC, USA.

Thanks to Paul Volpi, UHC, USA.

Thanks to Michael Ellingson, UHC, USA.

Thanks to James D. Lieser, UHC, USA.
Change 30.024 New format MG073FE decodes SMF73GEN and R79CGEN FICON

FORMATS Express "Generation", precipitated by Martin's MXG-L post

VMAC73 and Pat's update request and Brian's reminder to include

VMAC79 79's, with some values below provided by Cathy.

Feb 17, 2012 Dec 2: IBM confirmed reports print the hex value, so MXG

Nov 5, 2012 now formats SMF73GEN as hex to be consistent with that

Dec 2, 2012 undocumented-by-IBM design, but RMF Level 2 has NOT been

able to document if any of the unknown values below exist

01X='01X:FEX OP@1GBPS'

02X='02X:FEX OP@2GBPS'

03X='03X:FEX2/FEX4 AUTO@1GBPS'

04X='04X:FEX2/FEX4 AUTO@2GBPS'

05X='05X:FEX4 OP@4GBPS'

06X='06X:????'

07X='07X:FEX8 AUTO@2GBPS'

08X='08X:FEX8 AUTO@4GBPS'

09X='09X:FEX8 OP@8GBPS'

0AX='0AX:????'

0BX='0BX:????'

0CX='0CX:????'

0DX='0DX:????'

0EX='0EX:????'

0FX='0FX:????'

10X='10X:????'

11X='11X:FC_S'

12X='12X:????'

13X='13X:FC_S*FICON EXPRESS8S'

Nov 5: Decimal value 17 and 19 were found by IBM's Martin

Packer although others in IBM support are apparently not

aware of those undocumented values.

Dec 2: APAR OA40204 reports 'FC_?' or blank value may be

printed for channels dynamically added; restart of the

RMF address space will correct to FC_S.

Dec 11: IBM RMF Level 2 confirmed that RMF reports show

value '13' unexplained for FICON Express 8S so the MXG

format was expanded to include that descriptions in the

FORMATS member and above.

Thanks to Dr. H. Pat Artis, Performance Associated, USA.

Thanks to Brian Currah, Independent Consultant, CANADA.

Thanks to Martin Packer, IBM, ENGLAND.

Thanks to Cathy Cronin, IBM, USA.

Thanks to Linda Berkeley, DISA, USA

Change 30.023 A third-party product creates invalid DB2 ID=101 records.

VMACDB2 MXG's error message cites 1994's Change 12.220 and APARs,

VMACSMF because IBM made the same error (IFCID=239 as subtype 0

Feb 14, 2012 versus correct subtype=1) back then. This change reads

the DB2 Header and uses the IFCID to set the SUBTYPE for

ID=101 to circumvent the product's error, so the customer

won't have to wait for their vendor to fix their record.

The error occurs in both DB2 V9.1 and DB2 V10.1 records;

in V10.1, IBM (finally!) populates the first byte of the

SMF header for ID=100/101 with the "record has subtypes"

bit, but that enhancement was not made in this product.

The MXG customer chose to not identify the third-party.

March 7: MXG customer reports vendor corrected the error.

But this change is robust and will be left in place.

July 27: See Change 30.137. This change was NOT robust!
Change 30.022 Cosmetic. Format $MGDB2PK was associated with variable

VMACDB2 QPACAAFG but was lost in 29.29 and 30.01. It is restored

Feb 14, 2012 now but FORMAT QPACAAFG $MGDB2PK.; can be used in your

DB2 reports to "print pretty".

Thanks to Matthew Chappell, Dept. of Transport Main Roads, AUSTRALIA
====== Changes thru 30.021 were in MXG 30.01 dated Feb 13, 2012=========
Change 30.021 -Numerous updates for processing RACF Unload under ASCII.

EXRAC130 Variables input as $EBCDIC should have been $CHAR in 0500

EXRAC207 and later records; double-question-mark protection for

EXRAC208 missing values has been added.

EXRAC280 -New ACCOUNT variable is created in RACF0220 and RACF0260

EXRAC2B0 as length $40 containing both ACCOUNT1 and ACCOUNT2.

EXRAC508 -Structural support for new RECTYPE values defines all the

EXRAC5B0 macros and creates/updates the members to create datasets

IMACRACF for 0130,0207,0208,0280,02B0,0508 and 05B0, but in this

VMACRACF iteration, none of those records are yet decoded; only

VMXGINIT variable ZDATE is kept in those new datasets.

Feb 12, 2012

Thanks to Matthew Chappell, Dept. of Transport Main Roads, AUSTRALIA
Change 30.020 Support for MacKinney Systems VTAM SWITCH USER SMF RECORD

EXVTSW01 creates these four datasets:

EXVTSW02 DDDDDD DATASET DESCRIPTION

EXVTSW03

EXVTSW04 VTSW01 VTAMSW01 USER SIGNON EVENT

IMACVTSW VTSW02 VTAMSW02 USER SIGNOFF EVENT

TYPEVTSW VTSW03 VTAMSW03 SESSION START EVENT

TYPSVTSW VTSW04 VTAMSW04 SESSION STOP EVENT

VMACVTSW This support has not yet been data-validated.

VMXGINIT

Feb 10, 2012

Thanks to Eric R. Carlson, Kroger

Change 30.019 Cosmetic. Both members incorrectly had RACFIN as the DD

TYPERACF name, but the correct DDNAME was always IRDBU00 to read

TYPSRACF the unloaded RACF Database, as that is also the program

Feb 10, 2012 name used to create the unloaded file.

Thanks to Donald Williams, UNC Health Care System, USA.
Change 30.018 -Cosmetic, but confusing. The label for TYPE4224 variable

VMAC42 AORMEMNM contained "RENAMED" but the corrected label and

Feb 9, 2012 events are AORMEMNM='ADDED OR*REPLACED*MEMBER*NAME'.

-New variable ADDREPLA contains A or R for ADD/REPLACED.

-Dataset TYPE4225 is created for RENAMEs.

Thanks to Joe Kimberly, Yellow Freight, USA.

Change 30.017 MXG 29.29 ITRM. ERROR: DATASET DB2ST225 IS NOT SORTED.

DOC ITRM SAS Note 45583 documents the error and ultimate fix,

Feb 9, 2012 but it is circumvented, simply, by inserting

%LET EPDBOUT=_SDB2225;

as the first statement in your //SYSIN DD.
Change 30.016 RMF III dataset ZRBLCP did not remove duplicates when it

VMACRMFV was sorted; variables LPARNAME LPARNUM LCPUADDR were

Feb 8, 2012 added at the end of MACRO _BZRBLCP to correct.

Thanks to Wayne Bell, UniGroup, USA.

Change 30.015 MXG 29.29. JCL Proc examples had a trailing comma on the

MXGSAS new (unused, for the future) //MXGTEMP DD statement that

Jan 24, 2012 needed to be removed.
Change 30.014 -Support for APAR OA33947/OA339448 which adds four fields

ASUMTAPE to the TYPE21/PDB.TAPES (tape dismount) dataset:

VMAC21 SMF21MCR='BYTES*READ*BY*CHANNEL'

Feb 8, 2012 SMF21MCW='BYTES*WRITTEN*BY*CHANNEL'

SMF21MDR='BYTES*READ*BY*DEVICE'

SMF21MDW='BYTES*WRITTEN*BY*DEVICE'

-ASUMTAPE was enhanced to also add these four variables,

plus SMF21CRR and SMF21CRW to PDB.ASUMTAPE.

-These fields exist with the APAR (record is longer), but

they are only populated for IBM System Storage TS1140

Tape Drive, device type 3592 Model E07, which has three

new 3592 media types (MEDIA11/12/13) and two new

recording formats EFMT4 (enterprise format 4) and EEFMT4

(enterprise encrypted format 4). MEDIA11/MEDIA12 have a

non-compressed capacity of 4000 GB and MEDIA13 500 GB.

Thanks to Scott S. Throckmorton, SPRINT, USA.

Thanks to John A. Napuarno, SPRINT, USA.
Change 30.013 If you specified RUNWEEK=YES on zOS you may have gotten

BLDSMPDB an MXGWARN message about overlaying weekly datasets. If

Feb 8, 2012 you are using fixed allocations for your weekly datasets

this is normal and can be ignore but, if you are using

GDGs (recommended) and/or putting the weekly to tape it

is not needed. BLDSMPDB now looks (on zOS) to see if

you specified WEEKTAPE=YES or are writing to a GDG and

then suppresses the copying of the weekly PDBs.

Thanks to Peter Farrell, Commerce Bank of Kansas, USA.
Change 30.012 Cosmetic. Removal of the annoying and useless SAS note

VGETOBS RUN STATEMENT HAS NO EFFECT ON PROC SQL, by the insertion

Feb 8, 2012 of a QUIT statement after each PROC SQL. Members touched:

VGETFMT VGETLABL VGETLEN VGETLIBS VGETOBS VGETVAR

VMXGCNFG VMXGDSNL VMXGENG VMXGLBIN VMXGOPTR VMXGPPDS

VMXGUOW ANALID

Thanks to Nick Johns, Sainsbury's Supermarkets Ltd, ENGLAND.
Change 30.011 CRITICAL ERRROR FOR JES3 BUILDPD3 users with MXG 29.29:

BUIL3005 Line 483 in BUIL3005 MUST BE CHANGED TO (MULTIDD=' ').

Feb 8, 2012 That line in 29.29 had MULTIDD='Y' which caused the PDB

library datasets PDB.JOBS/PDB.STEPS/PDB.PRINT to all be

COMPLETELY WRONG. Change 29.263 correctly made the change

to the BUILD005 member for JES2 but was reversed in the

JES3 BUIL3005 member.

Thanks to Rob Hermes, Sentry Insurance, USA.

Change 30.010 Variable STFBIT06 was incorrectly set equal to STFBIT05.

VMAC7072 Variable STFBIT07='SMF70GAU*VALID?' is created and kept.

Feb 8, 2012

Thanks to Karl Lasecki, Chemical Abstracts Service, USA.

Change 30.009 -Support for SMF 119 Subtype 6 z/OS 1.13 INCOMPAT. Doesn't

VMAC119 cause an error, but values in 2nd and subsequent segments

VMXGIPV6 are trashed because MXG did not protect for a change in

Jan 31, 2012 length of the subtype 6 record.

Feb 7, 2012 -Subtype 2 TTAPLDAT variable supported.

Jul 12, 2012 -Support for all IPV6 addresses in TYPE119 datasets, using

the VMXGIPV6 %macro to convert the $CHAR16 hex field into