* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
Thanks to Bruce Widlund, Merrill Consultants, USA. Change 10.020 Landmark CICS records may produce ERROR. INVALID OFFSETS TYPEMON8 message with LENGTH=0 in the message. The first two bytes TYPEMONI of the Landmark record contain zero, instead of the actual Apr 6, 1992 record length. (When/Why Landmark made the change is not known). Change member TYPEMON8: Change "LENGTH" in lines 064700 and 064900 to "LENMONI" so that the field in these two bytes no longer overrides the LENGTH=LENGTH value that is captured in the INFILE statement. Archaic TYPEMONI for Landmark Version 7 was similarly changed for consistency. Thanks to David Bane, Jefferson County (Colo) Public Schools, USA. Thanks to Chun-Heng Liu, Bellcore, USA.
VMAC110 invalid in type 110 records are now only printed for the VMACSMF first two records. MXG notes of bad records are still put Mar 27, 1992 on the log for the first 20 occurrences of a bad record. Apr 20, 1992 Back-to-back type 02 or 03 (dump header/trailer) records were not expected by VMACSMF's new messages, and the time of the FIRST RECORD IN GROUP message was not correct. (I wondered why SMFDUMP output would begin with a pair of type 02 records, and with the first record's timestamp several hours later than the second record, but realized the output was first dumped by SMFDUMP and was then later copied by SMFDUMP which added the 02 at the beginning and the 03 at the end of the copy too!).
VMXGVTOC have a "Standard User Label" (DSORG=PS-SUL) cause an MXG VMXGVTOF note CRITICAL ERROR IN VTOC PROCESSING, EXTENTS NOT FOUND. Mar 27, 1992 PS-SUL datasets have NREXTNTS=1 in their DSCB1, but two extents are contained in DSCB1: extent #0 with EXTYPE=40x for the one track Standard User Label, and extent #1 with the real file. MXG now captures this extra track/extent and includes it in TRKSALOC and TRKSUSED (note, however, ISPF and LISTVTOC do not properly count this SUL track). The change is in the FMTID='1' logic in members VMXGVTOF and VMXGVTOC. The changes to VMXGVTOF are: a) Move lines 042900 and 043000 (OUTPUT VTOC1/DSNAMES) to after 044400. b) Delete line 044000 (IF FIRST EQ 0 THEN DELETE). c) Change line 044300 (OUTPUT EXTENT;) to now read IF FIRST GT 0 THEN OUTPUT EXTENT; d) Insert four lines after 044300 reading: IF EXTYPE EQ 40X THEN DO; /*STANDARD USER LABEL*/ NREXTNTS=NREXTNTS+1; TRKSUSED=TRKSUSED+1; END; The same changes need to be made to VMXGVTOC. Line numbers are: a) 055700 and 055800 to after 057200, b) 056800, c) 057100, and d) after 057100. The only PS-SUL datasets found thus far are the log files created by Omegamon/CICS Version 500! Thanks to Mike Jacques, Best Products, USA.
VMAC110 cause MXG to loop. MXG detects the bad record and PUTs a Mar 25, 1992 note on the log "UNEXPECTED STATISTICS SUBTYPE", but MXG's attempt to skip over an unexpected segment fails when the segment is corrupted (i.e., it has STILEN=0). Line numbers 408200 and 408300 currently read: IF (COL+SKIP LE LENGTH+1) THEN INPUT +SKIP @; ELSE INPUT; but they must be changed to read: IF (COL+SKIP LE LENGTH+1) AND SKIP GT 0 THEN INPUT +SKIP @; ELSE DELETE; The cause of the single occurrence of this type of corrupted record is still under investigation. Thanks to Jim Gilbert, Texas Utilities, USA. Change 10.016 Documentation note for TYPE6 (and PDB.PRINT) datasets. ADOC6 The fields SMF6DDNM, SMF6DSNM, SMF6PRNM and SMF6STNM that Mar 25, 1992 were added by PSF to type 6 SMF records do NOT exist in a type 6 record created by JES. Those fields exist only in the PDDB built by PSF and are not in the JOE built by JES. The variables exist, but their values are blank for DDname DSname, Procname and Stepname if JES did the printing. IBM APAR OY48265 documents their omission by JES. Thanks to Marcia Ketchersid, Price Waterhouse, USA.
EXNSPYTR MXG dataset NSPYTR, thanks for this significant user VMACNSPY contribution. Mar 25, 1992 Thanks to Lois Robinson, M & I Data Services, Inc, USA.
VMAC71 always had missing values because the test in line 084500 Mar 25, 1992 IF LENSWAP GE 360 THEN DO; must be changed to read IF NRSWAPSG GE 15 THEN DO; Additionally, variables SWAPSHRT (logical swap candidates) SWAPLGPY (logical swaps actually swapped) and PCTLSWAP (pct logical swaps that swapped) used to be MVS/370 only, but are now calculated for XA and ESA environments by the addition of these three lines after line 091400: SWAPSHRT=SWAP-SUM(PHYEXT,PHYAUX); SWAPLGPY=SUM(LOGEXT,LOGAUX); IF SWAPSHRT GT 0 THEN PCTLSWAP=100*SWAPLGPY/SWAPSHRT; Thanks to Lois Robinson, M & I Data Services, Inc, USA.
VMACX37 by changing EQ 'X37 33' THEN to GE 'X37 33' THEN Mar 24, 1992 because the record format was (apparently) unchanged. The variable STEPCPU must be changed to STPCPUTM in two places so the CPU time will be kept by MXG. Thanks to Mike Jacques, Best Products Co., Inc, USA. Change 10.012 MVS/ESA V4.2 Dynamic I/O Reconfiguration is now supported ASMTMNT in these "monitor" programs provided by MXG. The MXG Tape ASMVTOC Mount Monitor, ASMTMNT, the MXG Fast VTOC Reader, ASMVTOC, ASMVVDS the MXG VVDS Reader, ASMVVDS, and the MXG SAS Function to FMXGUCBL Dynamically Allocate All Disks, FMXGUCBL (now redundant in Mar 13, 1992 purpose with the ASMVTOC program), all use the new UCBSCAN service so these programs will recognize new devices that were added by MVS/ESA after IPL. Thanks to Bill Fairchild, Royal Software Associates, USA. for enhancement. Thanks to Guy Garon, Verstand, CANADA. for review of Bills' work Change 10.011 SPMS 1.2.1.3 writes invalid record if a volume is deleted VMACSPMS or renamed, without first changing SPMS parameters. The Mar 13, 1992 resultant SMF record contains a value of 1 for SPMSREXT, but sections 3/4 do not exist in the record, causing MXG to STOPOVER abend. This is really an Amdahl problem, but this circumvention protects their error. Change DO _I_=1 TO SPMSREXT; to read IF LENGTH GT 188 THEN DO _I_=1 TO SPMSREXT; (Note: NL 22 misspelled 1.2.1.3 as R2.1.4). Thanks to Peter Evans, Inland Revenue, Worthing, ENGLAND. Change 10.010 TYPE70PR variable NRPRCS, number of logical partitions VMAC7072 is still incorrect after the PR/SM Effective Dispatch Time Mar 12, 1992 APAR is installed. Change 9.179 subtracted one for the pseudo partition "PHYSICAL", but since that partition segment is last in the actual record (even though it has the Logical Partition Number LPARNUM of 0), only the observations in TYPE70PR for LPARNAME of PHYSICAL have the correct number of logical partitions! Line 131110, IF LPARNAME='PHYSICAL' THEN NRPRCS=NRPRCS-1; must be deleted, and a new line must be inserted after line 133220 (SKIP=SKIP-16;, inside the DO group to read LCPUEDTM) containing: NRPRCS=NRPRCSS-1; (yes, the variable on the right does have an extra 'S'). Thanks to Bruce Widlund, Merrill Consultants, USA.
WEEKBLD BUILDPDB/3 in MXG 9.9, but were not added to WEEKBLD or MONTHBLD MONTHBLD. Now they have been added, with these BYs: Mar 10, 1992 WEEK.TYPE70PR: BY SYSTEM STARTIME LPARNUM LCPUADDR; WEEK.DB2STAT0: BY SYSTEM QWHSSSID QWHSSTCK; WEEK.DB2STAT1: BY SYSTEM QWHSSSID QWHSSTCK; But what about DB2ACCT; wasn't it added to BUILDPDB? Yes, but, since Change 10.053 now gives you the choice of the destination of the DB2ACCT dataset, and since I don't know if you really want to put your detail DB2ACCT data in the weekly PDB, I can't automatically add it to your weekly PDB for you; you'll have to do that yourself, (with no BY statement, since it is no longer sorted), if you really want detail DB2ACCT data weekly!
WEEKBLD may get a NOT SORTED condition in WEEKBLD under MXG 9.9, Mar 10, 1992 because your previous sort order might be different than Apr 20, 1992 the sort order used by MXG 9.9. Simply remove the BY May 5, 1992 statement from your WEEKBLD and the daily datasets will be concatenated instead of interleaved in sort order. This is not only a circumvention to this specific problem, but in fact is the way of the future, as DB2ACCT is no longer built in sort order; see Change 10.053!
VMACTPX TPXELAP=TPXELAP*900/40812; Feb 27, 1992 must be deleted. The value is correct without conversion. Thanks to Sam Sheinfeld, Kraft General Foods, USA. Change 10.006 Cosmetic change. Variable SMFT0BST should have format of VMACCMA DATETIME21.2 and should have LENGTH of 8. Feb 27, 1992 Thanks to Ken French, Wisconsin Gas, USA. Change 10.005 Type 42 SMF record causes STOPOVER ABEND. One ABEND is VMAC42 because APARs OY48288 and OY39393 incompatibly re-format Mar 9, 1992 the record, and require a new VMAC42 member to process the Mar 14, 1992 completely restructured record. However, MXG could also fail on records created before the above APAR, because the NRSTOR in line 020300 should have been (NRSTOR-1). Since the original records were not correct, the only thing that makes sense, if you want to process the type 42 record, (it contains 3990 cache statistics if you have SMS volumes behind the cache) is to install the above APARs and to ask for MXG PreRelease 10.1, because these two APARs correct the errors previously reported (but not fixed) in APAR OY36035 and OY39393. MXG circumvention for those two earlier APARs was removed in this almost complete rewrite of VMAC42. However, users with IBM's Cache RMF Reporter or Legent's DASDMON/ASTEX products have said they found TYPE42 added nothing useful to those two products. Revision 1MAR94: New subtypes of the type 42 record added great value to the type 42 record! See later changes! Thanks to Greg Scriba, Budget Rent-A-Car Corp, USA. Thanks to Glenn Hanna, Textron Defense Systems, USA.
VMXGHSM value of 297 or 405 depending on the release of HSM, but Mar 9, 1992 it now can be calculated independent of release. In lines 152300 and 153000, replace "405" with "MCDNVSNO+65". Additionally, MCDMCNAM in lines 140500 (label=SMS...) and 141600 (... $HEX2.) should have been MCDSMSFG. Without this change, MCDMCNAM printed funny because it was given the $HEX2. format. Thanks to Roger Edwards, South Carolina Electric & Gas Company, USA.
VMAC6 original PSF record did not contain the 8-byte FORM name, Mar 9, 1992 and old MXG code that bypassed inputting the 8-byte field should have been removed when PSF added the longer field. Lines 026000 thru 026300 need to be replaced with: IF SMF6LN3 GE 14 AND LENGTH-COL+1 GE 8 THEN INPUT FORM $CHAR8. @; since the 8-byte form name is now in all type 6 records. Thanks to Lars Hylin, TryggHansa-SPP, SWEDEN.
TYPEIMS IMSTRAN._IMSTRAN, but using MXG's suggested DDNAME of Mar 9, 1992 IMSTRAN for the _IMSTRAN value caused no error condition! Only if you used a different DDNAME did an error occur. Thanks to Richard S. Ralston, Rochester Telephone, USA.
ANALDB2R and the System Parameter Report ABENDs with "Variable Not Mar 9, 1992 Found" due to inadequate testing of the final 9.9 code. a.Insert the following line in two places, after line 016050 and after line 025220: LENGTH DB2 AUTHID PLAN CONNID CORRNAME CORRNUM DB2LOCAL DB2REMOT $ 8 ; b.Replace all occurrences of SM102SSI with QWHSSSID. These are the lines: 088580, 088620, 093840, 095140, 096260.
=========================member=CHANGE09================================ /* COPYRIGHT (C) 1984,1992 MERRILL CONSULTANTS DALLAS TEXAS USA */
press; see the Change Log, below, for Changes 9.236 thru 9.245. The library now has more members, lines, datasets and variables than was stated in the newsletter. This final MXG 9.9 library contains 1,605 members, 388,651 lines of code, builds 1,093 datasets with 41,332 variables documented in DOCVER with delta-doc in DOCVER09. Over 800 sites have installed a PreRelease of MXG Version 9! The installation instructions for MXG 9.9 were contained in NEWSLETTER TWENTY-ONE, which is contained in member NEWSLTRS, repeated also below in this member.
and builds 1,093 datasets with 41,332 variables that are documented in member DOCVER. Datasets changed between MXG 8.8 and MXG 9.9 are documented in member DOCVER09. 2. Major enhancements and new products supported in MXG 9.9.
Support for Boole & Babbage CONTROL-D SMF record. Support for CA-1 (TMS) Release 5 complete rewrite. Support for CADAM's Statistics Data File. Support for CICS/ESA 3.2.1 product. Support for Codework Software's SNAPAD-MVS user SMF record. Support for Database 2 Release 2.3. Support for DCOLLECT APAR OY36364 change in track capacity. Support for Fischer's Totally Automated Office TAO. Support for HSM 2.6 SMF record. Support for Interlink's SNS/SNA Gateway SMF record. Support for Interlink's SNS/TCPaccess SMF record. Support for Interlink's SNS/TCPvt SMF record. Support for LEGENT's MIM Multi-Image Manager Support for LEGENT's LANSPY component of NETSPY (4.1). Support for LEGENT's BUNDL product modified type 6 SMF record. Support for MVS/ESA 4.2.2 (RMF 4.2.2) changes. Support for NetView NPM 1.5 release. Support for NetView FTP SMF record. Support for Omegamon for CICS/ESA Version 550 ESRA user SMF. Support for Omegamon V550 SMF 110 EMPs (Basic, DB2, DL/I). Support for SCA's CMA-SPOOL user SMF record. Support for Shared Medical Systems CICS exclude logic. Support for Softtool Corporations's CCC (Change and Control). Support for Software AG's NET-PASS user SMF record. Support for Type 30 APARs OY33312 and OY25606 (no changes). Support for 3490E (Serpentine) tape device. Support for 9345E DASD device. Addition of DB2ACCT,STAT0,STAT1 datasets to your PDB. Error in VMXGVTOF/VMXGVTOF (only 3 extents kept) corrected. Revision of BUILDPDB to eliminate SAS 5.18 Compiler Error 344. Cache RMF Reporter support enhanced, decoded, and documented. DB2 Reports corrections and enhancements in ANALDB2R. Fujitsu FACOM MSP and FSP supported in XPDLPDA. IMS Input Queue time, resources, CONDCODE corrections. PR/SM Trend Data Base implemented. VM/XA Trend Data Base implemented.
alphabetical list of the most important changes precedes the changes.
no reported problems. Sites migrating from MXG Version 8.8 or later have found installation of MXG 9.9 was smooth and easy. The only known incompatibilities are listed below, before the instructions. Under ALL SAS Versions: BUILDPDB/3 sites who have added DB2 processing to their PDB must now "back-out" their exit code as described in Change 9.175; MXG now has added DB2ACCT/DB2STAT0-1 datasets automatically to your PDB, and a syntax error in BUILDPDB will occur if you fail to heed this note. Only under SAS Version 6.07: Use new member CONFIG07 instead of CONFIG. No error will occur, but several unnecessary WARNING messages will be eliminated by use of the new CONFIG07 member for 6.07.
sites must add a new temporary DD card in their JCL for BUILDPDB: //SMFTEMP DD UNIT=SYSDA,SPACE=(CYL,(20,20)) This inconvenience may help eliminate SAS 5.18 compiler 344 errors. If you encounter SAS 5.18 errors 344 or 160 see Change 9.175. A syntax error in BUILDPDB will occur if you fail to heed this note. However, if you have NOT installed MXG 8.8, you MUST note:
are required by MXG were changed between MXG 7.7 and MXG 8.8. b. Execution under SAS 6.06 is different than under SAS 5.18. See SAS Notes section of newsletters 17-21. e. To write your PDB directly to tape, IMACCICS must be changed as described in comments in the member. Although MXG does support creation of the PDB directly to tape, most sites find it better (especially elapsed time) to create the PDB on temporary disk and then use PROC COPY to copy from disk to tape. (BUILDPDB re-reads PDB datasets to build RMFINTRV, and this can cause lots of tape spinning when the PDB DDname points directly to tape.)
well as for any last minute changes added after Newsletter composition. 1. Installation, re-installation, and Space Requirements. The MXG Installation instructions are found in Chapter 32 of the MXG Supplement for both new installation and for version replacement, and those instructions, as modified herein, are still valid.
single file with DCB=RECFM=FB,LRECL=80,BLKSIZE=32720. The MXG tape is an unloaded Partitioned Dataset in IEBUPDTE format. Note that the tape blocksize was changed to 32720 (it had been 6160 in prior versions). You will receive I/O errors if you specify the incorrect blocksize.
Under CMS use TAPPDS command to build the SOURCLIB MACLIB library. Allocate the MXG.SOURCLIB for MXG 9.9 with SPACE=(CYL,(50,1,299)), using DCB=(RECFM=FB,LRECL=80,BLKSIZE=23440) on 3380 devices, or DCB=(RECFM=FB,LRECL=80,BLKSIZE=27600) on 3390 devices.
be required by the MXG SOURCLIB MACLIB, but during the CMS installation process you will need at least 100 free cylinders on your minidisk.
beginning with IMAC....), and by "MXG Exit Facility" members (members beginning with EX....) that are copied and edited into the installation "USERID.SOURCLIB", the name of the "MXG Tailoring" library, that you create and concatenate ahead of MXG.SOURCLIB to the SOURCLIB DDNAME:
// DD DSN=MXG.SOURCLIB,DISP=SHR --> never changed (mine) If this is an MXG re-install, there should already be a USERID.SOURCLIB. If not, then allocate one using the same attributes as the MXG.SOURCLIB, with SPACE=(CYL,(1,1,99)). Under CMS create an equivalent MACLIB.
IMAC members. Most MXG sites have only a few tailoring members in their USERID.SOURCLIB (typically, IMACACCT, IMACSHFT, IMACWORK).
not exist in your USERID.SOURCLIB, and should always be removed when you install a new version of MXG. However, if you have installed printed Changes from an MXG Newsletter, you might have copied VMAC member(s) from MXG.SOURCLIB into your site's USERID.SOURCLIB and then modified the VMAC member. (Alternatively, you could have created an MXG.CHANGLIB in which you put those in-between-version changes.) In either case, if you made temporary changes, they must be removed now. Delete all of the VMACs members from your USERID.SOURCLIB (or delete the MXG.CHANGLIB). Otherwise, your modified VMAC member would be used instead of MXG's. You should record all tailoring changes in your USERID.SOURCLIB so the next MXG technician will know what you have done. You should create a member named CHANGES in your USERID.SOURCLIB, similar to member CHANGES in the MXG.SOURCLIB which documents all MXG changes. If there are IMAC.... members in your USERID.SOURCLIB, you must look at the alphabetic list of changed IMACs in the Change Log, below, and must retrofit your tailoring on the new member in this library. In MXG 9.9, only IMACACCT was changed (Change 8.290, in member CHANGES). Whenever you install changes or test a new version of MXG (or even your own reports), be extra careful to look on the SAS log for any real error conditions. Search for all occurrences of "ERROR:" and "ERROR :" and "UNINITIALIZED" and "NOT CATLGD", as they may indicate a serious error. A PROC PRINT and a PROC MEANS of each new MXG-built SAS dataset can help you to understand their contents, and should be used to examine any unusually large, negative, or suspicious values. Print all variables in the dataset, and read the variable's descriptions in Chapter FORTY. Summary of critical actions to be taken in installing new version:
and, in general, must be deleted. b. All IMAC.... members in your USERID.SOURCLIB must be compared with the IMAC.... members that have been changed in this MXG Yüklə 28,67 Mb. Dostları ilə paylaş:
|