* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
Change F21FVOL from $CHAR8. to $CHAR6. Change F21DAIR from $CHAR8. to $CHAR4. Change F21DARC from $CHAR8. to $CHAR1. Insert two lines after F21SBMSG PIB2. @; IF FTPDCTLN GE 129 THEN INPUT to conditionally input F21DAIR/F21DARC (a feature that was not documented by the record's vendor!). Thanks to Paul Mei, Imperial Oil Limited, CANADA.
EXM24ACT datasets, and the account input code formerly in EXM24ACT VMACM204 (for compatibility with archaic versions of MODEL204) was Jul 19, 1992 moved into VMACM204. EXM24ACT is no longer referenced. Change 10.119 A strange type 30 subtype 1 record caused INPUT STATEMENT IMACACCT EXCEEDED RECORD LENGTH error because of an MXG logic error Jul 17, 1992 if a type 30 ends with an account section. This record is questionable, as it contains only a PROD, ID, and ACCT section, and the "INITTIME" is nulls, so this may in fact be an invalid record, but MXG still should not fail too! Change the last line of IMACACCT to read IF LENGTH GT TEMPLOC THEN INPUT @TEMPLOC @; so the existing INPUT @TEMPLOC @; is only executed if the record has additional data sections. Thanks to Bruce Widlund, Merrill Consultants, USA.
ANALCACH could be missing, and only the first LCU was reported. Jul 17, 1992 The logic was revised to merge BY LCU VOLSER and output Oct 8, 1992 only when both TYPE74 and CACHE90 had data (MXG does not output TYPE74 if there was no I/O activity during the interval, while CACHE90 always had an observation.) Thanks to Scott Ashby, U.S. Customs Service, USA.
BUILDPDB causes APPARENT MACRO INVOCATION ERROR message, because I BUILDPD3 forgot that CMS is limited to seven-character %macro names BUILD518 when I added %VMXGDKRO and %VMXGDKRW macro definitions and Jul 17, 1992 invocations in MXG 9.9! Change both VMXGDKRO to VMXGDKO and both VMXGDKRW to VMXGDKW to comply with the CMS limit. If you are still executing under CMS 5.18, there are other problems! The FILE SMFTEMP DCB=SMF; statement will fail under CMS if the input SMF file is a VBS file, because you can only read VBS under CMS, you cannot create VBS. You would need to change BUILD518 to use FILE SMFTEMP RECFM=VB LRECL=32756 BLKSIZE=32760; and pray you never see an SMF record that is 32760 bytes long!
Thanks to J. D. Hill, CyCare Systems, USA. Change 10.116 STC Release 1.2 of the STC4400 HSC SMF record was changed VMACSTC incompatibly. The one-byte STC07CON field in the middle Jul 15, 1992 of the record is now a four-byte field. MXG does not fail but the data values are trashed, and of course there is no record version indicator in this subtype 7 record!. The correction is to replace STC07CON PIB1. with @; IF LENGTH-OFFSMF EQ 105 OR LENGTH-OFFSMF EQ 137 THEN INPUT STC07CON PIB1. @; ELSE INPUT STC07CON PIB4. Thanks to Glen Farmer, Hallmark Cards, USA.
VMACSYNC "MAX-100K", indicating SYNCSORT can use the REGION size Jul 13, 1992 minus 100K, COREREQ will be -100K, after you change the INPUT statement for COREREQ from PIB4. to IB4. Thanks to Brian LeBlanc, Chrysler Corporation, USA.
VMAC80 to a change in the value CA stores in RACFVRSN. The type Jul 12, 1992 80 SMF record created by TOP SECRET is identical in format to the IBM record, but CA's OFFSET is from the beginning of the physical record, while IBM's OFFSET is from the start of the logical record. MXG tests RACFVRSN to know if the record is an IBM or a CA record. A new value of 43X (previous values were F3X or F4X) must be added to the test in line 007700 to recognize this as a CA record. I assume this new value is associated with a new release of TOP SECRET, but nobody at CA bothers to keep me informed! As an aside, the CA OFFSET value is actually consistent with offset values in other SMF records; the RACF type 80 is the only IBM record which calculates offset from the logical record! Thanks to Mark Paulson, Maurices, USA. ==Changes thru 10.113 were included in MXG PreRelease 10.1 Jul 10, 1992= Change 10.113 Sample IEFU83 SMF exit that filters type 40 SMF records, ASMIEFU8 only write SMF records for tape devices. This exit is in Jul 10, 1992 use to measure tape drive allocation time by merging SMF type 30, type 40, type 21, and MXGTMNT SMF records with an algorithm still in development, but the exit by itself may be useful so that you can create type 40 (deallocation of dynamically allocated devices) for tapes only, and thereby determine the JOB name of those jobs which allocate tape devices dynamically (so that they can be excluded by JOB name in MXG's ANALTAPE analysis). Thanks to Gary Strohminger, AT&T Transtech, USA.
EXOPC... significant user contribution adds several new datasets FORMATS and expands logic to handle records spanned across blocks. IMACOPC The "OPCA" prefix for dataset names was changed to "OPC", TYPEOPC the variables prefixed "OPC" are now prefixed "TRL" to TYPEOPC agree with IBM field names, and the input file is now VMACOPC OPCLOG instead of OPCALOG. (To eliminate confusion with VMACOPC the earlier MXG support, members TYPEOPCA/VMACOPCA are Jul 9, 1992 deleted and replaced by TYPEOPC/VMACOPC.). See comments in member VMACOPC for an appreciation of the extensive work that the contributor accomplished. Thanks to Rodney Marwick, Vereinte Versicherungen, GERMANY. Thanks to Wolfgang Vierling, Vereinte Versicherungen, GERMANY.
TTXPDS The TTX product is a set of tools for capturing MVS data Jul 7, 1992 (control blocks, data records, etc.) from within a SAS program; many of its tools are implemented as ASM source code routines that (once assembled and link-edited) can be CALLed from within SAS. Most MXG sites probably will not need to create monitors, but TTX is now available in MXG if you need it. (TTX customers found TTX useful for its DASD space measurement and Tape Device analysis, but both these facilities were already provided to MXG sites in ASMVTOC, ASMVVDS, and MXGTMNT. In fairness, however, it must be noted that TTX tape monitoring also provides device allocation time statistics not (yet!) captured in MXGTMNT.) The single MXG member, TTXPDS, is actually a 164-member PDS that contains installation instructions, excellent documentation, and commented source code for the ASM and SAS TTX programs. Please let us know which parts of TTX you have found useful. Thanks to Guy Garon, Verstand, CANADA. author and creator of TTX. Change 10.110 Support for AS400 now supports V2R1M0 (and V1R3) and was ADOCQAPM restructured. New members TYPEQAPM/VMACQAPM now follow AS400PDS MXG naming conventions and builds all 13 QAPM.... datasets JCLQAPM from AS400 data. Member ADOCQAPM documents how to extract TYPEQAPM AS400 data and sending it to MVS, and JCLQAPM shows how to VMACQAPM split an AS400 tape into 13 files, and invokes TYPEQAPM to VMXGDSNL create all 13 QAPM.... datasets from those files. Jul 6, 1992 AS400 data does not contain a "system" identifier, but you can use the DSNAME of the MVS dataset with the AS400 data to identify which AS400 system's data is being read. The macro _MXGDSNL opens the INFILE and extracts the low-level qualifier of the GDG into the %macro variable &LOWLEVEL that is then stored in variable AS400SYS in each QAPM.... dataset. AS400 support in VMACQAPM is fully functional, but variables are not yet labeled and the datasets need to be better documented. The _MXGDSNL was originally a %MACRO, but an 0C4 ABEND in the %MACRO compiler caused me to change it and use the old-style substitution macro, even though it is in a "VMXG...." member normally used only for %MACRO. SAS Zap Z6074721 corrects the problem; when pervasively installed, I may revert back for consistency. Thanks to John Astle, National Australia Bank, AUSTRALIA. Thanks to Greg Scriba, Budget Rent-a-Car, USA. Change 10.109 MXG source members have always been numbered lines, but CONFIG if you submit a job with the SYSIN statements unnumbered, CONFIG07 you will receive a very un-obvious 180 syntax error. SASOPTV5 With option S=0, SAS reads columns 73-80 of the first SAS Jun 30, 1992 statement, and if no line numbers are found, SAS concludes your source statements are unnumbered, and sets S=80 to read all 80 columns. However, when you %INCLUDE an MXG member, those line numbers in columns 73-80 cause the SAS 180 syntax error, or even an "UNEXPECTED END OF FILE". To prevent the occurrence of this error, MXG members CONFIG, CONFIG07 (for SAS Version 6) and the (now archaic) SASOPTV5 (for SAS Version 5) contain options S=72 and S2=72 so that SAS will always only read columns one thru seventy-two as MXG SAS statements. Thanks to MP Welch, US Sprint Dallas, USA.
VMAC30 APPCDAT and APPCDAR must be input as RB8. instead of the Jun 30, 1992 present PIB4. format. Thanks to Diane Eppestine, Southwestern Bell, USA. Change 10.107 Messages "INFO: THE VARIABLE xxx ON DATA SET yyy WILL BE DOC OVERWRITTEN BY DATASET zzz" are printed on the SAS log if Jun 30, 1992 SAS options MSGLEVEL=I is specified (the default is N). These messages result when MERGE datasets have multiple occurrences of the variable xxx, and are not informing you of any problem. (These info messages may be useful during testing, but they serve no purpose in normal execution.) Thanks to Doug Drain, National City Bank, USA Change 10.106 NPM 1.5.1 subtypes 90x-96x (144-150) caused "NONZERO TOF" VMAC28 or "RECORD NOT OUTPUT" message; these X.25 records had not Jun 30, 1992 been validated. Only the new NPMEVX25 dataset is affected. Lines 168100,168200,257100 values 92, 95, 96 must be 92x, 95x, and 96x. Line 329100 must be changed to read: ELSE IF 90X LE NPMSUBTY LE 92X OR NPMSUBTY=96X THEN DO; Line 329400 must be changed to read: ELSE IF 93X LE NPMSUBTY LE 95X THEN DO; Line 242900 (+1 following DDD input) must be deleted. Variables LXETDDTA/LXETGDTA (lines 242000-242100) must be $CHAR9. vice $CHAR8. Most LXET.... variables are now formatted as $HEX, as they contain unprintables. Thanks to Scott Ashby, U.S. Customs Data Center, USA.
VMACSTC to decode its eight variables, instead of successive bits Jun 29, 1992 for each variable, starting in line 034800. Thanks to Daryl Skufca, DITSO Cleveland, USA. -----Changes thru 10.104 were printed in MXG NEWSLETTER TWENTY-TWO----- Change 10.104 EPILOG/MVS support was still wrong, after Change 10.079! VMACEPMV The *SM180NIO and *SM180NEQ should have been Jun 24, 1992 *(SM180NIO-1) and *(SM180NEQ-1) respectively. Also, the input SM180RID RMFSTAMP8. is now SM180RID ?? RMFSTAMP8. because the field is incorrect in the SM180SUB='TOTS' data record. Because MXG the EPMVEP dataset contains events TOTS/PGN/PGP/TSO,BAT,STC/tso,bat,stc/ some fields may not be valid for some values of SM180SUB. It is possible that separate datasets may be created for each event type in future MXG versions, but that is still under study. Thanks to Wayne Parrino, Avery-Dennison, USA.
VMACVMXA monitor files with an extra, and invalid, control record Jun 23, 1992 between the valid "end" and "start" control records. The problem is being investigated with the vendor, but this circumvention has been added to MXG to strengthen its test for a valid control record. After the @; after variable IPARMLF1 has been input, insert the following statement: IF IPARMLF1 NE 00008709X THEN DELETE; The actual MXG change also puts a message on the log that the unexpected/invalid record has been deleted. This site's "MONWRITE" file also contained incorrect bytecount values which are also being researched. Thanks to Yam Tan, British Airways, ENGLAND.
VMACRMDS written erratically with inconsistent contents when it Jun 21, 1992 is compared to the IBM DSECT, and causes INVALID DATA message for variables RMDSMXVR,LLTH,VWDP,HHLD. This is not an important RMDS record, and only served to print a hex dump on the log. Now, all Packed Decimals are ?? protected to eliminate the message and hex dump. Thanks to Norbert Korsche, OMV-AG, AUSTRIA. Change 10.101 ROSCOE variables starting with ADSFUN2 thru ADSFNDSN are VMACROSC input incorrectly. Starting in line 074800, the offsets Jun 20, 1992 should be 211,219,227,235,243,251,259, and 259 (it was obvious once pointed out). Also, ADFSMEM and ADFSNDSN logic was enhanced and cleaned up in this change. Thanks to John Ellis, Commercial Union, USA. Change 10.100 Fujitsu's FACOM MSP/EX SMF records are now supported. IMACFACO Type 6,22,26 and 57 records were changed incompatibly, VMAC6 but only TYPE6 (PDB.PRINT) variables NODE,RMOTID and VMAC26J2 TYPE26J2 (PDB.JOBS) INROUTE,PRROUTE,PUROUTE,INDEVICE Jun 19, 1992 variables will be incorrect without this change. The type 6 one-byte NODE/RMOTID pair was expanded in place to two bytes each. The type 26 record was also changed to support two-byte node/rmotid for the IN,PR, and PU route codes, but instead of putting these data in IBM's pre-defined Routing Section, FACOM decided to tack those fields on to the end of the descriptor section! Facom MSP/EX users must update member IMACFACO to tell MXG your operating system level to cause MXG to read in their relocated data. See comments therein. Unfinished in 10.1 Beta: Type 26 may have also relocated DEVNAME (SMF26NDV), but that relocation is not coded yet. This should have no impact except for that variable. Type 22 record change was only to make existing fields reserved, and had no impact on MXG code or execution. Type 57 record has also relocated DEVNAME, but type 57 is not used in any standard MXG BUILDPDB nor reports. Thanks to Joan Dobbie, Justice Information System, S.A., AUSTRALIA
VMAC75 with MVS/ESA 4.2.0 records. DEVNR (or UNITADDR, its old XMAC75 MVS/370 name) used to be written as hhhF (device BF7 was Jun 17, 1992 'BF7F'x. Document APAR OY48957 now indicates that DEVNR is now written as hhhh (to support 4-hex-digit addresses). Since this was not documented in the 4.2.0 SMF manual, MXG continued to divide by 16 to shift the "F" out. Now, the correction is to replace line 020400: DEVNR=FLOOR(DEVNR/16); with IF MVSLEVEL LT 'SP4.2.0' THEN DEVNR=FLOOR(DEVNR/16); I'm surprised it took this long for this error to show up, but a) the VOLSER was correct, which I guess most people use in tracking paging activity, b) it did not create a note or message, just a wrong value, and/or c) MVS/ESA 4.2.0 is so good, and sites using it are so smart as to get enough memory, so that paging and swap are no longer the bottlenecks which caused us to look at TYPE75 data regularly in earlier operating systems! Thanks to Diane Eppestine, Southwestern Bell, USA.
VMAC37 Their record is basically compatible with NETVIEW type Jun 19, 1992 37 records, but they set PRODUCT='NETM' instead of the 'NETV' value expected, and their subtype 2 record also contains the GEND triplet, while IBM's subtype 2 did not. Change IF PRODUCT='NETV' THEN to IF PRODUCT='NETV' OR PRODUCT='NETM' THEN and replace IF PRODUCT='NETV' AND SUBTYPE GE 3 THEN with IF (PRODUCT='NETV' AND SUBTYPE GE 3) OR (PRODUCT='NETM' AND SUBTYPE GE 2) THEN for MXG to support either NETVIEW or NETMASTER records! Thanks to Normand Poitras, TELEGLOBE Canada, CANADA. Change 10.097 Analysis of VSAM data sets may have the incorrect value ANALDSET for PROGRAM name. Variable SORTTIME, created in the Jun 17, 1992 ADD statements for NAME=EXTY64 in this member, defaulted to LENGTH 4, causing truncation of the value (up to 255 seconds could be lost), causing incorrect sequence with the INITTIME value from the file's step record. Insert LENGTH SORTTIME 8; after SORTTIME=SMFTIME to fix this error. Also, TYPE64 does not contain variable OPEN that is used in ANALDSET, causing VSAM Input and Output I/Os to be summarized together in DSNSUMS. In the IEBUPDTE step, add OPEN to the KEEP= list for TYPE64, and just before the OUTPUT TYPE64; statement insert: IF ACBOUT='Y' THEN OPEN='OUTPUT '; ELSE OPEN='INPUT'; IBM Info/Sys Item Q494663 (all 39 pages) confuses issues, but ultimately points out that the count of INSERTS,SPLITS UPDATES, etc., in a type 64 record "Change" counter is not due to this job's open, but is the catalog change since open, and that is why you can see UPDATE counts non-zero for INPUT! Only the EXCPS count in TYPE64 is for this open (as it alone was fixed by ancient APAR OY15663). Thanks to Gary Matney, Twentieth Century Investors, USA. Change 10.096 PDBTREND JCL example builds PDBs and updates TRENDs from PDBTREND SMF input for new sites to "initialize" their past trend Jun 16, 1992 from before they begin regular building of the PDB. The sample report herein used RMFINTRV/TYPE72 instead of the TRNDRMFI and TRND72 dataset names (which were change way back in MXG 8.3, but this example was overlooked). Thanks to Mike Skopec, Platinum Technology, USA.
VMAC28 which creates type 28 SMF records, has been tested. Jun 13, 1992 Six subtypes (10x,11x,12x,13x,20x, and 30x) populate the five MXG interval NPM datasets NPMINLU,NPMINNCP,NPMINPU, NPMINRTM, and NPMINSES. The Version 2 Release 0 level of Blue Line is required, as the type 28 records written by earlier releases were not correct.
ANALDB2R the (new in 10.1) summarized (and thus smaller) ASUMDB2A Jun 13, 1992 dataset if it is found in the PDB= input library list. This will significantly reduce the run time of ANALDB2R. (Only the Accounting Trace needs the detail transaction records in DB2ACCT; the Accounting Detail is really a summary, and ASUMDB2A is summarized at that same level!) You can force MXG to use the DB2ACCT dataset with the new USEACCT option: %ANALDB2R(PDB=PDB,USEACCT=YES); If you have taken advantage of sending your DB2ACCT data to the DB2ACCT ddname (Change 10.053), and you have added ASUMDB2A to your BUILDPDB and WEEKBLD jobs (Change 10.yyy), then your existing %ANALDB2R reports with PDB=PDB specified will work just fine. If you have put your DB2ACCT data in the DB2ACCT dd, but did not build ASUMDB2A, to get your DB2 Account reports, you will need only to add the DB2ACCT ddname to the PDB= list of ddnames to be searched: %ANALDB2R(PDB=PDB DB2ACCT); The ANALDB2R reports now include the new DB2 2.3 fields printed by DB2PM, except for the DDF data fields, because we have no test data (hint, hint)! Change 10.093 Trending of DB2ACCT data will now use the new ASUMDB2A TRNDDB2A dataset if it exists in the WEEKly PDB library, but if Jun 12, 1992 ASUMDB2A has not been created in your WEEKly PDB, then TRNDDB2A will use the DB2ACCT dataset (which is more expensive because it has many more observations than does the ASUMDB2A dataset built by member ASUMDB2A). Change 10.092 Minor cleanup of several of the TREND members. Variable TRNDRMFI ZDATE was added where missing and INTERVAL (the number TRND70 of RMF intervals) is created in RMF based datasets for TRND70PR enhanced reporting capabilities. TRND71 TRND72
Jun 12, 1992 Change 10.091 One user asked for it, here it is. Enhancement of the MNTHCICS MXG TREND architecture to trend monthly in addition to MNTHDBDS the strongly preferred weekly trending. MXG strongly MNTHDB2A feels weekly trending must be used for capacity trends, MNTHDB2S but some sites still think they need monthly trends too! MNTHJOBS The MNTH.... are corresponding TRND.... members modified MNTHRMFI to create MNTH.... instead of TRND.... output datasets, MNTH70 with the interval set to MONTH. The MONTH PDB should be MNTH70PR used as input, although WEEKly PDBs can be used (but the MNTH71 current month's data will be incomplete until monthend.) MNTH72 Jun 12, 1992 Change 10.090 The DB2ACCT dataset was externalized by Change 10.053, ASUMDB2A but it may be too large for typical analysis. Just like Jun 12, 1992 ASUMCICS summarizes CICSTRAN transactions records into a much smaller, yet very usable PDB.CICS dataset in the PDB, member ASUMDB2A summarizes DB2ACCT detail accounting (DB2 "transaction") records into the much smaller, yet also very usable PDB.ASUMDB2A. ANALDB2R will use the smaller PDB.ASUMDB2A (if it exists) in DB2 reports reduce the amount of data that must be read. The input dataset is the DB2ACCT dataset and the summarization is BY QWACLOCN QWHCCN "date-hour" SHIFT (where "date-hour" is the value of QWACBSC at the hour level). IT IS STRONGLY RECOMMENDED that all DB2 sites add ASUMDB2A to your daily PDB by adding %INCLUDE SOURCLIB(ASUMDB2A); following the include of (BUILDPDB); this has already been added to the BUILDPDB step in the JCLPDB6 example.
execute the ASUMDB2A include in a separate JCL step, since the WORK space required for sorting and summarizing DB2ACCT into ASUMDB2A can be greater than the WORK space Yüklə 28,67 Mb. Dostları ilə paylaş:
|