* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
TYPENETP session logon, logoff, and disconnect/reconnect times. VMACNETP Aug 13, 1991 Thanks to Nancy Ayers, General Electric Lighting, USA.
VMAC74 not formatted as TIME12.2, but now they are. Aug 9, 1991 Thanks to Chuck Hopf, Primerica, USA. Change 09.116 NPM 1.4.1 support was not complete in MXG 9.3. The code VMAC28 does not fail, but messages (NON-ZERO COF, UNEXPECTED Aug 9, 1991 SUBTYPE, CALL HOME) are printed, and not all of the new Aug 12, 1991 subtypes were output. Several changes were required. Thanks to Jim Shumaker, American Express, USA.
TESTIBM2 a 6000K region under 5.18 because TYPE102, instead of Aug 8, 1991 TYPE102A,TYPE102B are included in MXG 9.3's TESTIBM2. This change uses a %MACRO to detect which SAS version is used and includes TYPE102 if under 6.06+, or includes the pair TYPE102A, TYPE102B if under 5.18. Thanks to Diane Eppestine, Southwestern Bell, USA.
UTILGEVX referenced the non-existent member (MACROS) and had the Aug 8, 1991 wrong macro names. The INCLUDE for (MACROS) should have been for (VMACVMXA), the _INFILE should be _MWINPUT, and the _ENFILE should be _MWENDIT. The comments should say the input comes from fileref MWINPUT and VB records are written to fileref OUTFILE. Thanks to Jay Cicardo, Southwestern Bell St. Louis, USA. Change 09.113 The VSAM Sharing Options in the VVDS were not fully VMACVVDS decoded in the two flag variables VVRA2REG/VVRA2SYS. Aug 8, 1991 Two new variables with values 1, 2, 3, or 4 for both the cross-system and cross-region share options now are created with: VVRSHREG=FLOOR(INPUT(VVRATTR2,PIB1.)/64)+1; VVRSHSYS=MOD(FLOOR(INPUT(VVRATTR2,PIB1.)/16),4)+1; Thanks to Jeff Fox, SKF USA, Inc, USA. Change 09.112 In analysis of ESA benchmark data, I discovered PERFGRP VMAC30 and MULTIDD was not kept in TYPE30_D and PDB.DDSTATS. Aug 8, 1991 Now they have both been added to the KEEP= list. Thanks to Chuck Hopf, Primerica, USA. Change 09.111 MXG recommended half-track BLKSIZEs of 23040/27647 for CONFIG 3380/3390s but did not realize SAS 6.06+ has an option CONFIG07 specifically for DASD, and there is also a TAPE option. Aug 7, 1991 Now, MXG CONFIG/CONFIG07 contain BLKSIZE(DASD)=HALF BLKSIZE(TAPE)=MAX Thanks to Chuck Hopf, Primerica, USA.
ASUMCICS 7.1 summarization code had stored SYSID into APPLID to Aug 7, 1991 create APPLID, but that line now causes APPLID to be truncated to 4 bytes with 8.1. Change line 008700 from APPLID=SYSID; to read
IF APPLID=' ' THEN APPLID=SYSID; and add APPLID to the KEEP= in line 006200. This change will only work with Landmark 8.1 data; the datasets built from 7.1 data records does not contain the variable APPLID, so the change must coincide with your implementation of TYPEMON8 processing of 8.1 data. Thanks to Freddie Arie, Lone Star Gas, TEXAS.
CHANGES The 9.3 label printed on the tape was correct, but the INSTALL change from 6160 was not stated. Worse, a note in the Aug 7, 1991 Installation section of Newsletter TWENTY said the tape BLKSIZE was 23440, which it never has been! The tape blocksize had to be increased so that MXG 9.3 would fit on a 600-foot 3420 reel, but it also reduced the time to create 3420 or 3480s. The BLKSIZE=32720 will now be used for all future MXG Versions. Sorry for my carelessness!
JCLPDB6 pointing to your format library because Change 9.094 now JCLTEST uses the MXG MGBYTES format. In JCLPDB6, a // is needed JCLTEST6 before the OPTIONS= parameter on the EXEC statement. Aug 7, 1991 Thanks to Mark Delorme, Minnesota Power, USA. --Changes thru 9.107 were contained in MXG PreRelease 9.3, Aug 1, 1991-- Change 09.107 MONITASK variable TATASKNR contains transaction counts TYPEMON8 for history records, but Landmark's Release 8 relocated Jul 30, 1991 the field to what MXG read as TASINTL1 $CHAR4. Now, that input is TATASKNR PIB4., the original TATASKNR is now unkept variable TATASKNN, and TASINTL1 was never kept. Thanks to Annette Miller, Dale Electronics, USA. Change 09.106 IMS multiple-message transactions resources were wrong. TYPEIMS Lines 145300-148400, which calculate the average DL/I, Jul 30, 1991 CPU, etc., must be moved to after line 144200, so that the average is calculated only once, instead of being a moving average. Thanks to Russell Dewar, NM Computer Services, AUSTRALIA. Change 09.105 Change 9.100 discussed the new DROP,KEEP,RENAME warning. DOC While initially I did not like the default of warning, Jul 30, 1991 it appears to be worthwhile; it uncovered many cases of misspelled variables in KEEP lists that were not being output, and some cases of variables that should have not been in the KEEP list, when I ran the MXG 9.3 QA runs. All members that could be corrected were, but some MXG members intentionally contain unreferenced variables, and these members may produce warnings (which have no real impact, except for the condition code four!): VMAC6 VMAC40 VMAC110 The protection in BUILDPDB/BUILDPD3 was extended to suppress warnings for the entire member.
ANALDBTR NOT SORTED error in S008S009, S0015S018, or S059S058 due Jul 28, 1991 to a misspelling in ANALDBTR. The error occurs only if a one of these trace events was incomplete, i.e., when a start event or end event record was not in the input. These three sets of variables were reversed: Line Now Should be 049000 IF E008TM=. IF S008TM=. 049400 IF S008TM=. IF E008TM=. 068100 IF E015TM=. IF S015TM=. 068500 IF S015TM=. IF E015TM=. 164500 IF E059TM=. IF S059TM=. 164900 IF S059TM=. IF E059TM=. Thanks to Bob Farrell, Sun Alliance, ENGLAND. Change 09.103 -A minor revision to ANALPATH was provided by its authors ANALPATH to deal with a divide by zero if no prime shift data was IMACPDBX used for the analysis. Jul 28, 1991 -The new member IMACPDBX will undoubtedly replace the MXG IMACPDB, but is placed in a separate member for sites to validate its architecture. Dan Kaberon has implemented a slick technique that lets you trivially change the variables that are sum/min/maxed from the steps data to PDB.JOBS, and you no longer have to count and set up the "dummy" X variables in the original IMACPDB. The new member also added three variables, PGSUSED PGSGLOAD and SHEETPRN to the PDB.PRINT data set. Thanks to Dan Kaberon, Hewitt Associates, USA.
BUILDPDB interval, or job, if more than 1476 DDs are in the task. BUILDPD3 MXG has always created separate observations for each of IMACPDB these "Multi-DD" records, which contain only EXCP/IOTM VMAC30 resource fields. However, several elapsed time measures Jul 28, 1991 calculated by MXG from timestamps (ALOCTM,DSENQTM,EXECTM RDRTM,SELAPSTM) should not have been calculated, and are now set missing. A new variable, MULTIDD='Y' is created to flag these records in TYPE30_4, TYPE30_5, TYPE30_6, and TYPE30_V datasets. If the need is demonstrated in the future, MXG may add logic to sum the MULTIDD type 30 into a single record, but the cost of double processing does not seem necessary at this time. For now, flagging these "pseudo-step" records and ensuring there is no duplication of these elapsed time measures is enough. MULTIDD was also added in IMACPDB to the _PDB30_4 list. -The MULTIDD records for TYPE30_V intervals have another problem; the begin of interval INTBTIME does not exist (has missing value) in the second and subsequent MULTIDD record (because IBM puts it in the processor accounting section, which is not created in MULTIDD records!). The INTBTIME cannot be retained from the first record to the subsequent records while processing SMF data, because other SMF records from other tasks can be sent to SMF in between the first and subsequent intervals of our job. It was necessary to modify the logic of BUILDPDB/3 to add an extra PROC SORT and logic to fill in the missing INTBTIME, so that sites who wish to account using their interval records can cluster the MULTIDD records. If your site creates interval records, you probably want to have this corrected, and if there is no interval data, there is no cost to this enhancement of PDB.SMFINTRV. Note this change does not correct the TYPE30_V data set built by member TYPE30, but only the PDB.SMFINTRV data set built by BUILDPDB/BUILDPD3. -Two other problems with MULTIDD records were corrected in BUILDPDB/3. The variable STEP was a counter of step records found, but it was also being incremented for each of the MULTIDD records. STEP is now incremented only for the actual step record, not for the MULTIDDs. The variable RESTART was a counter of job restarts, but it too was being incremented for each MULTIDD record. Now it only counts real job terminations as RESTARTS. Thanks to Diane Eppestine, Southwestern Bell, USA. Change 09.101 DOS/VSE Landmark CICS records are non-standard formats. TYPEMOND Each block begins with 2-byte block length, followed by Jul 27, 1991 two 4-byte length fields, the second of which contains the data-length of the following data record. The 4-byte pairs and data records are then repeated. This format can be read with the following changes to TYPEMONI for Landmark 7.1 records. The new member TYPEMOND contains this change, but the logic has not been data-tested yet. Replace With INPUT INPUT BLKLEN PIB2. @; LENGTH PIB2. LOC=COL; MFSREC $CHAR1. DO WHILE (COL+8 LT BLKLEN); @; INPUT @LOC FIRSTLEN PIB4. LENGTH PIB4. MFSREC $CHAR1. @; LENGTH=LENGTH-2; Immediately before the percent sign before MACRO _ANALMON insert LOC=LOC+FIRSTLEN; END; Thanks to ???, ???, EUROPE. Change 09.100 SAS 6.07 compatibility. SAS validation of variables in BUILDPDB KEEP, DROP, or RENAME statements or options was never BUILDPD3 consistent; an unreferenced variable in a "D,K,R" could CONFIG07 print an error, a warning, or no warning, depending on Jul 27, 1991 whether the "D,K,R" was an option or a statement and/or whether the "D,K,R" was for input or output. SAS 6.07 now consolidates the action by input or output and has two new options, DKRICOND and DKROCOND which can set the action to be taken to ERROR, WARN, or NOWARN. By design, MXG has unreferenced variables in KEEP= lists for output and since the SAS 6.07 default is WARN, many unnecessary WARNING message will be printed on the log, and the step will end with condition code 0004. These warnings can be eliminated by adding DKROCOND=NOWARN to the CONFIG member of MXG, but then SAS 6.06 will fail because this option is unknown to SAS 6.06! As a result, there is a now a new member, named CONFIG07, for SAS 6.07 which has DKROCOND=NOWARN specified. Just in case you miss this note, however, BUILDPDB/3 are specifically protected by the addition of %MACRO VMXGDKRN to set NOWARN during the SMF processing phase under 6.07 or later: %MACRO VMXGDKRN; %IF %SUBSTR(&SYSVER,1,4) GE 6.07 %THEN %DO; OPTIONS DKROCOND=NOWARN; %END; %MEND
%VMXGDKRN; and after the DATA step there is a %MACRO VMXGDKRW to reset the option to DKROCOND=WARN. This may change as more experience with these new options accumulates. Thanks to Rick Langston, SAS Institute Cary, USA.
VMXGVTOC number of tracks allocated for the VTOC; not the total VMXGVTOF tracks on the volume. This change summarizes the detail Jul 27, 1991 information into VTOCINFO, correcting TRKSALOC, and adds variables TRKSUSED, NUMDSN, PCTALOC to make the VTOCINFO dataset more meaningful for DASD capacity analysis. Additionally, in the VMXGVTOF member only, each volume's UNITADDR, UCBTYPE, and STARTIME (of the ASMVTOC run) are now added to the VTOCINFO dataset. These fields were at the end of the record created by ASMVTOC, but were not kept in MXG's processing. Thanks to John Mattson, National Medical Enterprises, USA. Change 09.098 The original members WEEKBLD and MONTHBLD contained both JCLWEEK JCL and SAS code, which required unnecessary JCL changes JCLMONTH due to SAS or SAS changes due to JCL. This change puts WEEKBLD the sample JCL in members JCLWEEK and JCLMONTH and has MONTHBLD only SAS code in WEEKBLD and MONTHBLD. The JCL examples Jul 27, 1991 in these members (an in all future JCL examples) will be only for the SAS Version 6 environment.
CONFIG track (See SAS Notes in Newsletter TWENTY). Since these Jul 26, 1991 libraries are RECFM=FB,LRECL=512, the correct half track data library block sizes are Data libraries: 3380 BLKSIZE=23040 3390 BLKSIZE=27648 Member CONFIG now specifies BLKSIZE=23040 as default. -The MXG Default BUFNO=2 is now specified in CONFIG. With a half-track BLKSIZE, transferring one track of data per SSCH results when BUFNO=2 is specified. The incremental gain of additional buffers above 2 does not seem needed and I have always felt righteous if I transferred data for 1 revolution and then freed the device to other users. Since the virtual storage required for each SAS data set is BUFNO*BLKSIZE, reducing BUFNO from 3 to 2 concomitant with the above BLKSIZE increase will mitigate MEMSIZE. I plan further benchmarking to see if there really is a value in increased BUFNO (only even values make sense), but early results show half track and BUFNO=2 gives very good performance and minimized resources reasonably. -The increased BLKSIZE value has increased the virtual storage required for the INFILE processing parts of MXG, so MEMSIZE=24M is now specified (increased from 12M) to ensure unnecessary "out-of-virtual-memory" ABENDs. Since MEMSIZE is above the line virtual storage, I don't think this increase will affect any real resources, and SAS only gets what it needs anyhow. -The option ERRORS=2 was added, so that if you get any invalid data hex dumps, only the first two will be on your log, instead of the SAS default of the first 20. Change 09.097 HSM 2.6 SMF records were changed INCOMPATIBLY. The DSR VMACHSM and VSR have new fields, VSR fields (VSRTBAK,VSRTALC, Jul 24, 1991 VSRNDSV, and VSRTCPU), are now reserved, and bit fields are now decoded into new variables. MXG supports not only HSM 2.6, but also HSM 2.4 and 2.5 SMF records. Thanks to Joseph J. Faska, Depository Trust, USA Change 09.096 VM/XA messages "LOGICAL RECORD SPANS PHYSICAL BLOCK" are VMACVMXA incorrectly printed on the log. The error was introduced Jul 22, 1991 by Change 8.244; line 005970 must be (COL-5+MRHDRLEN). Fortunately, the datasets built were valid, but the MXG messages sure filled pages of your log! Thanks to Rob Owens, SAS Institute Europe, GERMANY. Thanks to ???, ???.
BUILDPDB dataset TYPE0203 in your PDB, so you can keep track of BUILDPD3 when SMF data was dumped; a type 2 record is written at VMAC0203 the start of each SMF dump (IEASMFDP) and a type 3 is Jul 21, 1991 written at the end of each dump. Back to back type 2s indicates probable duplicate data, because a dump was started but failed to complete. Member VMAC0203 was also changed, to create variable RECNUM, the record number of each 2 or 3 record, in case you need to strip out duplicated records. Change 09.094 The _SMF macro, used by all SMF processing programs, now VMACSMF prints a message on the log "MXG SUCCESSFULLY READ SMF" Jul 21, 1991 with the number of records AND the number of megabytes of data that was found in your SMF file. Change 09.093 This revision of existing TRND72 member adds several new TRND72 MVS/ESA 4.2 variables to the TREND.TRND72 dataset. Jul 20, 1991 Thanks to Chuck Hopf, Primerica, USA. Change 09.092 Trending of TYPE71 data is added by this change, using TRND71 the WEEK.TYPE71 dataset as input. (Since the TYPE71 Jul 20, 1991 data already exists as one observation per interval, there is no need for an "ASUM71" member.) Thanks to Chuck Hopf, Primerica, USA.
ASUM70PR by this change. Member ASUM70PR creates PDB.ASUM70PR by TRND70PR summarizing TYPE70PR into one observation per interval Jul 20, 1991 for each system. (If you have more than one MVS system running, remember that each one creates observations in TYPE70PR for each SYSTEM. Either SYSTEM or LPARNAME has to be used to avoid duplication in your reporting. MXG keeps all SYSTEMs found in TYPE70PR). Member TRND70PR takes the WEEK.ASUM70PR, and adds its new data to the TREND.TRND70PR data, which can be used for tracking the utilization of all your LPARs. Thanks to Chuck Hopf, Primerica, USA. Change 09.090 ASUMCICS used more temporary work space than needed, as ASUMCICS some variables were not dropped, and no LENGTH statement Jul 20, 1991 was used. After line 003400 (DATA NULLCICS;) insert LENGTH DEFAULT=4 ENDTIME STRTTIME 8; After line 009199 (END;) insert DROP ENDTIME FILECN PRIINCHR PRIOUCHR RESPONSE SYSID TRANSACT;
TRNDVMXA correct. PFXUTIME was wrong because it should be in the Jul 18, 1991 NORM13 list instead of NORM1. PCTCPUBY was wrong because it is recalculated and uses PFXUTIME! Thanks to ???, 3M Europe, GERMANY.
EXTYSPMC their user SMF record. The original VMACSPMS supported EXTYSPME SPMS Release 1.0, but that code was temp VMACSPM0, and VMACSPMS VMACSPMS now contains support only for SPMS 1.2. There are two data sets created now, SPMSCED "Cache Extent Jul 18, 1991 Definition" statistics, for each CED (which might be an entire volume, or just a data set), and SPMSEXT "Cache Extent" statistics, for each EXTent (which will normally contain one observation for each CED, unless the dataset in the CED is itself in extents). Although statistics can be captured in the CED part of the record, there is an option to disable statistics in the CED, so MXG will create the sum of the EXT data and store into the CED dataset, which seems to be the most likely dataset of general interest, and by summing the EXT data into the CED, either data set will be valid. Note that some of the fields may not be valid; SPMSATBC contains negative values. Amdahl is investigating. Thanks to Elliot Weitzman, Oryx Energy Company, USA.
IMACFILE showing how to write SMF records out to an OS file now Jul 18, 1991 has a FILE LOG; statement after the PUT _INFILE_ so that and error messages PUT by MXG will be sent to the log. Without the FILE LOG; statement, error messages were written to the output SMF file! Thanks to Brenda Rabinowitz, Prudential-Bache Securities, USA.
VMACACF2 processed. They are now output in the ACF2JR dataset. Jul 18, 1991 The LID at the end of these records is not currently decoded; since the records themselves were not output, it is not clear the contents of the LID are needed, but that will change if users request it! The change was to change ELSE IF ACSMFREC='L' AND ACSMFFCN LE 2 THEN DO; to ELSE IF ACSMFREC='L' THEN DO; in line 049400, and change IF ACSMFFCN=2 THEN DO; to IF ACSMFFCN GE 2 THEN DO; in line 050200. Thanks to Rachel Bromage, L.O.L.A., ENGLAND.
VMAC6 before SMF is fully up) have no JES number and their VMAC26J2 JCTJOBID variable contains job name. The logic added in VMAC26J3 MXG 8.8 to support the APPC TYPETASK tested JCTJOBID to VMAC30 see if it started with an "A", but this caused "Invalid VMAC32 Data Error" for JESNR if the STC happened to start with Jul 18, 1991 an "A" (like ACF2!). This change reorders the logic to first recognize an early address space (JCTJOBID=JOB) to set TYPETASK='STC ' and JESNR=., or otherwise use the original logic to determine TYPETASK and JESNR. The only impact were messy record dumps on the log when MXG tried to read characters as numbers! Thanks to Stephen Tull, State Energy Commission of W.A., AUSTRALIA.
VMAC110 Its old contents, the count of load requests, was moved Jul 18, 1991 to new variable PCLOADCT, which will be non-missing in all CICSs, and the old variable PCLOADCN contains the count of actual loads. The change occurred in MXG 8.8 but was not documented. Thanks to Ms. Ericson, EDV Gmbh, Vienna, AUSTRIA.
BUILDPDB but did not elaborate on its significant effect on lines VMAC6 printed counting in MXG. The APAR changes the variable Jul 17, 1991 OUTDEVCE (SMF type 6 field SMF6OUT). Formerly, OUTDEVCE was the name of the output device to which the print was sent, e.g., PRINTER1, PUNCH2, or R196.PR1 for a remote printer, R196.PU1 for a remote punch (remember, external writers for microfiche and other devices often "punch"). The APAR changed OUTDEVCE to contain the VTAM LUNAME of the printer, which no longer contains indication of the type of device to which print was sent. MXG still uses Yüklə 28,67 Mb. Dostları ilə paylaş:
|