input records it required 862MB to create the format
and nearly as much to load it. But, the only time you
might need all of the records is when you are running
an IO trace. In the case of an Audit trace, you have
to build an Audit table to tell DB2 which things you
want to audit. So, selection criteria for DBNAME and
OBNAME are added to ANALDB2R to reduce the volume of
records input to VFMT102. You can select based on:
SYSTEM DB2 DBNAME and OBNAME
By selecting only the needed DBNAMEs, the virtual storage
needed for the format was less than 50 MB, so selection
is ALWAYS wise to do.
In addition, SYSTEM (z/OS execution system) is added as a
criteria for ALL ANALDB2R reports (DBNAME and OBNAME are
only available to VFMT102 datasets with DBID or OBID).
Don't know what DBNAME/OBNAME(s) you have? New report
MXGDBIDS=ONLY provides the list of all combinations
of SYSTEM QWHSSSID (DB2 SUBSYSTEM)DBNAME OBNAME using:
%ANALDB2R(PDB=SMF,MXGDBIDS=ONLY);
RUN;
-Unrelated, new parameter MXGACC01OUT creates an output
dataset that you name in that parameter from the MXGACC01
PROC TABULATE.
Change 30.240 Graphic and tabular reports of DB2 buffer size and max
GRAFDB2B usage, by DB2 Subsystem and Buffer Pool. Will use either
NOV 10, 2012 SAS/GRAPH or ODS GRAPHICS for graphs and PROC TABULATE to
create a tabular report.
Documentation of parameters:
PDB=PDB One or more PDB DD NAMES (LIBNAMEs)
SASGRAPH=NO Create bar charts with SAS/GRAPH
ODSGRAPH=YES Create bar charts with ODS Graphics
TABULATE=NO Create a tabular report
INTERVAL=QTRHOUR Any valid interval value
SAS versions 9.2 and earlier will not work for ODS; 9.3
is required for ODS graphics. If you are at 9.2 and don't
specify SASGRAPH=YES, the tabulate report will be created
instead. If you specify SASGRAPH=YES but it is not
installed, on SAS 9.3 or above, ODS GRAPHICS are used.
Otherwise, only the PROC TABULATE report is created.
Change 30.239 -VMACIMS IMS Eyecatcher variables STREQxxxx had $HEX40.
VMACIMS format but were correctly input as $EBCDIC4; the format
VMACRMFV and listing in NOTRAN were removed. Purely cosmetic.
VMAC120 -VMACRMFV variable ASMVER00 is now correctly INPUT $CHAR1
Nov 10, 2012 instead of $EBCDIC1 as it contains HEX text characters.
-VMAC120 variable SM1209GS is now correctly INPUT $CHAR8
instead of $EBCDIC1 as it contains HEX text characters.
(Note: $CHARn is REQUIRED only for MXG execution on ASCII
platforms - on z/OS $CHAR and $EBCDIC are identical.)
Change 30.238 Support for Phoenix Software International (E)JES SMF
EXTYEJES Accounting Record creates new EJESSMF dataset. MXG reads
IMACEJES either the unique date format for ESMFTBGN or, after
TYPEEJES EJES/14242 update, in (E)JES V5R3, the SMFSTAMP format,
TYPSEJES transparently.
VMACEJES New dataset:
VMXGINIT dddddd dataset description
Nov 11, 2012 TYEJES EJESSMF (E)JES SMF ACCOUNTING
Thanks to Mike Moyne, HHSYS, USA.
Change 30.237 Support for Version 4.3.0 BETA93/BETA97 (INCOMPATIBLE).
EXTYB97M -BETA93: New variables added to BETA1 dataset:
EXTYB97N BETAATYP='SEND*AS'
EXTYB97O BETABODY='BODY*TEMPLATE*MEMBER'
EXTYB97P BETABTYP='OUTPUT*TYPE'
EXTYBET7 BETABUFS='MAXIMUM*BUFFER*SIZE'
EXTYBET8 BETADCR ='DCR*NAME'
EXTYBETH BETAFILE='MAIL*FILE*NAME'
EXTYBETI BETAFROM='MAIL*FROM'
FORMATS BETAIPAD='IP*ADDRESS'
IMACBE97 BETALINK='LINK*TEMPLATE*MEMBER'
IMACBETA BETALTKN='LTOKEN*LIST*TOKEN'
VMACBE97 BETAMAXA='MAXIMUM*MAIL*ADDRESSES'
VMACBETA BETAPORT='PORT*NUMBER'
VMXGINIT BETARPLY='MAIL*REPLYTO'
Nov 13, 2012 BETASEXT='SOURCE*EXTENSION*NAME'
BETASFRM='SOURCE*FORM*NAME'
BETASUBJ='MAIL*SUBJECT'
BETATRMD='TRANSLATION*MODULE'
BETATRTB='TRANSLATION*TABLE'
-BETA93: New $MGBETPT format maps these values of BETAPTYP
in BETA1 dataset, which describes which of the sets of
variables exist in this record:
'80'X='80X:DCR OF TYPE SYSOUT'
'40'X='40X:DCR OF TYPE MAIL'
'20'X='20X:DCR OF TYPE CLIST'
'10'X='10X:PRE-ALLOCATED DD NAME'
'08'X='08X:DCR OF TYPE VTAM/APPC'
'04'X='04X:DCR OF TYPE SUBSYS'
'02'X='02X:DCR OF TYPE TCP/IP'
-BETA93: New Subtypes 7, 8, and 22 are documented but only
the header variables exist in the new BETA7 BETA9 BETA22
datasets until actual records are available.
-BETA93: New Subtype 49 creates BETA49 dataset for Batch.
-BETA97: New Subtype 25 creates BETA9725 dataset.
-BETA97: New Subtype 50 creates BETA9750 dataset.
-BETA97: New Subtypes 49 and 51 create BETA0751 but only
header variables are created, awaiting test records.
Thanks to Mrs. Karen Sendelback, Finanz Informatik, GERMANY.
Change 30.236 Cosmetic, spurious messages. TYPE113 processing printed
VMAC113 messages ERROR: DEACCUMULATION DETECTED RESET when HIS
Nov 8, 2012 sampling was enabled for one minute every five minutes,
because MXG did not use the SM113CF1 Start of Interval
flag to bypass the test for negative deltas that printed
these messages. However, both TYPE113 and ASUM113 were
correctly created because MXG's test for the output did
work as designed. Now, SM1113CF1 flag is used to bypass
the creation of these messages.
Thanks to Erling Andersen, SMT Data A/S, DENMARK.
====== Changes thru 30.235 were in MXG 30.08 dated Nov 7, 2012=========
Change 30.235 Variable CFWAITTO='TOTAL CF*CPU*WAIT TIME' is created in
VMAC74 dataset TYPE74CF as the SUM OF(CFWAIT01-CFWAIT15) to
Nov 7, 2012 match existing CFBUSYTO total CPU busy time.
Thanks to Joseph J. Faska, Depository Trust, USA.
Change 30.234 First MXG 30.08, zEC12 ONLY, and ONLY with APAR OA37826,
VMAC74 which added the HO segment to the RMF 74 subtype 4 record
Nov 7, 2012 ERROR: INVALID DATA FOR CHAR4
INPUT STATEMENT EXCEEDED RECORD LENGTH.
because that code was only syntax checked, awaiting data
with that APAR installed, and CHAR4/ passed syntax but
failed when data was read, as it should have been CHAR4.
Thanks to Jim Horne, Lowe's, USA.
Change 30.233 -TYPE70 variable CPUWAITM was wrong and was larger than
ADOC7072 CPUUPTM when HiperDispatch was active (SMF70PAT GT 0) but
VMAC7072 IRD was not active (SMF70ONT=DURATM for all engines).
Nov 7, 2012 MXG did not subtract parked time from CPUWAITM, BUT ONLY
Apr 1, 2013 CPUWAITM was wrong, and since CPUWAITM is NOT used in any
other metrics, they WERE correct. Only if you compared
CPUUPTM with CPUWAITM would the error have been observed.
This error was only significant at low utilizations when
CP engines were parked; during peak intervals when all CP
engines were NOT parked, the CPUWAITM value was correct.
-But in examining the 70 records, observations in TYPE70PR
have been found with SMF70PAT greater than SMF70ONT and
DURATM by over 5 seconds; new code detects and resets
SMF70PAT to SMF70ONT and zeros CPUWAITM when a small
negative value (less than 0.10 seconds) is calculated.
So both NEWWAIT and SMF70PAT in TYPE70PR are different.
RMF development has confirmed that because ONT and PAT
are retrieved independently with DIAGNOSE instructions,
the can have different values, and RMF Reports use the
same heuristic I implemented, to store ONT in PAT when
PAT is greater than ONT.
-Inserted Apr 2013: A "WARNING. SMF70PAT GT ONT" message
was previously printed, but since there is nothing that
you can do with that information, as of MXG 31.02, it is
no longer printed.
-Variable CPUUPTM is now documented in ADOC7072:
"Originally the CPU "UP" duration for calculation of
available capacity of all CP engines, and was the
product of NRCPUS*DURATM, but that was back when the
number of CP engines were static, at least between
IPLs. Now, with IRD and HiperDispatch "varying" or
"parking" engines, NRCPUS is the AVERAGE (and
fractional) number of CP engines that were ONLINE
during this interval, i.e., that that were made
available to this z/OS system during this interval, so
the CPUUPTM=NRCPUS*DURATM now will vary and it is no
longer the "available for static capacity" up time."
Thanks to Mark Cohen, EPVTECH, ITALY
Change 30.232 Hiperdispatch introduces some vagaries into percent CPU
GRAFWRKX measurements. PCTCPUBY in RMFINTRV is calculated based
Nov 6, 2012 on the average number of CPUs online but that may be
something less than the actual number of CPs assigned
to the LPAR. GRAFWRKX now produces 3 different CPU busy
by workload charts.
% of the average number of CPUs online
% of the CPUs assigned to the LPAR
% of the LPAR SHARE (this can exceed 100% if an LPAR
is 'stealing' from other LPARs.)
Thanks to Mark WIlliams, Marks and Spencer
Change 30.231 -Support for IFCID 219 populates existing T102S219 dataset
VMAC102 with new QW0219xx IFCID-specific variables.
Nov 5, 2012 -Support for IFCID 220 populates existing T102S220 dataset
Nov 8, 2012 with new QW0220xx IFCID-specific variables, but there are
discrepancies between the IBM DSECT and the actual DATA
and a PMR is opened with IBM to resolve. See Ch 33.064.
-Support for IFCID 402 populates existing T102S402 dataset
with new QW0402xx IFCID-specific variables, but IFCID 402
is a statistics interval record with accumulated values,
so you MUST invoke TYPS102 or use %READDB2 with PDBOUT=,
or invoke _S102402 after dataset T102S402 is created, to
do the deaccumulation. And unlike the other DB2 V10
interval statistics records, IFCID=402 is written at 15
minute instead of 1 minute intervals.
-Support for 4TH Waiter in T102S196 dataset added Nov 8.
====== Changes thru 30.230 were in MXG 30.08 dated Nov 5, 2012=========
Change 30.230 Variables LPnPAT were missing in PDB.ASUM70PR,PDB.ASUMCEC
VMXG70PR (but SMF70PAT parked time was valid in PDB.ASUM70LP and
Nov 3, 2012 PDB.ASUMCELP datasets). The LPnPAT variables were not in
the RETAIN statements for the two datasets, so they have
always been missing; this is not a new error!
Thanks to Wayne Bell, UniGroup, USA.
Change 30.229 Support for DB2 NETEZZA Optional data has been read and
IMACDBNZ some corrections were made in the DB2STATS/DB2NETZA.
VMACDB2 -These DB2STATS variables
Nov 2, 2012 Q8STSCPU Q8STSELA Q8STTCPU Q8STTELA Q8STACPU Q8STAELA
were not divided by 4096.
-These DB2STATS variables
Q8STACTV Q8STCCPU Q8STWCPU Q8STQUEM
were incorrectly de-accumulated.
-The Q8AC triplet was incorrectly input, causing all of
the Q8ACxxxx variables in DB2ACCT (when enabled by the
removal of the comment block in IMACDBNZ) to be wrong.
And, the Q8ACNAME field is now INPUT and populated.
IBM DB2 Analytics Accelerator IDAA uses Netezza.
Thanks to Victoria Lepak, Aetna, USA.
Thanks to William E. Howard, Aetna, USA.
Change 30.228 Support for CICS/TS 5.1, INCOMPATIBLE CHANGES, INSERTS.
UTILEXCL -CICSTRAN has new fields inserted at the end of each
VMAC110 segment. The RMI fields that were formerly optional
Dec 30, 2011 are now created by default. CMODIDNT
Apr 25, 2012 TDILWTTM='TDILWTT*DURATION' 403
May 28, 2012 TDILWTCN='TDILWTT*COUNT' 403
Sep 25, 2012 TDELWTTM='TDELWTT*DURATION' 404
Oct 15, 2012 TDELWTCN='TDELWTT*COUNT' 404
Nov 1, 2012 ROMODDTM='ROMODDLY*DURATION' 348
ROMODDCN='ROMODDLY*COUNT' 348
SOMODDTM='SOMODDLY*DURATION' 349
SOMODDCN='SOMODDLY*COUNT' 349
ISALWTTM='ISALWTT*DURATION' 319
ISALWTCN='ISALWTT*COUNT' 319
TCALWTTM='TCALWTT*DURATION' 343
TCALWTCN='TCALWTT*COUNT' 343
SOCIPHER='SOCIPHER*COUNT' 320
CECMCHTP='CECMCHTP*NAME' 430
CECMDLID='CECMDLID*NAME' 431
MAXTASKS='MAXTASKS*COUNT' 433
CURTASKS='CURTASKS*COUNT' 434
SC64CGCT='64-BIT*C*GETMAINS' 441
SC64CHWM='64-BIT*C*STORAGE*HWM' 442
SC64UGCT='64-BIT*USER*STORAGE*GETMAINS' 443
SC64UHWM='64-BIT*USER*STORAGE*HWM' 444
SC64SGCT='64-BIT*SHARED*GETMAINS' 445
SC64GSHR='64-BIT*SHARED*BYTES*GETMAINED' 446
SC64FSHR='64-BIT*SHARED*BYTES*FREEMAINED' 447
TASZIPTM='TASK*ZIP*CPU*TIME' MXG-Created
TASELGTM='TASK*ZIP*ELIGIBLE*CPU TIME' MXG-Created
CPUTONTM='TASK*TOTAL*CPU TIME*ON ZIP' 436
CPUTONCN='TASK*TOTAL*DISPATCHES*ON ZIP' 436
OFFLCPTM='TASK*ZIP*ELIGIBLE*RAN ON ZIP*CPU TIME' 437
OFFLCPCN='TASK*ZIP*ELIGIBLE*RAN ON ZIP*DISPATCHES' 437
ACAPPLNM='APPLICATION IN*APPLICATION*CONTEXT*DATA' 451
ACPLATNM='PLATFORM IN*APPLICATION*CONTEXT*DATA' 452
ACMAJVER='MAJOR VERSION IN*APPLICATION*CONTEXT*DATA'453
ACMINVER='MINOR VERSION IN*APPLICATION*CONTEXT*DATA'454
ACMICVER='MICRO VERSION IN*APPLICATION*CONTEXT*DATA'455
ACOPERNM='OPERATION IN*APPLICATION*CONTEXT*DATA' 456
MPPRTXCD='MPPRTXDC' 449
FCXCWTTM='WAIT TIME*FOR EXCLUSIVE*VSAM CI' 426
FCXCWTCN='WAIT COUNT*FOR EXCLUSIVE*VSAM CI' 426
FCVSWTTM='WAIT TIME*FOR*VSAM*STRING' 427
FCVSWTCN='WAIT COUNT*FOR VSAM*STRING' 427
-TASCPUTM has always included the CPU time on zIIP/zAAPs,
and thus can EXCEED the elapsed time when the specialty
engine is faster than the CP engines, as documented in
Change 29.076, and because previously the TASZIPTM was
not separately recorded in CICSTRAN. Even though 5.1 DOES
have the separate field, I chose to NOT change TASCPUTM,
even though that is inconsistent with the "normal" MXG
implementation of keeping the CP and zIIP/zAAP times in
separate variables, because it seemed changing the value
in TASCPUTM would have caused more impact to you.
-CICSTRAN fields not created in 5.1 (are missing values)
DB2WAITM/DB2WAICN 189
J8CPUTM/J8CPUCN 260
J9CPUTM/J9CPUCN 267
MAXJTDTM/MAXJTDCN 277
CBSRVRNM 311
EJBSACCT 312
EJBSPACT 313
EJBCRECT 314
EJBREMCT 315
EJBMTHCT 316
EJBTOTCT 317
MLXSSCTM/MLXSSCCN 411 (not documented as gone by IBM)
-CICSTRAN fields in 5.1 that have altered meaning:
These fields now include the new GET64 CONTAINER and the
PUT64 CONTAINER data values:
PGGETCCT 323
PGPUTCCT 324
PGGETCDL 326
PGPUTCDL 327
PGCRECCT 328
-CICSEXCE dataset has two new values of EXCMNRIX of
GUDSA - Wait for GUDSA Storage
GSDSA - Wait for GSDSA Storage
-CICS Statistics Interval now defaults to 1 hour versus 3.
-CICLDG variables added:
LDGLLRRO='LIBRARY*LOAD*REQUESTS*RO TCB'
LDGLLTRO='TOTAL*LOADING*TIME*RO TCB'
-CICM variables added:
MNGCECTP='CEC*MACHINE*TYPE'
MNGCECID='CEC*MODEL*NUMBER'
-New STID=62, same as STID=60, outputs CICDS dataset.
Eighteen TCBs exist in TS/5.1, but none are new. The MXG
TCB variables in CICDS dataset all have the two-character
"TCB Name" text in their labels, and the MXG variable's
suffixes (DSG, DS1, DS2 ... for QR, RO, CO ...) are
listed in this table mapping the IBM 5.1 TCB Numbers:
TCB Name: QR RO CO SZ RP FO SL SO SP EP TP D2 S8 L8 L9 X8 X9 T8
IBM TCB NR: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
MXG Suffix: G 2 3 4 5 6 7 8 H M N D B A I J K L
-STID=101 adds two new variables to dataset CICWBG:
WBGATOMS='ATOMSERVICE*REQUESTS'
WBGJVMSV='JVMSERVER*REQUESTS'
Change 30.227 Documentation updates, to give better examples of how to
ADOCRMFI define workloads in RMFINTRV.
UTILWORK
Oct 31, 2012
Change 30.226 -Support for AIX/LINUX NMON data with FRENCH language text
VMACNMON and with fractional numbers with commas instead of the
Nov 1, 2012 expected period, found (so far ONLY) in "BBBP" records.
-Support for MEMAMS Memory Object adds MSxxxxxx variables
to the NMONINTV dataset.
Thanks to Atsou Toulabo, GMF, FRANCE.
Thanks to Giles Fontanini, GMF, FRANCE.
Thanks to Olivier Fy, GMF, FRANCE.
Change 30.225 With more than about 40 workloads defined in RMFINTRV,
ANAL72GO VMXGRMFI could fail due to macro variable string length
ANALDB2R limits on list of variables. And, if you workload prefix
ANALID was too long, VMXGSUM (called by VMXGRMFI) could fail on
ASUM113 truncated variable names, causing variable not FOUND.
MULTIPDB New MXGEXIMSG macro variable replaces all hardcoded
READDB2 arguments so that, when directed by support@mxg.com, you
SMFSRCH can use this syntax
UTILNPRT %LET MXGEXIMSG=YES;
VGETENG to enable (logs) of print lines for diagnostics.
VGETLIBS
VGETOBS
VGETSORT
VGETWKLD
VMACID
VMXGFIND
VMXGINIT
VMXGOPTR
VMXGPRA1
VMXGPRNT
VMXGRMFI
VMXGSRCH
VMXGSUM
VMXGSUM
VMXGUOW
VMXGWORL
Oct 30, 2012
Change 30.224 -Documentation note on SMF backup when execution on ASCII.
CHANGES Change 23.090 provided this technique to back up the SMF
VMXGGETM file when executing MXG on ASCII (and note the file name
Nov 1, 2012 of the backup has the date/time):
DATA _NULL_;
DATE=TODAY();
TIME=TIME();
DATETXT='D'!!PUT(DATE,YYMMDD10.)!!'-'!!'T'!!
PUT(HOUR(TIME),Z2.)!!'-'!!
PUT(MINUTE(TIME),Z2.);
CALL SYMPUT('DATETXT',DATETXT);
RUN;
FILENAME SMF FTP ("'SYS4.SMF.YOUR.DAILY(0)'")
USER='xxxxxx'
HOST='xxxxxxxx'
DEBUG
S370VS
RCMD='SITE RDW READTAPEFORMAT=S BUFNO=35' /*for tape*/
LRECL=32760
PASS='xxxxxxxx';
FILENAME SMFBKUP
"D:\Users\365173\MXG\SMFDATA\SMF.HHPR.&DATETXT";
%LET MACFILE=
%QUOTE(
RDW=LENGTH+4;
BDW=RDW+4;
FILE SMFBKUP RECFM=N LRECL=32760;
PUT BDW &PIB.2. '0000'X RDW &PIB.2. '0000'X
SMFINFILE @;
);
RUN;
%INCLUDE SOURCLIB(BUILDPDB);
RUN;
That is STILL the correct (and only SAFE way) to back up
the file being read, in spite of a post to MXG-L that
reported this error message using that technique:
"ERROR: The '/' INPUT/PUT statement option is
inconsistent with binary mode I/O. The execution of
the DATA STEP is being terminated".
And, that text was found in SAS Note 3404, an ancient
note that was fixed in SAS Version 8.2.
That error message was NOT due to the backup technique;
there was a prior and unrelated syntax error that was the
true cause of that binary mode I/O error message.
But, a subsequent post suggested that RECFM=S370VBS could
be used to create the ASCII backup file, BUT:
YOU CAN NOT USE RECFM=S370VBS on ASCII for OUTPUT.
While you can write with that RECFM with no errors on the
log, THE OUTPUT FILE CANNOT RELIABLY BE READ. Sometimes
it is valid, sometimes it is not, and there is no clue,
until you try to read the backup file.
-VMXGGETM is revised to support RECFM=N write of VBS data
when it is executed on ASCII, so you could use
FILENAME SMFBKUP
"D:\Users\365173\MXG\SMFDATA\SMF.HHPR.&DATETXT";
%VMXGGETM(SMFOUT=SMFBKUP,NRECORD=MAX);
as a standalone program to create a backup of your SMF.
Thanks to Michael Mayne, HHSYS, USA.
Change 30.223 Support for user-created CICS variables TRANSU, PGMU,
UTILEXCL USERU and USERDATU. UTILEXCL must be executed to create
VMAC110 the IMACEXCL to input those fields, and the four IMACICxx
IMACICUW members must be copied into your "USERID.SOURLIB" and the
Oct 26, 2012
Thanks to Randall R. Schlueter, FirstData, USA.
Thanks to Joan E. Nielsen, FirstData, USA.
Change 30.222 IFCID=239 DB2ACCTP observations did not set DB2PARTY nor
VMACDB2 QPACROLL nor QPACRUSM for the ID=101 SUBTYPE=1 records.
Oct 26, 2012
Change 30.221 Example HSM reports 3 and 4, Concurrent HSM Activity and
ANALHSM Concurrent HSM Queued, are now sorted by datetime within
Oct 25, 2012 each HSM Function.
Thanks to Rick Ralston, Humana, USA.
Change 30.220 Support for NDM-CD Subtype CX Certificate Expire subtype
EXNDMCX creates new NDMCX dataset.
IMACNDM
VMACNDM
VMXGINIT
Oct 24, 2012
Thanks to Douglas C. Walter, CitiBank, USA.
Thanks to Brent Turner, CitiBank, USA.
Change 30.219 The mapping of DBID/OBID hex values to the actual name of
ANALDB2R the database or table were not always decoded correctly
VFMT102 by the format created by VFMT102. In some cases IFCID 105
Oct 21, 2012 was written up to 30 seconds AFTER the trace record that
Nov 5, 2012 needed the 105 values, so a format based on timestamps
cannot be used. This iteration creates the format based
on variables SYSTEM DB2SSSID QWHSACE DBID (or DBID OBID).
NOTE: REGION=200M or larger may be required because this
format is MUCH larger; the size is related to the number
of observations in T102S105 and T102S107 datasets.
Nov 4: The Oct 21 iteration could cause duplicate values
error when building the format; NODUPKEY replaced NODUP
to circumvent the error, but this could cause some DBID
and OBID values to remain HEX (i.e., unmapped). We are
still redesigning the entire mapping algorithm but not
in time for today's MXG 30.08. Contact support@mxg.com if
you want the redesigned mapping when it's ready.
Thanks to Alyona Bertneski, JPM Chase, USA.
Change 30.218 In ANALDB2R, INTERVAL=xxxx wasn't supported, causing
ANALDB2R MXGERROR: YOU SPECIFIED INTERVAL=HOUR
Oct 19, 2012 MXGERROR: AND DATETIME=QWACBSC BUT THAT
MXGERROR: DATETIME VARIABLE IS NOT IN THE SUMBY LIST
MXGERROR: VMXGSUM TERMINATED EXECUTION
if you were using MXG 30.05 or earlier. With later MXG
versions INTERVAL= was ignored for the Accounting reports
with no error message. Now, if INTERVAL= is specified,
but the correct datetime variable is not in your SORTBY=
parameter, the datetime variable is added to SORTBY list.
-But for DB2ACCTP, intervals are still calculated based on
QWHSSTCK (the end of the interval), because QPACSCB did
not exist originally. While it could be now used, that
would require significant updates to the ASUM and TRND
members, and it is still possible for the PLAN/PACKAGE
to fall into different intervals.
-Statistic data is always summed using QWHSSTCK; since the
interval duration for statistics in DB2 V10 is now fixed
at one minute, changing to start versus end would not
make much difference.
Thanks to Ron Wells, Springleaf Financial Services, USA.
Change 30.217 -Reading RMF III data on ASCII platform generated INVALID
VMACRMFV data messages when the (new) MXG00 record (created by the
Oct 18, 2012 new ASMRMFV to document its version) was read, but there
Dostları ilə paylaş: |