MXG examples, if your %VMXGSUM uses an OUTCODE= parameter
to re-calculate the DATETIME= variable-name, your results
may be seriously wrong. If your code looks like this:
DATETIME=STRTTIME,
INTERVAL=MONTH,
SUMBY =APPLID DATETIME TRANNAME,
OUTCODE =STRTTIME=DATETIME; DROP DATETIME; ,
it must be replaced with this:
DATETIME=STRTTIME,
INTERVAL=MONTH,
SUMBY =APPLID DATETIME TRANNAME,
ID =STRTTIME,
Prior to 12.084, the DATETIME= variable-name was forced
to LENGTH 8, but when the new ID=variable-name parameter
was added to replace the recalculation in the OUTCODE=
parameter, the automatic forcing of LENGTH 8 was dropped.
All MXG invocations of %VMXGSUM were changed, but I did
not realize nor document this exposure if you did not
make the change.
(Eliminating OUTCODE= eliminates a data step; also, since
12.084+ keeps only the needed variables, the variable
might not even exist to have its length changed.)
When a datetimestamp value is stored in length 4, it can
be truncated by up to 255 seconds, which can cause the
summarization value to be on the prior day, week, or
month!
No code was changed by this documentation-only change.
Thanks to Ahn Ngo, Crowley Maritime Corporation, USA.
Change 13.151 -HP PCS variables NONEW NOKILL and NOSHORT are characters,
VMACHPAI not numerics. Add all three variable names to the $8
VMACHPSU FORMAT statement in VMACHPUX, and add NONEW and NOKILL to
VMACHPUX the $8 FORMAT statement in VMACHPAI and VMACHPUX to fix.
VMACHPUX -Comparing CPU time in the HPUXGLOB and HPUXAPPL datasets
Aug 2, 1995 shows expected comparison (HPUXAPPL records over 90% of
the global CPU time. However, HPUXPROC shows more CPU
time than was recorded in the HPUXGLOB, probably because
the CPU time IN HPUXPROC is in seconds (rather than tenth
of seconds), and it appears that fractional CPU seconds
are written as 1 second. The site has "Short Lived On",
causing records for tasks running less than one second,
which may contribute to the discrepancy. HP is being
contacted concerning the CPU time resolution in HPUXPROC.
Thanks to Dan Sidorick, Smith Klein Beecham, USA.
Change 13.150 MXG 13.04 tape only. Deleted line will cause ABEND.
ASMTAPES After label TIMRPOST, following the WTO statement and
Jul 31, 1995 before the PURGEDQ statement, insert:
L R8,PRGERMTR
MAINTLEV was changed from 4 to 5 to reflect this change.
========MXG Version 13.04, dated Jul 31, 1995, thru 13.149======
Change 13.149 Support for Kodak's ACXIS software for Kodak Optical Disk
ADOCAXC (by Data/Ware Development), Version 2.1.0, thanks to this
EXAXC01X significant user contribution creates ten new datasets.
EXAXC02X AXC01X - AXCIS DATA CREATION SUBTYPE 01X'
EXAXC02I AXC02X - AXCIS INDEX EXTRACTION SUBTYPE 02X'
EXAXC03X AXC02XIS - AXCIS INDEX EXTRACTION SEGMENT XIS'
EXAXC04X AXC03X - AXCIS LOCAL INDEX UPDATE SUBTYPE 03X'
EXAXC05X AXC04X - AXCIS GLOBAL INDEX UPDATE SUBTYPE 04X'
EXAXC06X AXC05X - AXCIS ARCHIVAL SUBTYPE 05X'
EXAXC07X AXC06X - AXCIS USER STATISTICS SUBTYPE 06X'
EXAXC08X AXC07X - AXCIS RETRIEVAL ACTIVITY SUBTYPE 07X'
EXAXC09X AXC08X - AXCIS FAILED RETRIEVAL ACT. SUBTYPE 08X'
IMACAXC AXC09X - AXCIS UNAUTH. ACCESS ATTEMPT SUBTYPE 09X'
TYPEAXC
VMACAXC
Jul 30, 1995
Thanks to Stephen Bell, Westfalisch Lippischen Sparkassen, GERMANY.
Change 13.148 I have never actually published standards for MXG code.
VMACXXXX Many users have contributed code that works, but I often
Jul 30, 1995 have to spend some time revising their code to my format,
because I have never formalized exactly how to write MXG
code. Member VMACXXXX and the other ....XXXX members are
good examples of the basic code structure, but I will now
begin to include specific coding standards that I try to
us, some cosmetic, some functional, for now in VMACXXXX,
but likely to be moved to a different-named member in a
subsequent iteration.
Change 13.147 Support for LEGENT's HyperBuf SMF Record adds new dataset
FORMATS TYPEHBUF, thanks to this user contribution. The original
EXTYHBUF code was tested with Beta Release 4.02 of HyperBuf,
IMACHBUF although I changed some of the code (see change 13.148)
TYPEHBUF and only syntax checked afterwards, as the test data file
VMACHBUF had not yet arrived for validation.
Jul 30, 1995
Thanks to Joseph G. Ogurchak, Westfield Companies, USA.
Change 13.146 Five variables in NDM Connect Direct NDMMC dataset
VMACNDM (NDMTNAME,NDMFNAME,NDMANAME,NDMNRECS,NEMNBLKS) and four
Jul 30, 1995 variables in NDMWO (NDMTNAME,NDMFNAME,NDMANAME,NDMTSKNO)
were wrong because NDMUID was expanded from 8 to 64 bytes
in these records. The MXG test:
(NDMRTYPE='MC' AND LENGTH=168) must be changed to read
(NDMRTYPE='MC' AND (LENGTH=168 OR LENGTH=214)) to fix.
In addition, the actual change now inputs and keeps new
variable NDMWODAT, the undocumented text string at the
end of the WO record. (I suspect my DSECTS are old!).
Thanks to ???, Alcatel, FRANCE.
Change 13.145 Support for Packet/Main SMF record creates 11 datasets
EXPKMNBI thanks to this significant user contribution:
EXPKMNBL PKMNCONN - Connect to TIC
EXPKMNCO PKMNDISC - Disconnect from Packet Network
EXPKMNDI PKMNBIND - Bind Completed
EXPKMNER PKMNUNBN - Unbind processed for user
EXPKMNFE PKMNERR - Error Events
EXPKMNFL PKMNSTUP - Startup of PKTMN Program
EXPKMNFS PKMNSHUT - Shutdown of PKTMN Program
EXPKMNSH PKMNBLOG - Bind Image Log (for Session Data Logging)
EXPKMNST PKMNFLOG - Outbound FMD Logical Message (for ")
EXPKMNUN PKMNFTST - File Transfer Start
IMACPKMN PKMNFTEN - File Transfer End
TYPEPKMN The first five datasets have been validated with data.
VMACPKMN
Jul 29, 1995
Thanks to Mr. Loewenthal, Zonussi Elettrodomestici, ITALY.
Change 13.144 Support for NetCompress SMF record creates six datasets,
DIFFNTCP thanks to this significant user contribution:
EXNTCPAP NTCPINAP - Application Interval - type 03
EXNTCPOP NTCPINSY - System Interval - type 02
EXNTCPRT NTCPSESS - Device Session Start - type 05
EXNTCPSE NTCPSESE - Device Session End - type 06
EXNTCPSS NTCPSTRT - System Startup - type 01
EXNTCPSY NTCPSTOP - System Stop - type 04
EXNTCPOP Since the NTCPINSY dataset contains accumulated fields,
IMACNTCP member DIFFNTCP is automatically included in TYPENTCP,
TYPENTCP Note if you tailor BUILDPDB to add NTCP processing, you
VMACNTCP must also add %INCLUDE SOURCLIB(DIFFNTCP) in EXPDBOUT.
Jul 29, 1995 However, since the documentation does not describe which
fields are in fact accumulated versus end point values,
I had to deduce from the test data which fields to DIF(),
so please validate closely that I got them all!
Thanks to Mr. Loewenthal, Zonussi Elettrodomestici, ITALY.
Change 13.143 TSO/MON 6.1 only, variables TRIVTM NTRIVTM and LONGTM are
VMACTSOM were 38400 times too small; replace the three TU4. with
Jul 29, 1995 &PIB.4. and the values will be correct. (When I validated
the 6.1 changes last fall with test data, I only looked
the counts of transactions, and failed to perform a
reasonableness check on the response time values.)
Thanks to Yingha Mui, Canada Life, CANADA.
Change 13.142 Variables LCSLCBR and LETHCBR were misspelled as the 2nd
VMAC28 occurrence of LSCLCBS and LETHCBS, and the second label
Jul 28, 1995 for LCSLXBYT was deleted.
Change 13.141 Cosmetic changes. Duplicate variable names occurred in
VMACHPUX KEEP= statements, causing no error, but as they really
VMACIAM serve only to confuse, the duplications were removed.
VMACOMCI The MEMBER(VARIABLE) that were changed in each member:
VMACXAM VMACHPUX(EXPORTIM), VMACIAM(IAMAVGRL), VMACOMCI(EAMAXT),
VMAC110 VMACXAM(SLORESP1,SLORESP2), VMAC110(LDGDPSCR),
VMAC7072 VMAC7072(CPUWAITD,CPUWAITE,CPUWAITF), VMAC99(PHSPS).
Jul 27, 1995 (Freddie's diagnostic program, which reads MXG source to
look for inconsistencies, found these duplications.)
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 13.140 DFSORT Release 13 only. Variable ICEINPDS was repeated
VMAC16 four times in the KEEP=, the LABEL, and the INPUT
Jul 27, 1995 statements. The 2nd thru 4th occurrences of ICEINPDS
should have been ICEINNDS, ICEOUTDS and ICEOFLDS.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 13.139 Almost cosmetic; MXG previously kept only the first 9
DIFFDB2 IFCs and Destinations in DB2STAT0, and printed a message
VMACDB2 ("This is not usually important") if additional segments
Jul 27, 1995 were found in your record. Since this caused a few calls
I elected to increase the kept IFCs and Destinations to
14, since that appears to be the default count. These
counts of activity by IFC and Destination are rarely
needed, but now they exist. See Change 12.279.
Change 13.138 Using TYPEMON8 to process Landmark TMON/CICS Version 1.3
TYPEMON8 will cause the "IT APPEARS YOU ARE TRYING TO PROCESS ..."
Jul 26, 1995 message about decompression exit. That text now reminds
you that TYPETMON is required for Version 1.3 records.
Thanks to Jerry Boggess, County of Sacramento, USA.
Change 13.137 The MICS VM Data Transmission Program's VB output file is
VMACVMXA already supported in MXG VM/ESA member VMACVMXA, by using
Jul 26, 1995 the _VMINPUT macro instead of the _MWINPUT macro.
Only comments were changed by this Change.
Thanks to Ian Davies, Workers' Compensation Board of Alberta, CANADA.
Change 13.136 Variables HMF5BUS and HMF5TIME were not in the KEEP= list
VMACHMF for dataset TYPEHMF5, and they were also left out of the
Jul 26, 1995 LABEL statement in change 13.038.
Thanks to Shaheen Pervaiz, Acxiom CDC Inc, USA.
Change 13.135 This revision to the MXG Tape Mount and Tape Allocation
ASMTAPES monitor provides SRB reliability enhancements and adds
VMACTMNT new diagnostics. This is MAINTLEV 4 of the monitor and
Jul 25, 1995 should resolve several erratic problems with the SRB
Jul 29, 1995 routine (including, possibly, the occasional stall where
the monitor stops writing SMF records). This revision
creates a separate mount record for PROGRAM=IEFIIC, which
is now known to be the program name seen when a job step
is delayed in allocation recovery, and I intend to see if
there is any way to match up this IEFIIC record to its
related job, but I have to get the monitor into test site
hands to create the test data to examine first! Because
these PROGRAM=IEFIIC records represent allocation rather
than mount delays, I chose to delete them in VMACTMNT so
your statistics will not be affected. Sites wishing to
examine these records can remove that test from VMACTMNT.
Thanks to Tom Parker, Hogan Systems, USA.
Thanks to Jim Purdie, BancOne, USA.
Thanks to David Childers, Lowe's, USA.
Thanks to Shaheen Pervaiz, TransUnion, USA.
Thanks to Tracy Blackstone, Kaiser Permanente, USA.
Change 13.134 Date/time selection failed, especially crossing midnight.
ANALRMFR Find and delete each of the 44 lines containing either
Jul 24, 1995 IF TIMEPART("&BEGTIME"DT) LE TIMEPART(STARTIME);
or
IF TIMEPART("&ENDTIME"DT) GE TIMEPART(STARTIME);
Thanks to Norbert Korsche, OMV AG, AUSTRIA.
Change 13.133 Candle's Supersession Release 147 causes MXG message that
VMACNAF "More account fields were encountered ..." is corrected
Jul 24, 1995 by Candle PTF QLV1372.
Thanks to Mr. Schott, Rehau AGu. Co., GERMANY.
Change 13.132 Variable DURATM was neither calculated nor kept in the
VMAC28 NPMVSVGB data set; it was added to the KEEP= list and
Jul 24, 1995 created in the 'VGB' segment processing.
Thanks to Carl Sommer, SAS Institute Cary, USA.
Change 13.131 Several corrections to HSM FSR SMF record processing:
VMACHSM -Variable FSRTBYTW was mis-calculated. It should be:
Jul 24, 1995 FSRTBYTW=SUM(FSRTBYBK,FSRTBYTW);
-The DO I=1 to FSRNENT1 loop should have included all of
the SUM functions and the FSRTVOLS logic, with the
%INCLUDE SOURCLIB(EXHSMFST) and END relocated to just
before the DO on FSRNENT2. Before this change, MXG only
output the counts for the last tape when this FSR had
multiple tapes, and always had TPTYPE='INPUT'.
-Variable FSRTVOLS was added to LENGTH statement as $30.
Thanks to Wanda Prather, Johns Hopkins University APL, USA.
Change 13.130 Internet addresses FTPCLHST FTPCRHST F20LHST and F20RHST
VMACILKA were numeric variables in hex; with this change they are
Jul 24, 1995 character variables of length 15 with numbers and decimal
points between them. Inputting each of the four bytes as
individually using PIB1. and then concatenate the PUT
function of each byte, using:
ADDR=PUT(B1,3.)!!'.'!!PUT(B2,3.)!!'.'!!PUT(B3,3.)!!'.'
PUT(B4,3.));
Note added Aug 1996: Data from before and after this
change cannot be combined, as these four variables are
numeric before and character after. If you must combine
(i.e., year to date), then you must convert these four
variables in your existing accumulation from numeric to
character, using this logic:
MACRO _CONVERT
B1=FLOOR(X/65536);
B2=FLOOR((X-B1*65536)/4096);
B3=FLOOR((X-B1*65536-B2*4096)/256);
B4=MOD(X,256);
ADDR=PUT(B1,3.)!!'.'!!PUT(B2,3.)!!'.'!!PUT(B3,3.)!!'.'
PUT(B4,3.));
%
DATA NEWACCUM; SET OLDACCUM;
DROP FTPCLHST FTPCRHST F20LHST F20RHST;
X=FTPCLHST; _CONVERT; XTPCLHST=ADDR;
X=FTPCRHST; _CONVERT; XTPCRHST=ADDR;
X=F20LHST; _CONVERT; X20LHST =ADDR;
X=F20RHST; _CONVERT; X20RHST =ADDR;
DATA OLDACCUM; SET NEWACCUM;
DROP XTPCLHST XTPCRHST X20LHST X20RHST;
FTPCLHST=XTPCLHST;
FTPCRHST=XTPCRHST;
F20LHST =X20LHST ;
F20RHST =X20RHST ;
Thanks to Mohammad Mourad, AT&T, USA.
Change 13.129 DB2 Statistics Report again, but only individual fields!
ANALDB2R -PMSTA01/PMSTA02 labels for Buffer Pools BP0 and BP1 for
DIFFDB2 GENERAL and READ ACTIVITY were printed as BP1 and BP2.
VMACDB2 In ANALDB2R find GENERAL and make the following change,
Jul 24, 1995 and then find READ ACTIVITY and make the same change:
Jul 25, 1995 %IF &B EQ 1 %OR &B EQ 2 %THEN %DO;
Jul 26, 1995 @1 "BP&B GENERAL "
Jul 27, 1995 %END;
must be replaced with:
%IF &B EQ 1 %THEN %DO;
@1 "BP0 GENERAL "
%END;
%ELSE %IF &B EQ 2 %THEN %DO;
@1 "BP1 GENERAL "
%END;
-The LOG RBA field is printed as a decimal when it is a
hex address, and must be stored as length 8.
In ANALDB2R, find this line with QWSDLR and add HEX12.:
+2 'LOG RBA :' QWSDLR HEX12. ;
In VMACDB2 add variable QWSDLR to the LENGTH statement
to make it length 8 instead of the default length of 4,
and add a line QWSDLR HEX12. to the FORMAT statement.
(I chose HEX12 for an 8-byte field because RBA is a 24bit
address, and because HEX16 produces wrong values - see
SAS Technical Note).
In DIFFDB2, remove the line QWSDLR=DIF(QWSDLR);
-The second of the two lines with this label is wrong:
DBD REQUESTS NOT IN EDM
Change that 2nd label to DBD REQUESTS/DBD NOT IN EDM
The original calculation was always correct.
-The value for REQUESTS FOR PT SECTIONS in the Statistics
summary is incorrect. Find the line reading
+3 'REQUESTS FOR PT SECTIONS '
and change the next line to QISEKTG instead of QISEKT.
Now, find the previous SUM= statement and add QISEKTG.
-Statistics Detail report, page 4, right half of page
(AUTHORIZATION ATTEMPTS thru LOOK AHEAD MOUNT SUCCEED):
The /MINUTE /THREAD /COMMIT columns contain wrong values
(the left hand COL1xxxx variables are printed instead of
the right hand COL2xxxx variables). You must find each
of the report labels for the right hand column, and for
those that are followed by lines with COL1PMIN COL1PTHD.
and COL1PCOM, change the COL1xxxx to COL2xxxx. Twenty-one
sets of three lines were changed.
-Statistics Detail report, page 6, right half of page,
(GET PAGES thru RANDOM GET PAGE RESULTS), same error as
page 4 - file labels and change COL1xxxx to COL2xxxx.
Thanks to Neil Ervin, Huntington Service Company, USA.
Thanks to Cal Cooke, Huntington Service Company, USA.
Thanks to Dean Berry, Farmland Industries, Inc, USA.
Change 13.128 Support for APAR OW13246 (PSF/MVS Release 2.2.0) adds new
VMAC6 variables SMF6BYTE (bytes transmitted) & SMF6TARG (target
Jul 23, 1995 address) to dataset TYPE6, for sites exploiting the new
PSF/MVS Download feature. Note that these new variables
are not automatically carried into the PDB.PRINT dataset
with BUILDPDB, but you can tailor IMACPDB easily to add
them if you need them.
Change 13.127 This change is for documentation of an incompatibility
FORMATS with SAS Version 5; there was no actual change. Beginning
Jul 23, 1995 with MXG 13.01, member FORMATS cannot be executed under
SAS version 5 or SAS version 6.06, nor can it be executed
if the output LIBRARY is a version 5 format library. The
syntax OTHER=(| $HEX2. |) added by Change 13.061 did not
exist in those archaic versions of SAS. However, if you
delete all of the lines in member FORMATS with that
OTHER= syntax, the formats program will execute without
error, even on those old versions.
Change 13.126 This change was revised after Newsletter 28 was printed.
VMACVMXA VM/ESA MONWRITE records written both by Sterling's
Jul 23, 1995 VM/Monitor and by IBMs MONWRITE have changed in VM/ESA
Jul 24, 1995 2.2. MXG calculated the number of control records using
Aug 22, 1995 NRCRRECS=(IPRMMSG2-IPRMMSG2+1)/12; (even though there is
only one control record per block), and verified that the
record was a control record by testing IPARMLF1=8709x,
but the IPARML control block has changed. Sterling writes
records with IPRMMSG1=IPRMMSG2=028x that have MWTCAREA of
all zeroes (so this is not a valid control record, altho
028x is the correct offset to where MWTCAREA should be!),
and IBM writes records with MSG1=MSG2=3Fx that do contain
a valid MWTCAREA, but 3Fx is the wrong offset to it!
(These heuristics were needed in early VM/XA records, but
now that the IPARML has changed, they can and must be
removed with these changes:
-The block IF MOD(IPARMLF1,10000X) NE 8709 ... to END;
was deleted.
-The calculation NRCRRECS=(IPRMMSG2-IPRMMSG1+1)/12; and
the following INPUT @IPRMMSG1+1 @; was replaced with:
NRCRRECS=1;
INPUT @41 @;
(the code added by the July change, between these two
lines was also deleted by this August change).
-After the @; after CAEND is input, insert this code:
IF CASTR=0 AND CAEND=0 THEN DO;
NRCRRECS=0;
DELETE;
END;
With these changes, MXG now skips over the MWTEXTBF area
that contains the IPARML control block, and instead reads
the MWTCAREA directly to determine how much data (if any)
follows this control record.
Thanks to Ian Davies, Workers' Compensation Board of Alberta, CANADA.
Thanks to Connie Mak, Avon, USA.
Change 13.125 Landmark TMON for MVS corrections. The line reading:
VMACTMVS IF JDSTCBS GT 10000 THEN DO;PUT _N_= COL=;LIST;STOP;END;
Jul 23, 1995 was deleted. That debugging code for a bad record (over
Aug 21, 1995 10,000 TCBs in real memory) caused the MXG job to stop
before the end of the input file, and there was no error
message nor condition code set by MXG; the only clue was
a single record hex dump printed on the SAS log.
Variables STARTIME and DURATM were removed from the KEEP=
list for dataset TMVSCC (which is an event record, not an
interval), and SYSTEM=CCCSMFID; was inserted before the
%%INCLUDE SOURCLIB(EXTMVCC);
to correct the blank value for SYSTEM in that dataset.
Also, variable CFIUTYPE was changed from numeric to
character and formatted $HEX8, to be consistent with the
other occurrences of unit type in other TMVS records. I
recognize this may cause a problem if you combine TMVSCF
data sets built before and after this change.
Thanks to Rod Fernandes, Albert Heijn B.B., BELGIUM.
Change 13.124 RMM SMF Record caused INVALID DATA FOR MDUCDATE/MDUCTIME
VMACEDGS if there had been no user change because the PD4 fields
Jul 21, 1995 were nulls. Insert ?? between the variable name and
the &PDB.4. format name in the two lines which input the
variables MDUCDATE and MDUCTIME.
Thanks to Bob Newbury, University College System of Nevada, USA.
Change 13.123 Variables B1DIS B1INT CPGM LPGM ROBID ROBTY and SMSMC are
TYPETMS5 added to the output datasets created by TYPETMS5; these
Jul 21, 1995 variables (new in TMS Release 5.1) were added to VMACTMS
by Change 13.083, but were not carried into the datasets
created by the TYPETMS5 processing.
Thanks to Norbert Korsche, OMV AG, AUSTRIA.
Change 13.122 Variable RACFUSER from type 30 was added to the DSETOPEN
ANALDSET and DSETSUMS datasets created from 14/15/64 records so
Jul 21, 1995 that Auditors can know the submittor of the job that did
the access to the file.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 13.121 Reading your 3990 Mod 11 Fat DASD with SAS INFILE CVAF
VMXGVTOC option will fail, because the DSCB 5 2-byte addresses are
Jul 19, 1995 3-bytes for those devices. Removing the CVAF option will
circumvent the SAS error, because MXG does not need the
DSCB 5 records to constuct the VTOC datasets. However,
far better than using this old VMXGVTOC technology, the
ASMVTOC/VMGXVTOF pair have been the recommended VTOC tool
in MXG for years. If you now have DFSMS, using their
DCOLLECT is even better, since it includes the VSAM and
VVDS data that previously required you to also run the
ASMVVDS/TYPEVVDS pair. I have removed the CVAF option
from the INFILE statement to prevent this error, should
anyone still be using VMXGVTOC and not read this note.
April 20, 2006 Notes:
1. Member JCLDAYDS and DAILYDSN are the members to
use to capture/bill-for disk space and tapes.
2. SAS Note SN-015522 for SAS Version 9.1.3 does
now recommend specifying the CVAF option in the
INFILE statement to circumvent an 0C4 ABEND in
module UNKNOWN function VXVTC at offset 00082C.
Thanks to Terry Poole, SAS Institute Cary, USA.
========MXG Version 13.03, dated Jul 19, 1995, thru 13.120======
Dostları ilə paylaş: |