- 126 -

P. Carpenter March 16, 1973

In practice linkages are only made when the perceived need is deemed worth
the effort. Without a central system the "potential" barrier to forming
linkages can involve costly software and hardware interfaces. In a clinical
research and teaching environment the number of possibly useful combinatorial
linkages is large. If the "potential" barrier is great, innovation and
experimentation is impeded. The forces in the system are then centrifugal
instead of centripetal.

Since the management of the clinics and hospital also depends more and more
on computer manipulation and extraction of data, the total systems behavior
will have important economic as well as academic consequences.

The proposal for Computer Health Care Application Research gives an insight

into the clinical and academic benefits of a shared common data base. This

and several other grant proposals, involving interdepartmental collaboration
have called for linking of data bases. The second section of the proposal
addresses the important problem of the definition of the data base. The

third portion, deals with file and retrieval systems for a clinical data

base. This involves the potential utilization by twelve specific clinical
activities of a shared data base. This grant, if implemented would spend
approximately $86,000 per year in computer services. Some of these developments
are currently underway on ACME.

In addition to the academic research needs of the clinical faculty, there
are the requirements of the hospital for a shared data base. These are
derived from managerial and economic imperatives as well as the hospital's
educational and research goals.

There is no current completely acceptable solution that meets the requirements
of a complete Hospital Information System (HIS). The search for this solution
is a very important problem and one in which Stanford should be involved. It
will affect many aspects of medical education and teaching as well as practice
within a hospital environment. Within the next several years many elements

of such systems will be successfully implemented and will be important parts
of the operation of Stanford Hospital. The 370/158 has the capacity to allow
Stanford to implement a hospital information system. The design of such a
system and the timing and funding of its implementation are not part of this
plan.

The Technicon HIS at El Camino provides insights into costs and CPU requirements
of HIS. From the operation of the El Camino system since the first of this
year, it now looks like they will in fact realize net savings of $85,000 per
month, most of which will be realized by reductions in nursing staff personnel.
El Camino is a hospital with 446 beds and 60 bassinettes. The Technicon
Hospital Information System is designed around two 370/155's to support

2,000 beds at $6.00 per day. The CPU cost is about one-third the total cost.
This is in addition to the cost of business operating systems. Roughly, this
says that implementation of such a system at Stanford with 612 beds and 57
bassinettes would approximately double the dollars that would be available to
be spent by the Hospital for central processing over our worst-case projections
and a 50 per cent increase in our conservative projection in whatever year an
HIS should be installed.
- 12eT -

P. Carpenter March 16, 1973

It will be economically important in the future to bring together

dispersed elements of a patient information system into a coherent whole.

It may be too difficult and expensive to do so, if dispersion has gone on
too long. This is the difference between a stand-alone community hospital
and a hospital-cum-medical school. The former can wait until it knows exactly
what it wants to do. Stanford Medical School faculty and their research

and teaching interests are in integral part of Stanford Hospital. They will
and should carry out their academic functions in the best way available to
them. Nothing can or should stop the dispersive process except the better
alternative of a well-managed reliable central system that by its very
nature makes collaboration easy.

ECL/mla

Attach.
To :

FROM 1+

Suavect:

~ 128 -

Dart: = March 12, 1973

Elliott Levinthal, Ph.D. .

Stan Cohen, M. D. Ne .0sty, C8

Need for Common Computer Facility at the Medical Center

As we have discussed previously, there is an important need for a computer
facility at the medical center to provide capability for faculty to share
programs and data related to both clinical activities and research projects,

At the present time, individual projects being carried out by various faculty
members constitute component parts of what will probably eventually develop
into a hospital information system capable of handling large amounts of
patient-related data. Included among these components are the drug interaction
warning system of the Division of Clinical Pharmacology, the Microbiology
laboratory system developed on ACME by Dr. Merigan and his collaborators,

the Clinical Chemistry and Hematology laboratory system developed by Dr. Sussman,
the Medical Records system of Dr. Jim Fries, and the Cardiology data system

of Dr. D. Harrison.

Patient care at this medical center requires that these separate data bases be
available on a central computer system so that information accumulated by one
project can be shared by others. For example, the identity of organisms cultured
by the Clinical Microbiology laboratory and their resistance pattern should be
accessible by the pharmacy system programs, so that a prescription that is
inappropriate for a particular organism or drug resistance pattern can be detected
at the time it is filled. Similarly, data being accumulated by the clinical chen-
istry laboratory indicating inadequate renal function should be available to the
pharmacy system, so that alteration of dosage may be made for a drug eliminated
from the body by excretion through the kidneys. Conversely, drugs that artifac-
tually influence the results of laboratory test findings by interference with
spectrephotometric determinations and other test procedures, and this information
should be available to the clinical laboratory. Cardiology data should be avail-
able for similar reasons, and since drug influence interpretation of cardiovascular
tests, pharmacy data should be available through the cardlology system. All of
the types of data indicated here, plus clinical findings related to the patient
history and physical examination should be part of the time-oriented medical
record system being developed by Dr. Fries.

Although this brief memo stresses. the patient-care benefits that would derive

from having a large medical center computer system avajlable for sharing of

data bases and programs, I also want to emphasize the importance of such a system
to faculty research. Linkage of the clinical microbiology laboratory and pharmacy
systems will enable epidemiological investigations of the effects of antibtotic

use on resistance patterns of organisms isolated from patient populations.
Similarly, research to detect new effects of drugs on clinical chemistry tests will
also be feasible if the data bases can be shared. Atlhough these are just a few
examples, there are many other instances where sharing of data bases will enable
important investigative questions to be asked and answered,

I hope that this brief memo provides the information you are seeking.
FFICE MEMORANDUM ¢© STANFORD UNIVERSITY © OFFICE MEMORANDUM © STANFORD UNIVERSITY @© OFFICE MEMORANDUA

To t

From 3

Susuect:

- 129 -

Date: March 8, 1973

Elliott Leventhal

James F. Fries

Advantages of a variety of medical database operations sharing

the same computing equipment.

Within the medical center and hospital there are a number of patient
related computer databanks. Inevitably, the number and variety of
clinical databank operations will increase over coming years.

included in these databanks will be diverse yet similar.

various clinical laboratories, x-ray, cardiac catheterization and pathology

Over the long term,
the facility with which information may be exchanged between these different

departments will be accumulated in computer databanks.

Material

Thus, patient
identifying infornation, financial and accounting information, clinical
information required for insurance and third party carriers, historical
and physical examination data elucidated by physicians, therapy prescribed
and drugs dispensed, and the multiple forms of information emanating from

operations will be of great importance. A research study may require

Stratification in terms of socio-economic data kept by the business office.

The business office may require clinical information available in other
databanks to process insurance forms. Billing may ultimately be related

to the actual provision of the service at the physician level as documented

