* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
| Change 25.037 SORTEQUALS option should NOT have been added to CONFIGV8,
CONFIGV8 (MXG 25.02 only, Change 25.028) as that option was added Mar 16, 2007 in SAS V9, and did not exist in SAS V8. Thanks to Alan Gray, CareFirst, USA. Change 25.036 INPUT EXCEEDED for SMF 1415 in MXG 24.24, when subtype=7 VMAC1415 encrypted tape segment exists; line 743 should have been Mar 14, 2007 -130 and not -32. And now, with data, I can see that the Encoding Mechanism Key 1 and 2 fields, SMF14CD1/SMF14CD2 actually contain EBCDIC characters (L, H), although IBM still has not answered my queries as to how to decode the field or what it contained. Also, the Key Label 1/2, SMF14KL1/KL2 are now FORMATed $HEX128. See Change 24.047 additions in MXG 25.03. Thanks to Douglas C. Walter, Citicorp, USA. Change 25.035 Support for SMF 119 for z/OS 1.8 (INCOMPATIBLE, because VMAC119 MXG INPUT statements for subtype 70 were missing OFF119xx Mar 14, 2007 to relocate the pointer). New fields were added to many datasets by z/OS 1.8, as noted in the comments. Thanks to Marty Rhodes, The Hertz Corporation, USA.
EXCOPYCR unloaded datetimestamps, VOLSER, data volumes in and out, IMACCOCR in the CPYCROSS dataset. CopyCross was formerly an EMC VMACCOCR product, but now is a Diligent product which is named TYPECOCR VTF Mainframe 2.1.0 (Virtual Tape Facility Mainframe TYPSCOCR Systems. VMXGINIT Mar 14, 2007 Thanks to Brian Felix, Wachovia, USA. Thanks to James Bentley, Wachovia, USA. Thanks to Lana McCormick, Wachovia, USA.
ASMTAPEE deleted fields in internal macro definitions that caused Mar 10, 2007 "NOT FOUND" errors when assembled under z/OS 1.8. This revision only removed those references, but had no impact on the actual execution of MXGTMNT.
ANALRMFR active (ONLINE TIME, MVS BUSY TIME, CPU NUM), in the Mar 10, 2007 "Partition Data" report, WGT PROCESSOR NUM, LOGICAL Apr 10, 2007 Processors effective were incorrect, and in the "LPAR Cluster" report, LPARCPUS was incorrect. -Missing comma in 25.02 after MAX=NRICFCPU ... , added. Thanks to David Klein, DOITT City of New York, USA.
VMACTPMX as CAC7IDID in the KEEP list. Mar 7, 2007 Thanks to Scott Barry, SBBWorks, Inc, USA. Change 25.030 TYPE42DS variables from Data Set I/O Statistics Section, VMAC42 input when OFFDSIO is non-zero for this observation: Mar 7, 2007 AVGCONMS AVGCUQMS AVGDAOMS AVGDISMS AVGIOQMS AVGPNDMS CACHCAND CACHHITS CACHRATE CHITPCT CIOPCT DASDMPL DASDRATE DCMEPCT HITPCT ICLS IOCOUNT MAXRSPTM MAXSRVTM RCIPCT RDHITPCT RESPTIME RLCS SEQIOS WRITCAND WRITHITS were incorrectly carried forward into the next physical TYPE42DS observation, if it did not have a Data Set I/O Statistics Section. Now, IF OFFDSIO=0, those variables are set missing. Note that these variables TYPE42DS S42AMSRB S42AMSRR S42AMSWB S42AMSWR S42AMDRB S42AMDRR S42AMDWB S42AMDWR S42AMZRB S42AMZRR S42AMZWB S42AMZWR are only populated when the Access Method Statistics Section exists, i.e., when OFFDSAM is non-zero. I do not know why some DSNAME observations contain both or only DSIO, or only DSAM data, but this sample had: DSIO and DSAM 15808 DSAM only 914 DSIO only 6112 Thanks to Diane Eppestine, AT&T Services, Inc, USA Change 25.029 The individual IORATEn per-engine I/O rates in PDB.TYPE70 VMAC7072 were divided by DURATM, but IBM Reports use the SMF70ONT Mar 7, 2007 UpTime as the denominator, so the IORATEn variables are . now changed to match the RMF Reports. The total IORATE variable, however, is NOT changed, and is still divided by the DURATM, to be consistent with total IORATE data in TYPE74, TYPE78, and other data sources that don't have and idea about individual CPU engine up times. Thanks to Bruce Widlund, Merrill Consultants, USA.
AUTOEXEC incorrect values in PDB.ASUM70PR/PDB.ASUMCEC datasets for CONFIGV9 DURATM,PCTCPUBY,plus, but there was no error message. A VMXG70PR code change in MXG 24.07 in ASUM70PR is the real culprit, VMXGPRAL but the code works perfectly with the default SORTEQUALS. UCOMPSOE Please run PROC OPTIONS to confirm you have SORTEQUALS. Mar 10, 2007 If not, then you should use this IMMEDIATE CIRCUMVENTION: Mar 13, 2007 Change the option for the MXG job that runs ASUM70PR. Mar 16, 2007 You can change the option: - on the // EXEC statement: //MXGSTEP EXEC MXGSASV9,OPTIONS='SORTEQUALS' or you can change the option - in your SYSIN stream, with an OPTIONS statement; //SYSIN DD * OPTIONS SORTEQUALS; %INCLUDE SOURCLIB(....); I didn't really know any of this stuff until this error: When SORTEQUALS is specified, SAS ensures that the input order is preserved when BY variables have equal values. In the SPLIT70 redesign, I added logic that depended on LCPUADDR to be ascending order, but I failed to made sure it was; with SORTEQUALS, since the original PDB.TYPE70PR was in LCPUADDR order, the new logic worked just fine. However, when NOSORTEQUALS is specified, you have told SAS to not spend any more resources to preserve the input order, and, in this case, the output data was no longer in LCPUADDR order when NOSORTEQUALS was specified. The MXG coding error is now corrected, by adding LCPUADDR to the BY LISTs for the CPS70PRn sorts, so the ASUM70PR logic works with SORTEQUALS or NOSORTEQUALS. -However, now that I have seen this error, and even though it's extremely unlikely to occur elsewhere in MXG code, since MXG has always used only the SORTEQUALS option, I have added SORTEQUALS to CONFIGV9 and AUTOEXEC members, to protect for any other exposures. At worst, changing NOSORTEQUALS to SORTEQUALS might make the SORT use a few more CPU cycles and do a few more I/O. -Since the error results in very bad values, it looks like most sites still have the SAS default of SORTEQUALS, or this error would have surfaced during earlier testing. -Summary of MXG setting of SAS options: For z/OS execution of MXG, CONFIGV9 sets MXG SAS options: MXG's CONFIGV9 member still specifies NOTHREADS due to old SAS 9.1.2 errors; see Change 22.207. However, THREADS is primarily useful in non-z/OS; running multiple z/OS jobs in parallel on multi-engine boxes is essentially what THREADS is all about! MXG's CONFIGV9 member now specifies SORTEQUALS. For ASCII execution, AUTOEXEC sets MXG SAS options: MXG's AUTOEXEC member has never specified THREADS, so you get your site's default. MXG's AUOTEXEC now specifies SORTEQUALS; -An unrelated, harmless DIVIDE BY ZERO message if PARTNCPU was zero is now protected. Only occurred with old 1999 test data that was itself defective, but the exposure is corrected. -The VMXGPRAL ("Print ALL") utility was revised to invoke PROC COMPARE on all datasets in two libraries. -Why choose NOSORTEQUALS? It might save a few CPU cycles and a few I/Os, since it just merges the final sort segs, instead of sorting, but, according to informal feedback from SAS folks, it's only really required if you are use the THREADS option on ASCII platforms where you have more than one CPU. So what to do if your SAS folks demand you don't change NOSORTEQUALS? The new UCOMPSOE utility will run two PDB-builds, with NOSORTEQUALS & SORTEQUALS, and then uses the (enhanced) VMXGPRAL to PROC COMPARE each datasets in the two PDB's for differences. Unfortunately, PROC COMPARE will report all datasets with different sort order, even though the two dataset's values are the same. You use the PROC COMPARE output to identify differences, and then use PROC MEANS N MIN MAX SUM DATA= OLD/ NEW to verify that the numeric contents are the same. For example, MXG 25.02 found these datasets were built in different order with the two options in effect: TYPE70 TYPE70PR TYPE74CO TYPE74DU TYPE74PA TYPE74ST TYPE77 but the PROC MEANS showed no actual value differences. Mar 16: Find four lines with BWM. Delete the line which has PROC PRINT and printed lots of useless output. Thanks to Salis Gross Curdin, Credit-Suisse, SWITZERLAND. Thanks to MP Welch, SPRINT, USA.
VMACMONI error in no-longer-used VMACMONI due to missing second Mar 7, 2007 period; the correct syntax is MACRO _LMONDBD &PMONDBD..MONIDBDS % Thanks to Urs Kugler, Zurich Insurance Company, SWITZERLAND.
ANALFIOE now, that denominator is tested prior to the division. Mar 6, 2007 Thanks to James Majeski, AT&T Services, Inc, USA ====== Changes thru 25.025 were in MXG 25.01 dated Mar 5, 2007=========
VMAC7 (SMF7NROX) that is now used instead of the 2-byte SMF7NRO Mar 6, 2007 count of lost SMF records when SMF 7 data lost record is written. The MXG Variable LOSTRECS is populated from the new SMF7NROX field if it is present and SMF7FL1 bit is set that NROX is populated. Change 25.024 INPUT STATEMENT EXCEEDED for RACF 80 WHEN (301) Extension VMAC80A segment for OMVS and PROXY, but neither had any of the Mar 2, 2007 expected data segments. Now, LENLEFT is calculated and tested prior to the INPUT. Thanks to Robert Sample, Atlanta Journal-Constitution, USA.
ANAL16 dataset, to build a format for selection from a second ANAL30 dataset used DATETIME21.2 characters in the format, but Mar 2, 2007 that failed when months were crossed due to month names. This redesign uses PUT(datetime,13.2) to create the text (number of seconds since 1/1/1960) for the format item. Less pretty when printed, but it will always work. Thanks to Tom Elbert, Assurant, USA. Change 25.022 The RMF III ENC extension was usually not INPUT because VMACRMFV the ENCG3XEO offset does not point to the extension that Mar 1, 2007 was added to the end of the record ASMRMFV creates. That extension is located at ENCG3XEO=ENCG3DEO+ENCD3DEL which is now used to INPUT Service and Reporting Class information from the ENC Extension. Thanks to Brenda Rabinowitz, Merrill Lynch, USA.
UTILEXCL are found, to point you to read the text of Change 24.033 Mar 1, 2007 because there are multiple EZA segments created, and that Apr 17, 2007 change text has tailoring instructions. IMACICE2 message for EZ2 fields now also point you to read Change 24.033.
VMACDB2 DDF (DIST), but the data could be reversed, with the DIST Feb 28, 2007 data values in the QWS3xxxx variables and IRLM in the 4th set of variables, because IBM has changed which data is in which segment. This change tests the QWSnPROC name to determine which data is present, so that the QWS3xxxx are now ALWAYS the IRLM and QWS4xxxx is now ALWAYS the DDF data, so the data always matches the variable labels, no matter which segment had that ASID's data. Variables QWSnASCB,ASID,EJST,PROC,PSRB,SRBT,QWSnZSRB are created in PDB.DB2STATS from QWSA segments in SMF 100 records. Thanks to Rachel Holt, Fidelity Systems, USA. Thanks to Lori A. Masulis, Fidelity Systems, USA.
VMACRACF fields all contain EBCDIC, rather than ASCII text. The Feb 28, 2007 test data had been converted to ASCII when it was sent; all of the $ASCII inputs are changed to $EBCDIC now. Change 25.018 Support for eleven more optional CICS EZA02 fields with IMACICE2 these similar names: VMAC110 EZA0TCON EZA0TSTA EZA0TINV EZA0TDIT EZA0TDIP Feb 28, 2007 EZA0TGIV EZA0TSEC EZA0TA08 EZA0TA09 EZA0TA10 Apr 16, 2007 EZA0TA11 because I assumed they were now the default set of fields in that optional segment. However, as I have not seen them at other sites, I suspect they were accidentally created at this site, and thus not likely to exist in your EZA02 fields. As documented in Change 24.033, you must look at the output report from UTILEXCL to see what EZAxxxxx fields exist in your data, and then EDIT the IMACICE2 to only INPUT and LABEL those in your records. Text was revised Apr 16, 2007. No code change. Thanks to Paul C. Gordon, Bank of America, USA. Thanks to Peter Krijger, ANZ National Bank, NEW ZEALAND. Change 25.017 EXITCICS is the Assembly code for a SAS INFILE EXIT that EXITCICS will read and uncompress SMF 110 subtype 1 records as Feb 28, 2007 they are read. You assemble/link edit the ASM code in Mar 7, 2007 the EXITCICS member to create a load module CICSIFUE in MaR 10, 2007 a Load Library, concatenate that DSNAME to //STEPLIB DD in your MXGSASV9 JCL procedure, and then tell MXG you have the INFILE exit installed, using the (new in 24.24) SMFEXIT macro variable: //SYSIN DD * %LET SMFEXIT=CICS; %INCLUDE SOURCLIB(TYPE110); and MXG will read compressed and/or uncompressed records transparently. You can alternatively use ENGINE=CICS in your FILENAME statement to invoke the INFILE exit. - The LOAD MODULE must be named CICSIFUE. - The INFILE EXIT/ENGINE name is CICS. You need EXITCICS dated Mar 7. the Feb 28 didn't work. Thanks especially: Thanks to Rich Anderson, SAS Technical Support, USA, for his extensive testing and investigation that made this work! Change 25.016 Cosmetic. Variable SMFTIME was added to EXCLUDED FIELDS VMAC110 FOUND error message to identify when the record was Feb 27, 2007 written, so it could be compared with the time when the CICS Dictionary Records had been written. Thanks to Shirly Fung, HSBC, HONG KONG.
VMACNTSM is an INCOMPATIBILITY created by MXG Change 24.162, when Feb 25, 2007 the new variable BLKBINST was added to the BY list for the NTSM dataset BLKBERRY. The error only occurs in your WEEKly or MONTHly PDB build, and only when you have one or more PDBs that were created with the prior MXG version (i.e., the variable does not exist in the old datasets).
Adding a new variable to the BY list for an existing MXG dataset is done ONLY when it is absolutely needed. The primary reason MXG has a BY list for each dataset is to protect for duplicate records in the input file, When MXG uses the NODUP option in PROC SORTing from the "WORK" to the "PDB" library. The BY list must be complete so that duplicate observations are adjacent. A secondary reason is for retrieval performance; by creating datasets in sorted order, an extra SORT can be avoided in your report programs.
-Fix it permanently now, by adding the new variable to all of the old, existing DAYly and/or WEEKly PDBs that will be needed to build the new WEEKly and/or MONTHly PDBs, creating the variable with blanks for Character or a missing value for Numeric variables. You will need to look up the variable in the DOCVER member to find its DATASET, then the variable name in the listing to find the CHAR/NUM type and the LENGTH of the new variable, and then add that variable to all of the prior-built PDBs using this syntax: For a character variable: DATA OLDPDB.BLKBERRY; SET OLDPDB.BLKBERRY; LENGTH BLKBINST $32; BLKBINST=' '; or for a numeric variable: DATA OLDPDB.BLKBERRY; SET OLDPDB.BLKBERRY; LENGTH BLKBNUMR 4; BLKBNUMR=.; You will need to point "OLDPDB" to one of the prior PDB libraries that does not contain the new variable and run the datastep, then change "OLDPDB" to the next PDB, until all of the INPUT PDBs (dailies for WEEKBLD, or weeklies and dailies for MONTHBLD). And if the OLDPDB is a data library on TAPE media, it gets more complicated; you cannot have a TAPE PDB open for both INPUT and OUTPUT, and you cannot replace-in-place a dataset in a Tape media library, so you would need to use this syntax for each "PDB": PROC DELETE DATA=WORK._ALL_; PROC COPY IN=OLDTAPE OUT=WORK; DATA WORK.BLKBERRY; SET WORK.BLKBERRY; LENGTH BLKBINST $32; BLKBINST=' '; PROC DELETE DATA=OLDTAPE._ALL_; PROC COPY IN=WORK OUT=OLDTAPE; Once you have added the new variable to all of the INPUT PDB libraries, you can then rerun the WEEKBLD/MONTHBLD. -Fix it temporarily by redefining the _Bdddddd macro so it does not reference the variable for the WEEKBLD/MONTHBLD job:
-Look in the IMACxxxx member to find the "dddddd" text for the dataset with the error. In IMACNTSM, it lists that dddddd=NTBLKB for BLKBERRY dataset. -Then, look in he VMACxxxx member for _Bdddddd to find the BY list variables. In VMACNTSM, _BNTBLKB has MACRO _BNTBLKB DOMAIN SYSTEM BLKBINST STARTIME % -Then, in the //SYSIN for the WEEKly/MONTHly job, you would redefine the _Bdddddd macro with that variable removed: //SYSIN DD * %LET MACKEEP= MACRO _BNTBLKB DOMAIN SYSTEM STARTIME % ; %BLDNTPDB(your arguments for WEEKly/MONTHly); Since the new variable does exist in one of the INPUT data sets, it will be propagated into the new WEEKly PDB, so you would only need to use this circumvention for a maximum of five weeks, and then all of your Weekly PDBs will contain the new variable, and the redefintion of the MACRO _Bdddddd can be removed from your Monthly Job. However, this circumvention might fail due to NOTSORTED condition, (only if the "PDB" dataset had more than one value in BLKBINST variable); in that case, you would need to re-SORT those datasets using the _Sdddddd dataset SORT macro with the new _Bdddddd BY list definition: //SYSIN DD * %INCLUDE SOURCLIB(VMACNTSM);/*get _Sdddddd def*/ %LET MACKEEP= MACRO _BNTBLKB DOMAIN SYSTEM STARTIME % ; DATA WORK.BLKBERRY; SET PDB.BLKBERRY; _SNTBLKB
NOTE BENE: It is always STRONGLY recommended that you install a new version of MXG on the first day of your week, so that all of that week's daily PDBs are built with the same MXG Version. It just works better! Thanks to Terry Hein, ECOLAB, USA.
VMACNDM end of comment */ text. Feb 23, 2007 Thanks to Michael Creech, Fidelity National Information Svcs, Ind. Change 25.013 The PCTMVSBY in PDB.TYPE70PR when IRD was active and the VMAC7072 engine was not online for the entire interval were wrong; Feb 23, 2007 This also impacted the SHORTCPS value as well. Now, the SMF70ONT is used instead of DURATM for PCTMVSBY. Thanks to John A. Doan, T-SYS, USA.
VMAC99 because MXG thought there would always be a System State Feb 21, 2007 Information Section, but this record had none. The offset and segment length fields were populated, but the number of segments contained zero. Now, MXG tests segment count non-zero before reading that segment, and before OUTPUT of the TYPE99_1 dataset. This record contained Trace Table entries, so was thus a legitimate record. Thanks to Lawrence Jermyn, Fidelity Systems, USA. Thanks to Warren Cravey, Fidelity Systems, USA. Change 25.011A IBM Virtualization Engine TS7700 Series Statistics data TYPEBVIR can now be created as a RECFM=U or RECFM=VB History file, TYPSBVIR or those data can be written to SMF; this change supports VMACBVIR both the SMF and History file records. By default, MXG Feb 19, 2007 reads SMF data, but you must add MACRO _IDBVIR nnn % in Feb 26, 2007 IMACKEEP tailoring member to define your SMF record ID. To process the History File, change _SMF to _HISTFI in your TYPEBVIR or TYPSBVIR member. The Point in Time subtypes (01,02,10,11) are not written to the SMF file.
ANALMQMC it was preliminary and was replaced by revisions to the Feb 21, 2007 ASUMUOW program. The dataset MQMUOW is no longer created by ANALMQMC, as that logic is in a comment block, and now only ASUMUOW is executed with ANALMQMC is executed. Comments in the member were revised. Thanks to Harald Seifert, HUK-COBERG, GERMANY.
VMACTELE there were no changes to their SMF record. Feb 21, 2007 Thanks to Lawrence Hogg, NYU, USA. Change 25.009 The new ERASEPDB option was not set to a default; it is BLDSMPDB now set to YES. Feb 15, 2007 Thanks to Tom Kelman, Commerce Bank of Kansas City, USA. Change 25.008 -In IMACICOB, OMDBDB2LN should have been spelled OMBDB2LN. IMACICOB -In IMACICOM, QMMLN should have been spelled OMMQLN. IMACICOM Feb 15, 2007 Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
IMACICMR CMDDBCCP reversed; the correct order is CMDUDATA first. Feb 15, 2007 Thanks to Bill Keezer, SAS Institute, USA. Change 25.006 Support for MXG IMS Log processing for IMS Version 10: VMACIMS -For users of TYPEIMS7, members VMACIMS and TYPEIMS7 with TYPEIMS7 this Change 25.006 (in MXG 25.01) are required, and you ASMIMSL6 must update the _IMSVERS to 10.0 in IMACIMS7 in your JCLIMSL6 "USERID.IMSV10.SOURCLIB(IMACIMS7)" tailoring. Feb 19, 2007 -For users of ASMIMSL6,TYPEIMSA,JCLIMSL6 job stream, you Feb 27, 2007 reassemble ASMIMSL6 with the IBM IMS V10 macro library to create the "USERID.IMSV10.LOADLIB(MXGIMSL6)" for the PGM=MXGIMSL6 for your V10 jobstream. Yüklə 28,67 Mb. Dostları ilə paylaş:
|