* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
use this logic for USA East Cost time zone in EXCICTRN: IF MCTMNTAD=. THEN MCTMNTAD=.; IF MCTMNTAD=. THEN DO; STRTTIME=STRTTIME-HMS(5,0,0); ENDTIME =ENDTIME -HMS(5,0,0); END; to force the 5-hour conversion for non-4.1 regions. The first statement setting MCTMNTAD missing if it is missing if the "compiler faker" statement which eliminates the "uninitialized variable" message, so you could install this logic in EXCICTRN even before you install MXG 13.07! Variable MCTMNTAD was added to CICSTRAN by this change. Thanks to Glenn Yee, Health & Welfare State of California, USA. Change 13.246 Variable SETUP was added to _PDB26J2 macro so that that IMACPDB variable will be kept in the PDB.JOBS dataset. It turns Oct 25, 1995 out that the existence of a /*SETUP card causes JES2 to put the job in logical hold until the operator releases the job, but TYPRUN=HOLD is not set for these jobs. Now, for observations with SETUP='Y' in PDB.JOBS, you can identify these jobs that are delayed due to /*SETUP card. Thanks to Andy Vick, Allied Dunbar Assurance, ENGLAND. Change 13.245 In revision 4 of the type 6 SMF record, IBM truncated two VMAC6 bytes of SMF6TU field, but in revision 5 data, the value Oct 25, 1995 in SMF6TUL matches the length of SMF6TU, so the line that was added by Change 13.162 is now changed to read: IF REVISION EQ 04X THEN SMF6TUL=SMF6TUL-2; I have not found IBM documentation of their change yet! Thanks to Michael Moyer, Wyeth-Ayerst Labs, USA.
ANALDB2P statistics and accounting records, new subtypes and new EXDB2ACG segments create three new datasets: EXDB2PAT
EXDB2PST DB2ACCTG - Accounting - Group Buffer Pool usage VMACDB2 DB2GBPAT - Global Buffer Pool Attributes VMACDB2H DB2GBPST - Global Buffer Pool Interval Statistics Oct 22, 1995 The major change is the support for DB2 Parallelism, with multiple observations now created in DB2ACCT whenever DB2 event (like a QUERY) is actually parallelized. The degree of parallelism for a CPU bound task is constrained by the number of CPU engines, while it is the structure of your DB2 data (number of partitions, etc.) which limits the degree of parallelism for an I/O bound task. New member ASUMDB2P can be used to summarize these child and parent pairs (and the sequential, or non-parallelized DB2 events) so that there is only one observation for each event, with variables PAIRNR (a created sequence number token that was used to create ASUMDB2P from DB2PARTY), NRCHILD (number of children records for this event), and TOTELAPS (sum of elapsed time of all records for this event, because ELAPSTM is the true elapsed wall time of the parallel execution). Beware, sorting DB2ACCT is required to create both the DB2PARTY detail dataset and the output ASUMDB2P dataset, and DB2ACCT can be big! The parent record has a non-zero QXMAXDEG, the maximum number of parallel tasks, but there can be many more than QXMAXDEG children records written, because tasks can be parallelized in groups of different degrees. MXG creates formatted variable DB2TSKTY to describe each observation in DB2ACCT: DB2TSKTY Description C Child
P Parent S Sequential (i.e., non-parallelized) Complex queries in test data shows an event of three groups, with 9, 10, and 8 children respectively, so 28 observations in DB2ACCT were created for that parallelized query event. Almost all of the resources (CPU, I/O) are recorded in the child record, but the parent record contains important counts as well. Extensive testing of DB2ACCT data was done in creation of member ANALDB2P for parallel analysis, but the test data thus far has not used Global Buffer Pools, so those new datasets have not been data-tested. I have only casually validated the DB2STATS with 4.1 data for reasonableness, and VMAC102 has not yet been enhanced (I still await 4.1 trace test data). This note will be revised as testing proceeds. Change 13.243 MXG did not output observations to HURN49 if HU49XSNO is VMACHURN zero (user logs on to Huron server, but did not access Oct 20, 1995 another database before logging out). After the END; after the DO I=1 TO HU49XSNO; insert: IF HU49XSNO=0 THEN DO; %%INCLUDE SOURCLIB(EXHRN49); END; Thanks to Colin Bowen, Old Mutual, SOUTH AFRICA. Change 13.242 Correcting TYPE42DS STARTIME/ENDTIME from GMT to local in VMAC42DS exit EXTY42DS using STARTIME=STARTIME-HMS(5,0,0) (to EXTY42DS subtract 5 hours, for EST or CDT time zone) will not work Oct 19, 1995 because the EXTY42DS member will be invoked once for each dataset in a concatenation, causing STARTIME to be fine in the 1st dataset, but then off by 5 hours in the 2nd, off by 10 hours in the 3rd, etc. Instead, you must use STARTIME=SMF42PTS-HMS(5,0,0); and ENDTIME= SMF42PTE-HMS(5,0,0); to force the correct GMT value. When you have installed MXG 13.07 or later, you can revise your exit logic to use IF S42JDGMO=. THEN DO; STARTIME=SMF42PTS-HMS(5,0,0); ENDTIME= SMF42PTE-HMS(5,0,0); END: because MXG 13.07 adds support for APAR OW16125 that adds the actual GMT offset in S42JDGMO; with this revised code your forcing code will only be executed prior to install of that APAR. This is a documentation-only change; no MXG code was actually changed. Thanks to Diane Eppestine, Southwestern Bell, USA.
IMACSPCK decision "TO SPIN OR NOT TO SPIN" for specific cases. BUILDPDB For example, VM Print Jobs, run on MVS, will create only BUILDPD3 a type 6 print record. If you have tailored IMACSPIN so BUILD005 that SPINCNT is greater than zero (as recommended), those Oct 19, 1995 VM jobs will spin for SPINCNT days before finally being output into the PDB. If you know that all VM Print jobs have job names starting with RSCS, you can use this new IMACSPCK member, by coding therein: IF JOB=:'RSCS' THEN OKFLAG=1; which will sent all RSCS jobs directly to the PDB instead of waiting around in the SPIN library for SPINCNT days! The default exit contains only comments. Thanks to Norbert Korsche, OMV, AUSTRIA. Change 13.240 Dataset ASUMDB2B was not created in the weekly PDB from WEEKBLD the daily PDB's, but now it is. WEEKBLDT Oct 17, 1995 Thanks to Merlin Beeching, Generale de Banque SA, BELGIUM.
SASAFIX1 point value is unnormalized. See MXG Technical Note in Oct 15, 1995 Newsletter TWENTY-NINE for discussion. This member is an Nov 8, 1995 interim fix for MXG users executing under ASCII platforms and currently contains two SAS programs that will create the UWIS370F.DLL file for OS/2 SAS 6.10 or 6.11. -Nov 8. The OCT 15 fix returned a large negative value if the field was all hex zero, but that is now corrected, and SASAFIX1 now provides fixes for SAS for OS/2 for both 6.10 and 6.11 and for SAS for Windows for 6.10. Thanks to Ian Gibson, Queensland Transport, AUSTRALIA.
DIFFHMF semicolon is missing from each of the 6 LABEL statements, Oct 14, 1995 also causing UNINITIALIZED warning message.
IMACZDAT that you can easily force ZDATE to a specific date for a DOC rerun of a build job. Previously, you had to change the Oct 14, 1995 value of ZDATE in a separate place for each infile that you had to rerun. All of the associated statements to describe ZDATE (LENGTH, LABEL, FORMAT) were moved into the IMACZDAT member, and each statement ZDATE=TODAY(); or IF ZDATE=. THEN DO; do group were replaced with the %INCLUDE or %%INCLUDE syntax for member IMACZDAT. There were 113 members changed in response to this suggestion, which will surly make someone very happy some day! Thanks to Bruce Hewson, Alcoa, AUSTRALIA. Change 13.236 The execution delay percentage variables in TYPE72GO used VMAC7072 the workload manager sample count (VALDSAMP=R723MTVN;) as Oct 14, 1995 denominator, but that statement is now replaced with: VALDSAMP=PCTUSCUS+PCTDLTOT+PCTDLUNK; because the workload manager counts both address spaces and dispatchable units in the numerator (eg., an ASID may have an SRB executing and a TCB waiting). This discovery by Don was non-trivial and has been IBM-confirmed! Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
UDOCHECK statements to locate DO ... END pairs when you have one Oct 13, 1995 of those painful "MISSING END STATEMENT" syntax errors, often caused in my experience because a comment swallowed the END; statement) did not support DO WHILE / DO UNTILs. Thanks to Wayne Bell, National General Insurance Company, USA. Change 13.234 Variable NLDMSUBT should have been added to TYPE39_8 but VMAC39 it wasn't until now. Oct 13, 1995 Thanks to Wayne Bell, National General Insurance Company, USA. Change 13.233 MXG 13.06. Support for Landmark for DB2 V 2 has now been VMACTMDB tested with data which found undocumented alignment bytes Oct 27, 1995 and changed header, causing STOPOVER. In addition, many variables were not formatted that are now. Thanks to Ken Updegraff, Hershey Chocolate, USA.
VMACAPAF are 10000 times too small. Change their informat from Oct 17, 1995 &PIB.4.6 to &PIB.4.2 to correct. Additionally, variables LPMINPnn, LPTARPnn, and LPMAXPnn are now created with the Percentage allocation for each logical processor. Thanks to John Suters, Telecom Australia, AUSTRALIA. Change 13.231 The calculation of ARSPNET was sometimes incorrect. The VMACNSPY statement IF NETRSPNO GE .5*TRANSNO AND TRANSNO GT 0 Oct 12, 1995 THEN ARSPNET=CRSPNET/TRANSNO; should be ... THEN ARSPNET=CRSPNET/NETRSPNO; Thanks to Alan Keebel, British Steel, ENGLAND.
VMAC64 EXCEEDED RECORD error. The five lines at the end: Oct 11, 1995 INPUT BEGCCHHX PIB4. ENDCCHHX PIB4. +18 @;
must be replaced by this single corrected line: ALLOCCYL=ALOCCYL+ENDCCHH-BEGCCHH+65536; Thanks to Freddie Arie, Lone Star Gas, TEXAS.
WEEKBLDT ORDER error. The correct _BYLIST for TAPEMNTS is: Oct 11, 1995 MACRO _BYLIST SYSTEM SHIFT DEVICE TMNTTYPE TMNTTIME % . Thanks to Neil Ervin, Huntington Services Company, USA. Change 13.228 MVS/ESA V5 in Goal Mode only. Pre-Goal Mode, MXG only EXTY72GO output TYPE72 when the PERFGRP had activity (to save DASD FORMATS space, because IBM created segments for idle perfgroups), VMAC7072 and so in Goal Mode, MXG only output TYPE72GO when the Oct 10, 1995 SRVCLASS consumed resources (by testing, in EXTY72GO, for non-zero CPUUNIT,SRBUNIT,IOUNIT,MSOUNIT or TRANS). However, that test should only have been applied against service classes for address spaces (as only ASIDs contain resources). The result was that observations for trans service classes that had no completions during the interval were not output. The test should have been qualified by R723TYPE, as it describes which type of record we have. However, then I discovered that R723TYPE was missing in some MVS/ESA 5.2 data, because the resource flag, R723CRCA, was not set, and that had previously been a legitimate identifier that an observation was an address space. As a result of this discovery, I had to redefine the way R723TYPE is created: IF RPRTCLAS EQ 'Y' THEN DO; IF R723CRCA EQ 'Y' THEN R723TYPE='4';/*REPORT, ASID */ ELSE R723TYPE='5';/*REPORT, TRAN */ END;
ELSE IF R723CWMN GT 0 THEN R723TYPE='3';/*TRANSACTION*/ ELSE DO;
IF R723CRTX GT 0 THEN R723TYPE='1';/*ASID SC WITH RESP*/ ELSE R723TYPE='2';/*ASID SC NO RESP*/ END; -Now, with the correct definition and setting R723TYPE values, the logic in EXTY72GO could be changed so that only observations that could contain resources are tested to see if they should be output, using: IF R723TYPE IN(1,2,4) THEN DO; IF SUM(CPUUNITS,SRBUNITS,IOUNITS,MSOUNITS,TRAN) GT 0 THEN OUTPUT _LTY72GO ; END: ELSE OUTPUT _LTY72GO; With these changes, R723TYPE will be valid for all obs, and only those resource-containing observations written for Address Space Service Classes or Report Classes will be output by the exit. -Also discovered, the format names in member FORMATS for $MGRMFTY and $MGRMFRT were reversed. $MGRMFTY describes the type of record, while $MGRMFRT describes responses. Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA. Change 13.227 The VAX Accounting Support was designed for execution on VAXPDS ASCII platforms, which caused errors when executed under Oct 10, 1995 MVS. The RECFM=N for ASCII must be RECFM=VB for MVS, so I now have added a macro %%VMXGLRF in place of RECFM=N on each INFILE statement, and defined VMXGLRF to set the correct RECFM depending on where MXG is being executed. Also, the broken vertical bar character ('6A'x onMVS) used for concatenation was replaced with the exclamation points ('5A'x on MVS), because the '6A'x character is not correctly translated between ASCII and MVS systems. Thanks to Frank d'Hoine, Nationale Bank van Belgie, BELGIUM
VMAC42 subtype 6 (TYPE42DS dataset) observations. If the APAR Oct 10, 1995 has been installed, new variable S42JDGMO will be non missing, and MXG will have converted STARTIME and ENDTIME from GMT to local time of day. If S42JDGMO is still missing, the APAR is not installed, and STARTIME/ENDTIME will still be on the GMT clock.
VMAC30 be really far from the truth, because the line inserted: Oct 9, 1995 by that change: GMTOFF30=GMTOFF30+SMF30IST-INTBTIME; /*GET LEAP SEC*/ must be deleted. In attempting to correct IBM's error, I made the problem worse, by adding that heuristic that worked with my test data, but failed badly with different data. Removal of this line may still cause the problems that were discussed in 13.065, but it is the safest approach for "normal" sites. Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
EXTMDxxx changed their records, so MACRO _TMDVER is now defined in IMACTMDB member IMACTMDB to tell MXG to process version 2 records. VMACTMDB (The default in IMACTMDB expects Version 1 data records, Oct 8, 1995 so you MUST tailor IMACTMDB to process Version 2. The previous support created only TMDBDA,TMDBDB,TMDBDE, and TMDBDR datasets. For version 2, datasets TMDBDA2, TMDBDB2, and TMDBDE2 will have observations while their un-suffixed counterparts will only have observations with version 2, and TMDBDR no longer exists with version 2. These new version 2 data sets are now created and will have observations if their subtypes are found: TMDBDBA, TMDBDAB, TMDBDAF, TMDBDBB, TMDBDDF, TMDBDBK TMDBDBR, TMDBDW , TMDBDC. In addition, these new datasets are defined and will have observations, but only the record header is decoded for these subtypes at this time: TMDBBB , TMDBBC , TMDBBD , TMDBBE , TMDBBF , TMDBBG TMDBBH , TMDBBI , TMDBBJ , TMDBBK , TMDBBL , TMDBBM TMDBBT , TMDBDD This combined support for both versions has not been tested with data records, but the original code and the Version 2 code contributed by Peter were separately tested before I restructured and merged the code into the single VMACTMDB member, and no error have surfaced. Thanks to Peter Proppe, Bremer Lagerhaus Gesellschaft(BLG), GERMANY. Thanks to Ken Updegraff, Jr., Hershey Chocolate, USA.
VMACIDMS CA INCOMPATIBLY changed their PERFMON SMF record. MXG Oct 8, 1995 should have detected their change and deleted the changed Nov 14, 1995 record and print a NOTE on the log, but their change exposed an MXG logic error in detecting IDMS changes, and MXG ABENDed with INPUT STATEMENT EXCEEDED RECORD LENGTH. (In my defense, even CA IDMS Tech Support did not know THAT there was a change, nor WHAT fields were changed until I read this text to them!) Originally I thought the change was introduced in IDMS 12.01, but it is their maintenance level 9506 that contains the new data fields. -Delete the final IF SKIP GT 0 THEN INPUT +SKIP (the one after the END; /* END SUBTYPE 18 */ statement). This will eliminate the STOPOVER condition with 12.01 data, However, datasets IDMSARA, IDMSBUF, IDMSDBK and IDMSJRL will still be wrong because field lengths were changed. -To process ONLY 12.01 data, you could make these changes: After PMHRTYPE=1, change INPUTs of ARANAME $EBCDIC16. to ARANAME $EBCDIC27. ARAFILE $EBCDIC16. to ARAFILE $EBCDIC27. ARABUFR $EBCDIC16. to ARABUFR $EBCDIC18. INPUT ARAFPERA &PIB.2. /* #FILES FOR AREA*/ and change SKIP=SKIP-184 to SKIP=SKIP-208; After PMHRTYPE=2, change INPUTs of BUFNAME $EBCDIC16. to BUFNAME $EBCDIC18. and change SKIP=SKIP-120 to SKIP=SKIP-122; After PMHRTYPE=6, change INPUTs of JRLNAME $EBCDIC16. to JRLNAME $EBCDIC27. and change SKIP=SKIP-120 to SKIP=SKIP-131; After PMHRTYPE=18, change INPUTs of DBKAREA $EBCDIC16. to DBKAREA $EBCDIC27. DBKFILE $EBCDIC16. to DBKAREA $EBCDIC27. and change SKIP=SKIP-120 to SKIP=SKIP-142; -The actual change processes 12.01 and earlier data. Thanks to Don Snively, E-Systems, USA.
VMACCOMP record format, but two errors in MXG were uncovered: if Oct 7, 1995 you use a single SMF TYPE for your COM-PLETE record, MXG failed to output the COMPULOF and COMPUCKP datasets. The line with _IDCOMOF should test ULOGRTYP=3 (was 1), the line with _IDCOMCK should test ULOGRTYP=2 (was also 1). These two changes are required for either 4.5 or 4.6, but only if you use a single SMF record type in the _IDCOMP macro definition in IMACCOMP. Thanks to Wayne Bell, National General Insurance, USA. Change 13.221 Support for Tandem MEASURE processes their Process, CPU, ADOCTAND and Disk data files. See member ADOCTAND for discussion EXTANCPU of how to create, process, and use the three datasets: EXTANDIS TANDCPU - Interval CPU activity statistics EXTANPRO TANDDISK - Interval DISK activity statistics IMACTAND TANDPROC - Interval PROCESS activity statistics TYPETAND The Tandem data files contain ASCII character data with VMACTAND standard mainframe binary values; this support has been Oct 6, 1995 executed both under MVS and under OS/2 (and I discovered Dec 2, 1995 that the FB data records must have RECFM=F on the INFILE statement under ASCII versions of SAS, but must have RECFM=FB under EBCDIC versions, necessitating creation of the VMXGLRF macro to provide transparent support). NOTE: MXG will process the "native" ASCII TANDEM data on an ASCII platform (UNIX, OS/2, WINDOWS) as is. However, if you want to process the TANDEM data on with an EBCDIC platform (MVS, CMS, VSE), you must NOT translate the TANDEM data from ASCII to EBCDIC - send the TANDEM data to MVS as a BINARY file with no conversion and NOCRLF. If your character variables are filled with @@@@@, you are reading data that was converted from ASCII to EBCDIC, and it is not just characters that are corrupted! Thanks to Barry Pieper, Norwest, USA.
ANALRMFR ELSE clauses removed, and a RETAIN statement deleted in Oct 3, 1995 report enhancements.
VMACSFTA format from FB to VB format (for better maintenance in Oct 3, 1995 future versions), and added several new variables to both the Program and the Module datasets, including the Accounting Fields from the JOB card in the Program data.
EXHSMWWF HSM user SMF record creates new dataset HSMWWFSR with new IMACHSM statistics (counts, timestamps/durations, space used). VMACHSM The new segment is now put in the DFSMShsm smfid record Oct 2, 1995 (which previously contained only the DSR and VSR segments), but DFSMS 1.3 or APAR OW11391 will relocate the new segment to the smfid+1 record (which contains FSRs). MXG is coded to create it from either of the two HSM records. The HSMWWFSR dataset is an event record, written at the end of ABACKUP or ARECOVER, and thus there should be no accumulated fields across SMF records, so there is no reference to HSMWWFSR in member DIFFHSM. Thanks to Michael E. Friske, Fidelity Savings, USA.
VMAC42 changes the value of SMF42CSS,SMF42SSA,SMF42SAP,SMF42SSU, Oct 2, 1995 SMF42NSZ, and SMF42SPR (cache controller and non-volatile storage sizes), but OW14717 should not be installed, as IBM is replacing it with a better solution. A new APAR number OW16039 will be issued to fix the same problem but it sets a flag bit that MXG can use to determine whether or not the APAR is installed. These APARs affect only the 3990-6 in Enhanced Mode, and they change the value in the record to contain kilo-bytes instead of bytes, so the MXG change conditionally multiplies the six fields by 1024 if the new flag bit is on. Thus with this change installed in MXG, MXG will be correct with or without the APAR being installed. Change 13.216 The value of MAXTIME printed in the Title of reports is ANALPRTR wrong; the statement IF MAXTIME LT LATEST THEN DO; should Yüklə 28,67 Mb. Dostları ilə paylaş:
|