in the chart and from laboratory information as it becomes available to
the physician. Without provision for linkage and exchange of information
the individual databank operations will require duplication of effort in
data entry. Without capability of linking laboratory computer systems to
clinical medical record databanks, laboratory data must be manually re-entered.

It can be stated fairly that medical computing has consisted in large part

As the need for
computer based clinical information systems grows there is the possibility

The existence of

of duplication of effort both at Stanford and elsewhere.

of ever greater fragmentation and duplication of effort.

a central computing facility for the medical center and hospital will allow

planned growth, minimal redundancy, and exchange and pooling of clinical
data. It will place the hospital and medical school in a strong position
to meet increasing governmental requirements for “quality assurance” ana

medical audit.

JFF/hcp

4a
wd

OW 231ddO @ ALISUJAINA GUOINVIS © WNONVYOWIW FD1ddO © ALISMIAINN QGYOANVIS © WNONVYOWIW 351dIO © ALISBIAINN GUOIUNY

WNONYVEO
Dr.

- 130 -

March 8, 1973

Elliott Levinthal
Genetics Department

Dy, Donald Cc. Harrison
Cardielogy Division

Advantages for a Hospital Computing System

Following our discussion yesterday, I have considered the
advantages of a medical school computing system which would be

‘a combination of hospital and medical school programs. The over~

all advantages are as follows:

A.

Having a joint facility in the medical center would permit a
common data base for all patients. This is essential for

‘ongoing clinical research and for ease in efficiency of

administrative operations. The case for this is as follows:

I.

Ze.

-All patients under the care of Stanford faculty members

in the Stanford University Hospital are either referred
from the Stanford clinics prior to admission or are seen
in follow-up in the clinics. Thus, it is essential that

a data base include both aspects of the patient's record.
This would encompass laboratory reports, x-ray studies,
and ongoing follow-up data. These patients are frequently
part of research protocols relating to the action of

specific drugs, to the effects of surgical procedures, etc.,
and represent the basis for much of the clinical research

being carried out by the clinical faculty.

A patient seen by one particular group in the hospital is
frequently seen by others and data common to studies being
carried out by several interrelated groups should be
available to the various division and departments. This
is particularly true in the case of Cardiology where

-patients are first seen by the medical cardiologist. Data

are accumulated on the patients by the clinical laboratories,
by the x-ray units, by the cardiologic units with special
computer facilities such as the catheterization laboratory

or the EKG laboratory, and then the patients undergo some
surgical procedure in the Surgery Department. These patients
are then followed. up jointly by the various members of the
Medicine, Surgery, and Radiology faculty. Consultants from
Infectious Disease, from Immunology, and from other disciplines
also frequently are asked to see these patients. To devclop
new concepts regarding the nathogenesis of disease, to test

this in clinical populations, and to determine the effects

of interventions upon these diseases, it is essential that
these groups interrelate their data.
Dr.

B,

°C.

- 131 -
Elliott Lovinthal ; ~2- March 8, 1973

3. At the same time clinical data ara being transmitted to

; patient's records, hospital charges can be assessed.
Thus, for aase and efficiency of administrative detail, a
cooperative computer facility is necessary.

With increased emphasis upon judging the quality of medical

care and upon determining cost effectiveness of caro, the
integration of hospital activities and medical school activities
becomes absolutely cssential, Computer surveillance for drug
interactions, for physician performance, and for developing

new educational activities related to this aspect of medicine,
necessitate a combinod hospital medical school computer facility.

The accumulation of a critical mass of individuals working in
hospital information systems for Stanford Medical School scems
essential, The interrelationships of data from small computer
systems in the various divisions and departments and support
for these interfaces would be provided ky a combined computer

facility.

For the reasons of improving tho delivery of health care, for

enhancing clinical research, and for improving integrated teaching
‘ programs I would strongly support the developmont of a hospital
medical school computer facility.

PCr gr
To t
From ;

Suasect:

- 13e -

Date: March 9, 1973

