a ‘ THE UNIX NEWSLETTER VOLUME 2 NUMBER 9 OCTOBER 1977 Page 1 NOTICE This document may contain information covered by one or more licenses, copy- yights, and non-disclosure agreements. Circulation of this document is restricted to holders of a license for the UNIX or Mini-UNIX software system trom Western Electric. Such license holders may reproduce this document for uses in conformity with the Unix license. All other circulation ot reproduction is prohibited. RUNNING LATE We are still playing "catch-up". This newsletter is being prepared in mid-December and will be mailed before Christmas. The contents reflect the true calendar date, not the nominal month on the mast- head. The next issue, nominally November 1977, will be mailed early in 1978 and will complete this volume. Enclosed with that issue will be an invoice for Volume 3 (1978). SOFTWARE DISTRIBUTION We are well along on the backlog of tape orders. Almost all of une old orders which included a user tape have been mailed. A tem- porary shortage of new tapes due to vendor change has ended, and we should have eliminated the entire backlog by the end of January 1978. a As of now, there has not been sufficient new material submitted to justify a fourth software distribution. NEW TORONTO RELEASE The Toronto release has been recast into standard distribution format and is available as announced in the last issue. You are rem- inded that a new Toronto license must be submitted even if you had a previous license. The form is in the last issue. MEETINGS The minutes of the fall West Coast Meeting are included in this issue. Your attention is called to the announcement, in this issue, of a one day West Coast Meeting in January. USERS GROUP The tnembership in the Users’ Group now exceeds 250. All of the work on the newsletter, the software distribution, the mailing and invoicing is done by contributed time of volunteers. We have reached a size where the answering of telephone inquiries about either sub- scriptions or software severely impacts our ability to do our normal work. We must request that all inquiries about the above items be made in writing to the appropriate address in the box below. MAILING LIST Having discussed the issue of the proper use of the mailing list with several concerned people, we would propose the following “rules", The mailing list is the property of the newsletter and is pro- vided to you for use by your installation in order to encourage the in- terchange of information. The giving of this list to vendors is not in accord with our providing you with the list. Since all of those we spoke with felt they did not object to the receiving mailings from vendors but did object to vendors being given their addresses and telephone numbers, we have established a policy of doing such mailings to the membership for vendors for a nominal charge. If you are approached by vendors, please refer them to Ar- mand Gazes at the address below for details. Your comments upon and objections to this policy are solicited (in writing). “Address editorial material and software submission to Melvin Ferentz clo CUNY/UCC 555 West 57 Street New York, N.Y. 10019 Subscription requests, payments and address changes should be addressed to Armand Gazes Physics Department Brooklyn College Brooklyn, N.Y. 11210 The University of Wollongong ‘Ref. JR:gmge P.O. Box 1144 Telex AA 29022 Wollongong, N.S.W., AUSTRALIA 21st November, 1977 Professor Melvin Ferentz Brooklyn College of CUNY Brooklyn, New York 11210 U.S.A. Dear Professor Ferentz, Could you please enter our subscription to UNIX News. Our Interdata 7/32 UNIX has been running in production since July hence we were quite surprised to read Ken Thompson's letter in the last UNIX Newe concerning the Bell Laboratories version of UNIX for the Interdata 8/32 machine. Since our version of Interdata UNIX suffered vary little from memory requirement increases or performance degradation it seems that it established quite clearly the portability of UNIX vie a “C-machine” Yours sincerely, R. Miller J. Reinfelds. UNIVERSITY OF CALIFORNIA, SANTA BARBARA BLAKELEY © DAVIS + IRVINE * LOG ANCHLES © KIVERRIDE © SAN DIELO 1 HAN FRANCISCO { NTA BARWARA * BANTA CRUZ COMPUTER CENTER SANTA BARBARA, CALIFORNIA 93106 November 15, 1977 Mel Ferentz c/o CUNY/UCC 555 West 57 Street New York, New York 10019 Dear Mel: West Coast Unix users will have a one-day meeting at the Santa Barbara Campus of the University of California on January 20, 1978. The meeting will begin at 8:30 a.m. in the Program Lounge of the University Center. We hope that most Unix folks on the west coast will be able to attend. Sincerely, ko Ron Jeffries Programmer, User Services Computer Center RJ:bd Queers University Kingston, Canada K7L JNO DEPARTMENT OF COMPUTING AND INFORMATION SCIENCE October 6, 1977 Dr. Mel Ferentz Physica Department Brooklyn College Brooklyn, N.Y. U,S.A. Dear Dr. Ferentz: We currently have praliminary drivers for Dz-11 and RK-06. We would be glad to release them to individual sites, but do not want to release them for distribution as thay will be vastly modified soon, The Dz driver does not support modem control. The RK-06 deiver requires disk packs with no bad sectors. (This will be fixed in a subsequent version). Sincerely, Assistant Professor JHK:ap s enn = os Repo tute! chp sed time seco] : TELEPHONE: 0991177 BASSER DEPARTMENT OF COMPUTER SCIENCE School of Physics (Building A28), . ‘ University of Sydney, N.S.¥. 2006 10 November 1977 Professor Melvin Ferentz, C/- cUNY/uCC, 555 West 57 Street, NEW YORK, N.¥. 10019 UNITED STATES OF AMERICA Dear Professor Perentz, At Sydney University UNIX has been running on an 11/40 with great succeas for some time and winning over ‘all‘'. A larger machine to service the teaching/research needs of our Department is now under serious consideration. As a consequence we have been conducting a number of tests on an 11/70 at the University of New South Wales to determine UNIX's ability to handle a large number of student terminals. We hope to convince ... that an 11/70 + UNIX will meet our needs in the best possible way. During these tests we have come across a number of apparent bugs/glitches in UNIX when it is under a heavy load, the main areas affected being file system integrity and scheduling (process hanging). As we really cannot delve deeply into these problems at the present time. I would greatly appreciate it if you could air mail a copy of the “diff listing of changes/bug fixes to UNIX" to me aa soon as possible. This is probably vital to our case for UNIX. Por your information (and possibly others) I include chart of our results to date (a late night session last night!). ! Yours sincerely, (Piers Lauder) ot ao oy SPSTMIAL] socpunyows¢ SJ? TW f (om, 80 veyey + |” aoe voy Odd ga enn Pred my Cf - vopsay loi plat wood wabed my egy - smuyranre 7 + TOM NPD otf ddd pouypueg ux fufor KATHOLIEKE UNIVERSITEIT PACULTEIT DER SOCIALE WETENSCHAPPEN Prof, M, Fer Brooklyn Col Brooklyn MY 11210 USA NUMBGEN, September 6, 1977 ee 5700/GR/wh Dear Professor Ferentz, As you might have noticed, I have switched departments, About 3 months ago, I called you for information about heavy loaded UNIX systems, and fila shipping between - UNIX and IBM 360/370 machines. You directed me to Lev Law at Harvard, and to Chuck Prenner at Berkeley. Prom them, I got very valuable information for a follow-up on my initial proposal, The proposal is still in che mill, and may never get out, but my new department is interested very much in the RJE/file shipping part of my proposal, Therafore, I have included a note to be posted in UNIX News, At the same time I vrote to Rick Haight at Bell Labs, a pointer that I dido't follow at the time I called you, Thanks a lot, Sinceraly, ea George Rolf BRASMUSLAAN 16 NUMEGEN - TELEFOON (80) 31.2633 WIE and fi ipping twa: ugh. Who hae RJE and/or file shipping software batwaen UNIX and IBM OS-MVT/¥YS1/VS2/MVS syatema, A 2780 emulator for UNIX would be great to start with. Please contact: George Rolf Paychological Laboratory Erasmuslaan 16 Nijmegen The Netherlands be QUEEN MARY DEPARTMENT OF COMPUTER SCIENCE AND STATISTICS Pratmeact of Comauing Sconce |i Kiabase Profan of Thecretcel Compascon PJ Lande Professor Melvin Ferentz e/o CUNY /UCC 555 Weat 57 Street New York,M.Y, 10019 Dear Professor Ferentz, We have been succ for over two and a half yi COLLEGE UNIVERSITY OF LONDON MILE ENO ROAD LONDON Et 4NS Tol. 01-080 4015 20th October 1$77 afully running UNIX on a 11/80 a and recently increased the number of mounted filestoras on our system to seven, Since that time following: the proosssor we regularly sxperienosd the would enter the ‘idl routine servioe interrupts but not find any runnsble proseases to execute, Terminals at shell level were able to run shell commands, e.g chdir vithout an argu- ment, wait, ata, but would hang up if any diso access was required. We traced this fault to e deadlock over the blook buffers (our aystee is considerably larger than the one distributed and ve only hava roca for fifteen of th buffers), We originally suspected that deadlock was o0- curing becausa of the fact that four processes could be in 'exeo' simultaneously, however, reducing NEXEC to two did not cure the problem. Further investigation re- vesled that deadlock is possible whenever “NBUF - no. of mounted filestores <= no.of processes. executing 'breada’ simultaneously This is theoretically possible irrespective of the number of buffers and the number of mounted filestores (on the assumption that NBUF - atores < PROCS), ne. of mounted file- QUEEN MARY COLLEGE UNIVERSITY OF LONDON DEPARTMENT OF COMPUTER SCIENCE AMD STATISTICS MILE RND ROAD LONDON Ef 4NS Tot, 01-980 4811 However, systems with # large number of buffera or a mell number of mounted filestores will rarely (if ever) experience this fault. This bug may be easily oursd by not setting off « re head if no free buffers say, the condition in 'breada’ is initiated: if( rablkno && tincora(dey,rablkno) ) [ should be changed to: if{ rablino && linocore(dey,rablkno) &E (bfreelist.av_forw Ix &bfreeliat)){ yours faithfully, Richard Bornat Jon Rowson Ben Salama re available. That ta to under which read-ahead page 1 UNIX USERS*® GROUP Third West Const Meeting The fotlowing is # rough account of the West (Cnast meeting of the UNIX Users’ Sroup. It §s divided into sections roughly corresponding to the mejor topics discussed at the meeting. 1) The west Comst UNIX Users Two committees were estabiished to oversee future eerting oriented toward the west Comst user community. The first is a site selection ateering committee consisting of John Rass. Gerry Yarksdale and Wike O'Brien. The second $8 a topics committee consisting of Mark Kampe and two other peaple LI forget whore un- fortunately -- Edi]. It wes agreed to have roughly three meetings per year. The nest meeting will be at the UC Santa Barbara campus, to be fol- lowed by a» June meeting. Since there is » fairty wide class of known buas and tunian {tems associated with the system (the [U-16 driver as distributed does not work)» ft wes suggested that a new users’ Welcome vagon be instftuteds by having sessions at the meettings oriented to new users In additions ss an aid to Unix systen's progransers who are encountering difficulties with their Unix systeas, certain txperienced meabers of the comaunity have volunteered their ser- vices for BRIEF question-answering. The volunteers for this ser- vice weres John Bass CANS) 5466-4407 < 1Dan, BASSTSRI-KL Mark Kampe (233) B25-4733, MARKIUCLA-SECURITY Lauren weinstein (213) B25-4733- LAURENSUCLA-SECURITY def? Schriebesn (415) 642-1035 These people have varying deqrees of reachability. Kasoe and Senriebman can be quite hard to find. While dt was generally felt that there should be a centrat- fred detsbase of installation descriptionss no one could come up with an immediate schene which would sallow 1) a nicely formatted input document whith could be kept im os databases and ?) a description other than a borinaly detailed cstaiog of hardware configuration which does mot contain # description of the tyor of work being done and software being produceds kernel changes sadder ete. Jia Lieb frow ISI has volunteered sone cyclesr some disk and some of his time to try to make such a database a reality. 2) Accounting Rand's accounting scheme was described, in which separate user directories are charged to different eccount nuabers under ) cm pene 2 the owner. Process accounting is handled by new entries tn the U structure whith are coilected by.an expanded “wait™ system calt. The collection of such date is done by “init” which sanages the accounting file itself. UC Berketey described the “disk quota” system implemented by Ken Thompson during his stay theres wherein new type of inode was created. A file in a directory named “.q" may be crested by the supec-users whose address list does not contain file blocks, but rather s usage count and allowable Limit on blocks im use in that directory and all sub-directories. Every time » block is allocated, the .q entries must be updated ail the way up the tree. ALL 4g) files which are currently applicable to opened directortes are kept around in the in-core inode table. This scheme {3 combined with one wherrin users with group 10's greater than 127 cannot scceas files owned by any other user. 3) Text Processing Rob Lawrence of SRI described the basic capabilities of the Version 7 Phototypesetting patkace in the context of the Fditori- al Processing Center work now being carried on at SRI under the direction of Or. Oliver Whitby. He is interested in discovering whether a systes can be built which could be used by people with Little computer experience to process docunents of a fatrly hioh degree of complexity. berry Garksdale of the Naval Postgraduste School in Monterey described the work being done there in producing documents using @ vide variety of character sets on a Versatec orinter/plotter. Some character sets are based on the Hershey Digitized Character Set while cthees have come from SAIL. Documents are produced by the following sechanise: document -> troff -> virtual typesetting system -> versetec t Ve font files They have an editor for fonts to fix up characters that were sade ugly by the traenalation from a vector list to 6 digitized matrix. So far there is no nice wey to do veriable-width fonts. Current- ly the system runs at 60% of the maxieum hardware speeds usina the Stuultaneous Print/Plot mechanism of the Versatec. PGS fs willing to make its font files available through the UNIX Users” Group Software Distribution Center. 4) Multiprocessing The Naval Postgraduate School is also doing research on aA multiprocessor version of UNIX. They have two 11/50's comauni- cating through shered eemorys and an 11/34 with a Vector General Display also communicating with shared sewory. Their UNIX divid~ ed the texts datas end bss sections of a program tnto three dif- terent maps. The system runs at sbout the same speed as regular page 3 UNIX. with somewhat greater fragmentation of the freetist. They also have a shared-segment UNIX which persits allocation of com mon core to different processes. The entire acheme is designed to allow the allocation of data segaents to particular core areas which are shared with a separate display processor. Swapping stilt sends out all three portions of a program. Swapping poli- cies have not been investigated. The application of this systema is to a signal processing and display systems which is controlled by a fourths special-purpos processor also comaunicating through shared memory. it has a 1é-channal A/® converter and an array processor to handle signal data. The data can either be read by one 1t/50 for use in data reductions or by the other 11/50 for torsating and transeission to the 11/34 for real-time display. 5) Reliability of Files A rather confusing discussion on file system reltability resulted in the conctusions that UNIX needs 2 stand-alone res— toration prograasr since neither ROLLIN mor PRESERVE save the Spare sectors on a disk. versfon 7 has a fair variety of file System improvements. there is a current error worth tooking atz it the section of the system which updates inodes on the disk gets » read error on the block containing the inode it withes to Update, ie will mot check for the error. instead it updates the inode im the bad block and writes the bad block out. This can cause groups of 16 bad inodes all right togethers behavior which has been ooOserved in the past. Berkeley has modified “dump” and “resto3r” to use 8 rather larger record size on outputs which saves tape. UCLA has a utility for dusping the images of multiple disks to a single tape. This requires a suiti-file tape driver which UCLA and other installations nave. They also have a utilftys not untike tpe which has the ability to append tiles to the end of a tepe. There was m brief discussion of bad blockss durring which it wes mentioned that version 7 will cotlect bad blocks into » spe- etal inode (#2) on each file systema. Both John Bass of SKI and the Rand UNIX people will be work= ing on a more general wethad of archiving and backup in the coe- ing siz months or so, to address the problee of saving space and managing the extremely large disk drives now becoming avatlabte. It will combine forced and requested archiving of ald tiles and their deletion and restoration to the file system. It is hoped that these mecnanisas will have @ very sinple user interlace (wherein the user is not responsible for allocating or managing tapes), and that they will be suitable both for use by individual users and for system managers. 6) Secure UNIX page 4 Mark Kempe of UCLA described the work currently being dane on a “data-secure™ unix system being developed by using prograa~ verification techniques. Since these techniques ore stilt in their infancys the relevant portions of code must be smell. Hence, their systes runs avery small kernets with the scheduler and the fite handler running in supervisor and user spaces» and communicating with the kernel through a restricted set of systee calls. Security policy is mot part of the kernels it handles only enforcement. for the sake of verifiabilitys the kernel is non-interruptable. Suptr-user-restricted calls have for the most part been replaced by sore innocuous calle faplomenting the actu- al functions desired, of thrown away entirely in fovor of a dif- ferent protection scheme. Currently the work has variifed substantial portions of the kernels, and a prototype file/policy sanager and scheduler have been written. The prototype fite/policy manager can support a broad range ot policiess but currently only a type of military security rute is enforced. An ARPA Network control pragram to handle multiple levels of secure traffic has been designed and implemented. The work on the operstional prototype is continu- ings inctuding extenstons in functionality and pertoreance optia- ization. Ford Aerospace and TkW are working on secure UNIX projectss attespting to transfer the technology developed st MITRE and UCLA into a production Data Secure Unix system. It fs hupad that the resulting system witl be available to non-doD sites also (the UCLA work will pe in the pubtic domain}. design and developeen snould be done vithin two years. The expected target is the government installation desiring an off-the-shelf, supported, salle secure system. 7) Touch-tane UNIX Lauren Weinstein of UCLA has» in the (ast two monthse given UNIX the ability to communicate over a touch-tone phone in full ASCII, A user with @ touch tone phone can do anything that he could do with a terminal (send and receive nail, edit and compile programs, play games» etc.) A keystroke code has been devined which allows full ASCII to ve generated with fairly intuitive combinations of button presses. & VOTRAX synthesizer sorsks the Output over the chone using a substantially enhanced version of the Bell Labs "speak" program (a rule directed» englith text to phoneme transtator). A device driver was written to. interface to the votrax and a touch-tone modems and a progr was aritten to take the touch tone inputs translate it into ASCII and feed 4 into @ pseudo teletype. Although this project started out large -ly as @ toy, targe numbers of users across the country are stert- ing to express serious interest. 8) kand Software The Rand editor has undergone some faprovement to allow it to exacute external programs for text processing. So far inter- feces to “nroff*, for justificetions and to a program catled page 5 “epi, tor global replocenents have been coapleted. A “messege systea” ts undergoing terting which manages very Ltgh-vwolume maitbores in @ nner efficient to the user. It feats each component of each wesSsage (irom, tor ctr ete.) stparatetys and allows thr user to compose sessoges with arbi- crary cosponents. It manages permanent matlboxes $0 that old aessages may be forwardeds deleted» undeleteds edited (!)s ete. ach Component of @ messuge apy be separately edited. In order ta atlow as such as possible in the way of customt- zation of commands, a tool has heen added to handle the plethora of extra flags such customizations require tor commands. Cailed “sonvtoring"» this is an extra teature residing between the user and his shelis which expands commands tor which it has » profile to include sets of flags. argueents and pre- and post-conmmands specified by the user in nis permanent “profile” for that com- aand. ytring substitution with arbitrary-lenqgth strinus is also available. 9) Odds and Ends being a collection of raw random datas odd thoughts» end conversations that don’t fit in anywhere else. There was a lor of this toward the end of the seeting. A Personal Computer Networks being set up around the Gay Ares by computer hodbyists (including some ARPA peopled, is qoing to have a first protocol ready to try out $n a month or $0. Ini= tially connections will be made via tand-lines going over to ame— teor radio when the FCC uulls its head out of the ground and al~ fovs ASCII on the ham bands. Jeft Rottman at UC-Berkeleys when he was at a school on the fast Coast luntortunately 1 fon't remember which one ~-€d.) made some changes to UNIX to give it a real-tiae capability. Current- ly real-time processes live in Supervisor space and field inter- rupts directly frow the device registers, coapletely outside the rest of UNI, They have nooks into the system so that nor@al UNIX processes way read the data that the Superwisor process has fielded, The normal UNIK processes are locked jn core by @ separate flag from SLOCK, It 1s being conteaplated that the Su- pervisor process might be done away with entirelys depending on what sort of speed is requires. Alan Stoughton at UCLA has a driver tor Dyjkstra semaphorets so that user programs can do real P and V type things. The Ingres group at UCB has developed » slightly different type of sesaphore for use in their BUSS work. Ed Gould at UC Berkeley has a new sheil that looks Like a Language. It has C-style syntax. Something has to be done about UNIX power failures since it probably shouldn't try ta do an update with no power. A branch loop might be appropriate. Ors to be tanciers have the clock page 6 wett 20 seconds and then do an automatic reboot. This etisinates the problems of power fluctuations often seen in real situations when the power hes gone funny, A related {ten is to have # check made such that $f “4nit™ should dies the systea would automatically reboot. Some peonle would like a blocking version of the “sync” sys~ tem call, so that in situations where there is 2 fairty huse number of tn-core buffers which might have to be written outs you Can resume processing with the sssurance that the disk is fully up-to-date. Instrumentation - code Left in m45.s by Ken Thompson say be used to profile the system. te used the o-clock at high speed and reserved on aren of core ss large as the text size “of the system, The pc was used as on Index into this sonster array and the corresponding cell incremented at every tick. He ren this for a month and got soee very meaningful statistics on systes utilization. In particular he found thet a large ammount of tine was spent searching the process table. Data base systess - INGRES is available fron Bob Enstein at UC Berkeley» Electronics Research Lab. New release is V6. Bos- ton Children's "useum also has a very fast dictionary-type data~ base system available for money. The RAIN Relational Alaebra tn- terpreter is being developed by Prof. Shi-Kuo Change Dept. of Information Engineering, U. of Ill fnois @ Chicago Circles PO Rox 6348, Chicago (kl. 60680 in @ wedicel database environsents though #t fs oeneret-purpose. Arf Olldkatnen is drafting w letter from the entire Wert Coast Unix Users’ Group to DEC field service protesting the de- gredation in performance DEC has shown of tate. At leest two fn~ stallations have told DEC that if certain service personnel are sent to theie sites ever agains payment will be witheld- Syatem call #64 4s being reserved for instal lation-devendent indirect callse and aystem call #63 for Users’ Group standard calls. No drop-in code to support these indirect catls hes been developed yet (good luck» gang!?. 10) Coordination of changes There wes a great deal of distussinn about the coordination of system changes being made all over the country. Several ob- servations emerged. The UUG distributions are very hard to use. There shoutd be a brief (for each piece of jeproved software) of why it is dif- ferent, how it is differents and what non-stock system features #t relies upon, In the distributions as they now extsts you get a list of what ffles ere on the tape. Some have reasonable docum mentation, sowe don't. There is no way to tell what software you want without taking each file off of tape and diffing it with the page 7 analagous source thet you have. A form for descriving a changed piece of software should be foraalizeds and circulated. Thens the filled cut forms. should be put ontine somewhere, so that a person interested in some changes to program X can find out who has already done what kinds of things to progras %. Jim Lieb of ISI has volunteered some of his time, disk and cycles to try to apke this happen. Werk Kampe suagested the use of stondardr in-coder prose forms for program documentation, Such forms are in use at UCLA and Univ of Itt for all systew changes end mew oteces of software. The objection was raised that such comments in the code can substentially increase the size of source files on disk. There are clearly two schools of thought on in-code tocumenta~ tion, Sample tarms are included in an appendin with comments on thelr use. Tt was suggested. that when 9 program is altered, that a diff be sent to the central clearing house as a useful piece of documentation. It was countered that diff often products unread- able output. Jim Lieb mentioned that a nicer differential file comparison program is now available. John Bass wenttoned that he hase for some timer been using tondittonal conpilation to out in his changes. This allows hin te eastly turn off features he doesn't wants at no objret code coat. Tt hoa the mice side effect of clearty bracketing off the changed code. Jtm ifeb is going to attempt to start » datebsse of systen changes. Tht in an attempt to increase the ambient level of understanding about what changes are available and who hes been working on what. Also, it can serve as # Shoppina list for new unix sites whe are pondering what system features they want to wets and have no ides what is svatlable. Appendix 7 Suggested forms for ln=Code documentation Durring a discussion o1 distribution packaces, the use cf a standard fors for incode documentiation was mentioned. This form was devised et the University of illinois Center for Advanced Computation and has proved very populer with everyone who has seen it. Thiet header sppears at the beginning of every major routine fn the TULtnots NCPe end of every aajor piece of Unte sofwtare written by our group wt UCLA. At firsts we thought it would be @ pain to fil out this form for each routine. Our thoughts on that subject have changed. We now fill out the form before codinn the routine. If you don't know enough to fill out the form, you clearty aren't ready to write code. If you have the fora filled outs the code qoee really quickly. We have found that this celigtous use of this form makes ft easier for # new person to read and understand the codes easier for thr prograamer to recomprehend the coder and easier for the orogrammer to hand the program off to another progranver. In additions collecting together all of these forms» and adding a salt ammount of general proses results in a packane © structural documentation superior to almost anything else we have see It if hoped that other sitess who are concerned about the above issuese will examine this fora and decide that they want to use one Like it. What is important is not this forms or any particular forme but rather that some effort in made to raise the ambient level of documentation. fe°L names <ftUl fn the name of the routine> funetions : <describe the function performed by this routine> elgorithm: <desceribes in general, the manipulations which are performed by this routine. This should serve as ® gap through the code> parpseeters: <list the names, types and significances of the parameters> returns: <(iat the classes of returned values and their significances? glovats: 3 <ttat atl globets referenced or modified by this routines * $e 4m particularly cool to designate which ones are sodified> calls: <tiet alt routines called by this routine> called by! Clist all routines which coll this routine this is the hardest oart to keep updseted> history: <atarting with the ortginal writer of the routine detail each tise the routine hes been changeds by whow and why. " the contents of thin field are clearly the well defined at 10 Tats foem was devised at UCLA as = counterpart to the above form. We use ft at the beginning of each file of code. It goes at the beginning of each aadule. Wantar rey module names <neee of the file poes here> 3 ftunetton: <deseribe whet this module has to de with the overall system> globals contsined: enumerate the globals defined tn thin sodule and their purposes> routines containedt <enuserate the routines defined in this module and their purposes> modules referenced: <enu te the sodules thet are included in the compilation of this module and explain their significances> eodules referencingr (enumerate the modules whiths in sone fashions depend on this module. Ap abowes thin field is tll defined and hard to maintein> Haves: ccepile time psreneters: enumerate the compile time perameters ond their effects? history: <it 4s w matter of personat taste, what things are module history and what things are routine history> “Las we keep both of these forms in qenerally readable files, and just read thee inte the editor when we are typing in code. Our experience (direct and from people we have given our code to) is that the use of these files adds coneiderabty to the ease of writings waintaining and studying code. We have recefved (from » few sites) the objection thet inciuding oll this prose in the code drawatically increases the size of the source code. we find thet to be » small price to pays but can understand that not all groups would agree these forms have been shown in abstract. We Cand fell fa Leve with thease not when they were described, but rather when ve vere trying to understend a piece of code which included therm. Something which can changes overnight, the coding styles ef thirty peopte aust be fairly depressive. most other people) Appendix IT Wants and Haves List ’ DAI? @ driver (RAND) laproved RPO& driver (RAwD) Isproved TUIO driver (RAND) Floppy driver “(nosed A way of USEFULLY using mag tape for read/only file systens Oro sey ORC11 driver (OS) 256K Mode Lisp cost) 11/04 Unix cost> DQ driver CSR} trot? -a hendling {SR2) Unita Systens and applications types (SRI, BNR) Tenex Style echoing in imoroved tty driver (NOSCr UCLAD VBH Driver for the Til WOP Help aystee for the Unix Prograsmers Manual «ucsBy _ Multdftile TU10 Support (UCSFe UCLA)? —_ Geneaco graphics support (RAMD) Semaphore device driver (UCBs UCLA) Apoendix IIE Bug report ond survey foras dtea Lieb #3 going to attempt to act as s sore formel clearting house for buqs and fixes and inforration about different peoples verstons of the system. He hes proposed two fores. One for bug reports and one tor descriotfion of system changes. He is going to attempt to build databases ef the collected information and make then generoliy aveilable. Tho first fore is for bug reports. It 1s hoped that a the existence of @ foreels cantralized and organized system for collecting bugs and fixes wiil result in the wore rapid prosagstion of fixes through the comaunity and reduce duplication of effort. Jim wills in the neor futures distribute information about how his bug database can . be interrogated ond how reports of that information can be obtained. The second fora is for a survey of systes channes and versions. The results of this survey will qo into a database and will be ade available to people interested in enhancements to unin. It 4s hoped thet placing this information onlines and stteapting to maintain @ detebase will make it a valuable resource to the entire community. The aechanics of the distribution and secessing . of this information will be described soon. completed feras should be asiled tos Jim Lieb USC/Inforestion Sciences Institute A674 Adetralty Wy Marine Del Rey» Co 90291 or LIESSISIB The iversity~of Oklahoma — 202 West Boyd, Room 219 Norman, Oklahoma 72019 School of Electrical Engineering October 5, 1977 and Computing Sclancea Professor Melvin Ferentz c/o CUNY/UCC S55 West 57 Street New York, KY 10019 Dear Professor Ferentz: I am probably not the only peraon who has more than once reread all the old issues of "login" to see if anyone has a driver for a particular peripheral. For my own gratification, and those in a simi-~ lar position, I am offering to make a First cut at a directory of alien and/or modified device drivers. If people who have drivers for non- atock devices or have heavily modified a driver for some particular reason would send me a short note describing their creations, I will collect 211 the loose ends and then forward # condensed listing to you for possible publication. The note should describe the device, the reasons behind modifications, and ite availability (author will dis- tribute: author won't distribute but will give hints to others; ete.). I will try to get the list to you on about December 1 so people will have a chance to respond. Thankea for the help. Sincerely, ° Michael D. O'Dell Research Aesistant Computer Science Group University of Oklahoma 202 Weat Boyd, Room 219 Norman, OK 73019 Ho/ba =) kite eREUNIX SITE SURVEY Xkkka aR General Information Site Names Site (Cnailing/Arpanet) Address: System Manager/Administrator: Software support person: System information Cpu:s PDP 11/ Unix system version (Bell Labs): Current version (virgin Bell Labs or enhanced by another site): Date you received this verston: Enhancements made at your site: (describe interesting and useful things you changed/added to EXISTING software) Descrine NEW software you have developed at your site and are willing to release to the community: Subquestions: Is it documented? } Will you support it? as Will you provide sources? Will you provide consultation services? ; If so how much and how can you be contacted? Do you plan enhancements and new releases? Is there any licensing ($$) involved? If sore please describe: Describe your software wants/needs: (be as unrealistic as you like. Someone just may have it.) Are you willing/able to provide system resources or personal resources to the Unix community? If sos please describe conditions and arrangements: Everything else you would Like to say and we forgot to ask: UNIX BUG REPORT ~Date: Cpu: PDP 11/ Unix wersions Reported by (name): Please reply: Immediately (€ ) Site name: In "FlLogin™ ( ) Address: By Mail «) (Street) Don't reply € ) (City and state) (Zip code) (Telephone) Cext.) SRSSS SPSS SSS SSH SSSS SSMS TP HSSS SHS SS SSS PTV Ss FeSeSt SSS ses SHE sH SS SSS SST ssSe Ss sss esses ezesss Type of report: Program error G3 Documentation error a Suggestion Cc) Request for information ¢ ) Complaint . y For your information c) Module or document affected: Unix kernel «9 ) Unix shell € 9) state which/whose version: Command (Bell) (¢ ) Command (Unix group) ¢ } Document (Bell) ¢ ) Document (Unix group) U9 Library (Bell)? ¢ ) Library (Unix group) €) Program (Bell) (¢ ) Program (Unix group) £2 Module or document name: Uf it is a programming error is it reproducible? (yes/no): Jo you have a solution/correction? (yes/no): sess Descriotion of problem. Include source or diff Listing if you can: Correction or fix suggested: Recieved by: date: Repaired by: date: Answered by: g date: