COPYRIGHT (C) 1984-2007 MERRILL CONSULTANTS DALLAS TEXAS USA
CHANGE 05.05
=========================member=CHANGE05================================
/* COPYRIGHT (C) 1987 BY MERRILL CONSULTANTS DALLAS TEXAS */
This is MXG Version 5.5, the production release of MXG Version 5.
MXG Software Status as of December 17, 1987, thru Change 5.173.
What's new in Version 5.
1. MVS 2.2 support.
- New type 36 ICF Export/Import SMF record.
- New type 41 Data-In-Virtual SMF record.
- Changes in existing SMF/RMF records.
2. VM/SP Release 5 support.
3. SAR Accounting record support.
4. SAR Type 6 record support.
5. DASD storage measurement system (dynamically read all VTOCs).
6. IDMS 10.1 Performance Monitor record (new data sets) support.
7. ACF2 user SMF record support.
8. DB2PM validation and reports.
9. IMS log processing re-designed and supported for IMS 2.1.
10. STOPX37 user SMF record support.
11. RMF Cache Reporter validation and enhancement.
12. CICS 1.7 cleanups, enhancements, and more decoding.
13. DFSORT Release 9 support.
14. VM/Monitor summarization.
15. Vector Processor measurement.
16. TYPE64X data set for VSAM extents.
17. SYSLOG JES3 processing and JES2 SYSLOG example.
18. EDP Auditor Reports from RACF type 80 data.
19. Eight CPU engine (3090-800?) C.E.C. Support.
20. Online Business Systems WYLBUR Accounting SMF record support.
21. TSO/MON Version 5.1 support.
22. Extended Storage measurement enhanced.
23. 3480 tape drive error counting in TYPE21 added.
24. Separate counts of 3420 and 3480 tape drives in type 30 and PDB.
25. VSAM VVR Type 60 record decoded.
26. NETVIEW modifications to NLDM record supported.
27. RMDS support.
28. SYNCSORT user SMF record support.
29. CINCOM SUPRA log record support.
30. VM Account LOGOFF record support.
31. ROSCOE 5.5 SMF Account record support.
32. IMF 2.3 support for DDNAME level I/O counting.
33. NETSPY support.
34. OMEGAMON EPILOG 1000 support.
35. Externalized BUILDPDB macro definitions in IMACPDB.
36. HOGAN FPS transaction function code data support.
37. CICS 1.7 EXCLUDE option "support".
38. IDMS/R Performance monitor from IDMS journal file supported.
39. Landmark's SPECIAL 78 zap (adds CICS 1.7 MRO fields) support.
40. Naming conventions established for MXG's use of "New style" macros.
41. Elimination of excess tape mounts for monthly and weekly jobs.
What did not get completed in MXG Version 5.5:
1. VM HPO Release 5 has not been tested. IBM documentation indicates
no change in the data, but no user has confirmed this to be true.
2. BUILDPDB enhancements (which will use the new macro facility) to
more easily control variable selection (eg, XA only, etc.) were not
completed. IMACPDB externalized the controls for you to give you
control without the additional complications and naming conventions
needed when we actually do this enhancement. It is still planned.
3. The MVS Tape Mount Monitor code is not yet operational. The ASM
source code (ASMONTAP) is on this library, but needs modifications.
One volunteer will examine the code next spring.
4. TYPE64 data (see technical note, below) has not yet been added to
ANALDSET algorithms to resolve the incorrect type 64 counts.
5. IMS log processing puts waiting for input transactions in IMSMSGOT
Other 1988 expectations:
IBM announced plans for operating system changes next year which will
likely require changes to MXG software. IBM dates given below are the
availabilty date in the IBM announcement. We always hope to provide
MXG support by availability date, if we can get both documentation and
test data in time. We will likely repeat the strategy of the past two
years: a spring newsletter to announce when the pre-release of the
next MXG version is available, and a production MXG version shipped to
all customers in the fall.
a. March, 1988. Expected availability of VM/XA SP1, with a complete
new set of monitor records, new format, and zero compatibility with
current VM/SP VM/Monitor data. IBM says there will be no VM MAP for
this new VM/XA monitor, but MXG will be there.
b. May, 1988. PTF to MVS 2.2 which adds VIO activity fields to TYPE71
data (this PTF permits VIO to be directed to Extended Storatge).
c. Unknown. PTF to add JOB and READTIME which IBM left out of the new
MVS 2.2 Type 41 (Data In Virtual) SMF record.
d. December, 1988. Expected availability of VM/SP Release 6, with many
new data elements added to existing VM/SP VM/Monitor. This release
includes the new VM Shared File System, which creates new data.
e. Unknown. We expect to enhance MXG to support the PDL data written by
the FACOM OSIV/F4 MSP operating system.
f. Unknown. Other rumored impacting events may be CICS 2.1, a new DB2
release, and DOS/VSE Power record changes.
The 5.1 tape was tested for forty days and nites at forty sites.
The 5.2 tape has been executing at over 75 sites since August. All
problems reported were fixed in the 5.3 tape, sent to an additionaly
30 sites. The 5.4 tape was the final pre-release before production,
ans was sent to an additional 30 sites. As promised in Newsletter TEN
(June, 1987), MXG Version 5 production was built before the end of
Fall, 1987 (which ends December 21, 1987). Merry Christmas!!!
TRIVIA: Halloween is equal to Christmas:
OCT 31 = DEC 25
Think about it!
The changes described in this member are already in this MXG version.
They are listed below, after the technical notes. You must read each
description of all changes to ensure that you understand their impact
on your installation. Changes thru 5.99 were on the 5.1 pre-release,
the 5.2 pre-release include changes thru 5.125, 5.3 was thru 5.143,
and changes through 5.165. Changes 5.1 through 5.74 were printed in
Newsletter TEN, and changes 5.75 through 5.166 were printed in the
Newsletter ELEVEN. Changes 5.167 through 5.173 were added after the
newsletter went to press.
COMPATIBILITY EXPOSURES:
1. The aggregation interval of RMFINTRV data set was relocated in the
new member IMACRMFI, instead of being defined inline.
2. VM/Monitor users must read Change 5.133. The meaning of VMONDEV data
set variable CNTVIOCT was altered. A new macro, _INTRVL, is defined
in IMACVMON which must be changed if the interval between VM/Monitor
records is not the one minute default set by MXG.
3. BUILDPDB/3 users who have modified those members will find IMACPDB
now contains (hopefully) all the definitions to allow you to locate
your tailoring external (in IMACPDB) instead of internally.
Note: The PTF or APAR numbers were provided by some system programmer
who has actually installed this fix, but sometimes the number will no
longer be valid; IBM supercedes and replaces PTFs, and one APAR often
has several PTFs for the same logical problem. Use this information
only to search INFO/MVS for more information and exact status.
HOT PTFs: MVS:
MVS 2.1.7 PTFs OZ44728 and OZ92196 appear to finally solve the long
outstanding constraint that the SMF interval (for type 30s and 32s) had
to be greater than JWT. These PTFs apparently are already in MVS 2.2,
and the documentation still recommends that the Interval duration be
greater than JWT, but experimental system programers have reported that
that recommendation is no longer a requirement. Don't take my word on
this, but I think it's probably true.
A new PTF (only for MVS 2.2 and later) finally allows you to specify
BLKSIZE of the SMF data. Requested through SHARE in the CME project in
1973, it has finally been acknowledged in APAR OY07209 and implemented
in PTF UY12002.
MVS 2.1.3 and 2.1.7 do not write type 7 records when SMF recording is
lost! Fix is PTF UY12608.
For 3090-400s, 300s, and 600s with 128MB real memory, there are lots of
performance problems if you do not install OY01085. Your CE should
have caught this one for you. MXG NL TEN misprinted this PTF number.
Overlay and loss of SMF records - many strange symptoms - fixed by
PTF UZ46460 and UZ48888-UZ48891. Critical, must be installed ASAP.
Incorrect SMF EXCP data, especially 30s, introduced by bad UZ45011,
fixed with UZ47837 (pre-reqs UZ47834-UZ47837 and UZ50314-UZ50316).
Noted loss of VSAM counts in type 30, was fixed by UZ47837.
Originally reported by MMA, complete loss of SMF data will occur with
DFP Versions 1.1.1, 1.1.2, or 2.1 if you have installed the PTFs for
APAR OZ96798, and you have NOT corrected the PTF-in-error condition
described by APAR OY02500. The SMF data loss condition is cause by a
problem in VSAM introduced by OZ96798 PTFs. Message IEE978E: SMF NOW
HAS nnnnn BUFFERS will be issued after the initial number of SMF
buffers are used up, but there is no other external indication that all
SMF records have been permanently lost.
Incorrect counting of some tape mounts in type 30 records. After the
installation of UZ50959, tape mounts issued with message IEC501E (Look
ahead mount message) are not counted. Mounts with messages IEC501A or
IEC233A continue to be correctly counted. APAR OZ97886 describes the
problem, accepted by APAR OZ97617 which has the fix. The problem
primarily affected multiple volume mounts; only the first volume mount
was counted in the type 30.
HOT PTFs: VM:
Concatenated MACLIBs on different mini-disks will fail; only the first
MACLIB in the concatenation will be searched until PTF VM24283 is
installed. As long as the MACLIBs are on the same mini-disk, there is
no problem with concatenation (as suggested for the MXG SOURCLIB and
USERID SOURCLIB libraries).
Technical Notes, MVS:
a. Counting allocated tape drives.
The following is a revision of a note originally in MXG Newsletter TEN:
Counting of tape drives (TYPE30_4 or PDB.STEPS variables TAPEDRVS,
TAPE3420 and/or TAPE3480) is affected if the job step dynamically
allocates tape drives. For example, DB2MSTR dynamically allocates a
drive every time the recovery data is backed up. If each allocation
happens to get a different tape drive, the step record for DB2MSTR
would contain a different DEVNR (old UCB address) for each tape, which
MXG would count as a large number of tape drives. Only a few jobs
actually use dynamic allocation (thank goodness), but they tend to be
long running DBMS, which wreak havoc on the number of tape drives
perceived by ANALTAPE to be in use. You must use the type 40 (Dynamic
Allocation) record to find those jobs that dynamically allocate tape
drives, and exclude their step records before processing STEPS with the
MXG ANALTAPE program. Otherwise, it will appear the job step had all
those tapes for the entire time the step executed.
You can use the MXG Exit Facility to add type 40 processing, and in
the exit (EXTY40) and use:
IF DEVICE='3420' or DEVICE='3480' THEN OUTPUT TYPE40;
to only create observations for tape devices.
VMAC40 reads in a 40 and calls VMACEXC1, which decodes DEVCLASS,
DEVTYPE, and DEVNR for each UCB segment. VMACEXC1 then calls
VMACUCB to decode DEVCLASS and DEVTYPE (hex) into DEVICE (char);
the value '3420' or '3480' is set for tape devices.
Since SMF offers no option to create type 40's just for tape, you
still have to create all type 40 records, but this use of the EXTY40
exit allows you to keep only tape observations in TYPE40.
b. I/O Counts in TYPE70 and TYPE78IO.
The MXG Supplement noted that the I/O Interrupt Counts in TYPE70 were
observed to be greater than the 3090 IOP I/O Activity in TYPE78IO. It
was pointed out that IBM notes (in LY17-5500) that both TYPE78IO and
TYPE70 count SSCH (i.e. SIOs) and RESUMES, but that TYPE70
additionally counts PCIs, Device End following Channel End, and
Unsolicited Interrupts. The difference has been seen as 12-14% more in
TYPE70. Is this a useful indicator of anything?
c. SMF TYPE64 (VSAM I/O) counts.
VSAM counts (EXCPs, SPLITS, etc.) in type 64 records are wrong if the
VSAM file is concurrently opened. These counts are the "change since
open". Four jobs which concurrently opened the same VSAM file and then
read 9000 blocks, showed 9000, 18000, 27000, and 36000 EXCPs in their
type 64 records. The type 30 SMF record EXCP counts are correct. The
type 64 record has always been this way; only recently did a user
investigate the data. MXG will be enhanced to de-accumulate TYPE64
data, as ANALDSET does to de-accumulate TYPE1415 data. You could find
a CASPLIT count in a type 64, but the actual split may have been caused
by a separate job. You must sort all accesses to the same VSAM file by
open time and examine the end time for potential overlap and perform
you own de-accumulation.
d. CPU and I/O measurements when writing tapes.
In creating tape copies of MXG Version 4.4, we used SYNCSORT's free,
fast BETRGENR replacement for IEBGENER. Since BETRGENR copies one
cylinder at a time, the 833 blocks of 6160 bytes each required only 11
Start IO's, each SIO transferred 550KB of data in .44 seconds (you can
hear the voice coil humm that long), but there was then a delay of
about .6 seconds for the next SIO to commence (again, heard at the tape
drive). As a result, while the channel capacity is 1.25 MB/sec, even
with the transfer of 550KB per SIO, the effective channel capacity was
only 550KB/sec, or only 44% of IBMs stated capacity. This was in a
dedicated processor with no other work in progress.
Furthermore, this was for a single copy of the MXG library. The actual
data transfer took 11 seconds for the 11 SIOs, but the physical loading
of the tape, the swap in to reply (tapes are NL) and the rewind and the
unload time total just about one minute elapsed time. Because we were
waiting on the computer (THE definition of bad response) we allocated
more tape drives and found that with two tape apes (us), and four tape
drives, we could create 100 tapes per hour. Increasing the tape drive
count to six drives increased our production to 163 tapes per hour.
Note at this rate of 163 5.5MB tapes written per hour, the tape channel
was still only utilized at 250KB per second, or only 20% of the peak
transfer capacity. The peak-to-sustainable rate here was 5 to 1.
This should point up the fallacy of using the peak transfer rate (or
any peak rate) as a measure of capacity, without determining the actual
sustainable transfer rate. IEEE Computer magazine recently had a good
discussion with regard to the ratio between peak mega-flop rate and
achievable mega-flop rate on super computers, reporting typical ratios
also in the 5 to 20 range.
Each job executes 255 copy steps. All steps except the first recorded
.40 or .41 TCB seconds and .03 SRB seconds on a 3090-200. With 5.5MB
of data per step, this 13 MIPS (speed) processor is moving data at 13.4
MB per second. This is quite close to the one byte per one instruction
rate first noted on page 842 of the MXG book!
The first step of each job, however, required 1.06 TCB seconds and .06
SRB seconds, or 1.12 total CPU seconds apparently because the CPU time
for operator response to allocation recovery is captured in the step.
Each job enters allocation recovery because its specific UCB address is
offline at job initiation. The IEF244I - "Unable to allocate" message
set up the IEF238D - "Reply Device Name or Cancel" WTOR and the
R,99,181 reply apparently records .68 CPU seconds in the step record.
(The job which specifies VOLSER=MXG181 allocates UCB 181. NL tapes are
built so only one mount is needed, but require a reply to confirm the
VOLSER. With the UCB in VOLSER, the reply is fast and accurate.)
e. More EXCPs in 30's than in 4's and 34's.
Several sites have noticed approximately 10% more EXCPs are counted in
the type 30 subtype 4 (TYPE30_4 data set) record than the EXCPs in the
step type 4 (or type 34) for the same step. The type 30 is correct,
and the additional count in type 30 is due to the EXCP count to dynamic
allocations, which are captured in 30s but never were captured in the 4
or 34 records. As described on page 628 of the MXG book, if you used
4s or 34s, you had to use the 40s also. This is only one more reason
why the type 30 SMF record has (since 1978) always and all ways been
better than the type 4/34 records. It's even worse for the 4s and 34s
now. In MVS 2.2, IBM turns on a new flag bit in 4s and 34s to tell you
that the EXCP data on this step is incomplete in the 4/34 record and
you must use the type 30 for this step. (This happens for any step
with more than 1651 DD cards). STOP USING 4's and 34's! (MXG's
BUILDPDB has always used only type 30s.)
f. More CPUTCBTM in SMF than in RMF for a step.
Step termination data shows that the SMF CPU TCB time in the SMF type
30 can be slightly greater than the RMF CPU TCB time in RMF service
units in both the SMF type 30 and the RMF type 72 record for that step.
The step recorded 8.13 CPUTCBTM seconds in TYPE30_4, but CPUUNITS in
the step record (converted to CPU seconds) showed only 8.08 seconds.
This step executed in a unique performance group, and the TYPE72
CPUTCBTM was also 8.08 seconds for the interval in which the step
executed. This is not statistically significant, but an IBM expert
suggests this occurs because RMF gets it service unit values
(CPUUNITS,SRBUNITS) from the job data during step termination. This is
why the CPUUNITS in the type 72 data matched. However, after the
service units have been passed to RMF, the job is still in termination
and the SMF clock is still accumulating true CPU time for the step.
The extra CPU time recorded in the SMF step record may be due to SMB
processing (putting those termination messages on your SYSLOG listing)
or it could be installation code executing in SMF exits (perhaps to
print the job costs on the "banner page" in SMF exit IEFU83 or IEFU84).
At this site, there appears to be a fixed cost of .05 TCB seconds per
step termination which is not recorded in the TYPE72 CPUTCBTM, but
which is recorded in the TYPE30 CPUTCBTM. Even at 1000 steps
terminating each hour, this would be only 50 additional TCB seconds
for each 3600 seconds, or only about one percent.
g. MVS 2.1.7 page data set allocation size.
The Contiguous Slot Allocation algorithm, the very efficient way of
transferring up to 30 page frames contiguously with one SIO and with
minimal arm movement, was introduced for page data set I/O with MVS/370
SP 1.3 in the late 70's. Recently, several authors have concluded that
the algorithm will perform well only if the maximum number of slots in
use is less than 25% of the slots allocated. When the page data set is
full, the algorithm can not perform well, because it can not find
contiguous free slots. This greatly increases the search time, which
can negate the positive performance of the algorithm. For MVS/370
VSCR, IBM had recommended minimizing the number of slots allocated to
relieve MVS/370 VSCR because a small amount of CSA is used for each
slot allocated. With only 50K-60K virtual storage saved, real paging
is likely a more serious problem, and thus a larger page data set
allocation may still be advised. In early MVS/XA there also was a real
problem with large page data sets causing excessive seek times, but
that design error was fixed in MVS 2.1.2. You can use the MAXUSED and
SLOTS variables in TYPE75 to see if you might have a problem, and could
plot the percent used versus the service time (AVGRSPMS from TYPE74)
for each paging volume to confirm its real impact. It is clear that an
insufficient number of allocated slots will degrade the contiguous slot
algorithm; the exact percentage at which you encounter increased
service time may not be 25%, and you should construct your own data for
analysis.
h. Use STEP data for job ABEND analysis.
Analysis of "Job" abends really must be done from the PDB.STEPS (from
TYPE30_4 step termination), rather than from the PDB.JOBS (from
TYPE30_5 job termination). The CONDCODE and ABEND variables (Page 578
in the MXG Book, page 266 in the MXG Supplement) describe the value and
the type of termination. ABEND values of SYSTEM or USER indicate
abends and CONDCODE identifies the abend code, such as SYSTEM 322 or
USER 999. An ABEND value of RETURN indicates that CONDCODE contains a
return code value. While both variables exist in both PDB.JOBS and
PDB.STEPS, the ABEND value in PDB.JOBS is from the job termination
record, and can show an ABEND of SYSTEM for the job with a CONDCODE of
zero if the step which ABENDed was not the last step! The PDB.STEPS
data is thus not only more accurate, but since many abends result are
due to defective programs rather than defective jobs, using the STEPS
data allows you not only to identify which JOB abended, but also to
identify the name of the PROGRAM which abended. You may even be able
to recognize (by your program naming convention) which of your
development groups wrote the frequently-abending programs!). PDB.STEPS
data also identifies which step actually abended first when there are
multiple abends (and when there are COND=EVEN and COND=ONLY steps).
CICS CMF record blocksize is set by the JCT BUFSIZE parameter, and
typically is only 6000, which should be increased to half-track on
3380s to reduce IO counts and CPU overhead in building CMF records.
NPM may produce negative square root when calculating standard
deviation, since SSQ field can wrap in NCP.
Tape mounts in TYPE30_4 and PDB.STEPS does not include mounts issued
by JES3 for MDS mounts; they are counted in the JES3 Type 25 record.
Steps which mount a tape, and then RETAIN, will show zero mounts for
the subsequent step. If you want to identify steps which actually
use tape in any step, the EXCPTAPE and IOTMTAPE are much better
indicators of actual usage.
UCC7 can cause invalid READTIME error messages. There are two options
for UCC7 to identify jobs which are under its control. By default, the
eighth byte of JMRUSEID (the 'User identification field', MXG variable
LOCLINFO) is used. The UCC7 installer can choose any other byte of the
JMRUSEID if other products use the eighth. If all eight bytes are used
by other products, UCC7 will optionally store its flag in the first
byte of the Job Reader Date field. The normal value stored is a 'EE'X,
but if NCF is also installed, the field can take on almost any value.
When the Job Reader Date field is used, UCC7 traps each SMF record as
its being written and clears out the high order byte. Unfortunately,
the trap uses a table of SMF record IDs, and records which UCC7 does
not know about (such as the type 60, 61, 65, 66, 78, 80 and all user
records such as ACF2) are passed into the SMF file with an invalid
reader date. The result is a missing value for READTIME for these UCC7
controlled job records. Pages 2 and 9 of the UCC7 Installation Guide
discuss these options, and UCCEL technical support has the fix for the
60's and 80 records, as well as advice for handling user SMF records.
If the record has the Reader Date in the "standard" location (bytes
27-30), the fix is simply to add the record ID to ICMDSECT. For records
with relocatable format (like the type 78 record which can record a
specific job's virtual storage), more complicated instructions are
available from UCCEL. Since MVS 2.2 will use the first byte of the
date field for dates in the next millennium, UCC7 designers are looking
for an alternative.
Technical Notes, VM:
There are two ways to hold SPOOL data in VM so that it exists after the
spool data is read:
SPOOL READER HOLD holds the reader, while
CHANGE READER nnn HOLD holds the file
Hold only the reader, never hold the file, if you want the data to be
read. The CMS Diagnose 14 Subtype 1C command which is used to read the
monitor data in the spool, skips over held files.
VM will not create VBS records. If you install MXG under CMS to read
SMF data, you cannot build the SMFSMALL data set described in the
installation instructions. Change the Filedef and the FILE statement in
UTILGETM to build the SMFSMALL file with RECFM=VB,LRECL=32756, and
BLKSIZE=32760 on a 3380 disk and the program will work. Yes, it will
not make efficient use of the disk space, but SMFSMALL is only a small
test file of SMF data. VM is capable of reading VBS input tapes, so
you should have no problem processing SMF under CMS.
Technical Notes, SAS:
a. Eliminating tape mounts for SAS tape data libraries.
Many users have found that the weekly and monthly PDB jobs (described
in Chapter Thirty-Five with examples in MONTHBLD and WEEKBLD) can cause
lots of tape mounts and rewinds. Some sites have resorted to the
parallel allocation of as many tape drives as there are tape volumes to
avoid mounts. This problem is not unique to MXG, but results from the
protective instincts of SAS when tape data sets are involved. As you
will see, we now have a sucessful circumvention which minimizes the
amount of temporary DASD needed by WEEKBLD and MONTHBLD, and completely
eliminates the multiple rewinds and mounts for the output library.
The Present SAS Design:
SAS data libraries on tape volumes have no directory of what SAS data
sets are where on the tape. When a SAS SET statement needs to read a
SAS data set from tape, SAS rewinds to the beginning of the tape, and
searches for the desired data set. When a SAS DATA step writes a SAS
data set to tape, the tape is first rewound to the beginning, and SAS
searches for the data set name. If no match is found, SAS puts the new
data set at the end of the tape. (If a match is found, SAS starts the
new data set where the old one was found, erasing all old data sets
after that point on the tape.)
The Source of the Problem:
The required rewind spins the tapes a lot. If the SAS data library
fits on a single volume, there is not too much of a problem. But if
the output tape library expands to a second tape volume, each rewind
(i.e., each new SAS data set) causes the second volume to be
dismounted, the first volume to be mounted and searched, and then the
second volume remounted and searched, and finally the new data set is
laid down at the end of the tape! This always occurs when SAS DATA
steps create the tape data library.
Past Circumventions:
One solution was to build all of the desired SAS data sets on disk, and
then use PROC COPY from disk to tape. The PROC COPY knows it does not
need to rewind before each data set. While this avoids the mount
problem, it requires as much temporary DASD space as the size of the
entire SAS data library, which is why it was not recommended.
The New Solution:
Each new SAS data set is first built on temporary DASD in "tape
format", and then is copied to the output tape using FILE/INFILE logic,
exploiting the SAS CLOSE=LEAVE option to hold the output tape in place.
The temporary DASD data set is then erased, so that the job needs only
as much DASD space as the size of the single largest SAS data set to be
created. The "tape format" is created if the DDNAME of the SAS data
set being created starts with TAPE...., and is necessary so that the
SAS data set can be copied with the FILE/INFILE logic. The following
partial example shows how this is done (see member MONTHBLD for
complete implementation):
// EXEC SAS,OPTIONS='TAPECLOSE=LEAVE,GEN=0,ERRORABEND'
//MONTH DD DSN=MXG.MONTHLY(+1),DISP=(NEW,CATLG),UNIT=TAPE,
// DSCB=SYS1.MODEL,LABEL=EXPDT=99000
//TAPETEMP DD DSN=&TEMP,UNIT=SYSDA,SPACE=(CYL,(10,10))
DATA TAPETEMP._DSET; create _DSET in TAPETEMP
SET WEEK1._DSET WEEK2._DSET ... ; input data sets
BY _BYLIST: sort order variables
IF date selection logic; selection criteria
RUN:
DATA _NULL_; copy _DSET to MONTH
INFILE TAPETEMP;
FILE MONTH MOD CLOSE=LEAVE;
INPUT;
PUT _INFILE_;
DATA _NULL_; write EOF to TAPETEMP to
FILE TAPETEMP; "scratch" _DSET
These three DATA steps are then repeated for each data set to be built,
by invoking the _MNTHBLD macro as shown in member MONTHBLD. Our thanks
to Susan Marshall, SAS Institute, for this circumvention. The only
additional cost is the extra copying of each output data set. This
solution only eliminates mounts for the output SAS data library. If
the input data sets are on multiple volumes, each new data set may
causes the same rewind and dismount/mount sequence. These input mounts
can only be eliminated (at present) by specifying multiple units where
necessary, eg., with UNIT=(TAPE,2) for a two-volume input tape data
library.
SAS Institute is investigating a new SAS option which might allow
you to override that "rewind and search" algorithm for both input
and output tape data libraries. Provided the order of building new
data sets is the same as their order on the input data libraries,
such an option could completely eliminate the unnecessary mounts and
unnecessary copy steps. No commitment has been made by SAS yet.
However, early experience with this circumvention is overwhelmingly
positive - fewer tape drives, fewer tape mounts, significant reduction
in elapsed time, all for a few seconds of I/O time!
b. SAS ZAPs which you should install.
ZAP 516.2525 Corrects (erratic) error condition in PROC PLOT if
data set has zero observations.
ZAP 516.4592 PROC FORMAT can cause a "STOW failure" message on the
SAS log (no error condition, no abend) if the PDS to
which the formats are being written does not have
enough directory blocks defined. Some formats will be
missing, with no notification. This ZAP tells you.
c. SAS Options which you should be aware of.
FREE=CLOSE either as a SAS option or on a DD card in a SAS job
interferes with the IBM STIMER routine, which is used
to measure SAS step CPU time. FREE=CLOSE has caused
unpredictable USER 999 ABENDs with the SAS error
message CPU TIME EXCEEDED and a large value of CPU
time shown on the SAS log. The value on the log is
wrong (see the Step Termination message to confirm)
but the STIMER poped and SAS shut the step down.
Either do not use FREE=CLOSE, or use the SAS NOSTIMER
option, which eliminates the problem, but will also
eliminate the CPU used message on the SAS log.
NOMEMFILL Should always be specified, MEMFILL is a SAS debug
developers option which should never be used, as it
causes a seven-fold increase in CPU time.
==========================Changes======================================
The following changes are already in the Production MXG 5.5 library.
Some of the changes contain the code with line numbers, because those
changes were originally distributed (via prior newsletter, telephone
or telefax to correct immediate problems. Just for your information,
lines to be inserted have a period after the line number they are to
follow; existing lines which needed no change (usually included to
locate the change) have no period in their line number.
While this newsletter hits the high spots, you must read each change
description to ensure that you understand their potential impact to
your installation.
ALWAYS read member CHANGES for last minute changes and notes. This
newsletter is mostly an editied version of CHANGES slightly before
the production library is created.
ALWAYS read each member listed under an impacting change for
additiona comments, notes, and any last minute documentation.
Members DOCVER and DOCVER05 document the entire collection of data
sets created by MXG (DOCVER), and the delta-documentation of data
sets and variables changed between MXG Version 4.4 and 5.5.
NEXTCHANGE: Version 5
=============Changes thru 5.173 as of Dec 17, 1987 ===================
==================completed MXG Version 5.5.==========================
--Changes 5.167-5.173 were added after Newsletter ELEVEN was printed--
Change 5.173 Processing of IMF (Control/IMS) records from Boole &
Dec 17, 1987 Babbage with IMS Release 2.0+ was failing. The test of
VMACCIMS IMSLEVEL NE:'13' caused old format INPUT statement to
be executed. Test is now either LT:'13' or GE:'13'.
Thanks to Dave Lawrence, NCNB of Florida, USA.
Change 5.172 CICS 1.6 dictionary entry for USER field with length
Dec 17, 1987 of zero (i.e., no USER field in your data) caused an
UTILCICS unnecessary, incorrect and superfulous MXG message.
Change 5.171 Support for CICS 1.7 PTF UL14896 (which adds a new
Dec 16, 1987 SCWTETIM field to CICSEXCE exception data set). MXG
IMACPTF creates variables SCWTETM and SCWTECN for the field,
UTILCICS which reports time in suspend because unconditional
VMAC110 storage request was not satisfied.
Thanks to Joseph Faska, Chemical Bank, USA.
Change 5.170 Some complexity-level-4 variables had level-3 in their
Dec 16, 1987 labels. Labels are now correct. Member ANALRTM1 (only
ANALROSC existed in pre-releases) was eliminated by rewrite of
IMACROSC ANALROSC. Read important comments in ANALROSC, as it
TYPEROSC now deletes "useless" ROSC.... and RRTM.... data sets.
VMACROSC New macro _ROSCDDN is now defined in memeber IMACROSC
to name the DD to which final ROSCOE data sets are to
be written: _ROSCDDN.ROSCOE, _ROSCDDN.RRTMPSE and the
_ROSCDDN.ROSCAWS "important" data sets. Less important
data sets ROSCOAUD, ROSCOSHU, and ROSCOVPE are left in
the work file.
Thanks to Terry Trevier, Naval Construction Battalion Center, USA.
Change 5.169 The SMF interval recording INTERVAL variable was read
Dec 15, 1987 with TODSTAMP8. (an IBM TOD datetime value) instead of
VMAC90 with MSEC8. (a TOD time value). As a result, it was
printed as -525935 hours and 25 minutes - the correct
number of hours backwards from 01JAN1960 (SAS's zero
datetime) to 01JAN1900 (IBM's zero datetime).It now
will correctly print 00:30:00 for thirty minutes
Thanks to Shawn Wikle, Citibank South Dakota, USA.
Change 5.168 The %%INCLUDE which should have been %INCLUDE now is.
Dec 15, 1987
VMXGVTOC
Thanks to Chuck Rexroad, Perpetual Savings Bank, USA.
Change 5.167 The NETSPY support (Change 5.164) was written with no
Dec 15, 1987 knowledge that Duquesne provided sample SAS code with
ANALNSPY the product. With Duquesne approval, NETSPY support
EXNSPYAP now uses almost all of their variable names, so as to
EXNSPYLU preserve any reports you might have already written.
EXNSPYLI The MXG data sets created are different than in 5.4:
EXNSPYNC NSPYAPPL, NSPYLINE, NSPYLU, and NSPYNCP are now the
VMACNSPY four data sets created. Exits EXNSPYSE and EXNSPYTE
were deleted and EXNSPYLU and EXNSPYLI now exist. Data
from NETSPY 3.0 has now been tested. The default PROC
PRINT reports from Duquesne's sample are in ANALNSPY.
Thanks to Andy Schoentrup, Public Service of Indiana, USA.
Thanks to Luis Motles, Duquesne, USA.
==========Newsletter ELEVEN printed changes through 5.166=============
=============Changes thru 5.166 as of Nov 24, 1987 ==================
Change 5.166 The monthly MXG job can cause lots of tape mounts and
Nov 24, 1987 rewinds when a SAS DATA step writes multiple data sets
MONTHBLD to tape (SAS is preventing duplicate named data sets).
this change is a circumvention which writes the new
data sets first to a temporary disk file, but by using
a DDNAME starting with TAPE...., the data set is built
in "SAS tape format", which can then be copied from
the temporary disk file to the monthly tape with an
INFILE/FILE pair, which eliminates the rewinds. The
temporary TAPETEMP file only needs to be as large as
the largest single data set to be created. See the
code and comments in this member and MXG NL ELEVEN.
Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
==========The 5.4 Pre=Release included changes through 5.165=========
Change 5.165 This change will not affect many sites. It will be
Nov 22, 1987 needed ONLY if you receive the "Compiler Limit is
XMAC7072 Exceeded" error message from SAS on the SAS log.
XMAC71 This error does not occur with BUILDPDB unless you
XMAC73 have added many other SMF records with the PDB Exit
XMAC74 facility. (Only the world's largest PDB builder has
XMAC75 encountered the problem). The compiler limit problem
can not be fixed by SAS until Version 6, but we have
several circumventions available. The compiler has
a 4K table (cannot be expanded, thats the problem)
which sets an upper limit on the number of "Iterative"
DO statements (i.e., DO I=1 to something, DO WHILE,
DO UNTIL, but not DO groups like IF x THEN DO which
predominate in MXG code). There is an upper limit of
99 "Iterative" DO statements in a data step, but the
4K table is used by other SAS statements. The default
BUILDPDB has an actual upper limit of 56, but the MXG
default SMF record proccssing macros only use 24.
These new members are MVS/XA-only copies of their
corresponding VMAC.... member. By stripping out the
MVS/370 code, we reduced the number of "Iterative DOs"
these members would consume. This is only a temporary
solution. In our next version, we will begin to employ
the "new" SAS macros and will dynamically select the
MXG code which will be passed to the compiler, which
should stave off any compiler limit long before SAS
Version 6 is available on mainframes.
Thanks to David Daner, Sun Company, USA, USA.
Change 5.164 Support for the Duquesne network monitor NETSPY user
Nov 22, 1987 SMF record was added. Data for Release 2.3 and 3.0 has
EXNSPYAP been tested, but this still is our first support. s
EXNSPYNC Data sets NSPYAPPL, NSPYNCP, NSPYSESS and NSPYTERM are
EXNSPYSE created; member IMACNSPY sets the SMF record ID.
EXNSPYTE
IMACNSPY
TYPENSPY
VMACNSPY
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 5.163 Pre-release code for Candle's EPILOG 100 SMF data. The
Nov 22, 1987 MXG redesign of the SAS code provided by Candle has
EXTYEPIL not been tested with data. Only one data set is now t
IMACEPIL created, but this may be changed once real data volume
TYPEEPIL and data structure is known. Call for status before
VMACEPIL you execute this code.
Change 5.162 New member IMACPDB externalizes MXG code which was in
Nov 20, 1987 BUILDPDB/3. The control of the NODUP option, and the
BUILDPDB macro definitions for the MXG variables which will be
BUILDPD3 kept in the PDB data sets was moved to this member, so
IMACPDB that you can tailor PDB function in the IMACPDB exit.
UNLESS YOU HAVE MODIFIED BUILDPDB/3, THIS CHANGE WILL
HAVE NO EFFECT ON YOUR INSTALLATION. Only minor logic
changes were made in this relocation of code. The PROC
MEANS logic which SUMs, MINs, and MAXs variables into
PDB.JOBS from STEPS is now a macro (_PDBSUMS) defined
in IMACPDB, and two macros, _PDB26J2 and PDB26J3 (for
type 26 variables), replace the previous single _PDB26
definition.This is the first step in planned changes
to BUILDPDB to externalize variable selection and to
make user tailoring even easier. IMACPDB will be the
control point for these future enhancements. This is a
good time to say to the original suggestor of NODUP
logic, the formerly "unknown Australian",
Thanks to Phil Bailey, NRMA Data Processing, AUSTRALIA.
Change 5.161 Support for optional Hogan function code data for
Nov 20, 1987 Hogan System application transactions under CICS is
IMACICUS now described and implemented in this member.
Thanks to Chester W. Sutton, Sears Consumer Financial Corp, USA.
Change 5.160 Titles were cleaned up to be more descriptive, and the
Nov 19, 1987 (seldom needed) debug option TYPE110-4 is supported.
UTILCICS
Thanks to Pete Shepard, Ashland Oil, USA.
Change 5.159 ACF2 data for type "T" records has been debugged and
Nov 19, 1987 the pre-release's "congratulations, you found the
VMACACF2 untested code" message has been eliminated. Also, the
ACTFMTOD field is PIB4.2 and FORMAT TIME12.2 and
length 4, as it turns out to be only a time, not a
datetime.
Thanks to Pete Shepard, Ashland Oil, USA.
Change 5.158 CICS 1.7 monitor facility permits your installation
Nov 19, 1987 to EXCLUDE fields in the CICS type 110 records. It is
VMAC110 not my opinion that EXCLUDE is wise (almost for sure,
the variable you exclude will be the one you need),
but this enhancement provides support for CICS 1.7
transaction records created with the EXCLUDE option.
The instructions for using this MXG enhancement are
described by comments in member VMAC110. Search for
the string CICS1.7EXCLUDE (two hits).
Thanks to Dale Mattison, Shared Medical Systems, USA.
Change 5.157 IDMS/R Performance Monitor (formerly RTE) data can now
Nov 19, 1987 be processed from journal file with member TYPERTEJ as
TYPERTEJ well as from SMF file with member TYPERTE.
VMACRTE
Thanks to Jim Lawrence, Central and South West Services, USA.
Change 5.156 Type 24 SMF (JES2 SPOOL Transfer) records have now
Nov 18, 1987 been validated (and code corrected). SMF24CNT is PIB4.
FORMATS vice PIB1. Format MG024BC: new values for 'A0'X and
VMAC24 'C0'x were added. Format MG024SF: new values for '44'X
and '24'X were added. The value of variable SMF24EOJ
is always zero unless this is the last SYSOUT outgroup
of this job. In that instance, SMF24BCF will contain a
'..1.....'B ('20'X or '24'X), and only then will the
variable SMF24EOJ contain true End-Of-Job condition.
Thanks to John Dundas, International Flavors & Fragrances, USA.
Change 5.155 NETVIEW changes to original type 39 NLDM record were
Nov 18, 1987 not completely corrected by Change 5.57. SCS length is
VMAC39 actually 117 vice 118, because BINDCODE is PIB1. not
PIB2. This well documented change is with
Thanks to Mark Shephard, Dun & Bradstreet EBIC, ENGLAND.
Change 5.154 IMS Log variables DESTLINE and DESTTERM should have
Nov 18, 1987 been read as PIB4. vice PIB2., with HEX8. format.
VMACIMS
Thanks to Freddy Simberg, PK Banken Stockholm, SWEDEN.
Change 5.153 Several changes to Landmark's MONITOR for CICS:
Nov 18, 1987 1.Landmark's MONITOR summary history file records caused
TYPEMONI "Invalid data for TASKNR" because summary record has
nulls (hex 0) value. Error message eliminated and the
variable MONIRECD now correctly contains 'H' for the
History (Summary) observations and 'D' for Detail.
2.Observations in MONIDBDS and MONIUSER will now occur
only if the segment actually contains data. FATNUM
counts DBD segments in record, not the number which
contain data, and UTNUM counts the user segments, but
not the number which contain data.
3.Support for Landmark's SPECIAL 78 optional zap to
TMON Version 7.0 creates CICS 1.7 variables UOWID,
UOWTIME, USER, and NETSNAME in MONITASK data set.
Supplement pages 170-171 describe these variables.
UOWTIME is the decoded time stamp from first 6 bytes
of UOWID). Variable SYSTEM was also added to both
MONITASK and MONISYST data sets with this zap.
4.Initialization of all character values set by bit
testing and SKIP logic for any new data was added
5.Variable DURATM in MONITASK was not calculated for
the first interval during re-processing with DIF().
Two elegant algorithms were provided by two users,
and the shorter one (using POINT= to read ahead to
the next record) was chosen.
Thanks to Kathy Manos, The Stroh Brewery Co, USA.
Thanks to Robert Lewis, Landmark Systems Corporation, USA.
Thanks to Chuck Rexroad, Perpetual Savings Bank, USA.
Thanks to Simon Hendy, British Telecom, ENGLAND.
Thanks to Steve Morton, SAS Institute, ENGLAND.
Change 5.152 The CPU-specific variables PCTCPBYx "defaulted" to
Nov 16, 1987 100% busy for offline CPUs. This had minor impact,
VMAC7072 since variable NRCPUS showed how many were online,
amd also since CAIx flags each CPU as to on/offline
status. Furthermore, PCTCPUBY always accurately had
the true percent of online cpus time which was busy.
Nevertheless, the misleading 100% for PCTCPBYx has
been replaced with a missing value for CPUs which
were not online for the entire interval. (With this
change, the MVS/370 record logic was changed to use
the more robust MVS/XA technique.)
Thanks to Stephen Geard, Commonwealth Bank of Australia, AUSTRALIA.
Change 5.151 I finally accept the need to use the new SAS Macro
Nov 16, 1987 Facility. This change establishes naming conventions
USER.... for MXG members. The %MACRO facility works best if
USR..... the macro name is the same as the member name (then
VMAC.... AUTOCALL can be used). To facilitate this feature,
VMXG.... MXG will hereafter use names starting with VMXG....
VMACVTOC for both the member and macro name of MXG-supplied
VMXGVTOC new style macros. To balance this "theft", MXG will
hereafter not use member names starting with USR....
or USER.... - these will always be available to you.
Thanks to Bill Gibson, SAS Institute, AUSTRALIA.
who's comment on "using VMACVTOC (now VMXGVTOC) to graze the disk
farm" was under study when this choice was made.
Change 5.150 IMACFILE, taken after an SMF record has been read by
Nov 16, 1987 any MXG code, is self-documented, and is used for many
IMACFILE purposes, including deleting bad SMF records, printing
VMACSMF a "defective" SMF record, etc. IMACFILE is invoked by
VMACSMF. This change "cleans up" comments in VMACSMF,
and now new comments in IMACFILE identify all of the
variables which exist when IMACFILE is taken.
Thanks to Jim Gilbert, Texas Utilities, USA.
Change 5.149 Variable ZDATE was added to VMONUSRS, the one-per-user
Nov 16, 1987 summary data set. This provides the date of MXG run,
VMACVMON not the processing date of the data. VMONUSRS is the
summary of all observations in VMONUSRD (which could
be daily, weekly, etc.). Tailored summary (by hour, by
day, etc.) can be done in your code from VMONUSRD.
Thanks to Jim Gilbert, Texas Utilities, USA.
Change 5.148 CICS 1.7 UOWTIME was not properly decoded in the pre
Nov 16, 1987 releases of MXG for terminal tasks. Now it is. (Note
VMAC110 that UOWID, the 8-byte character string by which MRO
transactions can be collected was always correct; only
the extraction of its timestamp was in error).
Thanks to Bernadette Young, First Virginia, USA.
Change 5.147 MVS 2.2's catalog address space creates a type 30
Nov 16, 1987 interval record with JOB=IEESYSAS & TYPETASK=CATALOG
VMAC30 which caused "Invalid JESNR" message (no error set).
This change tests for IEESYSAS (system address space)
job name to avoid missing JES number for address
spaces which start before SMF is started.
Thanks to Jim Gilbert, Texas Utilities, USA.
Change 5.146 Variable DEN (tape density) in TYPE1415 data was not
Nov 13, 1987 decoded for 3480 (density=38000) devices. Now it is.
VMAC1415
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 5.145 Variables ROSJOB, ROSTIME, SMFTIME and SYSTEM only are
Nov 13, 1987 in ROSCOE 5.5 and later. The ANALRRTM reports, however
ANALRRTM used these variables, which were not defined in this
VMACROSC member (used only for ROSCOE 5.4A and earlier). This
VMACRRTM change initializes these four variables to blanks or
missing values so that ANALRRTM will work with either
ROSCOE 5.4, 5.4A, or 5.5 RRTM data.
Variable ZDATE was added to all ROSCOE data sets too,
and the code was prettied up.
Thanks to Rich Surgener, Security National Bank, USA.
Thanks to Jim Gilbert, Texas Utilities, USA.
Change 5.144 Change 5.44 should have also applied to ANALDB2. The
Nov 13, 1987 variable QXQUERY is now QXSELECT and QXALTBF is now
ANALDB2 QXFETCH in lines 331 and 354 respectively.
Thanks to David Daner, Sun Company, USA.
----Changes thru 5.143 as of Oct 22, 1987 were included in MXG 5.3a--
Change 5.143 Two syntax errors slipped into 5.3. prerelease tape.
Oct 22, 1987 1. Added semicolon to the end of line 2182.1 in member
VMACVMON VMACVMON.
VMACCIMS 2. Added DBDNAME $8. to line 180 (before semicolon)
in member VMACCIMS.
----Changes thru 5.142 as of Oct 15, 1987 were included in MXG 5.3---
Change 5.142 ROSCOE 5.5 support, including the AUDIT record and the
Oct 14, 1987 RRTM (response time) data, has now been added. This
TYPEROSC changes most of the ROSCOE members, and adds several
et. all. new data sets from accounting data. The RRTM records
are now a subtype of the SMF record, and the RRTM data
sets are now built by TYPEROSC. (Member TYPERRTM is
still in MXG if you are not yet on ROSCOE 5.5). Data
for all 5.5 records has been tested, except for the
5.5 Audit record (but that's not likely to cause you
any problem - ADR doesn't document how to enable that
new record, though they will tell you how by phone!)
Change 5.141 Boole & Babbage's IMF (formerly Control/IMS)
Oct 14, 1987 optionally will capture I/O at the DDNAME within
VMACCIMS DBDNAME for those DBDNAMEs with multiple DDNAMES. This
change adds the new variable DDNAME to the CIMSDBDS
data set. If the DDNAME is not blank, this is a DD
entry, otherwise it's a DBD.
Thanks to Ron Root, Sun Company, USA.
Change 5.140 The subtype 1 IDMS/R Performance Monitor record from
Oct 14, 1987 the new PMAM available in IDMS 10.1 is being created
VMACRTE in error. This change skips over the subtype 1 PMAM
data until Cullinet provides a modification (accepted
but not yet available) to correct their error.
Thanks to Rodney L. Reisch, General Electric Silicon Division, USA.
Change 5.139 The BDT (Bulk Data Transfer) record has now been
Oct 14, 1987 tested with real type 59 SMF records. Two changes were
VMAC59 required to VMAC59: line 1620, TRANTYID replaced
SMF59TID in the test, and line 1670's SMF59OFG field
is now input with a $CHAR1 instead of the incorrect
$CHAR4.
Thanks to Doris Burdick, U.S. Department of Defence, USA.
Change 5.138 The IMS log processing with TYPEIMS from MXG 4.4
Oct 11, 1987 fails. Most transactions were being thrown away
IMACIMS because of the changes in the IMS records introduced
TYPEIMS in 1.3 and 2.1. The pre-releases 5.1 and 5.2 modified
VMACIMS the MXG 4.4 code to stop deleting records, and did
correctly capture all resource data, but introduced
occasional transposition of the LTERM and TRANSACT
values. Most of all, I just did not understand the
logic of the donated code. This change marks the first
IMS log processing code which I actually wrote and
understand. The only original code in TYPEIMS/VMACIMS
now is the merge of the 07-08 log records. Larry
Alexander's fine IMS paper and 2.1 data were used to
now properly assemble all simple IMS transactions
perfectly. The existence of an 07/08 causes an
observation in IMSTRAN to be created, and if an 01
record was found, the message queue records (01,03,31,
35, and 36 are then collected under the transaction's
LTS (line, terminal, sequence) by their message queue
DRRN (dataset and record number) and the time stamps
(ARRVTIME,ENQTIME,GUTIME,STRTTIME,TMCNTIME, GUOUTIME,
ENDTIME and DEQTIME) are captured. Variables INBITS
and INCNTS identify which and how many IMS log records
were collected for this observation in IMS tran. This
code has processed many IMS log records, and seems to
be correct in assembling matching sequences. For some
very complicated sequences (those which do create an
01 for each 07, for example) will be fully assembled
into IMSTRAN for resource measurement and transaction
counting. The worst that can happen is that some of
the time stamps may be missing if MXG can't find the
message records corresponding to the 07 and 08 log
records. I am still investigating WFI (wait for
input) transactions, and may provide additional code
in the future to re-examine IMSTRAN see if the IMS
response for these unique transactions can also be
measured. In summary, the 5.3 IMS code is thought to
be completely accurate for resources and counting, and
either captures the correct response time, or sets the
response time missing. It's not done, but it's so
much better than anything before that it should be
used now for any IMS log processing.
Thanks to John D. Pike, American Airlines, USA.
Thanks to John Lemkelde, Pennsylvania Blue Shield, USA.
Thanks to Finn Poulsen, DANFOSS A/S, DENMARK.
Change 5.137 A syntax error resulted from a missing AXIS2 statement
Oct 11, 1987 in a PROC GPLOT. New line 370.1 should be:
GRAFRMFI AXIS2 COLOR=WHITE LABEL=('LOGICAL SWAP')
Thanks to John Potter, Mitsubishi Electronics, USA.
Change 5.136 ROSCOE 5.5 TERMNAME variable is now only in the signon
Oct 4, 1987 record, but 5.4 had it also in the logoff record. The
ANALROSC result was a blank value for TERMNAME. To correct,
change line 8 to now read:
PROC SORT DATA=ROSCOFF (DROP=TERMNAME);
Thanks to Richard Olimpio, O. M. Scott, USA.
Change 5.135 RMF Cache Reporter records which have only one storage
Oct 4, 1987 director segment caused INPUT STATEMENT EXCEEDED
VMACACHE RECORD LENGTH, "STOPOVER" condition. (All data tested
had two!) These changes were made:
Insert new lines:
@15+OFFSTAT GSLEN PIB2. 237.1
@; IF GSLEN=80 THEN INPUT 245.1
(SD2ID=SD2IDCU OR GSLEN=40) ); 258.1
Remove the "SD2ID=SD2IDCU);" at end of line 258.
Thanks to Benny J. Arnold, Kansas City Computer Center, USA.
Thanks to Don Tuttle, Kansas City Computer Center, USA.
Change 5.134 If you wanted to build the PDB data sets and only want
Oct 4, 1987 to spin once (for example, building from a monthly SMF
BUILDPDB file), you could not. Setting IMACSPIN to 1 caused the
BUILDPD3 un-matched records to be spun twice, since _SPINCNT
was compared with "1" in line 375/385 (BUILDPDB/3).
Changing the "1" to "0.5" solves this inconsistency.
Thanks to Bill Gibson, SAS Institute, AUSTRALIA.
Change 5.133 1.VM/Monitor USER records contain no logon flag. MXG
Sep 23, 1987 can recognize a logon if any of the DIF()'d counters
Nov 29, 1987 went negative, but that is not always the case. Now,
ANALVMON MXG compares the delta minutes since the last record
IMACVMON for this user with a new macro (_INTRVL, in IMACVMON)
VMACVMON in which you specify your expected interval duration.
If more than two expected intervals have been missed,
MXG assumes a LOGON and reinitializes. (Note that if
suspension occurs, records can be skipped.) The actual
comparison is IF DIF(STARTIME) GT 2 * _INTRVL THEN ...
The default value for _INTRVL is 1 minute. If you are
writing 10 minute intervals and you do not change the
value of _INTRVL in IMACVMON, all data will be zeros.
2.Twenty-one VM/Monitor durations (CPU times, Page and
I/O waits, etc.) are in counters which decrement from
a large positive number down to zero. MXG did not get
the correct value for the zero-crossing interval. The
problem only occurs when the system stays up for more
than a day (after 38 hours at 50% IDLETM, it resets).
The error caused the zero-crossing variable to contain
a very large negative value for that one interval. The
decrementing counters are identified by the syntax of
y=-DIF(x)/4096, which calculates the negative delta of
counter x into variable y. This change inserts a new
test for negative y following each -DIF() to correct:
y=-DIF(x)/4096;
IF . LT y LT 0 THEN y=y + 1E-6*16**9;
This fix was revised Nov 29, when IBM Level 2 made
it clear: six bytes of FFFFFFFFFFFF is stored. MXG
5.3 incorrectly used just 16**9, the 5.4 temporary
circumention used x/4096 pending this truth. Note
that computerese 1E-6*16**9 is simply 16 to the 9th
divided by a million, but the 68719.476736 decimal
equivalent leaves me cold. (Six bytes of FF, INPUT
as PIB6.6 is decimal 281474976; divided by 4096 to
get seconds, becomes 16 to the 9th over a million!)
3.I/O counts in VMONDEV are accumulated by DEVADDR since
last IPL, and MXG failed to de-accumulate the variable
CNTVIOCT. Macro _ANALDEV is now defined in VMACVMON
to sort and correctly calculate CNTVIOCT into VMONDEV.
(Note for recipients of pre-releases 5.1 or 5.2: This
de-accumulation WAS correct in the VMPDB.DEV data set
built by ANALVMOS. Now, the de-accumulation is done
in building VMONDEV). This change could impact the
compatibility of MXG. If you used VMONDEV from MXG 4.4
you probably did your own de-accumulation, and now you
will need to remove that de-accumulation.
Thanks to George Moskwa, Cole National, USA.
Change 5.132 If SAS OPTION NOTEXT82 is in effect, a syntax error in
Sep 23, 1987 creating the temporary $TCLASS reporting format in one
ANALCICS of these sample CICS reports. The right hand side of
the format values must be enclosed in single quotes,
or OPTIONS TEXT82 can be specified.(Our testing now
specifies NOTEXT82!)
Change 5.131 Variables INCONT, LOGONID, MSGLEN and ORGENT in the
Sep 23, 1987 TYPEIMS data set (from IMS Log records), which exist
VMACIMS in the RACF segment if you have RACF or ACF2 with IMS,
but were not in the KEEP list for IMS0103 data set.
As a result, they were blank. (FYI, they are defined
in member EXITRACF.)
Thanks to John Lemkelde, Pennsylvania Blue Cross, USA.
Change 5.130 TSO/MON 5.1 support has now been validated with data
Sep 21, 1987 containing the optional ACCOUNTing fields. Without
VMACTSOM this change, STOPOVER abend occurred if the additional
optional data was present in the record.
Line 2417 changed to INPUT NRACCTFL PIB1. @;
Lines 24192 and 24193 were deleted. (MINUS8= and INPUT)
Thanks to John Leath, Fleet Information, USA.
Change 5.129 The MONIUSER data set from Landmark's MONITOR has now
Sep 21, 1987 been validated. CLOCKTM is now calculated by 1E4, and
TYPEMONI the code was restructured to properly initialize.
Thanks to Chuck Comstock, Hallmark Cards, USA.
Change 5.128 Jobs with JCL errors in PDB.JOBS had blank value for
Sep 18, 1987 TYPETASK because it was not in KEEP list for the type
BUILDPDB 26 data. TYPETASK was added to _PDB_26 definition.
BUILDPD3
Thanks to Lee Salley, Westinghouse, USA.
Change 5.127 Several minor changes.
Sep 16, 1987 1.ANALAUDT and ANALDB2R were restructured to contain
ANALAUDT both JCL and SAS code. With the SAS JCLEXCL option:
ANALCICS %INCLUDE SOURCLIB(ANALDB2R)/JCLEXCL;
ANALDB2R SAS will skip over the JCL and execute the SAS code.
EXITMONI Alternatively, the JCL can be edited and submitted to
produce the report from either an MXG PDB library or
directly from SMF data. Both ANALAUDT and ANALDB2R now
permit date selection via the SYSPARM parameter on the
EXEC statement, as described in the comments. MXG will
use this pattern in future ANAL.... members.
2.ANALCICS PROC FORMAT at line 465 needed quotes on the
right hand side if SAS OPTION NOTEXT82 is specified.
3.EXITMONI installation instructions were improved.
Change 5.126 MXG Format $MGIMFFP was defined in lines 411-414 of
Sep 14, 1987 this member in MXG 4.4, but is not in MXG 5.2 member.
FORMATS If you use the first step of JCLTEST to add formats to
your existing SASLIB data set, you will not see this
error. However, if you create a new SASLIB using the
5.2 FORMATS member, the format will not exist. (Since
I tested by adding the new formats, my testing failed
to catch the error - guess who's testing philosophy
has been changed!). To correct the 5.2 FORMATS member,
copy lines 411-414 of 4.4 FORMATS member after line
615 of 5.2 FORMATS member.
----Changes thru 5.125 as of Sep 10, 1987 were included in MXG 5.2---
Change 5.125 JES2 sites using NJE will now find the PDB.NJEPURGE
Sep 10, 1987 data set automatically built by BUILDPDB will contain
BUILDPDB the non-execution purge records for NJE jobs. All SR
(SYSOUT Receiver) purge records and JR (job transmit)
purge records which do not represent actual execution
will be in this PDB data set. (Formerly, these purge
records were deleted by BUILDPDB). This data set may
be useful in tracking NJE job transmission input
delays as well as NJE SYSOUT delays. Additional work
in this NJE measurement area can be expected.
Thanks to Gary Zolweg, National Semiconductor, USA.
Change 5.124 Support for ROSCOE 5.5 Accounting records was added.
Sep 10, 1987 The ROSCOE Response Time Monitor (RRTM) data is now a
EXROSALL subtype of the 5.5 account records written to SMF.
EXROSATT Several new ROS..... data sets are created from the
EXROSCON new ROSCOE 5.5 account records. On October 11, 1987
EXROSDSF (in MXG 5.3), RRTM record support for ROSCOE 5.5 was
EXROSHEX added to these members, and the RRTM data sets are now
EXROSLIB created with TYPE/VMACROSC. The AUDIT record (new in
EXROSPUR ROSCOE 5.5) support was also added, but no audit data
EXROSSHU records have been available to test yet.
EXROSSOR
EXROSVPE
IMACROSC
VMACROSC
Change 5.123 VM Monitor summarization & documentation were cleaned
Sep 10, 1987 up in testing 5.1. The SEEKRPRT has been added and the
ANALVMOS documentation improved. VM Execs referenced in the MXG
DOCVMOS supplement now exist. EXECTEST is the VM equivalent of
EXECPDB JCLTEST, EXECPDB tests the MVS PDB building under VM,
EXECTEST and EXECEMAC provides an easy way to edit MACLIBs.
EXECEMAC
Change 5.122 Installation modifications to type 26 records caused
Sep 9, 1987 MXG problems because section lengths were not used to
VMAC26J2 +SKIP over new data. This change redesigns TYPE26J2 to
fully use the section lengths for immunity to change.
Thanks to Rob Clairmont, The Laurier Group Ottawa, CANADA.
Change 5.121 Several ANAL.... report members created unnecessary
Sep 9, 1987 messages (not referenced, uninitialized, etc.) which
ANALPROG were irritating but not critical errors to new users.
ANALESV
ANALTAPE
Thanks to Kathleen A. Morrison, Hit or Miss Inc, USA.
Change 5.120 The IDMS/R Performance Monitor (Change 5.95) did not
Sep 9, 1987 process the second subtype 1 record, which is now
VMACRTE recognized and creates the IDMSTASK data set.
Thanks to Rodney L. Reisch, General Electric Silicon Division, USA.
Change 5.119 Variables EXCPTODD/EXCPNODD and IOTMTODD/IOTMNODD in
Sep 9, 1987 TYPE30 data sets are missing if the program had no DD
VMAC30 cards. Uncommon, it does happen. MXG moved several
lines outside the NUMDD=0 do group to set these four
variables zero rather than missing in this instance.
Thanks to Kenneth D. Jones, Maritime Telephone and Telegraph, CANADA.
Change 5.118 Only for the TYPE74 data set and only under MVS/370,
Sep 9, 1987 the variable DEVNR (the MVS/XA and BUILDPDB/3 expected
VMAC74 variable name for the old UNITADR MVS/370 variable) is
missing. Correct for MVS/370 with the new line:
DEVNR=UNITADR; 172.1
to store unit address in DEVNR. MVS/370 sites would be
wise to position for MVS/XA by changing UNITADR to
DEVNR now in all programs using MXG data sets.UNITADR
does not exist under MVS/XA, DEVNR replaced it.
Thanks to Bob Rutledge, Sherwin Williams Paint, USA.
Change 5.117 VM Account support for the type 08 (user disconnect
Sep 9, 1987 or log off) account card record was added, creating
TYPEVM new data set VMLOGOFF. Variable LUNAME was also added
EXVMLOFF to the VMDISK, VMLINK, VMLOGON and VMLOGOFF data sets.
FORMATS LUNAME will contain the SNA (VTAM) terminal name for
SNA terminals, useful for identification of terminals
being used by VM users. In VMDEVICE data set, variable
DEVICECL is now decoded by new format $MGVMADV, which
permitted reducing DEVICECL from 8 to 1 byte.
Change 5.116 The format used in the PUT function at line 46 was
Sep 9, 1987 corrected from WEEKDAY3. to WEEKDATE3. to create the
MONTHBLD name of the day of the week as a character variable.
Thanks to Barry Lampkin, Blue Cross of Mass, USA.
Change 5.115 MXG error messages VMAC110.2 and .3 were revised to be
Sep 3, 1987 more descriptive when MXG detects a change in record
VMAC110 format due to CICS maintenance.
Thanks to Laurie Bigelow, UCCEL, USA.
Change 5.114 Variable SD2DEVNR was mis-spelled in the KEEP list for
Sep 3, 1987 CACHETY data set, and was thus not kept. Correct the
VMACACHE obvious mis-spelling.
Thanks to Ray Dickensheets, Yellow Freight System, USA.
Change 5.113 PGBLPGS, STGUTIL, and DRUMUTIL variables in VMONPERF
Aug 31, 1987 were not calculated in non-HPO data. COPY lines
VMACVMON 1545-1546 to become 1113.1 and 1113.2. MOVE line 1547
to 1113.3. Change 1113.1 to be: PGBLPGS=MAXSIZEP;
Thanks to ???, ???.
Change 5.112 This simple example of reading SYSLOG to track IEF244I
Aug 21, 1987 (job delayed due to tape allocation) messages from the
XSYSLOG JES2 SYSLOG file to create MXG dataset IEF244I will be
expanded in future versions of MXG to provide extended
analysis of important SYSLOG messages. Suggestions for
other events which are only available from SYSLOG are
solicited. This will not be expanded until Version 6.
Thanks to John Maher, American Honda Motor Company, USA.
Change 5.111 The bit testing to create TYPE25 (JES3 only) variables
Aug 21, 1987 ALOCBYDD and ALOCAUTO were reversed. Reverse the 0 and
VMAC25 1 values in lines 57-58 and lines 61-62.
Thanks to Miss C. Keelan, Commonwealth Bank of Australia, AUSTRALIA.
Thanks to Stephen Geard, Commonwealth Bank of Australia, AUSTRALIA.
Change 5.110 The decode of RECFM in both VTOC and TYPE1415 logic is
Aug 19, 1987 moved to new member VMACRCFM, and additional record
VMAC1415 formats (formerly OTHR, like FBA, FBS, etc.) have been
VMACRCFM added to (hopefully) completely decode RECFM and to
VMXGVTOC eliminate blank or OTHR values.
Thanks to John Potter, Mitsubishi Electronics, USA.
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 5.109 This change fixes an error which only existed in the
Aug 19, 1987 pre-release 5.1. For jobs which went through the SPIN
BUILDPDB data set, the variable SYSTEM was usually blank. The
BUILDPD3 change affected the five data sets built at line 284
(JES2, line 294 JES3). IN= logic was added to TYPE....
in the SET statement and the storing of SYSTEM into
the five SYSxxx variables was made conditional.
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 5.108 Some MXG modules now use the "new macro, or %macro"
Sep 3, 1987 facility of the SAS System. (MXG has always used many
JCLUXREF "substitution" or old-style SAS macros). The use of
VMXGVTOC the "new macros" requires the SAS system option MACRO
to be enabled (SAS 5.16 defaults to NOMACRO). This is
done either by adding MACRO to the OPTION list on the
EXEC SAS statement for a step, or by changing the SAS
system default (PROC SETINIT by the SAS installer.)
The listed members used the "new macro" facility and
their JCL example now specifies MACRO. Hereafter, all
MXG members that define "new macros" will be so noted.
Thanks to Ray Dickensheets, Yellow Freight System, USA.
Thanks to John Potter, Mitsubishi Electronics, USA.
Thanks to Rob Ray, EUA Service Corporation, USA.
Change 5.107 The variables TAPE3420 and TAPE3480 are now included
Aug 14, 1987 in the PDB.STEPS and PDB.JOBS data sets. Both members
BUILDPDB were re-numbered
BUILDPD3
Thanks to Dennis Dwyer, CITICORP, USA.
Change 5.106 The type 128 record which can be created by NPM is
Aug 14, 1987 actually supplied by IBM as source code for the exit.
IMACNPM Since the record id is not fixed at 128, this change
VMAC128 adds member IMACNPM in which you tell MXG the actual
record ID of the NPM VTAM Session records.
Thanks to Joseph Faska, Chemical Bank, USA.
Change 5.105 Support for SYNCSORT user SMF record was added. The
Aug 14, 1987 SYNCSORT data set is created. These members replace
EXSYNSOR XMACSYNC (Change 5.39).
IMACSYNC
TYPESYNC
VMACSYNC
Change 5.104 Support for CINCOM SUPRA 1.1 System log file produces
Aug 14, 1987 three data sets, SUPRDBMX, SUPRFILE, and SUPRINIT.
ANALSUPR Sample reports are in member ANALSUPR.
EXSUPDBM
EXSUPFIL
EXSUPINT
TYPESUPR
Thanks to Mark Degner, Navy Finance Center, USA.
Change 5.103 VM/Monitor Seek Analysis had one too few percent signs
Aug 12, 1987 which caused syntax errors. In line 459, change the
ANALVMOS '%' to '%%'.
Thanks to Steve Smith, Hammermill Paper, USA.
Change 5.102 Default SMF record id numbers for ACF2, MODEL204,
Aug 10, 1987 ROSCOE, and TSO/MON were changed to the inpossible
IMACACF2 values of 512 or higher, to prevent STOPOVER ABEND in
IMACM204 new sites testing JCLTEST.
IMACROSC
IMACTSOM
Thanks to Joseph Faska, Chemical Bank, USA.
Change 5.101 Format for CPUWAIT4-8 and PCTCPBY4-8 was not provided.
Aug 10, 1987 This only affected the 5.1 tapes. Change the CPUWAIT3
VMAC7072 in line 298 to CPUWAIT8. Change the PCTCPBY3 in line
316 to PCTCPBU8. Change CPUWAIT3 in line 479 to read
CPUWAIT8, only for looks since 370 can't run on 3090.
Thanks to Ruth Heidel, UCCEL, USA.
Change 5.100 CICS 1.6.1 FCGETCN field is increased from two to four
Jul 31, 1987 bytes by PTF UL10276.
IMACPTF IMACPTF - Replicate the logic for AP40463, and change
UTILCICS AP40463 to UL10276.
VMAC110 UTILCICS- Replicate lines 354-357 (for AP40463) and
change the test to 'FC-GET-COUNT' and set
PTF='UL10276';
VMAC110 - Replace lines 546-547:
FCGETCN PIB2.
FCPUTCN PIB2.
With these four lines:
@;
IF _UL10276 THEN INPUT FCGETCN PIB4. @;
ELSE INPUT FCGETCN PIB2. @;
INPUT FCPUTCN PIB2.
Thanks to Malcolm Morgan, Wachovia Bank, USA.
Thanks to Dave Feigenbaum, UPS, USA.
******Changes through 5.99 were on the first pre-release of MXG 5.1 ****
Change 5.99 The two new SMF records created with MVS 2.2 are now
Jul 31, 1987 available. A type 36 is written for each import/export
TYPE36 of the ICF catalog. The type 41 is written for each
VMAC36 access to a Data-In-Virtual object. The type 41 is
EXTY36 currently incomplete; the job name, readtime, etc of
TYPE41 the task using the DIV object was inadvertently left
VMAC41 out of the SMF record in ESP. A PTF is expected that
EXTY41 will add the data and probably break the VMAC31 code,
but I don't have the PTF number or change info yet.
With this change, MXG Version 5.1 Supports MVS 2.2.
Change 5.98 Minor, cosmetic change in creating SMF71IS1 and IS2
Jul 31, 1987 field names from the SMF71AVA field, none of which are
VMAC71 kept.
Change 5.97 This standalone JCL and program will decode the SAR
Jul 26, 1987 account records from its non-SMF journal file.
XMACSAR
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 5.96 MXG DASD Storage Measurement is now supported by these
Jul 26, 1987 new members. The earlier XMAPVTOC program has been up
FMXGUCBL dated and is now an executable (new style) SAS macro
VMXGVTOC %VMXGVTOC, which produces the VTOC and FREE data sets
TYPEVTOC from the DDNAME of DISK. These two data sets describe
the contents of that volume for billing DASD storage
and/or DASD capacity measurement. To measure all DASD
volumes in one execution, and to avoid JCL errors due
to offline volumes, the MXG-provided SAS function
FMXGUCBL dynamically allocates all online DASD volumes
to DDNAMES of DDnnnnnnn, and returns the number of
volumes found online. The example program in VMXGVTOC
can be executed to create the MXGVTOC and MXGFREE data
sets from all online DASD volumes.
Change 5.95 Support for IDMS 10.1 (pre-release) completed. The new
Jul 26, 1987 new "Application Monitor" record subtypes create ten
VMACRTE new IDMS.... data sets. The original TYPERTE data set
EXRTEARA is now created from the subtype 1 record. See comments
EXRTEBUF in VMACRTE for documentation and comments about data.
EXRTECDM MXG variable names are the same as the Culprit names
EXRTEDBK used in Cullinet's PMIRPT00 example report program for
EXRTEERU this IDMS/R Performance Monitor (formerly the Run Time
EXRTEINT Evaluator product, hence the RTE acronym). See Change
EXRTEJRN 5.120.
EXRTEPGM
EXRTESTG
EXRTETPI
Thanks to Terry Layman, Cullinet, USA.
Change 5.94 Validation of ACF2 record support has been completed.
Jul 22, 1987 See updated description of change 5.68.
Change 5.93 PDB.JOBS variables RACFGRUP RACFTERM and RACFUSER were
Jul 22, 1987 kept in _PDB30_4 instead of _PDB30_5. Thus these three
BUILDPDB variables in PDB.JOBS came only from the initiate 30_1
BUILDPD3 data set. A value placed in RACFTERM by an SMF exit at
terminate was not picked up by MXG. With this change,
the three RACF variables in PDB.JOBS will have their
value from the 30_5 if it exists, or from the 30_1 if
no job termination record was found. It was supposed
to have been this way all along!
Change: blank the three variables in line 84 and add
the three variables in lines 102-103.
Thanks to Kenneth D. Jones, Maritime Telegraph and Telephone, CANADA.
Change 5.92 RMFINTRV standalone execution had an extra semi-colon
Jul 21, 1987 in an include in the commented out code. Fixed.
RMFINTRV
Thanks to Steve Glick, Southern Methodist University, USA.
Change 5.91 If SRBCOEFF is zero, a division exception occurred in
Jul 21, 1987 MVS/XA. The division is now protected.
VMAC7072
Thanks to John Mueller, ARMCO Steel, USA.
Change 5.90 The CICS 1.6 variables ICV and ICVTSD were incorrectly
Jul 21, 1987 calculated. ICV=ICV/76.8 and ICVTSD=10*ICVTSD/3 in the
VMAC110 1.6 code only.
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 5.89 The variables QISEDBD and QISEPAGE in DB2STAT1 dataset
Jul 14, 1987 were wrong. Delete the two lines in ANALDB2:
ANALDB2 QISEDBD =DIF(QISEDBD);
QISEPAGE=DIF(QISEPAGE);
because these two variables are not accumulated.
Several other discrepancies between MXG and DB2PM are:
a. QISEFREE "FREE PG IN FREE CHAIN" reported in DB2PM
is (incorrectly) the value from the previous record.
b. DB2PM "Record Time" is QWHSSTCK-DURATM, the start
time of the interval, not the SMF record timestamp.
c. The DB2PM calculations for EDM Pool percentages are
frequently total several percent more than 100. This
is because QISEFREE is from the previous interval, as
noted above.
d. DB2PM reported "datasets open - current" is always
greater than the "maximum" value reported, and the
"current" number equals both QTDSOPN and QDDSMAX in
the record (which seems in error itself). The value
under "maximum" seems close to current; in most of
intervals it is equal to QB1TDSO (and there were no
higher buffer pools used). In other intervals the
printed "current" value is 2, QB1TDSO is 1 and no
other buffer pools were used.
e. DB2PM is flat wrong on the report page which has
both "AGENTS SERVICES - EXECUTION UNIT SWITCH" (for
QVASX... fields) and "STORAGE MANAGER (QSST.. fields).
The first six lines of the report are repeated in
lines 7-12 (which should be the first six S.M. lines).
Lines 13-19 contain what should be in lines 7-13.
What should be in lines 14-19 does not exist in DB2PM!
f. Other than that, DB2PM agrees with MXG.
Thanks to Martha Hall, Metropolitan Life, USA.
Change 5.88 The new IMS log processing logic (MXG Change 5.66) was
Jul 14, 1987 validated in detail by three sequential transactions
TYPEIMS under IMS 2.1. The new logic stood up to the test. The
only data we seem to loose now is the data from the
IMS type 36X log record, DEQTIME. The MSGDRRN value of
the 36 record is different than the MSGDRRN in the
0103 record; this prevents the 36 from matching. This
matter is under discussion with IBM. For now, IMS 2.1
is supported by MXG, but the three DEQ.... variables
are missing in the IMSTRAN data set from IMS log data.
Thanks to John D. Pike, American Airlines, USA.
Change 5.87 Support for the SMF record written by the STOPX37
Jul 12, 1987 product.
EXTYX37
IMACX37
TYPEX37
VMACX37
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 5.86 The labels for variables READY11 thru READY15 were all
Jul 11, 1987 for READY11 in the TYPE70 data set.
VMAC7072
Thanks to Ruth Heidel, UCCEL, USA.
Change 5.85 The RMF CACHE Report SMF support added by Change 5.31
Jul 07, 1987 provides correct device segment data, but only the 1st
VMACACHE control unit segment was read. Major logic changes are
in the logic to associate the control unit segments
properly with their device segments. MXG has now been
tested with REPORLVL data values of 17 and 18.
Thanks to Jon Sahl, New York Life, USA.
Change 5.84 For CICS 1.7, the CICSYSTM (global performance data)
Jul 01, 1987 variables CPUTCBTM and OWSTCPTM were wrong. This had
VMAC110 no effect on the CICSTRAN data set variables. A minor
error in calculation of TASKCPTM in CICSYSTM was also
corrected by this change. The figure on page 66 of
the MXG Supplement is accurate for CICS 1.6; the below
figure is correct for CICS 1.7 and uses the CICSPARS
descriptions of maintask, subtask, etc., values:
CPUTCBTM SRB
|-----------------------------------------------| |--|
MAINCPTM SUBTCPTM
|--------------------------------------|--------|
KCCPUTM USRCPUTM OSWTCPTM
|-------|------------------------------|--------|
| JCCPUTM TCCPUTM TASKCPTM |
|---------|---------|----------|
"CICS" "APPL"
|---------------------------|----------|
1. Change both occurrances (lines 821 and 884),
TASKCPTM=USRCPUTM-TCCPUTM;
to read
TASKCPTM=USRCPUTM-TCCPUTM-JCCPUTM;
2. Change line 883, which now reads
CPUTCBTM=SUM(KCCPUTM,OSWTCPTM,USRCPUTM);
to read:
CPUTCBTM=OSWTCPTM;
3. Insert after line 884 these five lines:
CICSCPTM=KCCPUTM+TCCPUTM+JCCPUTM;
MAINCPTM=TASKCPTM+CICSCPTM;
SUBTCPTM=OSWTCPTM-MAINCPTM;
OSWTCPTM=SUBTCPTM;
TOTLCPTM=MAINCPTM+SUBTCPTM+CPUSRBTM;
4. Add these five new variable names to the KEEP=
list (lines 66-81) for _CICOTHR.CICSYSTM.
Thanks to Joseph Faska, Chemical Bank, USA.
Change 5.83 CICS 1.7 sites with a large number of user clocks or
Jun 29, 1987 counters added to their type 110 SMF record received
VMAC110 the "Invalid task number" MXG error message because of
UTILCICS an MXG error. The string of connectors can be over 200
bytes, but MXG had only a 200-byte character variable.
The confirming symptom of this error is MCTSSDCN, the
number of "connectors", will have a value over 100 in
the MXG error message. Additional lines were changed
UTILCICS and VMAC110; only the execution-critical code
changes are printed here:
After line 493 (END;) and before line 494 (ELSE INPUT)
insert the following five lines:
ELSE IF CONNBYTE GT 200 THEN DO; 493.1
INPUT CICTRANV $CHAR200. @; 493.2
SKIP=CONNBYTE-200; 493.3
INPUT +SKIP @; 493.4
END; 493.5
Thanks to Shawn Weikel, CITIBANK, USA.
Change 5.82 Support for the modified type 6 SMF record written by
Jun 29, 1987 the SAR (SYSOUT Archival and Retreival) product from
VMAC6 Central Software and the VPS (Virtual Printer Support)
product from 1:
New line 111.1:
ELSE IF SUBS=50658 THEN SUBSYS='SAR';
Change line 137:
ELSE IF SUBSYS='JES3' THEN DO;
To read:
ELSE IF SUBSYS='JES3' OR SUBSYS='SAR' THEN
Thanks to Frank Bolan, Bergan Brunswig, USA.
Change 5.81 The CICS 1.7 variable UOWID (which ties a transaction
Jun 24, 1987 in an MRO Terminal Owning Region to the same logical
VMAC110 transaction in other Application Owning Regions) is
now formatted as a $HEX16 so it prints "better". The
first six bytes are the timestamp of attach and they
are now decoded into new variable UOWTIME. (For DL/I
batch jobs, only the time, HHMMSS, is actually in the
data record. The SMF record date is used for DL/I.)
Change 5.80 The interval of aggregation of the RMFINTRV data set
Jun 16, 1987 (set by macro _DURSET) is now defined in IMACRMFI so
IMACRMFI that inline changes do not have to be made. This is
RMFINTRV consistent with the description in the MXG Supplement.
Change 5.79 XMACVTOC now supports 3380 devices. This "extra" MXG
Jun 14, 1987 program reads the VTOC of a device pointed to by the
XMACVTOC DISK ddname, and provides the mapping of the disk
size and physical location of all data sets and free
spaces on a volume. You should compare this program
with MAPDISK on the SAS Sample library. This member
was replaced July 31, 1987 by Change 5.96.
Change 5.78 Support for DFSORT Release 9 which added new variables
Jun 14, 1987 to the type 16 SMF record. Access methods used, start
VMAC16 and end of sort timestamps, SRB CPU time, work data
set tracks and extents, I/O counts (SORTIN, SORTOUT
and total work), and sort return/reason codes are now
available for each sort execution. This member was
renumbered.
Change 5.77 1.The SYSTEM variable in PDB.PRINT will frequently be
Jun 10, 1987 wrong; usually the value of SYSTEM in PDB.PRINT was
BUILDPDB from the Step (30_4) record. This change corrects this
BUILDPD3 error and creates variables SYSINT, SYSSTP, SYSJOB,
SYSPUR and SYSPRN in PDB.JOBS to identify the system
from which each of the five records was found. As a
result of this redesign, SYSTEM in PDB.JOBS will come
from the first non-blank value in this ordered list:
SYSSTP, SYSJOB, SYSINT, SYSPUR, or SYSPRN to ensure
SYSTEM is non-blank and contains execution system if
execution records were found, otherwise it contains
the purge or print system id.
2.JOBCLASS was added to the PDB.PRINT and PDB.STEPS
data sets (from the PDB.JOBS) at the request of many.
3.PROTECT=ZZZZZ was added to the three CICS data sets
built by BUILDPD3 so that it would be consistent with
the JES2 version BUILDPDB, which has always used the
PROTECT= keyword.
Thanks to Georg Simon, Prudential, USA.
Change 5.76 The value of IRESPTM in CICSTRAN was set to missing if
Jun 10, 1987 any bit was on in TASERRFG, as these bits indicated an
VMAC110 error in timings. The bit meanings have been changed
FORMATS in CICS 1.6.1 and CICS 1.7 and CMF no longer corrupts
its timings. Therefore, IRESPTM is no longer dependent
on TASERRFG, and will always be calculated as ELAPSTM
minus WTTCIOTM. Format MG110ER has been changed to now
properly decode the new bit meanings of TASERRFG.
Thanks to Jo Engles, Virgina Light and Power, USA.
Change 5.75 Labels in VMAC110 were alphabetized. JCLUXREF needed a
Jun 10, 1987 DCLOG DD, and /* in JCL was changed to //* comments.
VMAC110 Option ERRORABEND was added to JCLPDB. All MXG
JCLUXREF production jobs must specify OPTION ERRORABEND to
JCLPDB protect you from yourself. ERRORABEND causes any SAS
error condition (but not warnings) to immediately
terminate the execution with a USER 999 abend. The
actual error condition will be printed on the log.
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
for alpha testing.
==========Changes thru 5.74 were published in Newsletter TEN===========
Change 5.74 Summarization and accumulation of VM/Monitor data a la
Jun 9, 1987 RMFINTRV into hourly (default) performance data with a
ANALVMOS small number of critical variables kept allows a years
DOCVMOS data in a small file for trending. Additionally, seek
EXECDALY histograms for VM disks is provided.
Member names have changed since Newsletter TEN.
Thanks to Steve Glick, Southern Methodist University, USA.
Change 5.73 Several minor cleanups detected in alpha testing of a
Jun 9, 1987 pre-release of Version 5:
VMAC128 a. VMAC128, two DOs removed and an END; removed.
TESTUSER b. TESTUSER, changed RMDSDATA to TYPERMDS (all).
TYPEDISO c. TYPEDISO needed quotes around SPLIT='*'.
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 5.72 The VM/Monitor TOD time stamp is written in GMT time,
Jun 9, 1987 but the Start Collection time stamp is in local time.
VMACVMON Local time is offset from GMT by the SYSTIME parameter
ZONE in DMKSYS. Some sites (my test site included) set
ZONE=0 and the operators enter local time. This causes
the TOD time stamp to be local time. However, if your
site uses a nonzero value for ZONE, the STARTIME value
produced by MXG for each record was in GMT zone. This
change corrects this MXG oversite by using the Start
Collection (Class 0 Code 97) record to calculate the
time zone difference and set MXG times to local time.
The following lines inserted/changed will correct the
MXG time stamps. (SAS 5.16 under CMS will not accept
nulls in the DHMS function, while MVS SAS will. Line
2025 replaces the nulls with zeros for this reason.)
TIMEZONE=0; 276.1
STARTIME=16*MNHTOD+BASETIME-TIMEZONE; 279
RETAIN BASETIME INTERVAL STARTIME TIMEZONE ZDATE; 284
COLLTIME=DHMS(DATTODCL,0,0,TIMTODCL); 2025
DELTATOD=(16*MNHTOD+BASETIME)-COLLTIME; 2025.1
TIMEZONE=3600*FLOOR((ABS(DELTATOD)+99)/3600); 2025.2
IF TIMEZONE GT 0 AND DELTATOD LT 0 THEN TIMEZONE=-TIMEZONE; 2025.3
STARTIME=16*MNHTOD+BASETIME-TIMEZONE; 2025.4
The actual change in Version 5 is more extensive, and
warns you if a 0/97 record was not found. It also will
process VM/Monitor data from any time period, as long
as the monitor data includes a 0/97 (formerly, only
data within the last 203 days, the wrap time of the 5
byte TOD field, could be accurately processed). If the
first record is not a 0/97, MXG defaults the time zone
to zero and what you get could be either local or GMT.
Thanks to Terry Magill, NAS, USA.
Thanks to Steve Glick, Southern Methodist University, USA.
Change 5.71 Variables VECTUTM, VECTU0TM and VECTU1TM, VM/Monitor
Jun 9, 1987 reported Vector Facility Usage time (total, CPU, APU)
VMACVMON were added to VMONPERF data set. Note that only the
usage time is reported, and only globally; there is
no vector usage time reported by user in VM. The MXG
supplement discusses the vector facilty measurements.
Change 5.70 Variable INTERVAL was added to all of the VM/Monitor
Jun 9, 1987 data sets.
VMACVMON
Thanks to Steve Glick, Southern Methodist University, USA.
Change 5.69 In these sample reports, transactions with blanks for
Jun 9, 1987 OPERATOR were not counted in some reports, because by
ANALCICS default PROC SUMMARY treats a blank value of a CLASS
variable as a missing value. These transactions will
be counted if you add the MISSING operand to line 50:
PROC SUMMARY DATA=CICSTRAN MISSING;BY APPLID;
Thanks to Jim Enia, Allied Signal, USA.
Change 5.68 Added support for ACF2 user (default=196) SMF record.
Jul 21, 1987 Ten ACF2... data sets are created. The ... suffix of
EXACFAR data set name is the same as the parameter name in the
EXACFCR ACF2 Utilities Manual, page 74 (1/15/85 revision). No
EXACFDR reports are written or planned. Half of the data sets
EXACFER have been validated with actual data. Only Release 4.0
EXACFJR and later ACF2 releases will be supported.
EXACFNRA
EXACFNRB ACF2 is a product of UCCEL Corporation, maintained by
EXACFPR their Chicago Development and Support Center.
EXACFTR
EXACFVR
IMACACF2
TYPEACF2
VMACACF2
Thanks to Jill Raudabaugh, Whirlpool Corporation, USA.
Change 5.67 Changed references to SMF59TID to correct variable
Jun 4, 1987 TRANTYID to eliminate "uninitialized variable" note.
VMAC59
Thanks to John Mueller, ARMCO Steel, USA.
Change 5.66 Support for IMS 2.1 log record processing and a major
Jun 4, 1987 redesign of the logic for building IMSTRAN. Previously
EXIMSOUT the algorithm threw away transactions that were not
IMACIMS perfectly matched. Now, an observation will be placed
TYPEIMS in IMSTRAN if a '07' IMS log record is found, even if
VMACIMS not all of the other possible log records exist. This
provides complete accounting for the existence and the
resource accounting of the transaction, but may cause
missing value for response time and some time stamps.
Since IBM does not put a version number in the IMS log
you must change the _IMSVERS macro (which is defined
in member IMACIMS) from its default of 1.3 if you wish
to process IMS 2.1 log records. This re-design has
been moderately well validated by comparison with data
from the IMF product, but as with any new design (and
especially with the undocumented state of the IMS log)
you should be alert for any idiosyncracies. This
change includes and superceedes Change 5.46. The code
in EXIMSOUT which formerly replaced IMSCPUTM with the
average cpu time per transaction has been eliminated.
Now, IMSCPUTM is the actual message region CPU time.
Thanks to John D. Pike, American Airlines, USA.
Change 5.65 Support for MVS 2.2 changes as announced in the MVS/XA
Jun 1, 1987 Conversion Notebook, Volume 2 (GC28-1411-0). Untested.
1. VMAC30. DIVRREAD, the 'ASID TOTAL*DIV REREAD*COUNT' is
added to the TYPE30_V, TYPE30_4, TYPE30_5 and TYPE30_6
data sets to report the new DIV (Data in Virtual) use
at the interval, step, and job level of detail.
2. VMAC7072. Three new variables added to TYPE72 data set
ACTFRMTM='ACTIVE*FRAME*TIME'
PERFACCT='PERFGRP*SET FROM*ACCOUNT?'
PGPAGEIN='PAGE INS*BY THIS*PERF GROUP PERIOD'
Note that ACTFRMTM and PGPAGEIN report memory and page
in counts by each period of each performance group!
3. VMAC90 and FORMATS. New subtype 17 (SET PFK) added to
the TYPE90 data set.
Change 5.64 Variable UCBTYPE was increased from 4 bytes to 5 bytes
Jun 1, 1987 to eliminate truncation of the last byte. Even though
VMAC21 the field is only 4 bytes, because it is stored as a
VMAC64 numeric in SAS, 5 bytes are required for resolution of
VMAC74 all four hex bytes. The change to a 4-byte character
VMAC75 variable was considered, but would be catastrophic on
any report program now using UCBTYPE. If you combine
your daily, weekly and monthly PDBs as recommended in
Chapter Thirty-Five using SET statements, there will
be no impact. However, if you use PROC APPEND on the
TYPE21 or PDB.TAPES, TYPE64, TYPE74, or TYPE75 data
sets, you will encounter an error message due to the
change in length. You could specify FORCE on the PROC
APPEND statement to force the joining of the old and
new, but that will keep the old length of 4 bytes. To
use PROC APPEND without error, you must re-create the
BASE= data set(s) with length 5:
DATA BASE.xxxx; LENGTH UCBTYPE 5; SET BASE.xxxx;
and then the PROC APPEND will succeed. (These are
some of the reasons MXG does not recommend the use of
PROC APPEND.)
Note: UCBTYPE is not a commonly needed variable, and
since it has never been right, probably is not used in
your report programs. DEVICE is decoded from UCBTYPE
and should be used instead.
Thanks to Bill Mullen, BGS, USA.
Change 5.63 TYPE30 variables JINTTIME,INTETIME,JTRMTIME,JINITIME,
Jun 1, 1987 SELAPSTM,JELAPSTM, and INTRVLTM are now created before
VMAC30 any MXG exits are taken. Formerly, they were created
just before the output exit of their respective data
set.
Thanks to Bill Mullen, BGS, USA.
Change 5.62 RACF Type 80 record with a zero length data segment
Jun 1, 1987 caused STOPOVER abend. Insert new lines 70.1, 70.2 and
VMAC80 72.1 after lines 70 and 72 in VMAC80:
@; 70.1
IF 0 LT RACFDLN LE 200 THEN INPUT 70.2
INPUT RACFDATA $CHAR200. @; 72.1
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 5.61 Untested assembly code for the tape mount monitor. Do
May 21, 1987 not use, as it has not been tested.
ASMONTAP
Change 5.60 JCL errors were not kept in PDB.JOBS from JES2. Code
May 20, 1987 to delete the multiple JES2 purge records in an NJE
BUILDPDB environment also deleted the JCL error's purge record.
1.Add variable INREASON to the _PDB26 keep list in
line 37.
2.Replace line 222:
IF SYSEXEC GT ' ';
with these two lines:
IF INREASON='SR' OR
(INREASON='JR' AND SYSEXEC LT ' ' THEN DELETE;
Thanks to M. N. Woolley, Dept of Finance, AUSTRALIA
Thanks to Cathy Ellis, Dept of Finance, AUSTRALIA
Change 5.59 TYPE64 only contains data on the first thre extents of
May 20, 1987 a VSAM entry. This change creates an additional data
EXTY64X set TYPE64X which contains the information on all of
VMAC64 the extents. (TYPE64 is unchanged and still will have
the data on the first three extents).
Thanks to Willie Antman, Federal Deposit Insurance Corp., USA.
Change 5.58 This change makes full use of the relocatable record
May 20, 1987 length information to protect MXG from any IBM changes
VMAC7072 to the performance group data. Insert two new lines
after line 1169:
SKIP=LENPGPS-56;
IF SKIP GT 0 THEN INPUT +SKIP @;
This change replaced by change 5.65, June 1, 1987.
Change 5.57 Support for NETVIEW changes to the type 39 record.
May 20, 1987 Without this change, some variables will be missing.
VMAC39 1.Change line 206 from:
IF VERSNLDM GE 000DX THEN INPUT
to read:
IF VERSNLDM GE 000DX OR PRODUCT='NETV' THEN INPUT
2.Change line 241 from:
IF VERSNLDM GE 000DX THEN INPUT
to read:
IF LENSCS GE 118 THEN INPUT
Thanks to John Fleig, Rochester Gas and Electric, USA.
Change 5.56 Devices offline at the end of the interval and any
May 20, 1987 device with CMBINVLD='Y' (indicating invalid data
VMAC74 from the hardware monitor in the channels) had none
of their utilizations calculated, but had some data
carried forward from the previous device. Delete
line 356 and line 379 so that utilizations will
always be calculated for all devices.
Thanks to MP Welch, Sisters of Charity of the Incarnate Word, USA.
Change 5.55 IBM's Report Management & Distribution System,
May 19, 1987 RMDS FDP creates a (default) type 217 SMF record,
EXTYRMDS which is supported by these new members. Data set
IMACRMDS TYPERMDS is created.
TYPERMDS
VMACRMDS
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 5.54 RACF records with identical SMFTIME values could
May 18, 1987 not be ordered as they occurred. A new variable,
VMAC80 RECIDNO was added to the KEEP= list and created
ANALAUDT with one new line inserted after line 45 in VMAC80:
RECIDNO = _N_ ; 45.1
ANALAUDT was also modified to use RECIDNO in creating
the Auditor reports.
Thanks to David D. Anderson, U.S. Bancorp, USA.
Thanks to Jim Bentley, U.S. Bancorp, USA.
Change 5.53 1.IDMS/R Performance Monitor (formerly RTE) records
May 18, 1987 now decode the RT1 variable data area (ERUS Batch,
VMACRTE ERUS CICS, and DC information). Ten new variables
are created: RT1DCTC RT1CDLT RT1DCUI RT1DCPN
RT1EBJN RT1EBNAF RT1EBALN RT1EBAFN RT1EBPN and
RT1MSSEV, due to Rod. This member will be
renumbered in MXG Version 5.
2.IDMS/R-PM records were changed incompatibly in
IDMS Version 10.1, and many new data segments now
exist in the RTE record, based on test data sent
by Dennis. The following changes are required to
process IDMS Version 10.1 RTE records:
a. Insert one new line after line 141:
IF RT1HDRVN EQ 1 THEN DO; 141.1
b. Insert five new lines after line 216:
@; 216.1
IF RT1HDRTL EQ 252 THEN INPUT 216.2
RT1MSRS2 $CHAR4. 216.3
@; 216.4
ELSE INPUT 216.5
c. Insert five new lines after line 220:
END; 220.1
ELSE DO: 220.2
SKIP=RT1HDRTL-16; 220.3
INPUT +SKIP @; 220.4
END; 220.5
Once Cullinet provides the formats of the PMIM
record types, they will be supported by MXG.
See Change 5.95.
Thanks to Rodney L. Reisch, General Electric Silicon Division, USA.
Thanks to Dennis Pugh, Browning Ferris Industries, USA.
Change 5.52 Several minor errors in the VM/Account data sets are
May 15, 1987 corrected by this contribution.
TYPEVM a. Variable TERMADDR should be read in with $CHAR4. in
lines 237 247 and 256 (instead of PIB4.).
b. Variable MINIADDR should be $CHAR4. instead of PIB4.
in line 249.
c. Variable MINIADDR should be $CHAR3. instead of PIB4.
in line 259.
d. Add new line after line 224 (1077052512 is the value
when four blanks are read with a PIB4. format).
IF BLOCKS=1077952512 THEN BLOCKS=.; 224.1
Thanks to Jan Van Lent, Fokker BV, NETHERLANDS.
Change 5.51 A fine set of DB2 reports, similar to those produced
May 14, 1987 by the DB2PM product, were provided by Tony. This
ANALDB2R member generates the reports, with selection by DB2
system as well as reporting time selection as shown
in the comments at the beginning of the member.
Thanks to Tony Shaftel, Farmers Insurance, USA.
Change 5.50 TYPE6 data set variable CONTRIND could not decode the
May 14, 1987 multiple bit conditions which sometimes occur. This
VMAC6 variable has been replaced by nine one-byte variables,
CONTRIN0 through CONTRIN9, containing a "Y" if the
condition described by the variable's label did occur.
This also takes less storage (9 bytes versus 22). Most
sites do not actually used these flags which identify
certain operator actions to the print file.
Thanks to P. J. Lines, Centre-File Limited, ENGLAND.
Change 5.49 IBM documentation error caused variable DVQUQCNT in
May 14, 1987 VMON602 data set to be incorrect. The variable is
VMACVMON only one byte for all releases of VM. Delete lines
2487 thru 2490.
Thanks to Steve Glick, Southern Methodist University, USA.
Change 5.48 TYPE78PA (Private Area virtual storage of monitored
May 14, 1987 jobs) variables suffixed with 9 were not calculated
VMAC78 as averages. Replicate lines 1638 through 1645 and
then change both occurrences of 4 in each line to 9.
Thanks to Rodney L. Reisch, General Electric Silicon Division, USA.
Change 5.47 VM Account record type 07 (VCNA) caused a STOPOVER SAS
May 14, 1987 error condition. Line 157
TYPEVM INPUT
should be change to
INPUT @9 ACCOUNT $CHAR8.
Thanks to Jim Gilbert, Texas Utilities, USA.
Change 5.46 IMS transactions were not properly assembled when the
May 14, 1987 record counter for the log is reset. It used to be
IMACIMS reset with each new log tape, but it is not clear now
TYPEIMS exactly when the reset occurs. The variable IMSTAPNO
VMACIMS (which was in the original European code but removed
by mistake) has been restored to resolve the reset.
There are many lines changed.
June 3, 1987. Change 5.66 superceeds this change.
Thanks to Lee Adams, United Telephone System, USA.
Change 5.45 Reading type 78 records from the VSAM SMF file causes
Apr 25, 1987 a STOPOVER abend. (There is no problem with reading
VMAC78 the normal dumped BSAM SMF file.). To read the type 78
VSAM format data, add +OFFSMF to lines 1668, 1695, and
1731. (OFFSMF is set by the _SMF macro in VMACSMF and
is 4 if a VSAM file is being read, 0 otherwise.)
Thanks to Wing Louie, Metropolitan Life Insurance, USA.
Change 5.44 DB2 Release 1 fields QXQUERY and QXALTBF were changed
Apr 25, 1987 in Release 2 and are now QXSELECT and QXFETCH in MXG.
VMACDB2 (QXALTBF was reserved, and QXQUERY was split into the
two query types SELECT and FETCH.) Change all five
occurrences of QXQUERY to QXSELECT and change the
label to read "SELECT*STATEMENTS". Change all five
occurrences of QXALTBF to QXFETCH and change the
label to read "FETCH*STATEMENTS".
Thanks to A. Williams, Shell U.K, ENGLAND.
Thanks to Richard Whitnable, State of Wisconsin, USA.
Thanks to Martha Hall, Metropolitan, USA.
Change 5.43 QTXA... variables in DB2ACCT are missing because the
Apr 25, 1987 length of the lock segment was changed, causing MXG to
VMACDB2 not read them in. Line 1238 should be changed from
ELSE IF LENLOCK GE 28 THEN
to read
ELSE IF LENLOCK GE 24 THEN
Thanks to Tom Frankle, Chemical Bank, USA.
Change 5.42 More than 200 bytes of user data (counter, clocks, or
Apr 21, 1987 characters) added to the CICSTRAN data caused the MXG
VMAC110 error message "data format has changed". MXG will now
input the first 200 bytes and skip over any excess.
The member IMACICUS can be used to actually decode
any local counters. (The optional DL/I counters are
decoded in IMACICDL.)
Thanks to Shawn Weikel, CITIBANK, USA.
Change 5.41 Reserved Change Number.
Mar 19, 1987
Thanks to Jon Sahl, New York Life, USA.
Change 5.40 Durations and counts for CICSEXCE exceptions were not
Mar 16, 1987 being calculated for CICS 1.7 exceptions. MSWAITTM,
VMAC110 TSWAITTM, and VSWAITTM are set to ENDTIME-STRTTIME.
The existence of the exception is still the important
event. (VSAM waits are usually due to insufficient
LSR buffers).
Thanks to Tom Wiebe, NERCO, USA.
Change 5.39 Preliminary re-write of SYNCSORT support, will become
Mar 11, 1987 VMACSYNC when tested.
XMACSYNC
Thanks to Jill Raudabaugh, Whirlpool Corporation, USA.
Change 5.38 Record subtype, SUBTYPE, is now created in _SMF macro
Mar 11, 1987 and is available to exit IMACFILE, for those records
VMACSMF which contain a subtype. END=ENDOFSMF and an include
for IMACFILE were added to _JOURNAL macro (for type
110 records in CICS journal format) so that it is now
consistent with the _SMF macro.
Thanks to Mark Nelson, UCCEL, USA.
Change 5.37 Revised installation instructions for the IDMSSTAT
Feb 2, 1987 program (which writes SMF records from IDMS) were
IDMSEXIT added. No change to the ASM source code was made.
Thanks to Ron Szczepanski, Whirlpool Corporation, USA.
Thanks to Keith Stout, Municipality of Anchorage, USA.
Change 5.36 A set of ten reports for the EDP Auditor, from RACF
Feb 2, 1987 TYPE80 data, was provided by its author, and with
ANALAUDT minor revisions was added as member ANALAUDT.
Thanks to David D. Anderson, U.S. Bancorp, USA.
Change 5.35 Variable VTAMCPUI, the CPUID*FROM*SYSTEM, at the end
Jan 29, 1987 of this VTAM SMF Accounting Record is now created by
VMAC128 MXG.
Change 5.34 To protect users from accidentally truncating the WORK
Jan 28, 1987 variable (which defines worktype and is expected by
IMACWORK RMFINTRV to be $CHAR5.), INFORMAT WORK $CHAR5. was
added. This is a minor change.
Thanks to Brian Cooper, Franklin Mint, USA.
Change 5.33 Announcement of the 3090-600 suggests there really is
Jan 27, 1987 going to be a 3090-800. TYPE70 data set was modified
VMAC7072 to support nine engines (numbered 0 thru 8 inclusive).
The eight CPU-specific variables (CAIn, CPUSERn, VFONn
CPUWAITn, IORATEn, PCTCPBYn, PCTTPIn, VFAFFTMn) now
exist for n=0 thru 8. This change supercedes change
5.1. These variables are not typically important; most
sites won't need to know these CPU-specific values.
The overall system measures related to these values
(CPUWAITM, IORATE, PCTCPUBY, PCTTPI) are correct with
or without changes 5.32 and/or 5.1.
Change 5.32 Support for the Online Business System WYLBUR Session
Jan 26, 1987 SMF record was added. One record per WYLBUR session
TYPEWYLB is written containing CPU, I/O and counts of some
VMACWYLB activities.
IMACWYLB
EXTYWYLB
Change 5.31 Support for the Cache RMF Reporter (IBM Program Number
Jan 25, 1987 5798-DQD) SMF records (default 244, 245) which invokes
TYPECACH AMS LISTDATA to extract counters for Cache DASD 3380
VMACACHE control units (models 11,21,13,and 23) was added. This
IMACACHE code was originally written in Germany and contributed
EXCAPAG to MXG. The code was revised and consolidated into the
EXCACHE members indicated, and has been tested with type 245
SMF records.
Thanks to ???, DZ/SP-CM Gotaher Verischerung VVAG, GERMANY.
for the original code,
Thanks to Kirby Kern, Commercial Federal S & L Omaha, USA.
for test data.
Change 5.30 Format MG078CV., which is used in many MXG data sets
Jan 24, 1987 to convert bytes to nnnK or nnnM printout was refined
FORMATS so that 16777216 bytes prints as 16MB (before this
change, the value had to be 16777222 before the format
changed from 15M to 16M). Correct this minor error by
changing .0009766 to .0009765625 in line 163, and by
changing .000000953674 to .00000095367432 in line 164.
Change 5.29 Support for TSO/MON Version 5.0 coded. Accounting
Jan 23, 1987 variables added to TSOMCALL and TSOMSYST. A new data
VMACTSOM set, TSOMDSNS captures data set names and members
which were accessed by commands captured in TSOMCALL,
if new TSO/MON option to do so was enabled. MXG 4.4
supports TSO/MON Version 5.0 without error, but if you
want the data new in TSO/MON Version 5.0 before we
ship MXG Version 5, call us. Too many lines changed
to provide here.
Change 5.28 The equation for PCTCUBSY (percent control unit busy
Jan 14, 1987 in TYPE78CF for 3090s) is incorrect in the RMF manual
VMAC78 on page 374. The minus is actually a plus.
The value of AVGCUHQL (CU-HDR queue in TYPE78CU) was
incorrectly calculated. The equation was corrected.
Source statement Line number
PCTCUBSY=100*PCTCUBSY/CHPIDTKN+PCTCUBSY); 1724
IF NRCUHREQ GT 0 THEN AVGCUHQL=(NRCUHENQ-NRCUHREQ)/NRCUHREQ; 1748
ELSE DO; 1749
NRCUHENQ=.; 1749.1
AVGCUHQL=.; 1749.2
END; 1749.3
Change 5.27 After each statement in which INVALID,VARIED,ONLINE,
Jan 14, 1987 LCI, and IDWRONG is set equal to 'Y', add a statement
VMAC73 ELSE XXXXXXXX=' '; where XXXXXXXX is the name of
the variable being set to 'Y'. Without these new ELSE
statements, once any of these variables were set to a
value 'Y', the value remained 'Y' for the rest of the
observations created from that type 73 record.
Thanks to Paul Larson, Marine Bank Services, USA.
Change 5.26 New variables SWAP EXTAUX LOGAUX LOGEXT PHYAUX and
Jan 14, 1987 PHYEXT are created, each containing the total swap
VMAC71 rate for tha swap transition. This total is created by
summing all eleven swap reason codes for a particular
swap transition. Insert after line 742, these lines: ,
SWAP =SUM(SWAPAS, SWAPDW, SWAPEX, SWAPNQ, SWAPNS, SWAPRS,
SWAPTI, SWAPTO, SWAPUS, SWAPVR, SWAPWT);
EXTAUX=SUM(EXTAUXAS,EXTAUXDW,EXTAUXEX,EXTAUXNQ,EXTAUXNS,EXTAUXRS,
EXTAUXTI,EXTAUXTO,EXTAUXUS,EXTAUXVR,EXTAUXWT);
LOGAUX=SUM(LOGAUXAS,LOGAUXDW,LOGAUXEX,LOGAUXNQ,LOGAUXNS,LOGAUXRS,
LOGAUXTI,LOGAUXTO,LOGAUXUS,LOGAUXVR,LOGAUXWT);
LOGEXT=SUM(LOGEXTAS,LOGEXTDW,LOGEXTEX,LOGEXTNQ,LOGEXTNS,LOGEXTRS,
LOGEXTTI,LOGEXTTO,LOGEXTUS,LOGEXTVR,LOGEXTWT);
PHYAUX=SUM(PHYAUXAS,PHYAUXDW,PHYAUXEX,PHYAUXNQ,PHYAUXNS,PHYAUXRS,
PHYAUXTI,PHYAUXTO,PHYAUXUS,PHYAUXVR,PHYAUXWT);
PHYEXT=SUM(PHYEXTAS,PHYEXTDW,PHYEXTEX,PHYEXTNQ,PHYEXTNS,PHYEXTRS,
PHYEXTTI,PHYEXTTO,PHYEXTUS,PHYEXTVR,PHYEXTWT);
MXG Version 5 goes further and sets all seventy two of
swap rate variables to missing if there are no swap
transitions for that swap reason code. This will cause
PROC PRINTs and MEANS to highlight only the transition
and reason codes which actually occurred.
Change 5.25 Variables VECTORON and VECONSAM were replaced with
Jan 14, 1987 VFON0 thru VFON3 and VFAFFTM0 thru VFAFFTM3 to track
VMAC7072 Vector Facility Online and Affinity by processor.
Change 5.24 Variable ABNDRSNC (abend reason code) was added to
Jan 7, 1987 TYPE30_4 and TYPE30_5 KEEPs, and new lines inserted
VMAC30 after lines 147, 326, and 487:
Source statement Line number
ABNDRSNC='ABEND*REASON*CODE' 145.1
ABNDRSNC $HEX8. 323.1
IF LENCOMP GE 8 THEN INPUT ABNDRSNC $CHAR8. @; 483.1
Change 5.23 Class 1 record with LENDATA=0 causes STOPOVER ABEND
Jan 7, 1987 because $VARYING is not smart enough to handle zero.
VMACVMON Lines 2087-2088 should be changed to:
Source statement Line number
INPUT @19 LENDATA PIB1. @; /*MN10YCNT*/ 2087
IF LENDATA GE 1 THEN 2087.1
INPUT @20 DATALINE $VARYING128. LENDATA /*MN10YI0*/ 2088
Thanks to Bill Cohen, Drexel Burnham, USA.
Change 5.22 OBJVALUE was ten times too large. Line 288 should be
Jan 7, 1987 OBJVALUE PIB4.1 instead of PIB4.
VMAC39
Change 5.21 The 3480 data fields were never read in, due to wrong
Jan 4, 1987 test value in line 68. New variables DEVICE and OPEN
Jan 26, 1987 are added. TAPUNSER was incorrectly decoded as numeric
ANALESV but is actually a character string in hex format. To
VMAC21 avoid conflict, new character variable TAPCUSER now
replaces TAPUNSER. For 3480s TAPCUSER contains the
last four digits of control unit serial number and the
single hex digit of the actual drive within that CU on
which the tape volume being dismounted was created.
For 3420s it contains the creation tape drive serial.
UCBTYPEs length is increased to 5 to avoid truncation.
Member ANALESV was also modified to print 3480 values;
those report changes are not given here.
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
The following change to VMAC21 is only needed if you are interested
in analyzing 3480 tape errors. It will be automatically installed in
MXG Version 5, as are the changes to ANALESV.
The change alters four existing lines and inserts twelve new lines.
The line numbers of the changes/inserts are shown below. Inserts have
a period after the line number they are to be inserted after. Changed
lines have no period.
Source statement Line number
DCBOFLG DENSITY DEVICE DEVNR 0007
OPEN 0010.1
TAPCUSER TEMP.... (rest unchanged) 0013
DEVICE ='DEVICE*TYPE ' 0027.1
OPEN ='TYPE*OF*OPEN ' 0032.1
LENGTH DEFAULT=4 UCBTYPE 5 SMFTIME 8; 0048
TAPCUSER $HEX6. 0051.1
@27+OFFSMF DEVCLASS PIB1. 0055.1
@28+OFFSMF DEVTYPE PIB1. 0055.2
%%INCLUDE SOURCLIB(VMACUCB); 0067.1
IF LENGTH GE 58 THEN DO; 0068
@44+OFFSMF TAPCUSER $CHAR3. 0070
IF DCBOFLG='0.......'B THEN OPEN='INPUT '; 0076.1
ELSE IF DCBOFLG='1.......'B THEN OPEN='OUTPUT '; 0076.2
BYTEREAD=4096*BYTEREAD; 0076.3
BYTEWRIT=4096*BYTEWRIT; 0076.4
END; 0076.5
Original lines 86-87 MOVEed to new lines 76.3 and 76.4
Change 5.20 The "Total Recorded CICS CPU Time", created only in
Dec 23, 1986 MXG reports in ANALCICS, is incorrect. As described in
Jan 26, 1987 the MXG supplement, the total CPU time recorded in the
ANALCICS CICSYSTM data set should have been(line 88):
CPUTOTTM = SUM(CPUSRBTM,CPUTCBTM);
NOTE: This only affects ANALCICS reports, not the MXG
CICSYSTM data set. See Chapter 21 in MXG Supplement.
Thanks to Beth Asbury, Prudential Home Mortgage, USA.
Change 5.19 PVTBOT, PVTTOP, and REGREQST were converted to bytes
Dec 23, 1986 (their value was multiplied by 1024), and they are now
VMAC30 converted by MXG format MG078CV., which prints bytes
as K or M, depending on magnitude. This was done to
See also make PVTBOT, PVTTOP and REQREQST consistent with the
Change 6.13 other virtual storage measures in TYPE30 data sets,
LSQSZHI/LOW, PVTSZHI/LOW and USRSZHI/LOW.
Thanks to Norbert Riehout, Great Western, USA.
Change 5.18 DL/I Counter d