bp
Elliott Leventhal, M.D. li(

Associate Dean pe VAR 1240/3
Thomas C. Merigan, M.D. ne

Chief, Division of Infectious Diseases

This memo is in respohse to your questions in regard to my thoughts
concerning the ACME system and its present and future contributions to
clinical investigation. The availability of equipment and the ease of
the language of ACME has personally benefited me enormously during the
past 5S years while we have been working with patient oriented systems
forour Diagnostic. Microbiology and hospital epidemiology functions.

As you know, all‘of our antimicrobial identification and antibiotic
sensitivity data goes into ACME on an on-line basis from our hospital

service laboratory. This involves only a minimal amount of time for our
secretaries and technicians and produces a useful return from t.o stand-
points: the antimicrobial sensitivity data is quality controlled prior to

its issuance to physicians and all of our previous experience is immediately
accessible for our clinical consultants as well as the Diagnostic Microbiology
Laboratory personnel.

In regard to hospital epidemiology, the filed information is automatically
put together on a monthly and semi-annual basis for reporting to the Infection
Control Board members and the state and county authorities. The infection
control nurses use this information in deciding whether there is any increased
incidence of nosocomial infection at Stanford University Hospital, and now
records dating back two years are available in that area whereas the anti-
biotic sensitivity and isolation information goes back some four years
allowing many types of comparisons which wouldn't be possible without this
regular recording of data.

I think the point you are particularly interested in, however, is how a
commonly shared system among various clinical users which is tied in with the
hospital system might be particularly advantageous. We find that as the ACME
system was used for development and now the maintenance of our infection control
and diagnostic microbiology systems, these two systmes can be linked up quite
easily and personnel who operate one can also utilize the other. However, a
very exciting proposition has come up in that our systems are being linked to
Dr. Stanley Cohen's pharmacy based system on drug interaction because our
languages are compatible. His system was also initially developed on ACME
equipment. Of course, he uses the hospital Business Office information in
his pharmacy based system. We would use a shared data base with him as well as
provide on-line quality control for the use of antibiotics. Hence, when drugs
are ordered from the pharmacy prior to their issuance to the wards, the reports
currently coming out of our Diagnostic Microbiology Laboratory would be used
together with appropriate rules to advise all concerned as to their suitability.

It is quite likely that Dr. Howard Sussman's clinical chemistry information
system will also be linked in the future to these systems to provide data on

WA Pe eels em FEO TRO wm le

DHIOMSIAINIA AvALAIWEOe

esreust atin AWAUNWIOC @ WAAR nd ant oe
- 133 -

potential limitations to use of antimicrobials which are an important part
of the quality control of physician decision making. As you can sec,
having all three’ of these systems linked up to a common hospital base
facility obviously allows interactive programs and shared data bases

which would not be possible without much interfacting difficulties. There-
fore, I believe a common hospital system will promote similar collaboration

for others in the future.

Can you send me a copy of the application on Computer Health Care
Applications Research for my files? Thank you.
- 13k -
APPENDIX B

STANFORD UNIVERSITY HOSPITAL
DATA PROCESSING DEPARTMENT

March 7, 1973

TO: Peter F, Carpenter, Assistant Vice President of Medical.‘:ffairs
, 7 . > J . ae \
FROM: V. H. Barber, Assistant Controller for EDP _ fo 1 2%*

SUBJECT: Medical Center Computer Planning Chronology

Presented below is a chronology of events related to computer planning
from late 1970 to date.

Late 1970 - Early 1971

Medical Center Sub-Committee for Computing accomplished very little
except for a survey of computer and data processing needs at the
Stanford University Medical Center.

October 1971

President's Computer Science Advisory Committee annual visit results
in general observation that computer planning has deteriorated,

December 8, 1971

Medical Center computer briefing to Dean Clayton Rich. Presentations
by:

Barber

Dickens

Franklin

Jamtgaard

» Phillips

. Roberts

Soa wmDoordc

December 28, 1971
Medical Center Computer Planning Committee created,

Chairman: —. Levinthal
Members: S. Cohen, M.D.
DeGrazia, M.D.
Dong, M.0,
Kalman, M.D.
Jamtgaard
Rindrleisch
Stead
Williams
Barber

_eeoeaxrHtnunmue
e
- 125 -

P. F. Carpenter March 7, 1973

Medical Center Computer Planning Committee meetings were held on:

1/24/72 Various configurations of computers, utilization of HDP and ACME
1/31/72 loads were monitored. Organizational structures were studied;
2/15/72 long- and short-term plans were considered. Needs of research
3/6/72 groups were put forth, First major report of hardware alterne-
3/20/72 tives was presented March 20, 1972.

4/10/72

4/24/72

5/3/72

5/19/72

5/31/72

Various meetings in June

July 18 - August 3, 1972

Presentations of the various alternatives to computing in the Medical
Center were made to the Computer Planning Comnittee.

July 18 Position paper advocating PDP-10 for the Stanford Medical
Center Service Computing Facility - R. Jemtgqaard and 7.
Rindfleisch,

July 26 Stanford University Medical Center Praposed Service
Facility position paper - V. Barber,

August 3 Position paper advocating that computing service for the
Stanford University Medical Center be supplied by a Uni-
versity computing facility - G. Franklin, T. Phillios,
M. Roberts.

August 11, 12, 1972

Recap of Committee activity and alternatives for computing to Dean
Rich. Made recommendation to him for comouting. The conclusions of
the Committee are attached in letters from £, Levinthal dated Augus¢
17 and August 18, 1972.

August 22, 1972

Medical School Executive Committee meeting. Clayton Rich, M.D., updated
Executive Committee on computing alternatives (see attached letter of
August 22, 1972).

August 21-23, 1972

Clayton Rich dismissed original committee (see 12/28/71) and created
an interim committee:

J. Stead

V. Barber

R, Jamtgaard
E. Levinthal

Chairman:
Members:
- 136 -

P. F. Carpenter March 7, $973

Purpose: Summarize the financial and technical findings of the Medical
Center Computer Planning Committee,

August 30, 1972

Interim Committee made its summarizing report to Clayton Rich
(Copy attached: Letter of August 30, 1972),

September, 1972

Gene Franklin made recommendation to Vice Presidential Group regarding
University-wide solution to computing. He was directed to draft a
policy statement and a plan.

November 8, 1972
Arn Advisory Group on Computing Merger was established consisting of:

Franklin
Creighton

Chairman: G.
K.
C. Dickens
T.
E.

Members:

Gonda, M.D,
Levinthal

This group appointed a Planning Task Force made up oF:

Chairman: C. Dickens
Members: V. Barber
R. Jamtgaard
M. Ray
F. Riddle

November - Decamber 1972

Task Force has several sub-committees, Various meetings were held
during this period of time.

December 29, 1972

Task Force submitted its report and recommendation to the Advisory
Group, Recommendations are attached,

January 1973

Dean Clayton Rich asked if the original SUH Data Processing proposal
(see July 26, 1972) could offer a possible solution to Medical Center
computing.
- 137 -

P. F. Carpenter March 7, 1973

January - February 1973
Numerous meetings and analyses were conducted in this period, Results
were a 360/65 or 370/158 if properly organized and planned could solve
Medical Center computing needs.

February 23, 1973
Recommendation to Vice Presidential Group for purchase of a 370/158,

March 1973

Medical Center computing solution still under study.

vhb:adg
II.

- 138 -
APPENDIX C
(Excerpt from ACME Note HAD)

IBM 2701/SATELLITE COMPUTER MULTIPLEXOR DESIGN AND OPERATION

INTRODUCTION

This paper is intended to describe the design criteria, specifications
and feature, theory of operation, and operational procedures for the

IBM 2701/SATELLITE COMPUTER MULTIPLEXOR. The design criteria section
explains some design philosophies and some desirable features that such

a system should have. Features section gives a list of specifications
and features. Theory of operation explains in detail how this system
works. And finally operational procedures section gives detailed trouble
shooting procedures for problem isolation and procedures to bring on a
new user.

DESIGN CRITERIA

The purpose of a HOST/SATELLITE COMPUTER MULTIPLEXOR is to allow several
remote satellite computers to communicate directly to a host computer

and vice versa. The main function of the satellite computer multiplexor
is to allow only one satellite computer to communicate to/from the host
computer at a time. The satellite computer multiplexor should be capable
of handling up to sixteen remote satellite computers. The satellite
computer multiplexor should be designed such that it will be independent
of the host computers' and satellite computer's designs and/or operational
characteristics. All remote satellite computers, 100 feet away from the
host computer, must transmit data serially to/from the host computer via
the satellite computer multiplexor. The satellite computer multiplexor
must be capable of timing out in the event of any malfunction or due to
one particular satellite computer which has used up its allotted time in
transmitting data to/from the host computer. And lastly, the host com-
puter must be capable of-interrupting any of the satellite computers via
the satellite computer multiplexor.

In order to meet the above criteria, the satellite computer multiplexor
can be thought of as made up of three basic sections: host computer
interface, multiplexor control, and satellite computer I/O control, as
shown in Figure 1.

The function performed by the host computer interface is handling all I/0
Signals to/from the host computer.

The functions performed by the multiplexor control are queueing satellite
computer interrupt requests, establishing communication with the host
computer, making sure that proper identification from the satellite com-
puter is passed to the host computer, passing status to the host and to

the satellite computer at all phases of the data transfer, detecting time-
out conditions, monitoring and flaging any malfunction for trouble-

shooting purposes, and allowing the host computer to interrupt any satellite
computer.
HOXATMI LINN YaELNdWOO ALITIGLVS T Fund

Joxagdyaynus sesndwod

pan

P1405

 

 

 

 

 

a Mysegul
ant —/ /— 2a

 

 

 

 

 

 

 

 

 

 

 

 

seendwos
! —_—- poloads
PI PIOS
a [{\919ua5H J0j;o4ju02
qd
t Yl
aaanduio>
aey]7eso
4aandwos aI Oysayul WwW s
aes JOloads ———/;
ee tiaees /\n.9Ua9

 

 

 

 

4@|JO4QUuE?

s4oxaldispaw

DIMMpsayut
aayndwo>

50H

 

 

 

 

 

 

dogndwo>

$50K

 

 
~ 140 -

The functions performed by the satellite computer I/O control are
serializing and deserializing data to/from remote satellite computers
and allowing parallel data transfer if satellite computers are within
100 feet of the host computer. Serial data are to be transmitted bit
asynchronous and an optional choice between word or character asynch-
ronous or synchronous,

In order to maintain complete flexibility at the satellite computer
end because of different computers, the interface between the satellite
computer multiplexor and the satellite computer is to be divided into
general and special interfaces. The general interface is to handle all
I/O signals to/from the satellite computer multiplexor and the special

interface is to handle all 1/0 signals to/from a particular satellite
computer.

For implementation, the host computer is an IBM 360/50 and the satellite
computer multiplexor is interfaced to one of the ports of an IBM 2701
Parzllel Data Adapter (PDA). This means that the satellite computer
multiplexor will work with any IBM 360/370 host computer as long as it
is interfaced through an IBM 2701 PDA port. Remote satellite computers,
on the other hand, can be DEC PDP-8, 9, 10, 11, 12, 15 or XDS Sigma 3, 5
7, or Hewlett/Packard HP-2411, 2115, 2116, or VArian 620i, 620f, or etc.

3

III. SPECIFICATIONS AND FEATURES
1. Handle up to 16 simultaneous satellite computers.

2. The satellite computer multiplexor is interrupt driven. It
operates strictly on demand/response basis.

3. Each satellite computer talks to the IBM 360 on a first come,
first served basis.

4. Each satellite computer can be assigned to any one of the 16
multiplexor channels.

5. Each satellite computer has a hardware key address at the satellite
computer multiplexor end for ID purposes.

6. Transmission mode is by serial asynchronous half duplex for remote
and/or parallel asynchronous for local operation.

7. Transmission speed is hardwired and the available speeds are:
250K*, 100K*, SOK, 10K, 5K baud per second.

8. Word transmission rate for maximum word length (20 bits) is:
12.5K, 5K, 2.5K, S500, 250 words per second.

*Recommended for twisted pair less than 1000 feet or coaxial cable for longer
distances
10.

11.

12.

13.

14,

15.

16.

17.

18.

- i141 -

Maximum serial bit transmission between satellite computer
multiplexor and satellite computer is 20 bits; that is 1 start
bit, 2 control bits, 16 data bits, and l Stap bit.

Maximum word length from satellite computer is lo bits.

Data path between IBM 2701 and satellite computer multiplexor
is 16 bits wide.

The satellite computer has the option to run in complete demand/
response (synchronous by character) or semi-complete demand/
response (asynchronous by character) modes. Note this is not a
programmable function.

The satellite computer running under complete demand/response
mode requires four twisted pairs and operates at lower data
rate,

The satellite computer running under semi-complete demand/

response mode requires only two twisted pairs and operates at
higher data rate.

The IBM 360 asynchronously can interrupt any satellite computer
via the multiplexor.

The IBM 360 can pass status to a satellite during the normal
transmission cycle.

The satellite computer will receive all error and termination
conditions through coded messages from the multiplexor so that
it can act accordingly.

Detailed handshaking procedures between the satellite computer
and the host computer are described in the section 'Asynchronous/
Synchronous Data Transfer between Satellite and Host Computers".
- 1he -
APPENDIX D

ACME Note AA-40
Erica Baxter
ACME Notes Index May 11, 1973

ACME Notes, written by all members of the ACME staff, are informal working papers.
They are divided below into four main categories: General Information, Administration
and Utilization, System Information, and User Information. Subcategories under System
Information and User Information parallel each other. Programs on ACME's PUBLIC file
and the ACME §tatistical Library are listed at che end of the Index.

The letters in the ACME Note codes are for filing and reference purposes only;
the numbers in the codes~-except for part of the J series--indicate reiasues.
All but historians can dispose of superseded issues. The J series and parts
of other ACME Notes are incorporated into the PL/ACME Manual (AM) revisions.

If you wish to have a copy of an ACME Note, it is available at the ACME office.
Those notes preceded by an asterisk (*) are new or have been changed in some way
since the last ACME Notes Index was issued.

ACME Notes which have become OBSOLETE with this issue of AA are liated separately
in the last section to this index.

GENERAL INFORMATION

AA-40 ACME Notes Index (Baxter)
MAY 11, 1973

AAOBS-8 Obsolete ACME Notes (Baxter)
OCT 10, 1972

ACONT-1 The Need and A Method to Obliterate Control Languages (Wiederhold) .
Submitted to ACM SIGPLAN/SIGOPS Workshop, Savannah, Georgia, April 9-12,
1973
NOV 22, 1972

AD-1 An Advanced Computer System for Medical Research (History,
Goals, etc.) (Staff)
MAR 1967

ADJ-1 An Advanced Computer System for Medical Research (Wiederhold)
DEC 8, 1969

ADJJ~! An Advanced Computer System for Medical Research (in Japanese)
(Wiederhold)
DEC 8, 1969

AE-3 A Timeshared Data-Acquisition System (Wiederhold/Hundley)
MAR 26, 1970

AF-I A Filing System for Medical Research (Frey/Gtrardi/Wiederhold)
MAR 24, 1970

AFORT-1 Implementing a Time-Shared/Realtime System in FORTRAN (Frey)
APR 23, 1972

AG-1 Usage of the ACME System (Wiederhold)
To be published in Statistik an Dokumentation in der Medicine
NOV 15, 1971

AHCALL~1 Communication Hardware for Simplified Protocol (Stainton)
FEB 14, 1973

AI-1 The ACME Compiler (Breitbard/Wiederhold)
MAY 8, 1968

AIM-1 A Method for Increasing the Modularity of Large Systems (Wiederhold/Breitbard)
DEC 31, 1968

AINST-1 Instant 360--Chart (Wiederhold)

JAN 1, 1969

AL-1 An Advanced Computer System for Real-Time Medical Applications
(Wiederhold/Crouse)
DEC 4, 1968

AMS~1 Mass Spectrometers in a Time-Shared Environment

(Reynolds/Tucker/Stillman/Bridges)
OCT 10,1969

AN-2 Setting Up a General-Purpose Data-Acquisition System (Wiederhold)
DEC 5, 1969

ANU-5 Information for New ACME Users (Baxter)
MAY 1, 1972

A0-3 Computers in the Medical Center (Staff)

SEP 13, 1972
APCALL-1 A Conventional Protocol for Synchronous Data Communications (Stainton)
FEB 14, 1973
APLAN~I
APUB-11

AR-1

AS~2
ASD=-1

ASQ-1

ATS-1
ATSC-1
ATYNFET~1
AV~4

BASS~1

BDEN-1

BDW-1

BSD-i

BSPD-2
CONS~4
ES-3
ESA-1
FY-1

HTAPE-2

LT~3

MOP~1

PLCH-1

PMOD- 1

PSCS-1

PVM- 3

PYMT-1

SHARE-1I

SUMFS~1I

SUMINI-1

TCAM-1

XDS-}

- 143 -

AA=40

Preliminary Planning Outline for a 370/158 Facility (Jamtgaard)
NOV 6, 1972

Papers Written by ACMY Usera (Baxter)

JAN 10, 1973

A Summary of the ACME Syatem (Wiederhold)

Speech given at Argonne National Laboratory.

OCT 31, 1966

A Summary of the ACME System (Wiederhold)

NOV 11, 1966

New Environments for Statistics (Wiederhold)

JUL 24, 1970

Square Computera in Round Sieves - An Approach to Determining the
Suitability of Computing Alternatives - Minis, Maxis, Shared - For
Various Problems (Gio Wiederhold)

Position Paper for the Second Annual Communications Conference at
California State University at San Jose, Jan. 24-25, 1973

NOV 15, 1972

Instrumentation tn a Time-shared Environment (Reynolds)

APR 1970

Comparison of ACME and Three LBM Time-Sharing Systema (Frey)

JUL 12, 1972

Tymshare Network Feasibility (Stainton)

JAN 22, 1973

Visitor's Information Sheet (Germano)

JAN 15, 1973

An Assesement of Current Developments in Computer Technology and Their
Significance for Development at the Stanford Medical Center (Wiederhold)
MAY 1, 1972

Beyond Lisp (Wiederhold)

MAR 29, 1972

The Use of a General-Purpose Time~Shared Computer in Physiology
Research (Dong/Wiederhold)

Presented at National Heart and Lung Institute's Conf. on Resch. Animale,
WoC, Jan. 72.

JUN 30, 1972

Interactive Use of a Timesharing System for Medical Laboratory
Support (Crouse/Wiederhold)

JAN 4, 1970

Sharing Patient Data Files (Wiederhold)
OCT 16, 1972

Consulting Schedule (Germano)

OCT 16, 1972

Programs Available on Campus (Liere)

OCT 17, 1969

Statistical Programs and Subroutines Available at ACME (Whitner)
OCT 30, 1970

The ACME File System (Miller)

FEB 27, 1969

Choice of Tape Units on 360/370 Equipment (IBM) (Wiederhold/Stainton)
Medical Center Computer Facility Planning Note

JAN 5, 1973

List of Other Installations Doing Relevant Work (Wiederhold)
SEP 10, 1968

Comment on Medical Applications Oriented Preliminary Data Base
Programs (Weyl)

AUG 25, 1972

A Choice of Language to Support Medical Research (Wiederhold)
Position paper for a panel discussion on "Computer Language for
Medicine,” to be held at the 1972 ACM Conference, Boston

MAR 6, 1972

Need for a Medical Applications Oriented Data Base Protocol and
Support Facility (Weyl)

JUL 6, 1972

Proposal for Small Computer Service by ACME (Stainton)

MAR 21, 197?

Paging Rates for a Joint Stanford Computing Facility (Wiederhold)
Medical Center Computer Facility Planning Note

DEC 19, 1972

Remarks on Paging Reference Diatribtuion (Rindfleisch/Wiederhold)
JAN 15, 1973

Trip Report - SHARE Interim Meeting, Dec. 3~6, 1972 (Frey)
Medical Center Computer Facility Planning Note

DEC 20, 1972

Specification of FORTRAN String Nandling (G. Wiederhold)
Medical Center Computer Facility Planning Note

SEP 7, 1972

Minicomputer Support at SUMEX (Wiederhold)

Medical Center Computer Facility Planning Note

OCT 10, 1972

Overview of the TCAM System (Stainton)

NOV 17, 1972

Test of ACME FORTRAN Code on XDS Compiler (Jamtgaard)

NOV 9, 1972
AAB-3
AAC~3
AACP-1
AAD-2
AAU71
AAUT2
ACM- 1
ADISK-1

®AFE-13

AORG~3

APAGE-1

APAGEX- 1

ARATE-1

AU-31

YPRANL- 1

ADD-4
AZ-4
CHANGE-1
co-2

CSMP-1

CSMPI-I
10-2
TOA-2
Rc-1
WAA-1
WWAC~4
WAU-1
weps-1
WCTR-~1
WwSYS-1

XPL-1

- 14h -

AA~40

ADMINISTRATION AND UTILIZATION

ACME Note Index: Update and Listing - Administrative Aide Instructions (Bassett/Baxter)

JUL 17, 1972

ACME User Accounting - Adminstrative Aide Instructions -- Update & Listing (C. Miller/Baxter)

JUL 17, 1972

ACME Accounting Programe at Campua Facility (Baxter)

NOV 15, 1972

APUB -~ Update & Listing (Baxter)

JUL 10, 1972

Annual Dollar Usage At ACME (C. Miller)

SEP 13, 1971

Annual Income by Category (Baxter)

AUG 4, 1972

Summary of Campus/ACME Merger Study (Jamtgaard)

NOV 30, 1971

ACME Disk Write Times (Germano)

NOV 22, 1972

IBM Field Engineering (F.E.), Data Processing (D.P.) and Office
Products (0.P.) Divisions (Lang)

APR 27, 1973

ACME Organization Chart (Baxter)

OCT 27, 1972

ACME Service Rates (Jamtgaard)

one page

APR 16, 1972

Description of ACME Service Rates (Jamtgaard)

four pages

APR 13, 1972

Revised Rate Structure for ACME Facility Services (Jamtgaard)

submitted to NIH, nine pages

APR 16, 1972

Monthly Usage at ACME (Class/Baxter)

FEB 22, 1973

Distribution of Print Job Lengthe (Germano)

NOV 10, 1972

SYSTEM INFORMATION

GENERAL

Useful Additions to the ACME Software (Wiederhold)
SEP 19, 1972
Current Size of ACME (Wiederhold/Frey)

JUN 7, 1971

Change(s) to the ACME System (S. Miller)

JUL 27, 1971

Configuration Changes at ACME and Their Effects (Wiederhold)
JUN 3, 1969

Design Considerations for a Digital Analog Simulator on ACME
(Hjelmeland)

oct 15, 1971

Interactive Continuous System Modeling Program (J. Hu)

APR 16, 1972

Text of Proposed I/O Supervisor (Sturgis/Miller)

JUN 30, 1966

CPU Allocation while Processing I/O (Miller/Wiederhold)

AUG 25, 1966

Control Language for an Interactive Computing System (Wiederhold)
MAY 23, 1966

Writeup Conventions (Wiederhold/Cummins)

JUL 28, 1966

ACME Routines: Listing and Description (Frey/Miller)

MAR 15, 1973

AUSCA--An Almost Universal Small Computer Assembler (de la Roca)
JUN 30, 1969

SYS/360 Standard Inatruction Set Sorted on Machine Code (Miller)
MAR 20, 1970

ACME System Core Timing Results (AMPEX va. IBM) (Frey)
NOV 29, 1971

ACME System Analysis--BCU (Smith)

JUN 4, 1969

Inferred Syntax and Semantics of PL/S (Wiederhold/Ehrman)
OCT 15, 1971
DEC~1
DP-1

FST-2
GLC-2
GLN-3

KO-8

NB~4

NC-8

NP-5
NS-3
NT-10
ONA~4
ONB~-2
00-2
PK~1
Pe-1
PPA-1
PR-10
PSs-1
PwW-10
REG-4

RSY~1

TuU-1
VP-2
VR-1
WADR-2
WASM-3
WATB~2
WCL-11
WCM-2
wcsq-3
WD-12

WDA-2

- 145 -

COMPILER AND iANGUAGE

Decimal Arithmetic in ACME (Wiederhold)

FEB 14, 1972

Proposal for Decimal Arithmetic in ACME (Wiederhold)

FEB 14, 1972

Input/Output Statement Types (Wiederhold/Frey)

OCT 20, 1968

Line Number Conversions (Wiederhold)

SEP 7, 1968

Line-Number Entries in Symbol Table (Sreitbard/Granieri)
AUG !6, 1968

Type Table for Operators (Breitbard)

MAY 19, 1969

Fdit Commands (Berman)

NOV 18, 1971

Execution Time Parameter Checking (Liere/Miller)

JUN 11, 1970

Character String Storage Organization and Handling (Breitbard/Wiederhold)
NOV 12, 1971

Array Descriptors in PL/ACME (Breitbard/Granieri)

AUG 18, 1968

Internal Procedures with Parameters (Breitbard)

JUN 24, 1968

Sequence of Processes for an Input Line (Wiederhold/Berman)
JAN 14, 1972

Symbol Table in PL/ACME (Wiederhold/Liere)

AUG 18, 1970

System-Defined ON Conditions (Feinberg)

JUN 26, 1969

Systems Execution of ON-Conditions (Feinberg)

JAN 10, 1968

Staff Guidelines for System Errors (Wiederhold)

MAY 19, 1970

Filing and Linking of Statements (Breitbard/Wiederhold)
MAY 1, 1967

LISP Under ACME (Berns)

JAN 6, 1971

ACME/LISP Internal Documentation (Berna)

JUL 14, 1971

Prologue (Granteri/Wiederhold)

NOV 12, 1971

Proposed PL/ACME Specifications-~Arrays and Parameters (Moore/Breitbard)
APR 14, 1966

Switches (Granieri/Wiederhold/Berman)

NOV 23, 1971

Register Usage (Liere)

APR 23, 1970

Proposal to Allow Release of Symbol-Table pages in Production Jobs
(Wiederhold)

NOV 23, 1971

The Inetruction GET SHARED (Granieri)

SEP 9, 1968

Code for PROCEDURE Statement (Wiederhold/Graniert)

SEP 12, 1969

Code for Restarting (Wiederhold)

SEP 3, 1968

PL/ACME Addresses (Breitbard/Wiederhold)

APR 7, 1969

ACME Assembler (Breitbard)

AUG 25, 1972

Adding Instructions to the Assembler (Breitbard)

OCT 31, 1968

CLASS{fication of Keywords in PL/ACME (Breitbard)

JUN 28, 1969

ACME Compiler COMMON Blocks (Feinberg)

JUL 23, 1970

Calling Sequences in PL/ACME and User-Written Functions (Breitbard/Granieri)
AUG 19, 1969

System Debugging Routines (Miller/Liere)

DEC 28, 1970

Dynamic Arrays -- Current Implementation and Notes (Wiederhold/Ss.
Miller)

SEP 13, 1971

PL/ACME Words and Built-In Subroutines (V. Wiederhold/G. Sanders)
DEC 1, 1972

ACME Error Dictionary - Part 1 (1-199) (Liere)

APR 20, 1970

ACME Error Dictionary ~ Part 2 (401-599) (Liere)

APR 17, 1970

ACME Subroutine FAULT: Error Handling within the ACME System (Liere)
APR 22, 1970

Subroutines for Compiling Input/Output Calls (Wiederhold)
MAR 27, 1970

ACME Subroutine PICK (Wiederhold/Berman)
~ 1h6 -

JAN 11, 1972

WPK-3 Character String Expanding, Condensing, and Moving Routines
for the Compiler (Wiederhold)
MAR 6, 1968

WSB-3 Adding Library Subroutines to PL/ACME (Liere/Miller)
JUN 11, 1970

WSF-4 ACME System Functions (Feinberg)
JUL 10, 1969

WSY-2 Symbol Table, Program and Data Routinea (Breitbard)
OCT 23, 1968

WIs-1 Assembly Language Character String Routines (Sanders)
APR 9, 1968

WUT-6 Assembly Language Utility Program (Miller/Liere)
FEB 27, 1969

*Z1800-1 1800 Flow Charts (Hundley)
MAR 20, 1973

ZA~t WRITE Flowchart (Wiederhold)
JAN 10, 1968

ZAR-1 Flowchart of ARITH and ADVNCE (Wiederhold)
SEP 21, 1970

26-2 GET Flowchart (Wiederhold)
AUG 13, 1970

ZL~1 LIST Flowchart (Wiederhold)
JUL 3, 1969

ZM-1 Flow Chart for ACME System Program MODIFY (Berman)
JAN 10, 1972

ZP-1 PROGRAM Flowchart (Wiederhold)
JAN 12, 1968

ZPICK-2 PICK Flowchart and Tables (Berman)
JAN 10, 1972

Z2PL-1 PL/ACME Flowchart (Wiederhold)
JUN 4, 1969

ZR-1 READ Flowchart (Wiederhold)
JAN 12, 1968
EXECUTOR

AY-1 Multi-Programming with PL/ACME (Cummins)
APR 7, 1967

CTP-1 Communication Port/Terminal Protection (Wiederhold)
MAR 6, 1972

MA~4 Memory Allocation in ACME (Breitbard/Wiederhold)
DEC 12, 1972

MO-1 ACME System Flow Diagram--General Flow of Time-Sharing Monitor (Wiederhold)
JAN 26, 1966

*OI-2 Attention Interrupt Routines (Sanders/Stainton)
APR 30, 1973

ST-3 User Status Array (Breitbard/Wiederhold)
AUG 2, 1968

WIUMP-13 Temporary Working Storage Function Table (Granieri/Wiederhold)
FEB 28, 1973

WYD-5 ACME Subroutine YIELD to Conmmutator: Subroutine YSET - set ENTRY2
(Frey /Graniert)
OCT 24, 1972

ZYL-1 Flow of Light Logic in YIELD (Wiederhold)

DEC 15, 1971

AA-hO
- 147 -

LNPUT/OUTPUT

TERMINALS AND DISPLAYS

H120CH~-1

U30CH-1

KA-5

KASCI1~2

KB-4

KCT-4

KE-7

KOM-1

PA-2

USP-1

WDERM-1

W1M~3

WKT-8

CRASH-1

FA-9

FB-6

FBS~1

*ECH4

FOCP-1

FPKR-2

FRM~1.

FSEC-I

FSTAT-1t

FTR-2

FUTLL-2

Telephone Line Communications for Terminals at Speeds of 60 and 120
Characters/Second (Stainton)
SUL 3, 1972

Telephone Line Communications for Terminals at Speeds of up to 30
Characters/Second (Stainton)

JAN 29, 1973

2741 Transmisaion Code (Cummina/Wiederhold)

DEC 5, 1970

ACME Use of the ASCII Character Set (Stainton)

JAN 29, 1973

2741 Typewriter Keyboard (Breitbard)

JUN 15, 1989

Terminal Conversion Tables (Stainton)

JAN 9, 1973

ERCDIC Codes for Full Character Set (Wiederhold)
JAN 12, 1973

Communication Nevelopment (Wiederhold)

JAN 4, 1972

Response to 2741 Attention Key (Wiederhold/Cummins)
AUG 2, 1966

Data Handling Capabilities on the ACME System (Feigenbaum)
NOV 17, 1964

Termtnal In and Qutput for 3270 Displays (Wiederhold)
DEC 30, 1971

Internal Subroutine IMAGE (Wiederhold)

OCT 24, 1969

TRMNLIO: Terminal Input/Output (Stainton)

DEC 19, 1972
FILES

Recovery from Disk Fallures (Frey)

SEP 24, 1971

ACME, File System--Data Sets (Frey)

NOV 22, 1972

ACM. File System--Contro] Block Formats (Frey)

JUN 19, 1972

Proposal to Kewrite the ACME File System (Sanders)
MAR 22, 1968

ACMI: File System--Codes (Frey)

APR 8, 1973

File Utility Program PDUMP (Frey)

NOV 19, 1969

User Tapes Dump and Reatore (Frey)

SEP 16, 1971

ACME File: Input/Output (Girard{)

MAY 8, 1969

File System Logical Flow--Text Files Processing (Frey)
MAY 5, 1973

File System Logical Flow--Miacellaneous Functions (Frey/Graniert)
APR 27, 197)

File Syscem Logical Flow--Data Files Processing and Index
Manipulation (Frey/Lew)

JUN 29, 1971

Opening or Closing a User Disk Pack (Frey)

OCT 18, 1972

Restoring Blocks Onto Disk From Tape (Lew)

FEB 29, 1972

File Utility Restore and Move Programs (Frey)

JAN 12, 1972

File Security (G, Wiederhold)

FEB 25, 1971

File System Statistical Summary (J. Hu)

AUG 9, 1971

ACME/OS Files Conversion (Frey)

OCT 4, 1972

File System Utility Library (Frey)

OCT 18, 1972

File Addressing (Frey)

FV-4
FW~3
PB-4
PE-3

PEFF-1

*®WCOMPRS-

WDDT-2
WFC-2
WFEM--3
WFL~-2

WFR-2

RPDPI-1
UART-~5
UD-5
UPDP-1

UPRO-1

UvDs-1
WEXC-2
WPDP-1
WPDPA-1
WPDPC-1

WID-1

CL=-2
CN-6
cQ-3

FLX-1

HAF-1

HAG-1

- 148 -

OCT 18, 1972
Input/Output Routines Called by User's Code (Miller/Frey)
OCT 21, 1968
File Utility Program SPACE (Girardi/Frey)
MAY 26, 1971
File Utility Program ANALYZER (Girardi /Frey)
MAY 27, 1971
Proposal to Aid in More Efficient Usage of Disk (Wiederhold)
DEC 30, 1971
2Data File Compression - Implementation Notes (Granieri)
APR 27, 1973
DDT Utility Routine (Wiederhold/Frey)
MAY 26, 1971
File System Calling Sequences (Frey)
MAR 31, 1969
File System Error Meseages (Girardi/Frey)
OCT 10, 1969
File Syatem Routine Linkage (Frey)
OCT 17, 1969
Returning Control After I/O (Girardi)
FEB 27, 1969

REAL-TIME

PDP-11 Inventory (Lew)

MAR 20, 1973

Access to Real-Time Directory Entries (Frey/Breverman)

OCT 20, 1972

1800 Users--Time Sharing System (Crouse)

NOV 3, 1969

PDP-11 Hanging the 360 Channel (Brigga)

MAR 1, 1972

Procedure for Assembling a Program for the 1800 with the 360 Batch
Assembler (Hundley)

DEC 15, 1972

1800 Voltage and Digital Scales (Crouse)

AUG 21, 1968

ACME Dummy Appendages for EXCP 1/0 (Sanders/Stainton)

FEB 22, 1973

Disk Monitor for the PDP-11 (Brigge)

JUN 21, 1971

Index for PDP-11 Software Binder in the Computer Room (Briggs)
AUG 9, 1971

Disk Monitor Utility Program for the PDP-11 (Briggs)

AUG 16, 1971

Program to Create Temporary Directory for Real-Time Files (Cummins)
APR 3, 1968

HARDWARE

Interrupt Level Status Words for 1800 (Miller)

AUG 26, 1966

Configuration of Machine (Wiederhold)

JUN 6, 1972

1800 Configuration (Wiederhold)

SEP 19, 1969

Specifications of 270X Data Adapter Unit and 270Y Remote
Experimental Terminals (Sederholm)

AUG 1, 1967

MPX/User Simulator (Matheson)

Engineering Note 060

SEP 11, 1972

IBM 2701 Parallel Data Adapter Simulator (Matheson)
Engineering Note 061

SEP 18, 1972

AA-hO
HAT-1
HB-]
HC-1
HD-1
HDC-2
HDEMO- 1
HDIG-1
HDR-1
HEA-1
HGI-1
HGL~2
HHOG—1
HK-1

