>From MXG Newletter FIFTEEN Nov 1989 - First Part - 1000 line limit IBM-MAIN
CME 20/20: The History of SMF
Session M710
August 21, 1989
H. W. Barry Merrill, PhD
Merrill Consultants
Dallas, Texas
SHARE Installation CM4
ABSTRACT
SMF became available 20 years ago with OS/360 Release 18. SHARE's 1964
SORC report was part of the input to IBM's 1966 SMF design document
(authored by an IBMer who had been a SHARE board member). The design
objective was two-fold: the stated SHARE requirements for control and
evaluation of the installation, and the unstated need for IBM to
understand how its OS and its program products were being used (which
and how much). That 1966 design document, when compared with the
current SMF implementation, will be shown to be remarkably accurate to
the needs of users even today! The presentation will also discuss the
never-announced and never-released IEHMAN report package! This
presentation is based on recently de-classified IBM design documents and
interviews with the original designers and developers of the SMF
product.
CONTENTS
A. Jun 15, 1964 SORC Report 46-47
B. 1964-1967 Brockish Interview Notes 48-49
C. Aug 25, 1967 Task Force Report 50
D. Nov 1, 1967 IBM Memo 51
E. Nov 1, 1966 Objectives 52-57
F. Mar 13, 1967 Addendum I Subset 2 58-59
G. Mar 14, 1967 Addendum II 60
H. Jul 27, 1967 Proposal Memo 60
I. 1967-1969 Schiffman Interview Notes 61-62
J. Oct 16, 1968 Subset I Final 62
K. Jan 31, 1969 Subset II Final 63-66
L. Jun 25, 1969 Subset II Final Final 67
M. IEHMAN 68
N. Jul, 1969 Release 18 69
O. Oct, 1969 Release 18.6 70
P. Jun, 1970 Release 19 71
Q. Feb, 1971 Release 20 72
R. Aug, 1972 Release 21.6 72
S. 1972-1974 Merrill Notes 73-74
T. 1975-1977 Hankison Interview 74
U. Aug 1, 1977 Objectives 75
V. Author's summary 76
W. Contributors to this paper 76
Copyright (C) 1989 Merrill Consultants, Dallas, Texas. This paper will
be published in a 1989 issue of the "Technical Newsletter for Users of
MXG". Permission is hereby granted to SHARE, Inc. to publish this
presentation in SHARE Proceedings. Merrill Consultants retains its
right to distribute copies of this presentation to whomever it chooses.
On April 7, 1964, IBM Announced OS/360. Were you computer literate then?
The IBM Design of SMF Was The Direct Result Of The 1964 SHARE Systems
Objectives and Requirements Committee "SORC". The SORC Report was
produced only two months after OS/360 announcement!
------------------------------------------------
APPENDIX F
Report of SHARE Systems
Objectives and Requirements Committee
June 15, 1964
------------------------------------------------
G.E. Bryan, Chairman L. Cohn
P.A. Cramer R. Gillespie
G.H. Mealy C.H. Weisert
"IV. JOB ACCOUNTING AND SYSTEM PERFORMANCE MEASUREMENT
The advent of multi-programmed and multi-processor machine
configurations has re-emphasized the always present need for job
accounting and made even more important the much neglected area of
machine and program performance measurement. Operating systems for
System/360 must provide as a standard feature a job accounting system
which retains records useful for both ordinary cost allocation of
machine component time and measurement of hardware and software
performance.
Accounting and statistical information should be carried in the system
on a job basis and identified by the following information supplied by
the submitter of the job:
1. A job number.
2. A programmer identification number.
3. An identification specific to the run.
4. Priority.
5. Other information as deemed necessary by
the individual installation.
In addition, in order to facilitate automatic scheduling of jobs for
optimum performance, the following should be supplied either by the job
submitter or, for "normal cases," be defined by installation standard
parameters.
6. Expected execution time, cutoff time.
7. Expected output volume (lines, records, cards) by data set, with an
installation standard limit provided in the absence of specifically
supplied data.
An installation standard factor should be applied to these numbers for
the definition of cut-off limits. The programmer should have dynamic
access to the limits for examination and modification during execution.
In certain installations there is a need to specify 'due' time -- the
time before which the job should be completed -- and 'drop' time -- the
time at which the job should be deleted if its execution has not been
started."
"The system should normally add to the job accounting record the
following information:
8. Date, and beginning clock time of the run.
9. Processor identification.
It should also add to the accounting record information for each task
performed in the job's execution:
10. Task Type (FORTRAN,COBOL,SYSTEM,EXECUTION,MESSAGE).
11. Mainframe time.
12. Equipment used (tapes,drums,data lines)
13. Output volumes (print lines, cards)
14. Core used for code.
15. Core used for data.
16. Operator intervention time (waiting for operator action).
At job completion time, all of the accumulated information should be
summarized and totaled for the user, should be added to a daily total
record, and should be output in some permanent form for later accounting
and statistical analysis.
Accounting for message switching should be done using the same
accounting mechanism with each message transmission treated as a single
task. The descriptive parameters in 1-5 are supplied by the system on
the basis of the called and calling parties. The task type (item 10) is
"message".
Flexibility should be included for the expansion of the kind and number
of statistics retained at installation or IBM option. Special
installation requirements and special IBM performance measurements
should be readily accomplised by addition of code and/or parameter
changes."
In June, 1966, Bob Brockish joined IBM.
Bob had been on the SHARE Executive Board 1963-64, and had taken Share
Systems Division job when George Mealy resigned to join IBM. Had been
at Martin-Marietta (1959) and was now data center manager at Thiokol,
Utah.
In 1966, OS/360 SYS1.ACCT accounting consisted of only an IEFACTRT Exit
which was taken only at Step Initiation (=8), Step Termination (=12), or
Job Termination (=16).
When the exit was taken, there were pointers provided to:
Job Name Step Name
Programmer Name Account Fields
Job Running Time Step Running Time
Step Number Cancel Bit
but the user would then have to format and write the data to SYS1.ACCT
using ASM code in IEFWAD. SYS1.ACCT was supported under OS/360:
PCP - 18K, 44K, and 100K Scheduler
MFT - 30K and 44K Scheduler
MVT - Scheduler
Clearly, this approach to accounting was inadequate.
Notes from my 1989 visit with Bob Brockish:
IBM'S MOTIVATION FOR DESIGNING SMF:
1. User need to account time and resource usage.
2. IBM's need to know about how the system was being used, especially
about which IBM Programs were used how much/often.
A "SYSOUT Project" had already been started inside IBM. Originally the
idea was to solicit customers to submit their SYSOUT on tape, which
would then be analyzed after the fact (for compiler messages, link
editor, etc.) to count program usage!
Ken Brownell was the manager with one other when Bob joined group.
Bob's task was to look at OS to see how data could be collected in the
operating system. IBM Programming Systems Division at Pok had just
formalized "Programming Objectives" in January. SMF was the first
project to comply! Bob began to develop SMF objectives from SORC.
The name, System Management Facility, was picked in a brainstorming
session July 6, 1966.
PROPOSED PHILOSOPHY:
IBM would provide a way to collect data, the customer must process and
report. IBM could not see a general way to report on the collected
data. Based on the SORC Report, Bob began to define the data to be
collected. The initial design was reviewed with the non-disclosure
signers at the Aug, 1966 SHARE in Toronto (but Bob could not go - Ken
Brownell wanted to see Toronto!)
People at that August, 1966 meeting:
Lora Steele, IBM SDD Share Liason
Arnold Smith, IBM Overall Liason to SHARE.
Omar Smith, Rocketdyne?
Phil Kramer, SDC Bill Thunderbirkk, ?
Roy Dickson, Okla, Phillips Petroleum Harvey Siegel, ?
Joseph E. Kelly, SOCONY Mobile Irv Lester, North American
John Noerr, Sinclair Oil
Follow up copy of the objectives was sent to:
Channing Jackson (SHARE)
Earl Althoff, VP Guide
Leroy J. Rodgers, Chair Guide COBOL project
IBM'ers also involved along the way:
Neil Lewis - primary planner at Pok Don Ludlow - SUPERZAP author
Harry Reinstein Ira Heiney
Hank Coon Bob Levy
SMF ultimately hit 160 OS modules!
The design had planned for "packages" of information, selectable,
perhaps incrementally delivered by IBM. As there was concern for
potential impact of SMF on the system, packages must allow installation
to specify only what it needed. The first package proposed, presented
at SHARE non-disclosure meeting in August, 1966, was the Basic
Accounting information (Start/Stop Times). This first package was then
reviewed at Feb 1967 non-disclosure meeting, and Bob then gave the
presentation of the revised package. End of interview notes.
Throughout much of 1967, a joint SHARE/GUIDE System Management
Facilities Study Group met under non-disclosure. At the Monday May 22,
1967, meeting in New York City at the Americana Hotel included:
Edward Boback (GUIDE) Logistics Research
T. Todd Brown (GUIDE) Iowa State University
Joseph C. Kelly (SHARE) Mobil Oil Corp.
Edward G. Laski (GUIDE) Aetna Life
John M. Noerr (SHARE) Sinclair Oil
David R. Paul (GUIDE) Iowa State University
Harvey Sigal (SHARE) Union Carbide
IBM: Paul Bouche, Poughkeepsie
Ken Brownnell, Boulder
Arnold P. Smith, White Plains
Don Miles
------------------------------------------------
This task force reported their conclusions
in the August 25, 1967 SHARE SSD:
------------------------------------------------
"Attached is a report for SSD describing user requirements for systems
management facilities under OS/360. This report contains the
information that was gathered by the Systems Management Facilities Task
Force in conjunction with GUIDE and IBM. The Task Force is now working
on further definition and input to help provide guidance to IBM as to
the OS/360 users requirements for System Management. Among other
things, the group would like input from users on what kind of system
management facilities they are currently supporting and what level of
degradation (core, time, DASD, space, devices) they consider acceptable
for each functional feature required in advanced system management.
This input should be sent to both:
C. Channing Jackson (Task Force)
R. Cleveland (IBM Poughkeepsie)
User members of the task force included
J.M. Noerr (SHARE, signer of report)
E.G. Laski (GUIDE)
C. Weisert (SHARE Sys. Division)
J.J. Jones (OS/360 Proj.)
J. Kelly (MCB)
A final comment on the task force itself. IBM has appeared quite
interested in this work and has done considerable leg work for us and we
feel that these people deserve recognition and thanks for their
exceptional devotion to getting a job done despite the task force's
sometimes apathetic reaction to their questions. These people are (all
SDD):
Paul Bouche
Bob Brockish
Ken Brownell
Don Miles
and others to a lesser degree."
------------------------------------------------
An IBM memo from Lora Steele, IBM User Group
Liason Poughkeepsie November 1, 1967 requests
IBM to make a commitment to announce SMF, and
details the history of user group involvement:
------------------------------------------------
"There has been long and consistent pressure from user groups for IBM to
provide System Management Facilities. It has become a ritual for SHARE
to request an IBM presentation on this topic every general meeting.
Although IBM has been unable to comply to date, we should plan to
provide such a presentation for the SHARE and GUIDE general meetings
following IBM announcement.
The first disclosure of IBM Confidential Information relating to SMF was
made to user group officials in August 1966 and consisted of a
preliminary version of IBM's internal objectives. These objectives were
a result of considerable effort by Messrs. Ken Brownell and Bob
Brockish of Boulder to obtain and organize the many and varied
requirements of user group members.
Mr. Brownell was assigned SDD responsibility for these objectives by
the OS Architecture and Planning management. Messrs. Don Warren and
Ward Lambert of DP were present at the first IBM Confidential meeting
held in Toronto on August 2, 1966. A revised version of the objectives
was mailed to user group officials on January 6, 1967.
In February and March, 1967 there was little activity. In April,
however, a new joint SHARE/GUIDE committee was formed to again review
the user group requirements. IBM's internal specifications were
disclosed to the committee in order to verify that their specifications
did in fact meet stated user requirements. On September 15, 1967, the
User Group Nondisclosure Agreements for committee members expired....
If IBM could make any kind of commitment for Systems Mangement
Facilities in the near future, the user groups would be mollified. If
dates and technical details are included in the announcement, they would
be pleased. If no technical details are provided, I suspect that the
committee will be revitalized and members will insist that they be
allowed to monitor IBM's implementation phase to make certain that the
considerable user group efforts have not been wasted."
IBM's earliest SMF objectives were specified in:
------------------------------------------------
From S/360-OP-001-01-Pok dtd Nov 4, 1966:
Programming Objectives
IBM System/360
System Management Facilities in OS/360
Dated: November 1, 1966
------------------------------------------------
"1.1 Purpose
1.1.2 The operating information has two primary purposes. First,
information is required to determine and equitably distribute the
costs associated with each program's use of the equipment.
Second, the installation manager requires certain information to
evaluate the performance of his installation both in regards to
his own standards as well as in comparison with other similar
computer operations in order to increase the effficiency of use of
his current equipment, improve the service provided by his
installation and plan future equipment, programming systems and
personnel requirements.
1.1.3 The dynamic control capability is required by computer center
management to monitor the work load of the System/360 as it is
being processed to verify that work to be accomplished is
appropriately submitted with proper identifying data and that
processing is carried out in accordance with accepted installation
practices.
1.1.5 For purposes of these objectives the term "user" refers to a
computer installation manager rather than to individuals using the
computer. The latter are referred to as problem programs.
1.2 Scope
1.2.1 The scope of a Systems Management Facility encompasses four
categories of support.
a. Systems Management Data Set
b. Data Collection Packages
c. Dynamic Control Entries
d. System Management Utilities Programs
1.2.2 The System Management Data Set is a permanently opened data set
specifically designed for the recording of Systems Management
Data.
1.2.3 Data Collection Packages include the gathering and retention of
data elements required for control, evaluation and cost allocation
of system usage. Items such as CPU time, storage utilization, I/O
device allocation and software components used are indicative of
the type of data required.
1.2.4 Dynamic Control Entries allow the user timely assurance of
efficient systems utilization by transferring control to a user
routine at appropriate times and places. These Entries transfer
control to user supplied coding which performs specific auditing
functions unique to each user."
"3.1.1 The required data elements are stratified into five packages as
follows:
1. Basic Job Data
2. Basic Step Data
3. Additional Job and Step Data
4. Periodic Job and Step Data
5. Sampled System Data
3.1.2 Package 1. Basic Job Data.
1. Job Log Number
2. //JOB Statement after validation
3. Entry Time of Day
4. Exit Time of Day
5. Effective Priority
6. Output Quantities - Sysout Lines/cards
7. Job Time
8. Job Termination Status
Two messages to be added to SYSOUT:
Sign on
Sign off
3.1.3 Package 2. Basic Step Data.
1. //EXEC Statement after validation
2. Step Time
3. Unit Addresses by Type of Device
4. Output Quantities (Lines/Cards)
5. Input Quantity (Card images only)
6. Step Log Number
7. Step Termination Status
One message to be added to SYSOUT:
Step Termination, Program, Time, etc.
3.1.4 Package 3. Additional Job and Step Data
Additional data elements for use in performing more sophisticated
costing and in managing data libraries.
1. Job Log Number
2. SYSIN Reader Identification
3. Reader/Intrepreter Time
4. SYSOUT Writer Class
5. Output/Writer Time
Additional per step data
6. Kept Data Set Identification
7. Deleted Data Set Identification
8. Created Private Data Volume Id (Released Private Data Volume
ID may be supported via Data Set Accounting)
9. Actual Maximum Core Used (Not the Region Parameter)."
"3.1.5 Package 4. Periodic Job and Step Data
Includes those additional items which are required for
configuration planning, software evaluation and system performance
appraisal.
1. Job Input Queue Time
2. Job Output Queue Time
Additional per step data
3. Step Start Time
4. Program Time
5. Data Set Descriptions
6. DD Statements
7. Number of Devices Used by type/step
8. Device Use Time by Type
9. Rolled Out Time
10. Storage Rolled Out
11. Number of Roll Outs.
Controlled by Operator Command.
3.1.6 Package 5. Sampled System Data
Provides the elements necessary to develop a statistical profile
of an installation's system use characteristics. After the option
is exercises at system generation time this set of data elements
is collected on a time based sampling interval (delta t).
Whenever delta t is satisfied the data will be recorded on
SYS1.MAN.
1. Time of day
2. Total Memory in Use
3. Number of Active Jobs
4. Number of Passive Jobs
5. Number of Devices in Use by type/chan
6. Number of Readers in Use.
7. Systems Work space in Use
8. Work Input Queue Lengths
9. Work Output Queue Lengths
10. Channel Queue Lengths
11. Seek Queue Lengths
12. Number of Active Tasks
13. Timer Queue Length
14. Number of Writers in Use"
"3.2 Systems Management Data Set
3.2.4 Systems Management Data will be recorded sequentially on SYS1.MAN
as the data is acquired. This method of collecting will require
the following considerations.
1. SYS1.MAN data may have to be sorted by Log Number prior to
input to analysis programs.
2. Each dumping of SYS1.MAN will be an incomplete segment of the
Systems Management Data Set.
3. A complete Systems Management Data Set contains all segments
collected between an IPL and the subsequent "drying up" of
the system.
4. In the event of an abnormal system termination contents of
SYS1.MAN shall be preserved. "
3.4 Dynamic Control Provisions.
3.4.1 Dynamic Control facilitiesj shall be provided in the form of
entries to a user routine taken at ....
3.4.2 JOB, STEP, and DD CONTROL CARD VALIDATION ENTRY ....
3.4.3 JOB INITIATION ENTRY ....
3.4.4 STEP INITIATION ENTRY ....
3.4.5 STEP TERMINATION ENTRY ....
3.4.6 JOB TERMINATION ENTRY ....
3.4.7 TIME LIMIT ENTRY ....
3.4.8 OUTPUT LIMIT ENTRY .... "
"3.6 Systems Management Utility Programs
Two Types of utility programs required in conjunction with Systems
Management Facilities are analysis programs and a list program.
3.6.1 Systems Management Analysis Programs
The purpose of these utility programs is to produce reports based
upon data contained in the SYS1.MAN data set. These reports will
provide management with the information necessary to understand
system usage and plan future improvements.
The analysis programs will yield information that describes the
workload and system utilization from several points of view.
One class of information should pertain to the overall system
usage and status independent of particular programs or job types.
Such information constitutes a "System Profile".
The "Job Stream Profile" on the other hand should describe system
utilization in terms of the characteristics of the input
workload."
A further classification of information should provide a "Job
Profile" devoted to revealing the nature of both the workload and
systems utilization in terms of the characteristics of individual
job types.
At the lowest level of detail, a "Job Step Profile" describes the
charateristics of individual job steps and their contribution to
systems resources utilization.
3.6.2 System Management List Programs
In addition to the programs to analyse System Management Data, a
utility program for listing System Management Data Sets is
required. The utility's function is to provide a printout of raw
Systems Management Data in either its natural order or in Job/Step
Log Number sequence. Operating under OS/360 this utility uses a
input either a disk or tape dump of a SYS1.MAN data set. It shall
have the ability to concatenate multiple SYS1.MAN data sets and
print out a composite listing. Information from the data set
labels will be printed at the beginning of the listing."
"4. Performance Objectives
4.1 The ultimate purpose for Systems Management Facilities is to supply
information from which installation management can know and
improve computing systems performance. Through the proper
utilization of good systems management data the user can reduce
operating costs. On this basis users are willing to sacrifice
some amount of performance for the ability to gather this data.
The system performance degradation however, cannot exceed the
reasonable value of the facilities. To guide in implementing
System Management Facilities in OS/360 the following performance
objectives are set forth.
4.2 There is to be no performance degredation when none of the Systems
Management Facilities are employed."
4.3 The performance of the operating system should not be degraded more
than 3% when the SYS1.MAN data set, Dynamic Control Entries, and
Packages 1, 2, and 3 are activated. In addition, the collection
of data in Package 4 should not decrease performance more than 4%
during those periods when it is active. Package 4 should cause no
degradation when it has been selected at system generation but is
not in use. Since the collection of Package 5 is based on the
value of a time interval. measurement of its performance should
be aimed at a time per sample basis. Each occurrence of sampling
of Package 5 data should not require more than 500ms on a 360
Model 50."
4.4 These performance objectives for OS/360 are summarized below:
Facility Enabled Timing Target Additional core
Requirements,
Maximum Bytes
none 0 0
SYS1.MAN +Dynamic Control 200ms/Job 256 + 128/Job
Package 1 500ms/Job 1024
Package 2 250ms/Step 512
Package 3 250ms/Job 512
+250ms/Step
+250ms/Data Set
Package 4 200ms/Job 1024
+300ms/Step
+500ms/Data Set
Package 5 500ms/Sample 1024
Based on jobs averaging 3.5 min and containing an average of 3 job
steps each having 5 data sets.
Based on CPU Model 50H with 2311 disk for system, SYS1.MAN and
SYSOUT residence."
Four months later, SMF Subset 2 was specified:
------------------------------------------------
Externally dated April 18, 1967
Addendum I
S/360-OP-0001-02-Bldr
Programming Objectives
IBM Operating System/360
Data Set Management & DA Space Accounting
Dated Internally: March 13, 1967
------------------------------------------------
"This addendum extends the scope of the System Management Facilities to
supply the user with the tools required to manage data set libraries and
to control and account for space usage on direct access devices. The
facilities to furnish this capability include the recording of data set
records on SYS1.MAN and a utility routine to retrieve the data set
records, put them in a data set management file, produce a data set
inventory and maintain the data set management file.
New data will be recorded when Package 3 is selected:"
A. NEW, Non-temporary Data Sets
1. Identify as NEW
2. Data Set Name (including GOOOVOO)
3. Creation Date
4. Expiration Date
5. Device Type
6. Number of Volumes
7. Volume Serial Numbers
8. Public or Private
9. Shared or Exclusive
10. Number of accesses to read
11. Number of accesses to write
for direct access for tape
12. File organization Data set sequence Nr
13. Amount of space Type of labels
14. Unit of Space Recording density
15. Number of extents 7 or 9 track recording
B. OLD Data sets - similar to NEW
C. Temporary Data Sets
1. Identify as Temporary
2. Device Type
3. Number of temporary data sets
4. Total number of volumes involved
5. Total number of accesses/records.
6. Total amount of space in bytes"
And then, amazingly, Subset 2 described the:
"IV. Data Set Management Utility
The Data Set Management Utility is intended to run daily or periodically
as required by the installation to provide information to guide the
operations staff in purging the data set library and to maintain the
circulation of data volumes.
A. Functions of the Routine
1. Extract data set records from concatenated SYS1.MAN dumps and use
them to build and maintain the Data Set Management File. This
Utility does not physically remove data set records from the Data
Set Management file on this basis. Instead it "deletes" by setting
a flag and inserting a deletion data in the appropriate record.
Actual removal of data set entries will be made via punched card
input after the information has been used for billing, etc., by the
user.
2. Produce a report by device type and volume serial number of data
sets whose expiration date has elapsed. This listing includes Data
Set Name, Programmer's Name, Accounting Fields, Creation Date,
Expiration Date, Date Last Written and Date Last Read."
3. Produce data set inventory report by device type showing activity.
This listing includes Data Set Name, Programmer's Name, Accounting
Fields, etc....
4. Accept, as input, punched cards with deletions and changes to data
set records in the Data Set Management File. These cards will be
prepared by the user's data librarian and input into the file
maintenance run. Through these cards, data set entries can
actually be removed from the file and revisions can be made to
accounting fields, responsible programmer's name, etc.
5. Provide exits for user supplied coding to perform other functions
desired by the installation."
Addendum II was dated a day later:
------------------------------------------------
S/360-OP-0001-03-Bldr
Programming Objectives
IBM Operating System/360
Job and Step Timing
Space Accounting
Internally Dated: March 14, 1967
------------------------------------------------
"This addendum replaces "Job Time" in the original specification with
"Job CPU Time", and adds a new element:
7b. Job Unoverlapped I/O Time
Job Unoverlapped I/O Time is the accumulation of time during which both
of the following conditions are satisfied:
a) input and/or output activities are being carried on by or for a job
b) and that job is not using the central processing unit.
Job CPU Time plus Job Unoverlapped Time equals the time a job would
require if it was the sole inhabitant of the computer system. It is the
summation of these two time measurements that ... should be compared
with when determining if the job is exceeding its maximum running time."
------------------------------------------------
Dated 7/27/67 is a Proposal for Extensions
to OS/360
------------------------------------------------
Proposing:
- Maintenance of the DA Volume Inventory
- A New Volume Reorganization Utility
- A New PDS reorg-needed status message
- A New PDS reorganization utility!
It appears this document was not accepted, but it contains a tantalizing
bit of data:
"3. Market Requirements
3.1 The problem of DA space deterioration potentially affects each of
the estimated 550 installations using OS as their primary
operating system. Also to be considered are the additional 1596
forecasted future users of the system."
550+1596 = 2146 Future OS Customers!!!
Initial specifications were completed in Summer, 1967 and SMF moved to
Poughkeepsie (Pok) for implementation under Saul S. Schiffman, with
Lynn Weisenreider in his group. Notes from 89 Saul Schiffman interview:
Biggest implementation difficulties:
to convince Supervisor in IOS to put in lines of code in Operating
System - they were very conservative on instructions in path.
Testing together to see that it worked was new, OS was the first large
scale software project.
Had to firmly make rules how to access SMF. Some developers did not
want user records - could garbage up the collection, but they lost.
MANX/MANY had to be handled by the system
Very hard at the beginning, everybody had their own ideas.
"Hundreds" of pieces of information.
Rule: Unless you can show me how you will use it, I won't add it.
That reduced hundreds to 30-40 items.
Complaint of expected SMF overhead of 5% was answered by jury rigging
SYS1.ACCT for all of the same data. Discovered that it too took 5%,
and showed in-line capture no worse than exits.
This convinced IBM that measurement could be an integral part of the
operating system, and also showed that SMF data was not optional - a
site simply could not run without this data.
Was the customer Measurement or Accounting?
Accountants - look at this data
Performance Measurement - look at that data
Picked common ground between the two.
Made attempt to convince users to use only the repeatable fields, and
make data more repeatable - MFT easier than MVT.
Wanted one project for billing and for measurement and evaluation.
When conflicts arose, measurement & evaluation guys gave up on
additional data fields.
Accounting - some things are outside of control (eg paging) - could
not predict branching impact, thus cannot charge for it. Began to
look at counting from application.
IBM could not answer "How do you account?"
"We were not going to write accounting and
billing routines at IBM.
Instead, we will document and provide data"
SMF Implementation began at the start of 1968. PCP, Fortran, MFT I, MFT
II development were at Kingston, while MVT, IOS, SVS, MVM were all at
Poughkeepsie. MVM (Multiple Virtual Memories) became MVS.
SMF Implementation Options now considered:
1. Have a program in the system dynamically sample and adjust the
system based on the actual measurements.
- heuristic approach
- radical (remember, this WAS 1968!)
- major proponent of this option was
Bart Page -"Brain behind the SRM.
Mind beyond others.
Ahead of his time, but
Not a good salesman."
or, what we actually ended up with:
2. Extension of traditional SMF design
Not much on analysis
Minimal reporting
End of 1989 Interview notes.
On October 16, 1968, Saul's group distributed their Final Specifications
on Subset 1:
------------------------------------------------
System Management Facilities (Subset 1)
Final Functional Programming Specifications
(MVT)
OS/360-OS-0043-05-POK
------------------------------------------------
Unfortunately, I have not see a copy of that document. Based on the
final implementation, however, Subset 1 created the following SMF
records:
Type 0 - IPL Record
Type 1 - Wait Time Record
Type 2 - Dump Header Record
Type 3 - Dump Trailer Record
Type 4 - Step Termination Record
Type 5 - Job Termination Record
Type 6 - Output Writer Record
Type 7 - Data Lost
Type 8 - I/O Configuration
Type 9 - VARY ONLINE Record
Type 10 - Allocation Recovery Record
Type 11 - VARY OFFLINE Record
Type 12 - End-of-Day Record
Earlier, on February 7, 1968 there had been:
------------------------------------------------
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
