* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
second SMF record containing only the two remaining Cache Data sections (one each for structure 13 and 14), but as neither the Structure nor Request Data sections are in that second record, it is IMPOSSIBLE for MXG to decode the second broken record. The record has SMF74RAN=1, indicating the "Reassembly Area" exists, but that design (to reassemble multiple "broken" records into a large record in the virtual memory of the reading program) requires offsets from one SMF record to be used to input fields in another SMF record, and that algorithm fails unless all of the SMF broken records are adjacent and found in the input SMF file, which cannot be guaranteed (as, for example, when the first broken record is the last record in today's SMF file, or if the SMF data was presorted). "Broken" records and reassembly areas are not new, but IBM has previously never spanned logical data fields between two physical records. Both the 74 subtype 1 and subtype 2 records are "broken" when there are many devices, but each "broken" record is self-contained and can be decoded with no dependency on other records. The required solution for the type 74 subtype 4 record is for IBM to write self contained data records. The first record should contain only as many Request Data sections as will fit with their associated Cache Data sections. Second and subsequent records must contain the Product, Local Coupling Facility, and Structure data sections, and then as many Request Data and their Cache Data sections that will fit together. To circumvent the error, an additional condition: AND CDSILOC+SMF744CL LT LENGTH was inserted in the existing IF statement IF R744CDSI GT 0 AND R744CDNE GE 1 THEN DO; before the THEN, so that the missing cache data sections are skipped (causing missing values in TYPE74ST). Thus far, only a few bad 74.4 records have been found per day on this OS/390 R2.8 system. While IBM's RMF Reporter does handle these broken records if they are found in the same SMF input file (which RMF has to first sort for the reassembly algorithm), if the second record is not in today's data, the RMF Report just skips that interval in its reports!
to revise their design so that when "broken records" must be written, they will be self-contained and not dependent on the contents of other records for decoding. This investigation also uncovered an MXG oversight; only the first cache data section was read for each structure, but there are a few structures that have as many as 63 cache data sections, (but only two of those sections had any non-zero counter values!). Now MXG sums all of the cache data section counters for each structure. Thanks to Steve Lottich, University of Iowa Hospitals, USA.
JCLIMSL6 was overlooked (LG and L5 were correct). It should be: Jan 21, 2000 SORT FIELDS=(1,12,A,43,8,A,29,1,A),FORMAT=BI as described in the text of that change. Thanks to John Pierce, Liberty Mutual, USA.
NTINTRV from the SERVER dataset instead of from the MEMORY data, Jan 21, 2000 so their values were not correct in NTINTRV. Inserting (DROP=POOLNPBY POOLPBY) after _LNTSERV in the MERGE statement will correct this error. Thanks to Greg Jackson, National Life of Vermont, USA. ======Changes thru 17.375 were in MXG 17.10 dated Jan 20, 2000====== Change 17.375 Report was showing equal utilization of the channel for ANALPATH both the LPAR and the CEC. Jan 20, 2000 Thanks to Tony P. Steward, Post Office, ENGLAND. Change 17.374 Windows 2000 NTSMF enhancements, etc. EXNTSMTN -Objects 'Job Object' and 'Job Object Details' are still EXNTTRMS flakey, sometimes containing NRNAMES and instance names EXNTTRMV (1 in Job Object, 2 in Details), sometimes NRNAMES=0. FORMATS While this is being resolved, MXG now protects both, IMACNTSM (but if NRNAMES=0, then the names will be blank and the VMACNTSM records of questionable utility!). VMXGINIT -New variable FTPUPTME added to FTPSERV dataset from the Jan 20, 2000 'FTP Service' object. -Three new objects supported: dddddd Dataset Object NTSMTN SMTPNFS SMTP NFS Store Driver NTTRMV TERMSERV Terminal Services NTTRMS TERMSESS Terminal Services Sesion -Sixty new variables added to SMTPSERV dataset from the 'SMTP Server' object are protected, but not input; I ran out of time in building MXG 17.10, but call for the update. Jan 21, 2000: No update needed; MXG 17.10 did contain all of the new variables, but I forgot to go back and change this text. Thanks to Jim Quigley, Con Edison, USA. Change 17.373 TRNDRMFI has been updated to keep xxxxMEMR memory vars TRNDRMFI as 8 bytes, like all other measures of memory, so that Jan 20, 2000 there is no loss of resolution.
VMAC74
Jan 20, 2000 Change 17.371 Support for LDMS product creates three new datasets: EXLDMSDB dddddd dataset label EXLDMSDI LDMSDB LDMSBASE SI-LDMS-BASE EXLDMSPC LDMSDI LDMSDIST SI-LDMS-DIST FORMATS LDMSPC LDMSPC SI-LDMS-PC IMACLDMS in this user-contributed enhancement. TYPELDMS LDMS is from Software Innovation in Germany, and it is TYPSLDMS used for archiving and viewing JCLLOG, SYSLOG, reports VMACLDMS and lists that were previously printed and delivered. VMXGINIT
Jan 20, 2000 Thanks to Thomas Heitlinger, FIDUCIA IT AG AG, GERMANY. Change 17.370 This test version of VMXGSUM enables a SAS VIEW in the XMXGSUM first datastep to reduce time and resources (CPU, I/O, Jan 19, 2000 and especially DASD space, since a VIEW is essentially a pipe that avoids hardening a dataset. This version also allows you to create the output dataset as a view with OUTDATA=X/VIEW=X, syntax (but of course you must use that dataset before you invoke VMXGSUM again). This member will become VMXGSUM in the next version, but is placed here for wider testing; copy this XMXGSUM into VMXGSUM in your USERID.SOURCLIB to test it yourself. Thanks to Chuck Hopf, MBNA, USA.
ANALRMFR MYTIME parameters for summarization tailoring. Jan 18, 2000
EXTYBE9A four new datasets from the many subtypes: EXTYBE9B "dddddd" Dataset Label EXTYBE9C TYBE9A BETA91A BETA91 HEX ST 10,14,28,48 EXTYBE9C TYBE9B BETA91B BETA91 HEX ST 22,24,36,42,44 FORMATS TYBE9C BETA91C BETA91 HEX ST 50 IMACBE91 TYBE9D BETA91C BETA91 HEX ST 60 TESTUSR1 The second variable data portion of the subtype 22-44 TYPEBE91 record is not documented, so those fields are not yet TYPSBE91 decoded into dataset BETA91B. VMACBE91 -Minor, but SMFCSTIM was shifted one byte to the left in VMXGINIT the record ('45400000'x instead of '00454000'x for noon), Jan 17, 2000 so there is an extra divide by 256 required. Thanks to W. Waldeyer, BHF-Bank AG, GERMANY. Change 17.367 NETSPY NSPYAPPL dataset had missing values for response EXNSPYAP time and percentages when NETRSPN6 (computed number of VMACNSPY LU6.2 responses) was zero. Logic was added to use the Jan 15, 2000 TOTRSPN6 (total number of LU 6.2 responses) if NETRSPN6 is zero. Additionally, exit EXNSPYAP tested only TRANSNO or OUTPUTNO, which suppressed output of any interval that had LU6.2 traffic but no 3270 traffic. The test now also tests TOTRSPN6 so that LU6.2-only intervals are output. Thanks to Julian Smailes, Experian Limited (UK), ENGLAND.
VMACTMS5 printed DENSITY IS MISSING and a hex dump of the record Jan 14, 2000 on the log, with no other impact. The existing test ELSE IF DENX=0DEX THEN DEN=0; was expanded to read ELSE IF (DENX=0DEX OR DEL='Y') THEN DEN=0; and that block of code was relocated to after DEL='Y' is set. Thanks to Warren Hayward, TJX, USA.
VMACTCP been updated so they can now be used. The _SUBTCP5 macro Jan 13, 2000 was deleted, as it was never referenced; the statistics record is recognized by length, not by subtype (which was user-settable and thus not reliable!). Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY. Change 17.364 XCF Path Statistics report, updated to report all ANALRMFR paths. Jan 13, 2000 Thanks to Neil Ervin, Schwab and Company, USA. Change 17.363 Year 2000. Julian Date Values for these products have VMACACF2 been protected to convert 01yyddd values to 20yyddd: VMACCTLT TYPEACF2 - LIDADATE, LIDCDATE, LIDDXPDT, LIDIPDAT, prot. VMACLMS TYPECTLT - CTLTDSN/CTLTVOL variables protected. VMACPROS but there are EXPDT fields that are not Jan 14, 2000 protected for invalid dates (like 99366). TYPELMS - This code had not been updated in a long time. EXPDT is now correct, but several datasets were also corrected, and the code now runs under ASCII as well as EBCDIC versions of SAS. These changes support Sutmyn/VTS/LMS 3.4. TYPEOMAU - OMJULDAT is protected, and OMDATIME corrected. TYPEPROS - GWADATE protected. GWAEXPDT is character. TYPEWSF2 - No julian date variable, listed in error. Unfixed, awaiting raw data: TYPEIAM: IAMCDATE=0852 decimal, 0354 hex, doc dddy!!! Unvalidated, these products have unvalidated fields and no test data has been made available. See the member YEAR2000 for variables and datasets: TYPEBETA TYPECMF TYPEDECS TYPEEDGR TYPEEDGS TYPEEPIL VMXGHSM TYPESARS TYPETMDB TYPETMVS TYPETLMS
Thanks to Warren Hayward, TJX, USA. Thanks to David Ehresman, University of Louisville, USA. Thanks to Kevin Marsh, AT&T Solutions EMEA, ENGLAND. Thanks to Caron Know, Willis, ENGLAND. Thanks to Steve Clark, California Federal, USA. Thanks to Coen Wessels, UNICIBLE, SWITZERLAND. Thanks to Caron Knox, Willis Corroon Group Services Limited, ENGLAND.
VMACTMO2 and lowatermark values in TMON for CICS/ESA 2.0 (TCE) Jan 13, 2000 statistics interval records will be always zeroes after applying SYSMOD TH01288 to TMON, but the HWM values in the TI record will still be valid, as they are obtained differently than the TCE records. The SYSMOD text has an extensive discussion of why the TCE HWM/LWM values cannot be calculated when the TCE interval is different than the CICS statistics interval. These fields in these records will be zero: Record Fields TP TPGWLRHW TPGHWMT TS TSGSTA6F TSGQNUMH TSGNCIAH TSGBUWTH TSGNVCAH TSGVUWTH TSGQINH TD TDGAMXIU TDGAMXAL TDGAMXWT TDGAMXCI TDGSMXAL TDGSMXWT
TX TXGPAT TXGPQT TR TRVRPLX TRVRPLXT TRXMCPAT TRXMCCPQ TRVLUHWM T2 T2TCBQHW T2TCBHWM T2ETHDHW T2EPTHDP T2EHTASK T2EH
TM TMCE1HWM TMCE2HWM TMCEBHWM TMCESTAM TT TTRMCNT TF TFFDSHSW TFFDTSHI
VMACEREP EREP record types are tested and will be bypassed (and Jan 12, 2000 and MXG WARNING message printed on the log) if any of the invalid record bits are enabled; previously only the record types that had experienced bad bits were protected. IBM's EREP writes out truncated records when it runs out of buffer space, and sometimes EREP doesn't edit the record and only writes out what's in the buffer, and sometimes EREP writes out incomplete records. Also, MCH '13'x record conditionally inputs ERRORID by testing length in LRBMLNH to avoid STOPOVER. Thanks to Jerry Urbaniak, Peoples Energy Corporation, USA. Thanks to Les Geraghty, DMR (an Amdahl Corporation), IRELAND.
VMXGRMFI have been revised and corrected, so the errors and fixes RMFINTRV apply only to the 17.09 code, but all of the new stuff TRNDRMFN now works! Your existing IMACWORK member will continue Jan 12, 2000 to work to define your workloads, if you do nothing, but Jan 20, 2000 now you can EDIT member RMFINTRV (instead of IMACWORK) in your USERID.SOURCLIB to create new workloads either in addition to your IMACWORK workloads, or instead of, by ignoring in IMACWORK completely. Member RMFINTRV invokes %VMXGRMFI, so you EDIT RMFINTRV to change the arguments. Remember, you NEVER change member VMXGRMFI; you only read it for its documentation of the arguments in comments. Then, in your RMFINTRV member, you invoke %VMXGRMFI with your chosen workload definitions, parameters, etc. Member RMFINTRV has documentation and examples in its comments. To match output to input sums exactly, all of the length 4 variables in RMFINTRV are now stored in 8 bytes. The truncation when stored in four bytes is only in the 7th significant digit, so using length 4 is not wrong, but with a daily totaly of 1,000,000 seconds, that caused a visually-obvious-even-if-not-significant difference of 0.1 of those million seconds lost between RMF & RMFINTRV. Since I wasted a full day chasing down that difference, I decided the small increase in DASD space would be worth you never having to ask why there was any difference! RMFINTRV now uses SAS VIEWS to pass data from one step to another without using DASD space, but now, an ignorable note "A stored DATA STEP view cannot run under a different operating system" is printed on the SAS log. Some additional documentation comments. Specifying IMACWORK=NO may cause UNINITIALIZED VARIABLE messages on the SAS log for the old variables that you no longer want. Putting a comment block aroung the label statement in your EXRMFINT member will eliminate those messages, but they have no impact.
variables for each period, including response time, transaction count, and swap count as has always been done for the TSO workload. You need to tell VMXGRMFI how many periods to be mapped with the syntax: WORKn=NNNN/LLLLLLLL/PGN/SRVCLASS/PERIODS See PERIODS= in member VMXGRMFI.
also say to use your IMACWORK member, and that IMACWORK member still contains the default to delete Report stuff the IMACWORK will have deleted the Report stuff before the new definitions are used. You will need to revise your IMACWORK member to permit use of Report stuff. Trending on the new RMFINTRV variables can now also be done, with this new VMXGRMFI's TRENDIN=, TRENDOUT=, TRENDBY=, and TRNDINTV= arguments, and by setting PDB=. Member TRNDRMFN is an example of the new syntax that will invoke VMXGRMFI to create TREND.TRNDRMFI with all of the new workload variables. These 17.09-only errors were corrected: -The default IMACWORK=YES caused MXG error message that RMFINTRV CPU TIMES DO NOT MATCH because OTHRCPU was included twice in the creation of variable CPU72TM. 17.09 sites can remove the OTHRCPU from the end of: ,BATCPU,TSOCPU,CICSCPU,IMSCPU,OTHRCPU, OTHRCPU is the fallthru workload for undefined PERFGRP or SRVCLASS that were not mapped in your IMACWORK, so if all work was mapped, then OTHRCPU will be zero and this error does not occur. -That error message does NOT set a return code nor stop your BUILDPDB job (because once you see the error and fix your workload definitions in your IMACWORK member or in your RMFINTRV invocation of %VMXGRMFI, you can simply re-run the RMFINTRV program to re-create the PDB.RMFINTRV dataset, without re-reading SMF data. -Detailed validation of 17.09 corrected values in a few variables from TYPE71 and TYPE74 datasets. -Using IMACWORK=NO and RPGNs did not use the RPGN data. Thanks to Bruce Lietz, Cessna Aircraft, USA. Thanks to Normand Poitras, ISM, CANADA. Change 17.359 VMXGSUM fails if variable names are created in lower case VMXGSUM and KEEPALL=NO default is used with SAS V7/V8, as that Jan 12, 2000 space-saving option invokes logic to figure out what variables need to be kept, and because the output dataset created by PROC CONTENTS that contains the list of variable names that exist has lower case values in variable NAME, but the dataset created by parsing of the arguments (like SUMBY=) that contains the list of variables that are needed has upper case values in its variable NAME, which then causes the MERGE matchup: MERGE A (IN=INA) B (B=INB); BY NAME; IF INA AND INB; to fail, as it sees those NAMEs as different values. And since there is no SAS facility for case-insensitive character tests nor case-insensitive MERGEing, three UPCASE() functions were inserted in the three places where variable NAME is read from the PROC CONTENTS output dataset.
accidentally used lower case in my test program, but it was very nasty in impact and not obviously caused. There was no error condition, but the output dataset had only 17 observations instead of 212; there were a few MISSING VALUES messages on the log during MXGSUM1 creation. Only when the SUMBY variables were printed was it found that one of them did not exist in the output dataset, which led to the discovery and fix.
because that bypasses the NAMEs matchup, but it can waste //WORK space if there are many unused variables.
ANALNSPY MICS SNTNSS report from MXG's NSPYLU dataset was added to Jan 12, 2000 the examples in ANALNSPY. (However, the MICS report does not correctly count input transactions; the MXG report prints both the MICS number and the true number). Thanks to Gene Rahe, Experian, USA. Change 17.357 To modify BUILDPDB to copy CICS Statistics datasets to EXPDBOUT your PDB, you should insert this code in EXPDBOUT: Jan 12, 2000 _S110 Jan 20, 2000 MACRO _SCICEXC % The BUILDPDB writes all CICS Statistics datasets to the work file (to later create PDB.CICINTRV), but those 50+ individual CICxxxx datasets are not copied into the PDB by default (they can be large; if you don't ask for them, they won't waste any space in your PDB). That macro invocation of _S110 sorts each TYPE110 dataset to the PDB, and the two MACRO redefinitions to null out the sorts of datasets CICSEXEC and CICSYSTM are needed because BUILDPDB will try to sort them later in its own logic, after the EXPDBOUT exit has been executed. Note: if you don't want to create any observations from the type 110 subtype 2 CICS statistics records, add this statement: IF ID=110 AND SUBTYPE=2 THEN DELETE; in your IMACFILE exit member. Thanks to David Ehresman, University of Louisville, USA.
IMACEXCL because the DO group IF MCTSSDCN LT 202 ... should have Jan 11, 2000 been deleted when the TS 1.3 INPUT logic was copied into member IMACEXCL. Delete that DO group. Thanks to Tony P. Steward, Post Office, ENGLAND.
VMAC42 SECTION TRIPLET error, but the message itself was in Jan 11, 2000 error. The test OFFCL+LENGTH GT LENGTH should have been OFFCL+LENGTH-1 GT LENGTH. The INPUT of SMF42CHL (twice) was changed from &PIB.4. to &PIB.2. and SUBTYPE= was added to those INVALID messages. Datasets TYPE42NF and TYPE42NU were affected. Thanks to Alan Deepe, Perot Systems Europe, ENGLAND. Change 17.354 Summarized variable RESPSTD was always zero; the code ASUMCICS SQRTARG=(SSQELAP/NUMTRANS)-(IRESPTM**2); ASUMCICX must be changed to read: Jan 11, 2000 SQRTARG=(SSQELAP/NUMTRANS)-((IRESPTM/NUMTRANS)**2); Thanks to Normand Poitras, ISM, CANADA.
VMAC7072 a Service Class and for a Report Class, the MXG NODUP WEEKBLD removal would not remove all duplicates. Adding variable MONTHBLD RPRTCLAS at the end of MACRO _BTY72GO will not impact the Jan 11, 2000 existing sorted datasets but will delete any duplicate records in TYPE72GO. Thanks to Chuck Hopf, MBNA, USA.
VMACTMS5 having been overlooked by Change 16.330, but now it is Jan 11, 2000 converted into a yyyyddd value. Thanks to Freddie Arie, Texas Utilities, USA. Change 17.351 Format MGSTCRS was corrected to 00/01 UN-/CONFIGURED. FORMATS Labels for STC26MST/MET were changed to TAPECOPY vice VMACSTC MIGRATE, for STC26VPO was changed to Position on the new Jan 8, 2000 MVC, and for STC26MID was changed to VTV VOLSER. Thanks to Herb Strazinski, US Bank, USA.
VMACSYNC contained multiple bits, variable CACHFWn was created but Jan 8, 2000 not kept, and two new flag variables were not decoded. Now, CONTIGn and CACHFWn are kept and right, and two new variables are decoded and kept: DYNALOn = 'WORK n*DYNAMICALLY*ALLOCATED?' UNOPENn = 'WORK n*UNOPENED*DISP=OLD?' for n=1 to 32, for each possible Sort Work Area. Also, the UCB address in variables UNIT1-UNIT32 is now the four digit character address, so their stored length was increased from $3 to $4. Thanks to Steve Colio, CIGNA, USA. Change 17.349 IBM Documentation of TELNET LOGF Date and Time Fields was VMACTCP wrong, causing MXG variable TELLOGFT to be wrong. Jan 7, 2000 Instead of being the time of logoff, the time field at offset 82-85 is the elapsed duration of the session! And the date field at 86-89 is redundant with the SMF date field (and this is the date field that IBM's APAR PQ34359 plans to change from the non-standard yyyydddF format to 0cyydddF in spite of its uselessness!). Adding the session duration and that date field created a value on Jan 3, 2000, for a session that ended Jan 1, which made Yüklə 28,67 Mb. Dostları ilə paylaş:
|