HKR~ 1

HLB~1
HMPI-1

HPDA-1

HPDP li~1

HPWR-1

HQ-2
HK-1

HRA-1

HRB-1

HRI-1

HRU- 1

HRUST=1

nSC- 1

RSCC-1
HSW-3

HSWA-1
HSWB-1
HSWC-1
HSWD-1
HSWE~1
HI-2

*HTEXT-1

RVB-1

- 149 -

Analog Transmission at ACME (Direct Line) (Holtz)

APR 9, 1968

Level Shifter (Bridges)

JUN 26, 1967

16-Channel, 8-Bit Synchronous A~to-D Converter (Flexer)
AUG 30, 1967

ACME Digital Display--Engineering Description (Flexer)
AUG 24, 1967

2702-2741 Direct Connection (Cummins)

NOV 21, 1966

Plotter Demo fur Dean's Conference Room and M112 (Cower)
JUN 11, 1970

Digital Test Box (Holtz/Osborne)

JUL 18, 1968

Proposal for a Standardized Demand-Response Interface (Cummins)
FEB 26, 1970

1800 Error Alarm (Osborne)

JUL 15, 1968

Replacement of the 270X% and 270Y (Stubbs)

DEC 8, 1970

Genetica Lab Connection in Room S007 (Osborne)

