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



Download 423.59 Kb.
Page4/5
Date conversion29.04.2016
Size423.59 Kb.
1   2   3   4   5

were too short.

Thanks to Matthew Chappell, Dept. of Transport Main Roads, Australia


Change 30.042 -SMF AUDIT REPORT. The existing _RPTID report in BUILDPDB

ANALID is significantly enhanced, and new variables are created

FORMATS in the PDB.SMFRECNT to provide more detail of counts and

IMACSMFF percentages of records and bytes in your SMF data. Each

VMACID obs summarizes an ID.SUBTYPE (described by new $MGSMFID

VMACSMF format), but records with Subsystem or Product Version

VMXGINIT (DB2A V10, CICSPROD TS4.2, RMF 1.12) are reported at that

Apr 14, 2012 level of detail. Plus, all obs have the min/max SMF time,

May 12, 2012 and any compressed records (DB2,CICS) are flagged!

May 28, 2012 -The temporary WORK.ID dataset is created and summarized

to create the PDB.SMFRECNT used for the report, and the

new variables increase its size, but it is temporary, so

only //WORK space is used. For BUILDPDB, the INCREASE in

work space required is 25 CYL per Million SMF records.

When %ANALID(PDB=SMF) is executed standalone, 60 CYL of

//WORK space is needed per Million SMF records.

That small increase in BUILDPDB is because the old ID

dataset was compressed by default when it should not

have been; compression doubled its size (due to the small

number of variables), but even the new ID is 9% larger if

compressed, so the COMPRESS=NO Dataset Option is used for

the WORK.ID dataset to minimize its space requirement.

-If work space is an issue, you can disable creation of

the WORK.ID dataset with %LET SMFAUDIT=NO in //SYSIN.

-The new Audit Report goes to PRINT by default, but it can

be redirected to ODS, on ASCII with this //SYSIN syntax:

%LET MACKEEP=%QUOTE(

MACRO _RPDBID

%ANALID(ODSTYPE=HTML,ODSPATH=E:,ODSFILE=ANALID.HTML);

%

);



%INCLUDE SOURCLIB(BUILDPDB);

or on z/OS, you would use this syntax:

%LET MACKEEP=%QUOTE(

MACRO _RPDBID

%ANALID(ODSTYPE=HTML,ODSPATH=MY.PDSE,ODSFILE=ANALID);

%

);



%INCLUDE SOURCLIB(BUILDPDB);

-You can also produce the SMF AUDIT REPORT directly from

an SMF file using:

%ANALID(READSMF=YES,PRINT=YES,PERCENTS=YES,PDBOUT=PDB)

to create all reports and the PDB.SMFRECNT dataset, and

additional arguments ODSTYPE=,ODSPATH=,ODSFILE= can be

specified on the %ANALID invocation for ODS/HTML output.

-VMACSMF was revised to create variable SUBSYSTEM for DB2,

CICS, MQ records (100-102,110,115-116), for 26's (JES2/3)

for 30s (JES3,TSO,STC,OMVS,etc.), for 6's (JES2/JES3/EXTW

PSF/PRINTWAY/CADI/BUNDLE/SAR/EXD), and PRODVERSION for

DB2 (V10), CICS (TS/4.2), RMF (ZV011300), and MQ (7.10).

This means that those variables are populated when the

IMACFILE/&IMACFILE exit is taken, so you can use them to

select those records by SUBSYSTEM/PRODVERSION either for

MXG processing, or if you want to write SMF records out

to a separate SMF file; see comments in IMACFILE.

-Format $MGSMFID maps IBM SMF ID numbers and Subtype to

describe each record/subtype. User SMF records will be

tabulated with just the ID and possibly subtype (if the

subtype flag is enabled in the USER record), but you can

create your own VALUE statements to be added to $MGSMFID

in the new IMACSMFF member in your tailoring library.

-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 ID 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.
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 DB2 variable QWHDRQNM can now contain an ipv6 address,

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

VMACDB2H right-most characters to be truncated. Change 22.196 in

Feb 29, 2012 2004 internally INPUT all of these variables as $128:

Mar 4, 2012 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 what permits MXG to

increase stored length without DASD increases when most

of the $128 are still blanks. Change 22.196 did provide

syntax to increase any of those variable's stored length.

Sometime after 2004, DB2 header variables QWHSLOCN and

QWHDSVNM, and non-DB2-header variables QLACLOCN QLSTLOCN

QMDALOCN QPACCOLN QPACLOCN QPACPKID were increased. This

change increases QWHDRQNM and these header variables

QWHCAID QWHCOPID QWHCEUID QWHCTCXT QWHCROLE

QWHCOAUD QWHCCV QWHDRQNM

and these two non-header variables

QPACASCH QPACAANM

to now be stored as $128.

Thanks to Fred Wondra, Balboa Insurance, USA.

Thanks to Mark Nakatani, WiPRO, 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, 20123 -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 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 these values provided by Cathy:

Feb 17, 2012 VALUE MG073FE

1='1:FEx OP@1Gbps'

2='2:FEx OP@2Gbps'

3='3:FEx2/FEx4 AUTO@1Gbps'

4='4:FEx2/FEx4 AUTO@2Gbps'

5='5:FEx4 OP@4Gbps'

7='7:FEx8 AUTO@2Gbps'

8='8:FEx8 AUTO@4Gbps'

9='9:FEx8 OP@8Gbps'

11='11:FEx8S AUTO@2Gbps'

12='12:FEx8S AUTO@4Gbps'

13='13:FEx8S OP@8Gbps'

;

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.
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.


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.

ITRM 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

Many 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.

-Support for all IPV6 addresses in TYPE119 datasets, using

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

the 39-character format. Some IPV6 addresses did exist in

variables with names ending in 6, but this new suite of

variable's names end with IPV6.

-Only these SMF 119 subtypes have been validated with data

1,2,3,5,6,7,10,20,21,70 and 72.

-The subtype 2 record has an old note suggesting that

Because this information duplicates all information

1   2   3   4   5


The database is protected by copyright ©essaydocs.org 2016
send message

    Main page