TNTRODUCT ION ACME, Advanced Computer for MEdical Research, is appreaching the end of it's fifth year as 4 research and development facility. This report describes the accomplishments of the first nine months of the current fiscal year which ends July 31, 1971, and plans for FY1972. We find that we are starting a period of transition for two reasons. ACME was designed as a research support facility but now faces the task of reconciling the needs of computer science oriented research and pub- lic utility type timesharing services. During the coming year we must move toward supporting cne cf these funecticns on alternate hardware. In addition, ACME started to charge fee-for-services in March, 1969. We do not expect the user community tc have adequate financial support to pay ACME's full costs by the end of FY1972. Therefore we are re- questing a 15-month extension to the grant pericd tc complete this critical period of transition. More development tasks have been iden- tified for FyYl972 than can be accomplished by existing staff and budget. A condensed list of tasks will be made in three tc four months, We hope that ACME and N.I.H. can reach an agreement on the retention of income for use at Stanford by that time. J. SUMMARY A. Fiscal Year 1971 - In Retrospect 1. ACME System The past year has been a very successful one in terms of improving gen- eral service levels for users of the ACME computing service. Our macor accomplishments were in these areas: improved reliability long record handling implementation of LISP small machine support One of our basic goals was to improve hardware reliability. The mean- time between failures for hardware increased by a factor of 4 in FYLO71. The mean-time between failures for all unscheduled downtime increased by a factor of 2.5. Another highlight of the year has been the announcement to users of new small machine assemblers. There are now over 0 small machine systems in the Stanford University Medical School. Most of these systems are Digital Equipment Corporation machines. The macro assemblers now handle PDP-&8, PDP-11, and LINK Computers. The extension of the file system to handle long records was a maicr ac- complishment. Historically, ACME has had a fixed block length cf 1968 bytes per record. With the new file system, records are spanned sc that the new maximum record length is 65,535 bytes. Another milestone has been the implementation of a LISP interpreter and LISP compiler under ACME. The ACME systems staff also implemented a powerful graphics support pack- age, an overlay system for various statistical subroutines to reduce the amount of core required by the system, and made many modifications to the communications software. 2. User Projects Significant progress was made on the Drug Interaction Program being de- Signed and developed to provide warnings to physicians whenever a pres- eription is likely to interact adversely with an earlier prescription given to a patient. I. SUMMARY A Clinical Laboratory Information System has gone through the development stage and is now ready for implementation. The DENDRAL research project staff became familiar with ACME and started to use the new LISP compiler under ACME. DENDRAL refers to the program which infers a structural hy- pothesis from mass spectral data. We made some progress in shifting users to a paying basis for ACME ser- vices. B. Fiscal Year 197é - Looking Ahead 1. ACME System Our major commitments are to maintain at least our present service levels and tc move toward generating added revenue. We are investigating three paths which will improve service and reduce our operating expenses. @ Retain stand-alone Medical School System. ® Move non-realtime computing to 360/67 and build front-end system for realtime users. ® Share facilities with the Hospital ADP Group. The ACME staff is especially interested in providing additional suppert to small machine users throughout the medical community. The Stanferd Medical School contains many small machines and the users cf these de- vices have repeatedly expressed interest in more and better support for them. We also understand that the Biotechnology Resources Branch is in- terested in computer to computer communications networks. During the balance of this grant period, we will continue to improve the reliability of the existing system. ACME has been charging fee-for-service since March 1969. There has been little incentive to increase revenues since every dollar received in income reduces the grant by a comparable amcunt. In the coming year we will ask that income derived from fee-for-service be retained at Stanford to support biomedical computing activities, part- icularly extensions to ACME's core research activities. 2. User Projects During fiscal year 1972, ACME will support: DENDRAL Drug Interaction Program Clinical Laboratory Instrumentation Other applications (3) IT. SUMMARY Other applications will be considered as opportunities arise. Charging rates for ACME services will be increased at varying intervals over the next two years. The goal of these changes is tc eliminate the subsidy in the present rate structure so that ACME users will pay full cost recovery for the services received. In addition, a Cardiac Care Unit Monitoring System will be started if ACME's income can be used to support expanded core research activities. C. Request for Grant Extension In March 1969, ACME started tc charge fee-for-service to the users. “We hoped that by the end of the current three year grant neriod, ACME user income plus charges to ACME ccre research projects Sor computing service would equal total ACME cperations ccst. A 15 month extension is needed for two reasons: (1) ACME users need more time to obtain computing dollars in their budgets: and (2) the transition tc alternate hardware requires more than the one year remaining in the existing grant. D. Overview of Five-Year ACME Experiment In 1966, ACME received a three-year grant from the Biotechnology Res Branch from NIH (then called the Special Research Resources Branch). two goals were: oO WUC m ® Development of an on-line realtime data collection and control system. ® Development of a PL/ACME compiler that could be learned and used conveniently by medical staff. In 1966 we decided that one large central resource could fill those re- quirements more effectively than multiple smaller systems in each cf the laboratories. The experiment has been a great success. The PL/ACME compiler can indeed be learned and used very easily by the medical staff. it was the first known demonstration of an incremental compiler. The outcome with respect to the realtime data collection user has nct been similarly successful. ACME found that medical users require an extremely high degree of reliability which was most difficult to achieve with the large computing systems of the 1960's. Therefore, many users have acauired small machines which are capable of achieving very high reliability and can be dedicated to a single purpose. The econcmics of small machines locked far different back in 1965 when the ACME propesal was written. The rate of change in this field has been truly dramatic. Design of a realtime data collection system for today's envirorment might well involve a nimber I. SUMMARY of smaller processor's as dedicated systems, some of which need to be hooked to larger systems. Computing problems requiring many cycles but minimal core and other hardware, can best be handled by the mini or midi systems. However, the small computers are proving inadequate for a small subset of user programs, are becoming more complex, and need big machines. The next step entails a marriage of the small machine systems which have been developed in the early 1970's with new communications technology as well as more stable and reliable larger systems. ACME is proud of what it has accomplished and has demonstrated an ability to cope with realtime data collection problems. ACM# is nearing comple- tion of the second year of a three year renewal grant. “The primary problem addressed in the proposal for this renewal period was to make the ACME system more reliable. Although much has been accomplished to achieve this goal, limitations of system 360 hardware, complex software developed locally, and reliability requirements imposed by the medical profession indicate needs for future developments in this field. (5) PART IT. ACME FACTLITY DEVELOPMENT TI. ACME FACILITY ACCOMPLISHMENTS - FY1971 A. Software Modifications 1. Improvements in Reliability A primary goal of the ACME staff has been to improve system reliability. The results of our effort may be seen in Table A which shows “ean Tir FYL9/71. During that time MTBF for hardware-caused system failures ard MTBF for all reasons, including hardware increased as follows: MTBF FYL9/O FYLOTL hardware caused 64.3 Lh6.E all reasons 3h 4 4.8 Some of the specific steps taken to accomplish this goal are weekly meetings with IBM systems engineers and customer engineers, impreved standards of cleanliness for the machine room, written procedures for ACME operators, and engineering changes from TBM. One majcr factcr was a system modification which allows concurrent use by systems pre- grammers and users during the evening shift. This gave the systems staff an experimental module without affecting the users. Prior to this, we had to mount new systems before they were completely debugged Since there were very few times when we could dedicate the entire sys- tem to the software staff. 2. Long Length Records File support routines were mofified so that a PL/ACME user can specify a logical record size greater than physical block size. A single READ or WRITE statement can reference up to 65k bytes of data. The size of physical blocks on disk has~been kept at 2000 bytes. 3. LISP Compiler An interpreter and compiler for LISP (List Processing Languages) was added. This in effect gives the ACME system a second language. Te enter LISP mode as opposed tc PL/ACME mode, the user includes a LISP keyword in his PROGRAM statement. LISP was implemented at the reauest of the DENDRAL research group, but may be used by any recognized user. TI. ACME FACILITY ACCOMPLISHMENTS - FYLO?71 4. Small Machine Support Assemblers As we indicated in the Annual Report for last year, ACME implemented a small machine assembler program for PDP-8's and PDP-ll's. This year it became operational and users may now write at an ACME terminal in PDP-8 or PDP-11 operation code. A PL/ ACME program will assemble their code and print back diagnostics. When the program is debugged, a user can load it directly from ACME to the small machine via a 2701 port or a line through the 1800 processor without going through the paper tare or card phase. Communicaticns Package A communications package has been written to handle communications ce- tween the Model 50 and smaller front-end machines such as the 1ESO ari PDP-11. One major change in the communication system was te adart the code in the Mcdel 50 to support the PDP-11l in the same manner as th 1800 is currently supported. Detailed plans have been made te meal the software in the Model 50 to permit non-2741 devices tc log-on te the ACME system via the PDP-11l. At present «ll log-ons must cecur via the TBM 2702 transmission control unit. a 2 L Vv Campus Computer Link A link between ACME's PDP-11 and the Stanford Campus PDP-9 allows ACME users to exchange data with all departments of the University. By the end of the current fiscal year we will complete a project which allows pregrams and data to be transmitted from ACME disk stcrage to Campus disk storage and vice versa. An ACME user will be able to run produc- tion versions of jobs on the Campus 360/67 in batch mode and a user of the Stanford ORVYL system will be able to communicate directly with ACME and transfer data and program files. 5. Other Software Developments Utilization Measurements Several new utilization measurements have been developed. We now know the number of users per half hour interval for weekdays and weekends. Utilization data include the number of users excluding staff, core pages used for various types of use, number of realtime lines open, and max- ima used during each half hour period including the ACME staff users. TT. ACME FACILITY ACCOMPLISHMENTS - FYLO71 Translator A PL/ ACME tO PL/1 program translator was completed. It is primarily in- tended to accommodate ACME users who wish to run producticn programs in batch mode at the Stanford Campus Facility. It also aids those who move to other Universities which support PL/1 patch service but not an inter- active PL language. Compiler Improvement Several incremental compiler changes were implemented. PL/1 type formats were added to the PUT EDIT statement and a STRING opticn added to the GE? and PUT statements. The user now has full capability of the SET and PUT statements and can format character strings. In addition, other significant accomplishments this past year include: ® new public programs added, primarily statistical ® project and data set protection increased by use of keywords @ ACME data set to OS data set conversion ® cverlay of ACME load module ®@ SYSGEN of OS Release 18 ® support of new hardware: Hazeltine Model 2000 and Beehive Model 3 displays Litton Model 30 printer B. Hardware Modifications 1. Improvements in Reliability Barly in ACME's history we vurchased special devices from TBM, identified as a 270X and four 270Y's. These devices were used for medium data rate acquisition for the realtime system. Unfortunately, this hardware never operated reliably and during the past year IBM repurchased it from Stan- ford University. This has been the biggest factor in increasing our hardware reliability. The new PDP-~11 and existing 2701 Data Adapter have veplaced some cof the functions of this hardware. Part of the sale proceeds have been spent tc design and build a special interface between ACME and the mass spectrometer. We have labeled this new device a 270Z interface. 2. Addition of PDP-11 The PDP-11 computing system acquired last summer has been installed and interfaced to the Model 50. At present the PDP-11 is being used te drive alphanumeric displays, a special printer, and a Sanders contrceller. The Sanders controller was originally driven by a 27OY. A PDP-11 disk has TI. ACME FACILITY ACCOMPLISHMENTS - FY1971 been ordered and will be delivered before the end of FYI971. This disk, which has approximately 2.4 megabytes of capacity, will be used fcr the Drug Interaction Program initially. 4. Addition of Displays and Printer We added two Hazeltine Alphanumeric Displays and one Litton Printer for the Drug Interaction Program. The Hazeltines were replaced by Eeehives because of problems experienced with shift keys. If one hit the shift key and an alphanumeric character, a spurious character resulted. Lu. Modification of 1800 Four analog input ports and 8k of core were added to the 1800 processor. The additional core has permitted implementation of a new communications system and allowed users to store data directly on the 1800 disk whether or not the Model 50 was operating. The added analog input ports have in- ereased the number of lines which can be handled simultaneously from lz to 16. 5. Other Hardware Changes 2414 Conversion ACME's 2314s will be converted to 2319s in the near future. This is a field modification which will reduce rent on the units by a few hundcred dollars per month without changing any of the technical characteristics. Loma Linda Graphics Terminals Two of these terminals are to come to Stanford University in the month of May. User Interfaces Over the past year several interfaces between ACME and user realtime in- strumentation have been designed and installed. Among these are inter- faces to gas chromatographs, plotters, XY recorders, and other small machines such as PDP-11 and PDpP-8. C. User Services The goals of the User Services Group of the ACME Project are to: ® offer individual and specialized help to the users ® train the user in the use of the ACME system ® make information about the use of changes to the ACME system readily and easily available (10) TI. ACME FACILITY ACCOMPLISHMENTS - FYLOTL For purposes of discussion, the funetion of the User Services Greup will be divided inte three activities; Consulting, Education and Documentatica. 1. Consulting The consulting staff consists of one part time member and three full time members. One full time member of the consulting group specialized in statistical problems, another in mathematical consulting. The cther full time consultant and the part time consultant are available fcr mcre gen- eral problems. By the end of April, the latter twce consultants will be relocated to an office recently constructed in the ACME machine roo where they will be more accessible to users. All consulting staff members maintain a consulting activity log which allows them to fcllow-up ana te spot problem trends. It is an important source cf inout te the ACE courses, the ACME manual, and the ACME system. 2, Education ACME offers courses in the PL/ ACME programming language and the use of the ACME systex. An introductory course consisting of three 1-1/2 hour s¢essicns is offered twice a month. Last year 189 members of the medical ccrmunity attended these courses. A 4-1/2 hour advanced course for realtime users was offered 3 times last year. The total enrollment was £1. These ccurses have been and will continue to be modified by user needs and problems. Since we now have a LISP compiler, ACME is offering a LISP seminar. This is a 2 hour introduction to some of the fundamental concepts of LISP. as well as a descripticn of applications best suited for LISP. The first such seminar had an enrollment of 26. 4. Documentation NEWS A publicly available program named NEWS is in the ACME system. This gives the user immediate nctice of any changes to the ACME system cr any other items of interest. The user may call this pregram, and by the use cf ap- propriate "keywords" (e.g. PLOTTING), retrieve all information that is of particular interest to him. NewsLetter ACME pulishes a Computing Newsletter on an as needed basis to inform users of: ® new programs and subroutines ® changes in ACME's operating schedule ® ACME course and seminar schedules TI. ACME FACILITY ACCOMPLISHMENTS - FY1971 ® new ACME documents ® changes in staff ® use of computers in medicine PL/ACME Manual The PL/ ACME Manual is a complete reference manual, with a complete def- inition of the PL/ ACME programming language, a detailed explanation cf its usege, and extensive examples. A new 300 page additicn was distri- buted in November, 1970. This year we plan to supplement the Manual with a thirty to forty page Primer. The PL/ACME Primer will teach the basics of the PL/ ACME language using step-by-step lessons with simple examples. Lh. User Tape Service Report Tn May 1969, a tape dumping and restoring service was provided whereby a user could remove files from direct access storage when on-line re- trieval was not required. Later the files may be copied back to disk. Dumping is the process of moving a file from disk to tape; restoring is the inverse. The user always provides his own tape. As of April 20, 1971, 215 individual requests for file dumps had been submitted. The requests came from 69 users; 31 requests from a single user; and 122 requests (57% of the total) from 11 users. 9,300 indi- vidual files have been dumped for a total of 268,150 blocks of 2000 characters. This volume is more than twice our disk capacity. Restore records have been kept since April 1970. 92 requests were sub- mitted for a total of 34,760 blocks covering 1028 files. 25 users have requested the service. One user of the 25 has asked for restores £7 times. TI. ACME FACILITY ACCOMPLISHMENTS - FYLO71L D. ACME Personnel Approximate FTE! Terminated q, Ti CURRENT DIR#CT STAFF At Present During Past Year Principal Investigator Joshua Lederberg, Ph.D. 0 Associate Principal Investigator Edward *eligenbaum, Ph.D. 0 Director Ronald Jamtgaard 1 Assistant Director L. Lee Hundley 1 Consultant to the Director Gio Wiederhold 45 Systems Programmers Robers Berns 1 David Cummins a Russell Briggs 1 David Emerson 4 Regina Frey 1 serge Girardi a Charles Granieri wu Devid Gray ot Ying Lew 1 Cle Osterby 1 Stuart Miller 1 Ken Salisbury i Donald Wilson 1 Applications Programmers Robert Bassett 1 Ray Liere a Linda Crouse 1 Robert Hale a) Gary Sanders 22 Jane Whitner 1 Voy Wiederhold 225 Research Assistants William Berman .5 (plus Computer Science Department related work at ACME) FTE is defined as "full time equivalent”. (13) IT. ACME FACILITY ACCOMPLISHMENTS - FYL9O71 Approximate FTE Terminated % Time weil CURRENT DIRECT STAPF At Present During Past Year AQ AONE Summer Student Help Douglas Brotz Andrew Saal Jot }--! Operations Charles Sandoval James Vantassel Charles Class (Manager) Richard Cower James Matous dames Meek James Rieman Jan Sutter Lee Weatherby Tee Whitely Iain NM HP ENP ee Secretaries and Administrative Aides Madeline Aranda 1 Trammel Lonas i Tucinda Miller 1 2 TOTAL ACME GRANT EFFORT (FTE) 18.20 OTHER PERSONNEL INVOLVED Folicy Committee Members Malcolm Bagshaw, M.D. Robert Baldwin, Ph.D. J. Weldon Bellville, M.D. Syron William Brown, Jr., Ph.d. Howard Cann, M.D. Charles Dickens Avram Goldstein, M.D. ponald Harrison, M.D. Ccurtney Jones Burt Kopeli, M.D, wht tate wt yy ~ elliott Levinthai, Php. ? Hxeludes summer student employees and those terminated during the year May 1, 1970 through April 30, 1971. (14) TI. ACME FACILITY ACCOMPLISHMENT - FY1971 Policy Committee Members Bruce Stocker, M.D. Howard Sussman, M.D. Jobst Von der Groeben, M.D. John L. Wilson, M.D. Business Manager Robert Langle (15) II. ACME FACILITY ACCOMPLISHMENTS - FY1971 E. ACME Organization The principal investigator of ACME has in effect subcontracted to the Stanford Computation Center the tasks of developing, implementing, and operating PL/ACME. With the advice of the ACME Policy Committee, he has directed the research activities and given much policy guidance. Since last September, the acting Director of the Stanford Computation Center (scc} has been Charles Dickens. In addition to ACME, there is 4 Campus Facility and a Stanford Linear Accelerator Facility. The Director of each facility reports to Mr. Dickens. In recent months, SCC has taken steps away from this facility organization toward functional organiza- tion. As a result of this change, ACME systems programmers will be grouped with systems programmers from the Stanford Linear Accelerator Center and Campus Facility. Similarly, operations and user services functions will become functionally organized. We hope that this change will improve service to users. Another group which has worked actively on the ACME project in the past year has been the User Charges Sub-Committee of the ACME Policy Committee. This group reviews requests for subsidized use of the ACME system and sets the Policy guidelines on such matters. (16) TIT. ACME'S FUTURE DIRECTION A. The Transition Problem 1. Statement of the Problem Two factors are forcing us to radically change the ACME Facility. The first is financial and the second is choosing to serve special research versus general computer users. The dollar problem is based upon estimates of income from fee-for-service over the next few years. ACME estimates that income from users will not equal the cost of providing PL/ ACME services over the next two years. JIncome estimates amount to roughly two- thirds of the direct operating costs where such costs are estimated at $650, 000, This level of operating costs includes maintenance and operatin staff but no development work, and is based on rental rates of existing 360/50 hardware. Utilization of ACME is not the problem; ACME's users simply do not have adequate funds in their budgets to permit continuing current usage at full cost recovery rates. If the current level of usage could be maintained while charging competitive service rates, the resul- tant income would exceed costs. roa Cc The second problem involves the dichotomy between computing support for computer science oriented research versus "public utility" computing services for a broad community of users. Initially, ACME was a research facility developing new software and hardware for medical research users. We were successful in fostering a substantial community of users who are dependent upon ACME for stable, reliable services with high availability requirements. The computer-science researcher can no longer obtain the system for 24 hours of continuous use to test new concepts. Service goals have been given higher priority than research goals. This choice was fcs- tered by the N.I.H-request to institute fee-for-service. In order to increase income, services had to become stablized. The problem now is to find a cost effective means of providing PL/ ACME type computing services to a community which has become dependent upon ACME. The current community does not have enough dollars to keep the existing system on a stand-alone basis. Three alternate paths appear to warrant further study: 1. Retain a stand-alone facility, by shifting to a smaller system or finding additional financial support; provide front-end processor for realtime users. tO * Move the time-sharing users to Stanford's 360/67 after mounting an interactive PL-language; fulfill realtime needs on a new front-end processor. 3. Share selected facilities between the Medical School, ACME and the Hospital Data Provessing Group. Note that -aths 1 and 2 both include front-end processors. The front-end system coul:! be duplicated to provide one for normal realtime services and another for dedicated use by various research projects. (17) TTI. ACME’S FUTURE DIRECTION These and other paths will be studied over the next few months. Fart of the investigation will include an analysis of the extent to whicn user files on disk are current and regularly used; what fraction of disk usage represents programs as opposed to data files; and dependence upon PL/ ACHE features. This information will be used to estimate the effort involved in any future conversion. After completing the various studies, we hope to have at least two years in which to design and implement the follow-on system. This assumes N.I.H. will approve the request for extension. A more detailed schedule including target dates for realtime and timesharing substitutes should be available by early Fall, 1971. The intervening studies will also provide answers to such questions as: ® How do service rates compare between ACME and Campus Facilities? ® what hardware alternatives really exist for replacement of the 360/50 in a stand-alone fashion? What changes would be required to mount PL/ACM® on these? ® [f a stand-alone system were added for computer science oriented medical research, what would be the marginal or incremental costs associated with non-realtime users? Could they nelp pay for the facilities without compromising research objectives? ® Should relationships with private companies be considered in which Stanford offers certain software (PL/ ACME) in return for computing services? ® what is the minimum size hardware facility acceptable to large control programs for realtime research (such as DENDRAL) ? ® How will computing networks influence the next generation of computing at Stanford? The above list covers just a few of the questions to be considered by the faculty and Computation Center staff. oO 2. Diseussion of Alternatives to be Explored Three paths have been selected for discussion. Additional alternatives will be added as they arise. a. Path 1: Retain a Stand-Alone Facility in the Medical School The current ACME system is a stand-alone facility in the Medical School. This arrangement could be retained by current hardware or by a shift to (18) TIT. ACME'S SUTURE DIRECTION alternate hardware such as an IBM 370/145. Two advantages of a stand- alone system are more direct control by the medical community and more flexibility to change than a larger service center with several thousand users. Three disadvantages are the relatively high fixed cost, the dichotomy in goals between research and service computing needs, and the jnaability to make convenient use cf all the other computing services available on Campus. *BM has recently announced a 370/145 system which, with 1 million bytes of high-speed core plus comparable amounts of disk storage and peripheral devices, could be rented for about $4,000 less per month than ACM# is paying for the 360/50 system. The primary difference between these two configurations is that the current system has 2 million bytes of bulk eore (8 microsecond) and 128k of 1 micrcesecond core. The 370/245 core would be faster than 1 micresecond. The current ACME system would not work well in the limited amount of core described here. However, it may be feasible to modify the ACME system so that 1 million bytes of nign- speed core of the 370 system could handle the computing requirements of the Medical Center better than the current system. The technical require- ments of shifting to this newer generation of hardware will be reviewed when we study the feasibility of retaining ACM= as a stand-alone Taci_ity. This path will become feasible if users in the STANFORD medical community can identify funding levels and sources adequate to cover the costs of operating a large system. A determination of potential fund availability will be made by late summer, 1971. Two types of operation could result. One is a service center providing time-snaring services with emphasis upon small machine supvort. Another is a research support system designed to support a limited number of research groups working in ccmputer science related areas. The latter mode of operation could entail a relatively large system (370/145, PDP-10, etc.) requiring several research groups in order to provide adequate financing. To date attempts to identify a few (four to six) research groups which might each provide e100, OCO cr more per year for computer service nave proven unfruitful. An estimate of $500, OOO in annual income from service fees for operation as a service facility rather than a research facility appears in Section VI. One question to be resolved is whether additional income might be forthcoming from witnin ACME's user population. b. Path 2: Move Timesharing to 360/67; Add Front-End Processor for Real- time Needs Description of Stanford Campus Facility. Both ACME and Campus Facilities are part of the Stanford Computation Center. The Campus Facility operates a 360/67 with one million bytes of core, and serves approximately 3.000 persons in the Stanford community. It is located about 500 yards from the ACME machine room. The Campus Facility supports approximately 20 languages in batch mode and three languages in timesharing mode. Services offered include a powerlul TIT. ACME'S FUTURE DIRECTION text editor, express batch and production batch services, plotting, remote job entry, and the possibility of handling some special devices with a PDP-9. At this time the Stanford Computation Center is merging toward a functional rather than a facility organization. As a result, ACME systems programmers are now grouped with systems programmers from the Campus Facility and the Stanford Linear Accelerator Center Facility. User services and operations personnel will soon be similarly organized. Sketch of Work Entailed. Considerable study will be required to evaluate the work required to merge the ACME and Campus Facilities. The problem has been reviewed in a cursory fashion with the following results. PL/ACME offers two types of services: the first is timesharing and the second is realtime data collection and control. The realtime data collection and process control functions would be moved to a smaller front-end machine. Current thinking is that the front-end processor would have 75 million bytes of disk storage attached to it and be capable of handling data rates faster than the ACME system now does. The timesharing portion of ACME service would be transferred to ORVYL, the timesharing monitor of the Campus Facility. This would be done by writing a new compiler under ORVYL but several segments of this compiler could prob- ably be copied directly from the current ACME system. An initial review of the task indicates that two to four man-years of effort might be required to mount an interactive PL/1 subset under ORVYL. It is essential that the transition to any alternative system be made with mini- mum changes to ACME users. Some of the options currently being reviewed in- clude the mounting of PL/C, the PL/1 supported under IBM's TSO, or a revised form of PL/ACME. The ability of the ORVYL monitor to handle its present load plus the PL/ACME load is also being studied. At the present time, we can merely indicate that one potential path for ACME's future is to merge with Campus Facility and reduce the fixed cost of a large hardware instal- lation while providing comparable levels of service. Tne realtime data collection and process control front-end machine would be designed for high reliability and availability. [It would serve = number of users and provide access to large disk storage devices o:. ‘¢é central facility. One potential method of fulfilling the needs of e more computer science oriented research groups would be duplicatix. ‘‘e front-end processor. This concept offers the advantages of using software developed for the realtime users, having redundancy in the hardware and software portions of the systems, and providing the exverimental grouns with access to the central facility. This idea also applies to Path 1. TIT. ACME'S FUTURE DIRECTION ec. Path 3: Sharing of Facilities Between ACME and Hospital ADP Group The Stanford Medical Center consists of a Medical School, Hospital, and Clinics. More than half of the house staff of the Stanford Hospital hold faculty appointments within the Stanford Medical School. Many of these same persons provide medical services through the Stanford Outpatient Clinic. The Hospital Administrative Data Processing Group is now operating an IBM Model 40 system and plans to install a Model 4O system sometime soon. Path three calls for sharing computing facilities between ACME and the Hospital Administrative Data Processing Group. Recently, the Hospital and ACME Computing groups prepared a joint report on the feasibility of linking the disk storage of the two systems together. The administration of the Hospital and Medical School are currently consid- ering this report. As the Hospital moves toward terminal-oriented services, an opportunity of sharing communications systems will develop. ‘Similarly, the future sharing of hardware, personnel, training, software systems, and other resources may become desirable and practical. It is premature to indicate the extent and degree cf the future integration of these facilities but additional cooperative ventures may be encouraged by improved definition of ACME's future role in the Stanford Medical Center. From ACME's viewpoint the Hospital ADP Facility will continue to fulfill the non-realtime needs of the administration. Terminal services will be implemented to drive hospital information systems. ACME's role in the hospital, as distinct from the medical school, will be the realtime aspects of intensive care and cardiac care unit monitoring and future areas of physiological monitoring. In addition, ACME will consider the role to be played by small machines in future hospital care and attempt to relate its small machine support to these functions. In additicn, ACME will continue to provide the advantages of convenience, prompt response, numerous and meaningful diagnostic messages, and powerful language attributes to developers of new programs. 3, Goal: Model System for Biomedical Computing Whichever of the paths discussed in the previous section is selected, the future systems should offer the following services. All are technically feasible with the current state of the art. a. Realtime Capability The facility should provide realtime data acquisition for researchers who do not choose to purchase their own mini-computer. At least 16 analog/ digital lines of input or output should be planned initially with a capacity to be expanded to 64 lines. The aggregate data rate should be at least a factor of 10 greater than the existing 1800 system. Individual users have already expressed a need for 40,000 samples per second (one sample is equivalent to 16 bits). Several individual lines should be capable of ACME'S FUTURE DIRECTION H 4 . handling up to 50,000 samples per second. Burst loads of 125,000 samples per second should also be allowed. b. Interactive/Batch Environment Both interactive and production computing are necessary. Interactive computing is desirable in the development and checkout phases of a pro- gram. It is also necessary for certain types of applications where the experimentor requires manipulative access to his data bank over extended periods of time. Other programs, after they have been developed, might execute better in a batch environment. These include statistical analysis and report generation of large quantities of data, Continued on-line com- puting also requires enhancement of the text editing facilities of ACME. ec. Language Considerations The system should be easy to use. Users are specialists in their own fields and should be able to use the computer facilities without becoming expert programmers. The current philosophy of providing a relatively simple computing language and filing capability should be maintained. The Medical Center users currently program in the PL/ ACME language. A well- defined language, perhaps nearly identical to the current language from the user's viewpoint, is required. PL/ACM= is a non-proper subset of FL/1. if it were redefined to more closely resemble a proper subset of PL/1, the researcher could easily specify whether his program should execute in an interactive environment or in production batch under PL/1. The high level language should also be able to vcroduce assembly code for a selected number of computers. Specifically, it should support compilation of assembly code for the user's small machine, d. Small Machine Support Small machine support requires convenient networking capability. Software and hardware must be available for communication between the mini-computer and the central facility. For example, a researcher might want to use his mini's console teletype for requesting services from the central cumputer, The results could be shipped back to the mini and placed on an output device such as a plotter, display, or magnetic tape. A library of software packages for execution in the small machine is desirable. These programs could be written for specific functions such as communication with the central facility and for device handling. Access to the central facility must be on-line and from a number of device types. In addition to the current 2741 typewriter terminals, access should be possible from other devices such as alphanumeric displays and the user's own computer. Thus the concept of networking should be carefully designed and incorporated into the system, (22) TIT. ACME'S FUTURE DIRECTION e. Access to Storage Easy access to a large data base is of paramount importance. Storage capabilities should be at least as large as the current filing capacity (466 million bytes). Concentration on reliability of the files will guarantee that the user's data is secure from destruction. At the same time realtime data acquisition requires a data rate to direct access devices that is double the current rate, i.e., from 10,000 to 20, 000 characters per second. Security of medical data demands that a filing system be reliable and include guarantees against unauthorized access. Software and hardware features are available for access protection and must be included in any redesign. Sinee the cost of fast direct access devices is high, the system should provide a simple vrocedure for removing data to an off-line device such as magnetic tape or tape cassette when it is no longer needed for on-line access and for copying it back to the direct access device. f. Graphics Graphic support must be available through the central processor and the user's mini-computer. Generalized support of a large number of devices does not appear to be required, Rather, specific applications should dictate what graphics support should be included. g. System Measurement No system should be implemented without designed-in measuremeny and evaluation tools. A future system should incorporate evaluation aids for determining such measurements as performance, usage of the various com- ponents, and measurement of user programs. h. User Support The central facility staff should not be isolated from the user's applica- tion. Management and programmers should be actively involved with the users of the system they have provided. Such involvement can include preparing project proposals, selecting and installing hardware, designing the user's program and in some situations, loaning staff for implementa- tion of the user's system. In any case, staff consultation should be readily available for solutions to user problems. i. Reliability and Availability From ACME's experience we find that the user community has extremely high reliability and availability requirements. We see as a possible solution (23) TiI. ACME'S FUTURE DIRECTION a host of small machines dedicated to on-line tasks with a large system providing backup. Because of these requirements we have put such emphasis on small machines in the foregoing discussion. B. Extensions to PL/ACME Services 1. Funding Priority Various extensions and additions to PL/ACME services are listed in the following two sections, Although we would like to do all of them during the coming year, we cannot because of financial limitations. Top priority must go to the aforementioned transition studies and implementation. There- fore, only some of the PL/ACME changes described below will be realized in FYLO7e2. New Services Nn a. Small Machine Equipment Pool ACME proposes to acquire a small machine equipment pool for users through- out the Medical Center. The purpose of the pool would be to let research teams use small machines for limited periods of time. Wherever possible ACME would charge the user an appropriate fee for use of the hardware. Tf the work is closely identified with the core research activities of ACME there would be no charge. The primary assumption behind this request is that a limited number of identical small machines and peripheral units would provide flexibility for various types of experimental set-ups. For example, one experiment may require Lk of core and a small disk unit whereas another experiment could entail 1°k of core and a tape unit. If these units are available within ACME, it may be possible to avoid having sevarate systems for every research group and may promote a far more efficient use of computing hardware. One idea to be explored in this area would be contributions to the equipment pool of small machine systems which are presently being used very little. b. Investigation of National Networks We understand that the Biotechnology Resources Branch is interested in determining the relevance of National Networks of Computers to the Health Care field. The Artificial Intelligence Laboratory at Stanford has participated in such a network. This local experience in the field coupled with the professional staff at ACME puts us in a good position to study the applicability of network computing to medical problems. If N.I.H. is interested in early evaluation of network techniques, Stanford would propose joining a network or establishing a link with a remote university site. The budget request for the coming fiscal year does not include any funds for the kind of hardware presently manufactured by Bolt, Baranek and (24) TIT. ACME'S FUTURE DIRECTION Newman (IMP and TIP). However, the ACME staff will be alert to potential applications that could utilize such a linkage. Jn addition, early in FY1L9O7¢, we will weigh the advantages of being associated with a local or national network if N.I.H. wants to pursue the subject. Comments of the Biotechnology Resources Branch are invited. 3. Extensions to Existing Services a. Support for Small Machines Tneluded in this area are: ® macro-assemblers for small machines other than the PDP-8, PDP-11, and LINK. ® simulator for small machines in ACME. ® utilities for loading small machines connected to the system and handling tape T/0, ete, ® user support: a collection of a small machine code library to be shared by users; documentation on small machine projects; development of standard interface hardware for connecting various small machines to larger systems on Campus. ® study of the feasibility of operating a library of small machines and peripherals. small machine compiler: a small machine compiler should be written in PL/ ACME or some high-level language to permit users to program their small machines in a subset of PL/ ACME. Tt would be desirable to some day incorporate into this compiler a model of the small machine parameters for each user. This would permit the large machine to determine whicn functions would be done in the large machine and which in che small, The large machine would also compile code for the small computer. b. Compiler Improvements Extensions to the PL/ ACME compiler are planned in two specific areas; text editing and information retrieval. Two or three commands, probably "move", "change", and “copy” will be added for text editing. Information Retrieval A limited information retrieval capability will be added. The ACME file system is well organized to accommodate certain information retrieval (25)