JUN 9, 1969

Cable Voltage Levels for the Sanders (Cower)

JUL 9, 1971

High-Speed Serial Digital Transmission (Flexer)

AUG 23, 1967

4 Bit Digital Sequence Controller, Serializer, and Tone Generator
(Osborne)

MAR 24, 1970

LINDA: The 1800 Baby Sitter (Osborne)

MAR 24, 1970

Manual Process Interrupts to the 1800 (Flexer)

AUG 24, 1967

2701 PDA to External Device Interface (Stainton)

SLAC TM#2
MAY 31, 1968
PDP-I! to 360 Connection (Van der Lane/Osborne)

FEB 23, 197)

A Proposed Method of Pretecting Computing Machinery from Power Surgea
(Hund Ley)

JAN 31, 1972

ACME Powcr Supplies (Holtz/Curtis)

APR 9, 1969

Five Integrated Ciccuilt Printed Cards (Flexer)

AUG 3), 1967

6-Bit Fuil Addex Printed Circuit Card, Models 3 and 4 with Three Dual
In-Lines per Rit (Flexer)

AUG 21, 1967

20-Bit Buffered Register, Model 2. Printed Circuit Card. Using
Motorola Dual In-Linas (Flexer)

AUG 21,1967

12-Bit 28 Complement, Inverter Printed Circuit Card (Flexer)
AUG 18, 1967

1800 Real~Time Clock (Flexer)

AUG 28, 1967

6-Blt Loadable, Synchronous, Up-Down Counter Printed Circuit
Card, Model 2 (Flexer)

AUG 21, 1967

COMPLOT Interface (Arndt)

Engineering Note #037

DEC 29, 1970

Sampling Ctock (ioltz/Larned)

MAY 5, 1967

Computation Center Lightbox (Holtz/Oaborne)

APR 7, 1969

ACME Switchboard (Holtz/Curtis)

APR 21, 1959

2741 Data Plug Installation (Wiley)

DEC 27, 1967

Cable Snterconnecting Box--Room S101 (Wiley)

DEC 27, 1967

Checkout for 2741 Terminal Installation (Wiley)

BEC 27, 1967

Tool Inventory--Technician's Box (Wiley)

DEC 27, 1967

User Interfacing Units-~-Room S101 Cabinet (Curtis)

FEB 2, 1968

IBM 1890 Input/Output Terminals (Holtz)

MAY 7, 1909

Termfiual Extension Cable (Stainton)

MAR 5S, 1973

Analog Transmission by Frequency Modulation (Holtz)

NOV 27, 1968

AA-4O
HWEA~1

HXxXU~1
HZ-1
KW-1

LIDANS-1

LIDL-1

