* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
| Change 22.163 The SAS User SMF record does not contain enough data to
VMACSASU permit the use of the NODUP option in PROC SORT to safely Jul 7, 2004 remove duplicates; NODUP removed 51,596 non-duplicates from 2,687,811 SMF records. Using READTIME JOB SMFTIME has only 10 milliseconds resolution, which is much larger than the elapsed time of many SAS steps, especially the repetitive SORTing of small datasets. A sequence number of the proc/data step within the session is needed to be able to safely remove duplicates, but for now, the NODUP option was removed from the PROC SORT for TYPESASU, to prevent the unwanted deletion of records that appear to be duplicates, but aren't. Thanks to MP Welch, SPRINT, USA.
VMACBETA Period is now input as &PIB.4. where BETAEXPD was &PD4., VMACBE97 in VMACBETA, and in BETA974 dataset, variable B974XPDT is Jul 7, 2004 input as &PD.4., as it is an expiration date. Thanks to Ruben de Leeuwe, Independent Consultant, THE NETHERLANDS.
IMAC6ESS variable ESSITRAY (INTRAY) and GEPARMKY=0045 creates the VMAC6 variable ESSPORNO (PORTNO) in TYPE6 when comment block Jul 7, 2004 in member IMAC6ESS is opened. Thanks to Engelbert Smets, Provinzial Rheinland Versich., GERMANY
TYPETNG data from a large site, requires REGION=280M, but this TYPSTNG caused INSUFFICIENT MEMORY errors in TESTOTHR step of the JCLTEST8 JCLTESTn test job for sites that didn't even have TNG. Jul 7, 2004 This change inserted %LET MAXROWS=1; so that only 20M is required, but a site with real TNG data will need to remove that statement, and may need 280M. However, sites with TNG should read Change 21.269 which discusses other MXG facilities for actual processing of TNG data. Thanks to Pius Nwaobasi, IBM Global Services, USA. Change 22.159 Variable SMF89LPI now always contains the correct LPAR ID VMAC89 whether less than or greater than 15, and SMF89LP3 is no Jul 5, 2004 longer kept, now that doc indicates what both contained.
EXTY84A variables are input; no one has actually ever requested VMAC84 MXG to support this JES3-only SMF record, and I'd be very VMXGINIT pleased if no one ever does. Jul 5, 2004
VMAC78 R783GFLG='IOQ*GLOBAL*FLAGS' Jul 5, 2004
VMAC73 CHANDCMG='CHANNEL*PATH IS*DCM*MANAGED' Jul 5, 2004 CHANCHCH='CHANNEL*PATH*CHARACTERISTICS*CHANGED'
VMAC71 SMF71PTH='AVG*TOTAL*SHARED*FRAMES*ABOVE 2GB BAR' Jul 5, 2004 SMF71PCH='AVG*TOTAL*CSTORE*FRAMES*ABOVE 2GB BAR' SMF71PAH='AVG*TOTAL*AUXSTORE*FRAMES*ABOVE 2GB BAR' SMF71BLG='PEAK*SHARED*BYTES*LARGE*VIRTUAL' SMF71PIH='PAGEINS*FROM AUXSTOR*FOR ABOVE*2GB BAR' SMF71POH='PAGEOUTS*TO AUXSTOR*FOR ABOVE*2GB*BAR'
VMAC1415 SMF14EDI='EXTENDED*DATA*INTEGRITY*EDI*FLAG' Jul 5, 2004 and FORMATed $HEX2.: Bit Meaning '1.......'B DSN found in EDI exclusion table '.1......'B DSN being opened for out, already open in '..1.....'B DSN being opened for in, already open out '...1....'B application requested EDI be bypassed Change 22.153 -TYPE6/PDB.PRINT variable SUBSYS='TCP ' is for PrintWay VMAC6 basic mode records; SUBSYS='TCPE' is now set if the SMF 6 Jul 5, 2004 record is from PrintWay Extended mode records. -New variables for PrintWay file transfer: SMF6URI ='TARGET*UNIVERSAL*RESOUIRCE*INDICATOR*URI' SMF6URIL='LENGTH*OF*URI' SMF6FTL ='*FILE*TRANSFER*LEVEL*INDICATOR' and SMF6BYTE is now input from PIB8 field. Change 22.152 Support for IFA Processors, APAR OA05731. FORMATS -TYPE70 dataset, new variables: VMAC7072 IFAAVAIL='IFA Processor AVAILABLE?' VMAC79 SMF70IFA='NUMBER OF*IFA PROCESSORS*ONLINE' Jul 5, 2004 IFACROSS='IFA*CROSSOVER?' Dec 12, 2005 IFAHONPR='IFA*HONOR*PRIORITY?' -TYPE72GO dataset, new variables: R723NFFI='*NORMALIZATION*FACTOR*FOR IFA*TIMES' R723RCOD='CONTENTION*DELAY*SAMPLE*COUNT' R723RCOU='CONTENTION*USING*SAMPLE*COUNT' R723ECTC='CPU TIME*WHILE DP*RAISED' R723IFAU='IFA*USING*SAMPLES' R723IFEU='IFA-ELIGIBLE*ON CP*USING*SAMPLES' R723IFAD='IFA*DELAY*SAMPLES' R723IFAC='IFA*CPU TIME*ON IFA' R723IFEC='IFA-ELIGIBLE*ON CP*CPU TIME' -TYPE791 dataset, new variables: R791TIFA='IFA*CPU TIME*ON IFA' (normalized to CP secs) R791TCP ='CPU TIME*SPENT ON*STANDARD CPS' R791TIFC='IFA-ELIGIBLE*CPU TIME*ON CP' R791NFFI='NFFI*NORMALIZATION*FACTOR' -TYPE792 dataset, new variables: R792TIFA='IFA*CPU TIME*ON IFA' (normalized to CP secs) R792TCP ='CPU TIME*SPENT ON*STANDARD CPS' R792TIFC='IFA-ELIGIBLE*CPU TIME*ON CP' R792NFFI='NFFI*NORMALIZATION*FACTOR' Dec 12, 2005: TYPE791/TYPE792 variable names/labels now match the actual variable names. Change 22.151 Cosmetic, only labels were changed. ADOC71 -CSLPFXAV/CSLPFXMN/CSLPFXMX contain only CSA FRAMES; back VMAC71 in MVS/370 those variables contained the sum of CSA+LPA, Jul 4, 2004 but ever since MVS/XA, they contain only the CSA Fixed Frame counts, so LPA was removed from their Labels. -Variables that had just "FRAMES" in their label now have CSTORE*FRAMES if the area was CSTORE. -Unfortunately, some variables in TYPE71 are in units of byte-storage (and formatted MGBYTES to "print pretty"), while these old variables still have counts of frames, but there is no way to be consistent without destroying your existing reports. Hindsight is wonderful, but can't be applied now! Thanks to Mayflor Dageforde, Blue Cross Blue Shield of Kansas, USA. Change 22.150 The LPAR name variables for LPARs 16-32 were only one VMXG70PR byte long; their initialization was corrected to eight Jul 2, 2004 bytes to hold the full name. Thanks to Bruce Widlund, Merrill Consultants, USA. Change 22.149 Enhancement to the UTILBLDP utility that "builds" a "PDB" UTILBLDP (actually, builds the SYSIN code) for arbitrary combos of Jul 1, 2004 SMF records: - ZEROOBS= parameter supports subtypes, so datasets built from specific SMF subtype can be created with zero observations. USERADD= 74, ZEROOBS= 74.1 74.5, creates TYPE74 and TYPE74CA with zero observations, but all other TYPE74XX datasets will be populated. - New MACFILEX= parameter allows insertion of code that would normally be inserted with %LET MACFILE= ....; UTILBLDP internally uses MACFILE=, so your MACFILE= insert is ignored. Probably not needed, as the main need for MACFILE= here was to suppress subtypes! -See member JCLRMF Thanks to Sue Castona, Rockwell, USA.
VGETENG returns the SAS Engine name (in macro variable &VGETENG) VMXGENG and the Device Type (in macro variable &VGETDEV), if xxx VMXGTAPE points to an existing SAS data library that was OPENed, VMXGINIT and sometimes even if the library has not been opened. Jul 6, 2004 The redesign also corrects these previous glitches: Jul 20, 2004 - If the XXX pointed to a sequential format library, on disk or on tape, the entire data library was read, wasting CPU, I/O, and elapsed time. - VMXGTAPE failed when the LIBNAME had not been opened. -When a LIBNAME statement exists for XXX, VGETENG/VGETDEV are always correct, whether XXX has been opened or not, unless there is a LIBNAME (XXX or some other ddname) that points to a non-existent data library on tape, i.e., a DISP=NEW file that has not yet been written to. The logic searches LIBNAMEs, and if an uncreated tape DD is found (perhaps before your wanted XXX ddname) an IEC145I 413-18 message is printed on SYSMSG and SASLOG has an I/O ERROR HAS OCCCURRED message, and the search is terminated (with a zero return code). If the XXX ddname is the uncreated file, VGETENG will have the Engine from LIBNAME XXX statement, but VGETDEV will always be blank for an un-created file. -If there is NO LIBNAME statement, the engine and device are correct only if the DDNAME has been OPENED, but the function does not fail; engine is UNKNOWN and device is blanks for unopened or even uncreated ddnames, on tape or on disk. Test %VMXGENG before using in production! -If XXX accesses a REMOTE SAS/CONNECT file, the MVS device type will be correct; on ASCII VGETDEV will be blank. -The other %macros, VMXGENG and VMXGTAPE were revised with the new logic, and return their original variables, but they exist only for backwards compatibility, as MXG's convention for %macros that "get" something is %VGETxxxx. -VMXGINIT was updated to %GLOBAL macro variable VGETDEV. LIBNAME Statement in SYSIN: YES NONE VGETENG VGETDEV VGETENG VGETDEV DISK
DISP=SHR/OLD REFERENCED CORRECT CORRECT CORRECT CORRECT DISP=SHR/OLD NOT REFERENCED CORRECT CORRECT UNKNOWN BLANK DISP=NEW CORRECT CORRECT UNKNOWN BLANK TAPE
DISP=SHR/OLD REFERENCED CORRECT CORRECT CORRECT CORRECT DISP=SHR/OLD NOT REFERENCED CORRECT CORRECT UNKNOWN BLANK DISP=NEW CORRECT BLANK UNKNOWN BLANK The 413-18 ONLY occurs when there is a LIBNAME, the device is TAPE, and the DDNAME has not been referenced.
Thanks to Rick Langston, SAS Institute Cary, USA. Thanks to Chuck Hopf, MBNA, USA. Thanks to Diane Eppestine, SBC, USA. Change 22.147 Performance enhancements to reduce I/O and CPU time, by ASUM42DS eliminating second pass of TYPE42DS, which was input to Jun 30, 2004 VMXGSUM and then input again to ANALCNCR. The redesign builds a View to create input to ANALCNCR at the same time the data is being read into VMXGSUM. New SAS NOTES: DATA STEP VIEW SAVED ON FILE WORK.SUM142DS DATA STEP VIEW SAVED ON FILE WORK.MXGSUM1 THERE WERE x OBS READ FROM DATASET WORK.TYPE42DS THE DATASET WORK.CNCR42DS HAS Y OBS AND 4 VARIABLES COMPRESSING .... MISSING VALUES .... THE VIEW WORK.MXGSUM1.VIEW USED THE FOLLOWING RESOURCES are printed on the log. The savings? Resource Before After Redesign EXCPs 1.8 Million 760K CPU time 78 minutes 46 minutes Elapsed 236 minutes 135 minutes Thanks to Chuck Hopf, MBNA, USA. Change 22.146 Most variables in the TYP119nn datasets, except for the VMAC119 STARTIME and SMFTIME, were on the GMT clock, but all of Jun 29, 2004 the internal variables are corrected to local time zone. Thanks to Robert Sample, Atlanta Journal Constitution, USA. Change 22.145 -TYPETCPC and TYPETCPF FTP Client/Server in SMF 118 record VMACTCP has GMT time in TOD variables FTPSTART and FTPEND; they Jun 29, 2004 are now corrected to local time zone. -Variable ELAPSTM is added to TYPETCPC/TYPETCPF datasets. -Without this change, ANALTCP reports sometimes had wrong TOD and zero duration because of the GMT time issue. No change was needed in the ANALTCP code. Thanks to Robert Sample, Atlanta Journal Constitution, USA. Change 22.144 DB2 Trace IFCID 140 variable QW0140RC, Return Code from FORMATS Access Control Exit has legitimate negative value of -1 VMAC102 if the Exit was not called, so the input was changed to Jun 29, 2004 IB instead of PIB; additionally, new format MGD140R is created to decode all of the return codes. Also, the QW0140RS, a four-byte reason code is HEX8. formatted. -Additional new values for format MGD140P for V7 and V8 are added. Thanks to Larry Stahl, IBM Global Services, USA.
JCLRMF "RMF-only" PDB library, including PDB.RMFINTRV, and the Jun 29, 2004 PDB.ASUM70PR, PDB.ASUM70LP, and PDB.ASUMCEC summary data. The default example skips the RMF 74 subtypes 1 and 5, so that PDB.TYPE74 and PDB.TYPE74CA datasets will have zero obs (i.e., they take no disk space). This example uses the enhancement in Change 22.149. Thanks to Sue Castona, Rockwell, USA. Change 22.142 Support for Thruput Manager SMF record VARNAME/TOKENID of VMACTPMX INNODE/16448, JBSBIND/50240, JVLVOL/57920, REQCLA/58082 Jun 28, 2004 was added to the CARDS; section; these VARNAMEs had only blank values for TOKENID, but had existing variables. Thanks to Kasandra Natzke, Information Resources, Inc, USA.
FORMATS added by APAR OA04877, creates new dataset TYPE748 with EXTY748 counts of I/O operations, Bytes Read/Written, and Active VMAC74 Time for ECKD, PPRC, and SCSI devices. Also, TYPE74CA Jun 28, 2004 dataset has Bytes Read/Written, and Time to Read/Write. The APAR adds the fields to the 74-5 and 74-8 records, but the new data is only populated if the ESS D/T 2105 device has micro code version 2.3.0.455 (Sand) or higher. Thanks to Willy Iven, Fortis Bank, BELGIUM.
BUILD005 because Change 22.052 did not add STEPNR in all places BUIL3005 where it was needed (CVRT30TD and SPIN30TD); fortunately, Jun 25, 2004 the exposure only occurs if two adjacent steps have the same INITTIME, and all sorts are now protectd. Thanks to Rich Lopez, Johnson and Johnson, USA. Change 22.139 The CICS ID variables in PDB.ASUMUOW: APPLID,USER,LUNAME, UTILUOWC SYSTEM,TERMINAL, and USERCHAR were incorrectly kept from VMXGUOW the LAST transaction segment, but should have been kept VMXGUOWT from the FIRST transaction segment. The sort order was Jun 29, 2004 was changed in Change 21.220, from descending ENDTIME to ascending STRTTIME to recognize the TOR transaction as the first transaction within the UOW, but the logic to store those ID variables was not changed. -LISTALL= argument, primarily for debugging, can now be used to add any of the FRSTxxxx, LASTxxxx, and HOLDxxxx variables to the PDB.ASUMUOW dataset. -New UTILUOWC member can be used to examine the CICSTRAN observations that made up a Unit-of-Work, for debugging. Thanks to Carla Fleming, King County, USA. Thanks to Sydney Cheung, King County, USA.
ANAL4GB to identify VSAM files that are approaching the 4GB size ANAL4GBO limit, but that only saw VSAM files that were opened in Jun 25, 2004 the SMF file that was read. This revision uses the DCOLCLUS dataset, created from IBM's DCOLLECT option of IDCAMS (JCL example in JCLDAYDS) so that all VSAM files can be examined for their size. - Using TYPE64, the HIGHALLOC was 3354M from TYPE64, but LISTCAT showed only 1234M, because it was run at a later time, and that VSAM file was defined as reusable and an RST was specified on the ACB at OPEN, so it was reset to empty before the LISTCAT was run. Thus both members may be useful in tracking VSAM size. Thanks to Dennis Cole, Commerce Bank NJ, USA. Change 22.137 Support for z890 new CPUTYPE='2086'x, REQUIRED ONLY for FORMATS OS/390 R2.10; MXG does not error with data from z890s, VMAC7072 but without this change, MSU-containing variables will be VMXGRMFI missing if you are still running your z890 under OS/390. Jun 28, 2004 -The '2084x CPUTYPE tests added to support the z990 CPU in Changes 21.141, 21.149, and 21.216 are expanded to now also test for the '2086'x CPUTYPE of the z890. -The table of "MSU" values in MG070CP format are updated with IBM announced Software Pricing MSU for the z890, which will eliminate the "CPUTYPE NOT IN TABLE" messages. Thanks to Ed May, Western Power, AUSTRALIA. Thanks to Al Sherkow, I/S Management Strategies, Ltd, USA. Change 22.136 The SMF Exit code to put Initiator Name and Init Number IEFU84 if the PROGRAM field in the SMF 30 subtype 1 record that Jun 24, 2004 was announced in Change 19.269 now exists in the member IEFU84, which is the JOB to assemble that SMF exit. Your System Programmer will need to install the exit for you, as it must be placed in an authorized load library, and he/she will want to examine this SMF exit code. MXG member VMAC30 already has the code in place and will now populate the variables INITNAME and INITNUM after you have installed the IEFU84 exit to add the data to SMF 30. But note that only "real" initiators have names/numbers; WLM-managed initiators will have blank initname and no value for initiator number. Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA. Change 22.135 The "MVS" SYSTEM NAME of each LPAR, SMF70STN, is added to VMXG70PR datasets ASUM70PR and ASUMCEC as variables LP0STN-LPXSTN, Jun 24, 2004 and in dataset ASUM70LP as SMF70STN. Thanks to Jim Horne, Lowe's Companies, Inc, USA. Change 22.134 The percentage of DURATM when each of the 32 CPU engines VMAC7072 was online is added in variables PCTONLN0-PCTONLNX in the Jun 24, 2004 TYPE70 dataset. Thanks to Jim Horne, Lowe's Companies, Inc, USA. Change 22.133 -Support for additional NDM-CDI Connect Direct subtypes: VMACNDM FA,FI,GO,IF,NL,PI,SY,TP,TR,UU,WS,ZI Jun 23, 2004 -Exit members EXNDMEV,EXNDMSB,EXNDMWS were deleted, as those subtypes are now output into existing datasets. -Comments in VMACNDM identify all known subtypes, those that have known DSECTS, and those for which I have had test data; if you have observations created in any of the datasets identified as "NO DSECT", contact support@mxg. Thanks to Jim Petersen, Washington Mutual, USA. Thanks to Stuart Hubbard, Washington Mutual, USA. Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.
ANALJOBE of a JOB did not keep CPUTM, had MULTIDD mispelled, did VMACSYNC not use MACJBCK to select specific jobs whose events are Jun 25, 2004 to be tracked, and deleted some 14/15 records for some long-running jobs.
VMACNSPY one SMF ID, which caused messages ERROR.VMACNSPY.1 with Jun 22, 2004 NSPYENTL=54754 and NSPYOFF=1539954642 in the text. This change merges the VMACNETM code into the VMACNSPY code so that NETSPY records (all of which have alpha subtypes) and NETMASTER (which have two-byte hex subtype) are now processed with the single TYPENSPY/VMACNSPY member to creates all NSPY and NETM datasets. This change requires MXG 22.01+, because of the new EXNETM50 and the revised VMXGINIT members added by Change 22.037. -While TYPENETM will still decode NETMASTER records, it is now archaic, since TYPENSPY creates both NETMASTER and NETSPY datasets. -Change 22.243 is required; it corrected this change. Thanks to Susan Fassette, Erie Insurance Group, USA.
MXGSASV9 conventions, many of which are documented in the section Jun 15, 2004 "Languages, Encodings, and Installation Codes" in the SAS Aug 24, 2004 "Installation Instructions for SAS 9.1.2 Foundation for z/OS" manual. The DSNAME and MEMBER names created depend on the two NLS/LOCALE options for your country, the "XX" Language Value and the "YY" Encode Value. Some DSNAMES use XXYY, some member names end in YY, and both SASHELP and SASMSG have ENYY in their DSNAME for the help and the messages that have not been translated into local. For example, "ENW0" for English in US, "DEW3" for most GERMAN languages, but "DEWB" for GERMAN in Switzerland. -To support this SAS change, the MXGSASV9 JCL procedure example has two new symbolic parameters, &XX and &YY with &XX=EN and &YY=WO as their default values, and you can see in that JCL where the XX and where the YY is used to form part of the DSNAME or MEMBER names. -New DD statements added in V9 are also added in the JCL example: TRNSHLP, ENCDHLP, and TMKVSENV. Thanks to Bernd Klawa, Stat Bielefeld, GERMANY. ====== Changes thru 22.129 were in MXG 22.06 dated Jun 14, 2004========= Change 22.129 "MVS" SAS only, I think! In SAS V9, the NLSCOMPATMODE CONFIGV9 option was changed to default to NONLSCOMPATMODE, which Jun 15, 2004 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.
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."
and NLS in SAS Technical Note TS-653 at www.sas.com. Jan 2012: See Change 27.356, which shows how to use the CONFIMXG and // EXEC SAS and //MXGNAMES to use the site's Yüklə 28,67 Mb. Dostları ilə paylaş:
|