LIDS-1

LK-1
OT-1

YTNM-2

- 150 -

AA-b
Summary of Western Electric (Telephone Company) Analog Modems
(Stainton)
JAN 17, 1972
Interface Between a PDP-8 and an IBM 1800 (Holtz)
MAR 28, 1969

Biochemistry Lab Connection--Stryer (Holtz/Curtis)

NOV 24, 1967

A Warning About IOHALT and the 2702 (Cummins)

JUL 10, 1968

Lightbox for Installation on Terminals Using ANSI Conventions
(Stainton)

SEP ll, 1972

IBM 2741 Lightbox for Installation on Terminals Using Direct-Line
Connection (Holtz)

NOV 27, 1968

IBM 2741 Lightbox for Installation on Terminals Using a Data
Set Connection (Holtz)

NOV 21, 1968

Proposal for the ACME/Campus Link (Girardi)

NOV 13, 1970

08/360 Timing for Large-Capacity Storage (Miller)

MAY 9, 1967

Loading Printer Buffer with TNMD (Emerson/Frey)

AUG 28, 1970

OPERATING SYSTEM

AUC-6
BUGS-1!
CAB-3

*CHGAVT-2

cP~5
*CT-21
DA-10
DG-5
EFAP~1
KD-2
*OA-9
OB-2
ODEB-2

OEX-1

OFA~1
OL-7
OM=4
ON-1
OR~15

OSAPP-1

OSF-2

OSM-3

360/50 Crash Frequency Chart (Class)

DEC 14, 1972

ACME System Problema (Miller/Wiederhold)
JUL 13, 1970

User Hardware Installations -- ACME Connected (Class)
JAN 4, 1973
Change OS Appendage Vector Table (Stainton)
SLAC TM#46
APR 18, 1973

ACME Catalogued Procedures (Frey)

AUG 10, 1970

ACME Terminal Listing (Claes)

MAR 16, 1973

Device Addresses (Miller/Granieri)

JAN 15, 1973

Device Names (Smith)

FEB 17, 1969

Temporary PRINOPUN Modification (Bassett)

MAY 22, 1972

Card Punch to Hexadecimal Conversion (Wiederhold)
SEP 9, 1968

Contents of ACME's 3M Disk Packs (Frey)

APR 23, 1973

08/360 System Generation (Glanckopf/Allen)

APR 11, 1968

Multiple Extent DEB Builder (Sanders)

MAR 1, 1972

08/360 FORTRAN H Version II (Release 14) Changes in Passing
Names (Glanckopf)

APR 16, 1968

Additional FORTRAN Language Facilities (Miller)

OCT 11, 1968

Loading ACME, ACME29, and ACMEO2 Systeme (Class/Granieri/Sutter)
FEB 19, 1971

ACME System Modules (Frey)

DEC 31, 1969

System Component Naming Conventions--05/360 (Allen)
NOT DATED

Procedure for Writing File Restore Tapes (Class)
NOV 29, 1972

Notes on OS Appendages (Stainton)

SLAC TM#3

JUN 8, 1970

APAR Submission for OS Component Problems (Glanckopf)
JUL 30, 1968

ACME Modifications to 08/360 (MVT) (Frey)

DEC 19, 1972