The USENIX Association Newsletter Volume 7 Number 1 January 1982 CONTENTS Summary of the USENIX Association Board of Directors Meeting ...... A Questionnaire oo... cscccsceesseeneees Answer Sheet for the Questionnaire .... Santa Monica USENIX Meeting Notes .... Introduction Session ........cceseseceeeee 9 System Portability Session ...... 12 Performance Issues Session .... 16 Networking Session ...........0006 18 Vendor Presentations Session ..... Zo Word Processing Session ........ 25 Applications Session ............... 27 Languages SesSiOn .......cccccscceeees oe 30 Database Management Session ...... ee 31 Review of Netnews BOF Session 33 NOTICE slogin: is the offical newsletter of the USENIX Association. ;login: is sent free of charge to indivi- dual and institutional members of the Association. The USENIX Association is a not-for-profit cor- poration incorporated under the laws of the State of Delaware. The officers of the Association are: President Lou Katz Directors John Donnelly Vice-President Peter Weiner Ira Fuchs Secretary Lew Law Debbie Scherrer Treasurer Mel Ferentz Wally Wedel The USENIX Association is an organization of AT&T licensees and sub-licensees formed for the purpose of exchanging information and ideas about the UNIX” operating system and the C program- ming language. Membership information can be obtained from the offices of the Association at USENIX Association Rockefeller University Box 8 1230 York Avenue New York, NY 10021 212-570-8934 The Association can also be reached electronically at ucbvax!g:usenix. This newsletter may contain information covered by one or more licenses, copyrights, and/or non-disclosure agreements. Permission to copy without fee all or part of this newsletter is granted to Institutional Members of the USENIX Association provided that copies are made for internal use at the member campus or plant site. The next meeting of the USENIX Association will be a joint meeting with /usr/group. It will be held July 6-9, 1982, at the Copley Plaza Hotel in Boston. Subsequent meetings are scheduled for Janu- ary, 1983, in San Diego and June, 1983, in Toronto. “UNIX is a trademark of Bell Laboratories slogin: Summary of the USENIX Association Board of Directors Meeting February 1, 1982 To: Members of USENIX From: Lew Law, Secretary of USENIX Subject: Report on the Board meeting held Jan 26, 1982, continuing on Jan. 29, 1982 Present: Katz, Weiner, Donnelly, Ferentz, Fuchs, Law, Scherrer, and Wedel The following invitees were present: Judy DesHarnais of ISC, Local Arrangements Chairwoman; Suzanne McNary, Local Arrangements Chairwoman for the Boston meeting being hosted by BB&N; Bob Lummis, Chairman of the Nominating Committee; nominees Bruce Borden, Tom Ferrin, Alan Nemeth, and Brian Redman. The quarterly meeting of the Board of Directors of the USENIX Association was held in conjunc- tion with the Winter Technical Meeting at the Miramar Hotel, Santa Monica. The meeting was brought to order at 6:30pm, Tuesday, January 26th, 1982. The purpose of the meeting was firstly to review any problems remaining in the arrangements for the technical meeting just starting; secondly to plan for the next technical meeting to be held in Boston in July and thirdly to deal with other administrative and business items. Judy DesHarnais, the Local Arrangements Chairwoman, had things well in hand. There were some minor problems needing attention, such as the production of the list of attendees for the Software Tools meeting, but nothing major. Conventions West, an organization hired to take care of some of the technical aspects of the meeting, in particular the Vendor Exhibit, had provided excellent service. Vendor exhibition space was considerably over-subscribed, but was limited by availability of space. The tutorial sessions were heavily over-subscribed, being limited to 25 participants each. It was hoped to get more feedback from the attendees, other than a general impression that the tutorials had proceeded smoothly. Lou Katz said there was some feeling among the conference attendees that the conference program should be available and distributed before the meeting. John Donnelly thought this would be very difficult to do, given the problems of organizing the program. Donnelly then requested that the next item on the agenda be the Boston meeting. Donnelly and Law had attended the /usr/group meeting in Boston in December, where there seemed to be great interest in holding joint meetings with USENIX. Law and Donnelly approached representatives of /usr/group to explore the situation, from which came the feeling that it would probably be a good idea to try this in Boston. Unfortunately the Monday of the week of the meeting is a holiday, as July 4th falls on a Sunday. This could cause some problems with scheduling. There was feeling on the part of some Board members that because of the time constraint, the joint meeting should not take place in Boston, but maybe at one of the following meetings. There was considerable discussion of the pros and cons, followed by a motion proposed by Ferentz that the Board go on record as being in favor of cooperation with /usr/group. The big problem was how soon the cooperation should start. The final decision hinged upon Donnelly’s assertion that he thought a com- mitment had been made, and his credibility and usefulness would be severely impaired if the commit- ment was withdrawn. A motion put forth by Katz was finally passed to form a committee to meet with representatives of /usr/group to discuss possible cooperation at the Boston meeting. Donnelly, Scherrer and Nemeth were appointed, and charged to report back to the Board on the following Friday (Jan. 29th), the last day of the meeting. Various other items were then dealt with. The timetable for election of the Board which will take office after the next technical meeting was set as follows: 2/15/82 Call for further nominations to be mailed 3/26/82 Nominations closed S/ 1/82 Ballots compiled and printed Volume 7, Number 1 January 1982 3 slogin: §/15/82 Ballots mailed to members of good standing as of 5/15/82 6/15/82 Last return date for ballots. The agenda for the USENIX Business session the following morning, and for the meeting of the attendees with the Board were discussed and set. Minutes of the preceding Board meeting were adopted following some amendments. Ferentz, as Treasurer, presented a Financial and Membership report for the year ending November, 1981. There were 265 Institutional members and 289 Individual members. Net assets have increased with the increase in membership. These assets are needed to provide working capital, such as the $26K which has already been advanced to cover expenses for the Santa Monica meeting and the Boston meeting. Motions were made and passed to receive the Treasurers report and to authorize an audit and generation of tax returns. Wedel reported that he had no time available for editing material for the newsletter, estimating that at least one day per week was required. There was some discussion as to the frequency with which the newsletter should appear, but it was inconclusive. Katz stated he would produce the January, 1982, newsletter, which will include a summary of the conference. Katz said that if he personally could not get this done he would take other measures to ensure publication. Tom Strong had been retained to take notes of the sessions, get copies of the viewgraphs and edit the result. Distribution tapes of the material submitted at the Austin Conference are going out. AT&T requires that we verify all licenses. In cases where we do not have positive evidence of licenses in the New York office we have written the members for copies of their licenses. Ferentz reported that 100 tapes had already been mailed and 240 were ready to go as soon as copies of the licenses are received. All V7 and V32 tapes for which license copies have been received have been mailed. At the Austin meeting three people from UCSD had volunteered to look at the submissions and annotate the tape, and Scherrer had been asked to act as chairwoman of the committee. The tape was perused and guide- lines for future submissions were drawn up. Wedel! stated that financial matters for the Austin Conference were not yet closed out due to administrative problems at the University of Texas. A tentative date was set for the next Board meeting. A question from Borden as to whether the nominees present were invited to future Board meetings prompted a resolution to the effect that they were invited but that no expenses could be paid. The meeting was adjourned at this point, to recon- vene at 2:00pm Friday Jan. 29th, 1982. Present at this session were all the Board, the nominees and Randy Frank. The first item was a report from the committee that was set up to meet with representatives of /usr/group. /usr/group wanted to equally share both time and income, and also realize money towards operating expenses. There was a lot of discussion as to how time could be distributed, whether parallel sessions were feasible, the effect on the Software Tools group, and division of expenses and income. The Board was split on the issue as to whether to proceed with a joint meeting in Boston but finally passed a resolution to go ahead, setting up a committee to work out the details with /usr/group. Material and statements relative to the divergent positions of the board members on this matter will be published in the next issue of ;/ogin. It was felt that if there could be cooperation under what all agreed were possibly going to be difficult circumstances, it would auger well for the future. It was sug- gested that a questionnaire be circulated to all attendees at the meeting just finished and all members, asking for feedback on the conference and on the idea of cooperation with /usr/group at the Winter, 1983, meeting. Law had the outline of a questionnaire and agreed to complete it and, after review, have it mailed. [It is part of this newsletter...ed] Committees were appointed for the next meeting: Local arrangements and budget - Donnelly (chair) and McNary; Technical Program - Nemeth (chair), Ferrin and Scherrer; Tutorials - Borden; Publicity - Katz; Vendor exhibits - Donnelly (chair), Nemeth. A motion was then made and passed that all expenses incurred on conference business be reim- bursed from the conference budget. Discussion then followed on the policy of renting vendor exhibit space. It was agreed past exhibitors would have first opportunity, with payment required by a certain 4 January 1982 Volume 7, Number I slogin: date, after which booths will be available on a first come, first served basis. The date and time of the next Board meeting were confirmed as Sunday, March 12th, 1982, start- ing at 10am, continuing Monday March 15th at 9am and ending no later than 4pm. The location will be Boston. Law agreed to ferret out information needed to complete an application for insurance to cover the Board and Association against liability. The application form he previously received seemed totally inappropriate. The question of publicity was deferred, as changes in the membership structure are being con- sidered, and it did not seem to make sense to recruit members into what seem to be inappropriate classifications. Fuchs, Katz and Law have been working on the Bylaws; Katz requested Fuchs to coor- dinate the work. It had become apparent in the nomination process that availability of travel expenses to Board meetings was crucial to acceptance by the nominees to serve. As a result a motion was made and passed that expenses for attendance at Board meetings be paid for by USENIX. Tom Strong took notes at the technical sessions of the meeting, which after editing, will be repro- duced in the January, 1982, newsletter. Several people are interested in producing the newsletter on a commercial basis, and have been asked to submit proposals in time for the next Board meeting. Katz requested authorization of funds for producing the January issue, and Wedel was asked to give a schedule for getting out the missing 1981 issues, possibly combined as one issue. Ferentz asked for cost estimates for tax purposes as USENIX operates on an accrual basis, and hence the cost should come out of 1981 funds before taxes. The first 1982 distribution tape will contain the submittals from the Santa Monica meeting. Six tapes have been submitted. The tape committee will attempt to annotate the contents. Ferentz will send out release forms almost immediately, and the delays due to the necessary request for copies of licenses from the people ordering tapes should not occur this time. Six items were dealt with under the heading of Any Other Business, this forming the remainder of the meeting. As it was very difficult to generate a meaningful budget to present to this Board meet- ing, Ferentz requested a motion of continuation authorizing expenditures at a rate not to exceed those of last year. The motion was made and passed. Katz stated he had spoken to AT&T representatives concerning USENIX acquiring a license to handle licensed material. AT&T will apparently look into and consider this. Law stated that he would like to get out of the manual reproduction and distribution business. Ferentz thought that such a service was very necessary, and that USENIX should explore alternatives, although the attitude of AT&T towards this is not very clear. Law was asked to write a letter to AT&T requesting permission for USENIX to reproduce documentation for other users. A vote of thanks was made to all the people who contributed to the success of the Santa Monica meeting, in particular John Donnelly, Judy DesHarnais, Peter Weiner and Interactive Systems Corp., Mike O’Brien and Dave Martin, the Session Chairman, and Conventions West. Groundwork is already being done for the San Diego meeting next winter. Donnelly has asked for a proposal from Conventions West, as their performance was impressive at this meeting. Judy DesHarnais may be available as the Local Arrangements Chairwoman again, which would be to everyone’s benefit. Randy Frank of the University of Utah offered to host the 1984 Winter meeting at Salt Lake City, Utah, The facilities appear to be good. Donnelly said there are two other offers for the same time slot - Phoenix and Portland, Oregon. Proposals from all three sites will be available at the next Board meet- ing, when a decision will be made. Adjournment was proposed by Scherrer and the motion passed at 8pm. Volume 7, Number 1 January 1982 5 jlogin: A Questionnaire The responses to this questionnaire will be used by the USENIX Association to help plan future meetings. A separate answer sheet with pre-printed return address has been provided for your answers. Please feel free to reproduce the questions and answer sheet for the use of other interested parties. 1. Santa Monica Meeting, Jan. 1982 1. Did you attend the Santa Monica USENIA% meeting? A. Technical Sessions 1, How do you feel about the number of presentations? 2. How was the length of the day (8 am to 6 pm)? 3. How interesting were the presentations? 4. How comfortable was the meeting room? 5. Should there be parallel sessions? 6. Should the session format be different? How? B. Birds of a Feather Sessions 1. How should the sessions be organized? 2. How much time should be allocated for a BOF? 3. Is there a need for BOFs in addition to those which met at the meeting? 4, Should a written summary be produced? 5. What is the optimal number of people for a BOF? 6. Should the format be different? How? C. Other _ Is it necessary to distribute a full program (names and titles) prior to the meeting? _ Is the list of attendees produced at the meeting useful? _ Is the list’s usefulness outweighed by its potential abuse? . What else could be done to make the meeting more effective? How useful would a list of pre-registrants and their hotels be? . When would you like to see abstracts available? NAW AWN this? Should USENIX distribute manuals? If so, which format would you like? Should there be conference proceedings? Would you pay extra for them? yo 90 II. /usr/group 1. Are you aware of its existence? 2. Do you belong to /usr/group? 3, Have you attended a /usr/group meeting? 4. Are you in favor of further cooperation between /usr/group and USENIX? III. General 1. Are you a member of the USENIX Association? 2. Is your organization a member of the USENIX Association? . Early publication of abstracts would impact the timeliness of topics. How do you feel about 6 January 1982 Volume 7, Number 1 slogin: Answer Sheet for the Questionnaire Please circle your answers. Please use a separate sheet for your comments, and reference the question number in your comment. When you are done tear out this answer sheet, place your com- ment sheet(s) inside it, fold to show the pre-printed address, staple, stamp, and mail. I. Santa Monica Meeting, Jan. 1982 l. yes no A. Technical Sessions 1. far too many toomany right number toofew far too few 2. far too long toolong right length too short far too short 3. very interesting interesting acceptable dull very dull 4. very comfortable comfortable adequate uncomfortable very uncomfortable 5. yes only if necessary no don’t care 6. yes no don’t care B. Birds of a Feather Sessions 1. more formal asis more impromptu 2. less than 1 hour Jl hour 1-1/2 hours 2 hours more than 2 hours 3. yes no don’t care 4. yes no don’t care 5. less than 20 20-30 30-50 50-100 more than 100 6. yes no don’t care C. Other l. yes no, but would like to see one no 2. yes no 3. yes no 4. nothing comments 5. very useful useful waste of paper undesirable 6. with pre-registration at registration after the meeting never 7. topic currency more important don’t care early abstracts more important 8. yes no don’tcare 8-1/2x1l 6x9 9.yes no don’tcare yes no _ don’tcare II. /usr/group l.yes no 2.yes no 3. yes no 4. yes no don’t have enough information Ill. General l. yes no 2. yes no Thank you for your help. Volume 7, Number 1 January 1982 From (optional) Brian Redman Be]] Laboratories Room 2E-314A Whippany Road Whippany, NJ 07981 jlogin: Santa Monica USENIX Meeting Notes Scribes’ Note Tom Strong, Strong Consulting, 5706 Van Fleet Ave, Richmond, CA 94804 I was not able to attend all 67 talks so some are not adequately covered below. Copies of the viewgraph foils, abstracts, and/or papers were used, when available. The abstracts and papers were very helpful in, providing accurate detail and making clear my scribbled notes. Abstracts have been requested for the talks on which I have incomplete notes and/or other information; summaries of those talks will appear in a future issue of ;login: Through these notes various network addresses are given. Inconsistencies in case and form in some of the addresses were found so don’t take the addresses given as gospel. Corrections to these notes should be sent electronically to ucbvax !g:usenix or to Lou Katz 541 Evans Hall EECS Department University of California Berkeley, CA 94720 Introduction Session USENIX Announcements The next three USENIX meetings are scheduled for July 6-9 at Coptey Plaza Hotel in Boston, San Diego in January, 1983, and Toronto in July, 1983. UNIX News from AT&T Larry Isley of AT&T UNIX System III (S3) has been announced. It was described as Version 7 plus PWB plus enhancements. It works on the VAX-11/780 and PDP-11/70, 45, 44, 34, and 23. The enhancements noted were: new Source Code Control System (sccs) commands, new graphics commands, new input/output features, C-compiler improvements, C-library additions, greatly enhanced terminal options, bugs fixed in many other commands, and various text processing changes. The text processing changes mentioned were a more efficient nroff/troff nroff bold font simulation, an escape feature to allow system command execution from within nroffftrafftext, new terminal driving tables, modifications to improve portability, and many mm macro enchancements. System III licensing fees are: first CPU each additional CPU 83 $43,000 $16,000 upgrade 32V 6,000 2,000 upgrade V7 18,000 7,600 upgrade V6 26,000 10,300 upgrade PWB 16,000 7,000 upgrade V6+V7 14,000 6,300 upgrade V7+PWB 4,000 3,000 There is one basic software agreement with supplementary agreements, depending on the custo- mers needs. Licensing procedures, and the time for each step, are: written request from customer, preparation of the agreement by AT&T (allow 2 to 4 weeks), agreement execution and payment (custo- ‘mer time), agreement execution by AT&T (1 day), and software delivery (allow I to 5 days). Volume 7, Number 1 January 1982 9 slogin: As a reminder it was noted that AT&T licenses UNIX as is, with no maintenance, no warranties, no patent indemnification, no trial period, and with payment in advance. The numbers of UNIX licenses and installations are given in the following tables. Licenses Commercial Educational Government Total M-UNIX 6 113 0 119 V6 90 346 50 486 PWB 46 56 63 165 V7 129 277 41 447 32V 73 132 15 220 $3 3 0 0 3 Totals 347 924 169 1440 Installations Commercial Educational Government Total M-UNIX 8 339 347 V6 157 904 129 1190 PWB 113 192 70 375 v7 172 795 38 1005 32V 96 228 15 339 $3 3 0 0 3 Totals 549 2428 252 3229 The licensing agent is Technology Licensing Manager American Telephone and Telegraph Co. P. O. Box 25000 Greensboro, North Carolina 27420 919-697-6530 An Error in System III VAX Booting Instructions [A note from an unrecorded source that I hope I wrote down correctly...Scribe] In the VAX con- sole commands to be used in bootstrapping "s 2" should replace "s 0" to cause the CPU to jump over the register save mask (2 bytes) at the front of the program. Whitesmiths’ Developments Mark Krieger of Whitesmiths Whitesmiths has announced release 2.1 of their C and PASCAL compilers and of IDRIS'™. Machines supported are the LSI-11, PDP-11, 8080, Z80, VAX-I1, and 68000. Changes include fixes to all known bugs, additional basic math functions, ADA-style exception handling for "enter" and "leave", improved code generation, and improved VAX and 68000 support. PASCAL conforms to the complete 1SO (draft) standard plus providing support for separate com- pilation. Modules can be linked to C or assembler code. A validation suite report is available - it currently fails one test. IDRIS is intended for machines too small to run V7/S3, it runs on the PDP-11, MC68000, and 8080. It is similar to V6 and has most UNIX utilities. A W7-type file system will be coming with VAX-IDRIS. Whitesmiths offers new releases of all its products every nine months. Release 2.2 is due in Sep- tember, 1982, and will include C and PASCAL for the 8086, Software Tools, and forte, a [irof-like?) text formatter. 10 January 1982 Volume 7, Number 1 slogin: UNIX at Berkeley Bill Joy of the University of California The Computer Systems Research Group at U.C. Berkeley is directed by Bob Fabry. It is an ARPA-funded research group that works on technical enhancements to UNIX on the VAX. They offer a VAX 32V tape with their enhancements called 4BSD. Tapes released after the meeting have drivers for newer DEC devices, thanks in part to Bill Shannon of DEC. These devices are the TU7 Magnetic tape, UDA5O0 disk controller, DN11 auto call unit, and one other. Bootstrap support is also provided for the TU7, Holders of old tapes who need these new drivers should contact UCB at the address below to pursue the matter further. Currently this tape is available for $300, but the cost will be increased soon to reflect the real costs of duplication. Currently there are about 250 4BSD licensees. The tape is under the AT&T license and not in the public domain. After a February, 1982, evaluation meeting a document describing future plans will be circulated. A new 4BSD distribution is planned for Fall of 1982. It should include local and long-haul network support, a faster file system, segmented virtual memory, and interprocess communication. They also plan to make available a tape of 4BSD-user-contributed software. A software organization package will be offered for preparing the contributions. In addition to everything else, they are also working on Fortran, mail, and the user interface. The group has been receiving a large number of phone calls lately, many of which are outside the scope of their charter as a research group; they ask that you use their help sparingly. They are behind on the bug reports but are actively working on them now. Bug reports should be sent electronically to ucbvax!4bsd-bugs or arpavax.4bsd-bugs@ berkeley You can get information on 4BSD by writing to Jeri Kotani Distribution Coordinator Computer Systems Research Group EECS Department U.C. Berkeley Berkeley, Calif. 94720 They ask that you write for the information packet, read it and only then call with questions. The group is not doing any work on PDP-11’s; it is thinking only along the lines of 32 bit proces- sors. UNIX at DEC Armando P. Stettner of T.1.G. group at DEC’ The T.1.G. group at DEC has a V7 distribution tape that is available free with a copy of your source license. It supports all memory management PDP-11’s, almost all DEC tape drives and disks, and has Bill Shannon’s overlay kernel. In about six months the group plans a new V7 release with on- line logging, more device drivers, and an easier way to configure to your PDP-11. Requests for infor- mation on the tape, called V7M, should be directed to Wendy Murphy DEC Continental Blvd. MK1-1/029 Merrimack, NH 03054 603-884-7256 decvax!wendy The UNIX Engineering Group in TIG is headed by James Barkley (decvax!jmb). The group con- sists of Armando Stettner (decvax!aps), Bill Shannon (decvax!shannon), Fred Canter (decvax!fred), Jean Wood (decvax'jean), and Jerry Brenner (decvax!kjb). The related UNIX Program Planning “Also president of the Armando P. Stettner School of Creative Driving Volume 7, Number 1 January 1982 11 slogin: Group consists of Rich Ptak (decvax!rlp), Bill Doll, and Tony Godino (decvax!tony). What’s Happening at DECUS Mark Bartelt of CalTech UNIX is now a valid topic of discussion at DECUS. After a lot of discussion the Special Software and Operating Systems (SS&OS) SIG has been formed, with UNIX as its primary topic. The SIG has about 1700 members and has offered tutorials and other things. It is planning to offer a tape of UNIX tools that are not covered by the UNIX license. The following addresses were offered: Tape Submissions: Newsletter (temporarily): Carl Lowenstein Mark Bartelt UCSD P-001 CALTECH 356-48 La Jolla, Calif. 92093 Pasadena, Calif. 91125 ucbvax!sdcesvax!mplsahc!cdl ucbvax!cithep!mlp Microsoft Overview - The XENIX Project Gordon Letwin, Microsoft Inc., The Microsoft Building, 1700 Northup Way, Bellevue, WA 98004, decvax!microso!gordon Microsoft specializes in OEM system software for micros. They find that BASIC is widely used. Among other things they are working on portability of C and PASCAL. They offer the XENIX system for micros such as the Z8000, 8086, and 68000. It is based on V7; they will be going to System III. XENIX is oriented towards an office environment. Future directions at Microsoft include expansion to 32-bit processors, distributed processing/networks, and personalized work stations utilizing intelligent terminals, windowing, and graphics support. European UNIX Users Group There will be a meeting April 16 and 17 in Paris(!). The European group may be contacted at the following address: R. A. Mason Computer Engineering Heriot-Watt University Mountbatten Building 31-35 Grassmarket Edinburgh EH! 2HT Scotland System Portability Session Experiences in Porting Coherent to the Z-8002 Robert Swartz of Mark Williams Co. {I had only the abstract for this talk...Scribe] This talk discussed the methods and strategies that were used in transporting the Coherent operating system to the Z-8002. It described the retargeting of the Mark Williams C compiler in detail. The design of the operating system kernel and the changes required to move it to the Z-8002 were also discussed. A simple and elegant solution to the byte swap problem was presented. 12 January 1982 Volume 7, Number 1 slogin: UNIX on IBM/370 Architecture Machines Steven J. Buroff of Bell Laboratories [These notes were taken from the foils and abstract...Scribe] They have implemented UNIX on 1BM/370 architecture machines. These include the 4341, 3031, and 3033 as well as the 370 family machines. Full-duplex UNIX terminal support is provided using an IBM Series/1 as a front end proces- sor. Remote job entry using the bisync protocol is also supported. The system is running on an IBM machine to take advantage of the power and reliability of the hardware and to better access large shared databases. The UNIX kernel interacts with the TSS kernel, which supplies the use of various well- proven code in TSS. Performance is shown in the following table: System Performance VAX 1.0 3033AP 8.2 3081D 8.7 (est.) 3081K 12.2 (est.) A 3033AP customer currently supports approximately 180 interactive users plus a large background load. UNIX Front Ends to Large Hosts Richard Hyde, 1.C.C.-B.Y.U., 460 N. University Ave., Provo, Utah 84604, 801-373-1313, ICC!rich or BYUCS!rich This talk discussed front-end machines for batch-oriented machines in general, and their connec- tion of an Onyx Z-8002 to an IBM 4341. Assuming the need for a large batch oriented machine, the use of a front-end such as UNIX offers a better and more portable development environment and reduced cost per terminal. Against this must be weighed the disadvantages of another machine to sup- port, or go down, and the cost of transmission between the front- and back-end machines. Various networks are possible; they used HASP for remote job entry. They recommend that the connection be through a DMA block device, not a character device. The front-end must be able to handle interrupts quickly. Significant questions about how much the user should have to know about the back-end machine were raised. For example, how much should the user have to know of the link? of the host JCL? of character translations? Several areas needing work for this type of UNIX application were noted: (1) fintlike syntactical checkers for other compilers on other machines, (2) JCL-generating programs to convert a "standard" form of job control language into its machine-dependent dialects, (3) network topological display tools for users, and (4) improved network mail facilities to and from both UNIX and non-UNIX machines. Ports of UNIX to the Motorola 68000 Rick Kiessig, Fortune Systems, 1501 Industrial Rd., San Carlos, CA 94070 Fortune Systems has ported UNIX to a 68000. Why select a 68000? (1) It’s powerful and rela- tively cheap (a little slower than an 11/44, in their experience). (2) 16 MB address space. (3) Family growth of the 68000 series, and multiple sources for components. They are using their own bus. In the software end, they started with MIT C compiler; it took about 6 weeks to adapt. They found that the compiler has about 8-10 bugs and produces optimized code about 15% larger than on a PDP-I1, that the loader is not complete, and that the assembler has 2-3 bugs. They found that Whi- tesmiths’ C is not really Bell "standard" C and that the code is generally not as dense as from MIT’s C compiler. Fortune will be offering a 68000-based UNIX system with 256Kb, 5.25 inch Winchester disk, and 720Kb floppy for around $6000, including a UNIX license. Volume 7, Number 1 January 1982 13 jlogin: Scattered Main Memory Allocation for Microprocessor-Based UNIX Systems Jerry Dunietz, Microsoft, Inc., The Microsoft Building, 10700 Northup Way, Bellevue, WA 98004, decvax!microsoljerry This talk, and a related paper, discuss the problem of memory management in UNIX. PDP-11 UNIX allocates one contiguous piece of physical memory for a process’s user page, data, and stack. As processes of various sizes die and new ones are created the memory is fragmented. They found many cases where a memory allocation request failed because a contiguous block of the required size was not available, they also found that on the average over 5 times the required space was free, but that the free space was in small pieces. They propose a scheme for allocating memory in discontiguous pieces on microprocessors. This allows their kernel (XENIX) to use every available page of memory, reducing swapping and memory- to-memory moves. The disadvantages on systems that do not have hardware features to map the I/O are: (1) swap- ping takes one I/O transfer per memory piece, and (2) physical I/O, which bypasses the system buffering mechanism, cannot be handled. Their answers to these problems are: (1) it is much more important to minimize the need to swap or do memory-to-memory copies than it is to minimize the number of I/O operations involved in swapping; (2) processes using physical I/O are rare, and so are handled specially and given contiguous regions of memory. How to Port UNIX to a Microcomputer Alan Whitney, Microsoft, Inc., The Microsoft Building, 10700 Northup Way, Bellevue, WA 98004, decvax!microso!arw They connect the target machine to an 11/70 over serial lines. The target machine needs 256Kb of memory, suitable memory management, a disk (hard or floppy) with at least 5Mb, 2 serial lines to the 11/70, a rom monitor, and a breakpoint device. They debug external devices such as the file sys- tem and tape by simulating them on the 11/70. The steps they follow when porting UNIX to a new micro are: (1) write a stand-alone program for the machine, (2) modify the simulated disk driver and Tun it stand-alone, (3) write the memory management <ode, (4) install the simulated disk driver into the system, (5) run the kernel test programs, (6) install initand sh, (7) write and debug the hard disk driver, (8) download the utilities from the 11/70 and test them, and (9) port the compiler. A Dual Processor VAX-11/780 George Goble, Elec. Engr, Purdue Univ., West Lafayette, IN 47907, 317-494-3545, decvax!pur-ee!ghg, arpavax.ghg @ berkeley They have put another 11/780 CPU in place of the SBI bus terminator on their WAX. The add- on processor runs only user-mode processes, with the original (master) CPU handling all system cails, interrupts, and user-mode processes in any left over time. They have found that performance is about 1.8 times as good as with a single processor VAX, although it can be hurt by many system calls and block memory writes. They run a version of 4.1BSD that was modified locally. They typically support 90-100 users with this system. Their analysis indicates the 2 processors use about 75% of the memory bandwidth so a third processor would not offer much. Problems encountered, and their solutions, were: (1) memory timeouts were found to be caused by cable problems (replacement cables available from AMP have insulators to reduce the problem), (2) LSI-11 console integration was surmounted by removing one of the LSI’s; (3) maintenance. They found that when a VAX "prober" instruction was executed right before a page boundary when lots of I/O instructions were also being executed a machine check would occur. Their solution was to put no-ops in to move the instruction past the page boundary. {DEC has announced the VAX 11-782 which consists of two 11/780 processors. (However, the second processor is not attached to the SBI of the original processor, as above, but communicates via shared memory.) It will be available as a field-installable option priced at about $180,000.] 14 January 1982 Volume 7, Number 1 slogin: Porting UNIX to the HEP: A Modern SuperComputer Mike Muuss, US Army Ballistic Research Lab, 301-278-5691, Mike @BRL HEP is a 64 bit word, byte addressable, register oriented, 4 CPU, 10-MIPS, 20Mb computer being built for BRL. It will be used for interactive high resolution 3D shaded and vector graphics, heavy timesharing uses (typesetting, applications, etc.), interactive modeling and analysis codes, number crunching, and MIMD algorithm research ("proposals invited"). The architecture of HEP is (quite by accident) uniquely suited for UNIX. It will be running the BRLNET high performance V6+ kernel. They will start with PCC and put the kernel in 1 CPU anda skeleton in each of the other 3 CPUs. Then they will bring in a HEP optimizing C compiler. Utilities will be mostly V7. A production system is expected during the summer of 1982. A TCP/IP network connection is planned by January. A Virtual UNIX for TOPS-20 Jay Lepreau, Computer Science Dept, Univ. of Utah, Salt Lake City, UT 84112, 801-581-8332 or 8224, Lepreau@UTAH-20, decvax!{harpo,randvax} !utah-cs!lepreau They are building a virtual UNIX to run under TOPS-20 so they can access the system languages and extended addressing of the DEC-20. Their goals are to provide the same file format for both TOPS-20 and "VUNIX", to be able to access both environments from C, to keep kernel changes invisi- ble to user programs, and to not hack TOPS-20. The order of projects has been to make PCC work, then provide a V7 environment, then transport user programs. Major problems encountered include the 20’s 36 bit word (standard byte size is 7 bits!), line terminators (CR/LF-LF), long file names, and no links. They have found that the "portable" C compiler is not particularly portable to word-addressable machines. They also found problems with the C language specifications when the target machine is dis- similar to the canonical PDP-11 architecture. UNIX on the PERQ Michael Tilson, Human Computing Resources Corp., 10 St. Mary Street, Toronto, Ontario, M4Y 1P9 Canada, 416-922-1937, decvaxthcr!mike The Three Rivers Computer Corporation PERQ is a high performance personal work station intended for management information systems. It uses a high resolution, micro-programmable bitmap display [quite impressive to see...Scribe], a 1 MIP processor, Winchester disk, tablet, IEEE bus, Ether- net, and writable control store. {My notes on this talk were inadequate; look for more information in a future issue of slogin:...Scribe] Volume 7, Number I January 1982 15 slogin: Performance Issues Session Performance and Robustness Improvements to V7 UNIX Thomas Ferrin, Computer Graphics Lab., School of Pharmacy, University of California, San Francisco, CC 94143 The Bell release of V7 has been found to be slower than V6. A number of improvements have been made and are available as the 2.81BSD tape. The improvements made include: (1) 1024 byte file system; (2) the buffer cache was moved outside kernel address space; (3) standard output to terminals is "line buffered"; (4) dynamic UNIBUS map allocation for the 11/70; (5) a search pointer for allocating free inodes; (6) hashed searching for in-core inodes and buffer headers, (7) inline macros used to cut down on subroutine overhead; (8) the process table is searched only to the last active entry; (9) reduced overhead on system calls; (10) a faster nameX); (11) optimized freelist interleaving; and (12) faster user file descriptor allocation. The graph presented suggested a 3X improvement with 20 users and a 2.5X improvement with 42 users. A paper is available at the address given above; please include copies of the signature page and "definitions appendix" page from the Western Electric license agreement. Information on the availabil- ity of the 2.81BSD distribution is available from Mary Ann Finnerty Computer Science Division EECS Department University of California Berkeley, CA 94720 or send uucp mail to ucbvax!maryann Be sure to indicate you are interested in the PDP-11 version ‘2.81’ distribution. High Performance File System Routines Robert Gray, Pattern Analysis & Recognition Corp., Seneca Plaza, New Hartford, NY 13413, duke!ladiron!bob, gray @berkeley Dave Bennet, Bell Labs (Holmdel) They described a need for very high speed I/O transfers on huge files. The goals were to be able to use normal utilities on the files, to do DMA to/from user space, to have it work on PWB, 4.1BSD, V7, and 2.8BSD, and to have no kernel changes. They have written a series of routines that allow the user to manage an area of the disk through special create, open, etc. calls. The routines interpret the superblock and inodes directly. Their measurements on 1Mb files on an RPO6 show significant improvements in data transfer speeds. The work should be complete in mid-February, 1982. A 15 page paper is available by mail at the above address. The software will be available. A Communications Co-processor for UNIX Mike Zuhl’, MS 92-515, Tektronix, Inc., Box 500, Beaverton, Oregon 97077, teklabs!tekmdp!mikez The Tektronix 8560 system is a multi-user UNIX-based microcomputer development system named TNIX. It needs lots of communication ability to support terminals with screen editors (RS- 232), RS-422/423 @ 153.6K baud communication, and other connections. They have produced an attached communications I/O processor (IOP) that appears as a superset of the standard UNIX tty driver to user programs. It appears similar to disk-to-kernel communication - the C-lists are gone and the driver is replaced by a simpler and smaller one. Each IOP will handie 4 ports, in any mix of RS-232 and RS-422/423. They have found that the use of these IOPs removes about 90% of the communica- tion load, yet still will provide throughput of about 2400 baud for single characters. a “The quote of the day: "Tektronix is very big on 3 letter acronyms; or, as we call them, 'TLAs 16 January 1982 Volume 7, Number 1 ~ jlogin: The IOP performs most of the normal terminal functions, and a few new ones. Each ASCII char- acter can be individually programmed as to how it should be echoed and what action it will cause. This allows mapping of all kinds of special actions, including "copy character from previous line". Com- mands and responses are queued in the IOP, with a flag telling whether the IOP or main processor owns the entry. Transaction keys are sent in commands and returned in responses to correlate responses to commands. The IOP is polled; it does not generate interrupts, It consists of 14K of ROM with about 6400 lines of C and 1200 lines of assembler, and 14K of RAM with about 3K per port of specific data. The hardware consists of 1 board, an 8088 processor, 2 SIOs, and a 4 channel DMA from the SIOs to IOP memory. Line Disciplines as Coroutines Dennis Ritchie, Bell Labs 2C517, Murray Hill, NJ 07974, research!dmr, csvax.dmr@berkeley The notion of line disciplines (protocol handlers) in Unix is useful, but done in a restricted and complicated way. An experimental version of the system replaces line disciplines, together with the device drivers for terminals and networks, with a unified structure of stream processors operating as coroutines. Each stream processor has a pair of queues, one each for the read and write direction, and for each direction provides a pair of routines. One routine accepts data blocks to be placed upon the queue; the other is called asynchronously to process the data on the queue. Queue processors are connected dynamically in a bidirectional line between the user process and the device driver. For example, a terminal attached through a network would be handled by a network device driver, a network protocol processor, and the terminal processor. All communication takes place by messages passed between queues. Besides ordinary data, mes- sages convey control information such as signals and IO control requests and acknowledgments. The contents of messages are passed by reference, instead of being copied, so that good performance can be achieved. Adapting BRL-UNIX to Support Simultaneous V6 and V7 File systems Robert S. Miles and Michael Muuss of US Army Ballistics Research Lab BRL chose to support their old V6 file systems when they converted to V7. They did this by changing the mount file system call to signal if the file is in V6 or V7 format. The inode tables are the same. UNIX Edition 7 Implementation for Smaller Systems Steve Sanderson, Dept. of Astronomy, University of Texas, Austin, Texas 78712, 512-471-4474 This talk described the trials and tribulations of bring V7 up on an 11/45 with only 64Kw of memory. Normally, V7 needs at least 128Kw of memory. They made V7 fit into their machine by: (1) reducing the size of the kernel to 16Kw, partly by making a dynamic buffer scheme where the buffers are gotten from and released to user space; (2) changing the loader so it fits in the top end of available memory instead of above 64Kw. Volume 7, Number 1 January 1982 17 slogin: Networking Session CCITT Recommendation X.25 and Its Implementation Justin Walker of Interactive Systems Corp. (These notes are taken from the foils and abstract...Scribel This talk described the X.25 network protocol and Interactive’s implementation of it. X.25 defines the mechanisms for a host to interface to a public data network, such as Telenet or Tymnet, using various levels of protocol. There are 4 levels of protocol defined: electrical, link, packet, and the interactive terminal interface. At the electrical level are such things as the shape of the plug. At the link level are things such as synchronization flags and framing and error control. At the packet level are such controls as multiplexing and sequencing infor- mation. Interactive offers its INcard product family for support of various types of networks. It includes RJE with Hasp and Bisync, interprocessor links with IPL/x and MIPL, X.25, and a Xerox 9700 inter- face. X.25 uses a normal UNIX open, close, read, write interface. They have now implemented 3 lev- els of the X.25 protocol and have it in test. The host side of the interface has been implemented on the ACC UMX-Z80, a Z80-based DMA interface to the UNIBUS. The implementation is one of several communications implementations on the UMC, using a common interface to UNIX. [The last foil has the line "System suitability: UNIX not a communications host". I did not hear the comments about this so leave interpretation of the quote to the reader...Scribe] TCP/IP Implementation Bruce Borden, 3COM Corp. [I have no notes, foils, abstract, or paper for this talk...Scribe] The Implementation of a Campus Network Jun Murai, Dept. of Mathematics, Keio University, 3-14-I Hiyoshi, Yokohama 223 Japan This talk described the Keio S&T Campus Network at the Science and Technology Campus of Keio University. It connects 5 PDP-I1/23’s and one PDP/60 running V7 using the "Acknowledging Ethernet" scheme. This scheme adds a built-in packet acknowledgment mechanism to Ethernet, while preserving the low cost. An Acknowledging Ethernet Interface Unit (AEIU) on each machine incor- porates the transport and lower layer functions in it. This provides quick and reliable communications and minimizes the software burden in each host. User access is through a shell compatible but rela- tively network-transparent interface. The network provides file transfer, RJE, mail, remote terminal connection and special device sharing. It runs through a 1 Km coaxial cable at 6 Mbps. Each host system has 4 levels of interface to the network. The AEIU driver makes connections and does I/O of packets between Ethernet sockets. Various C level system calls have been imple- mented to establish connections and send and receive messages. Encryption and decryption are sup- ported in a third level. User access to the network is specified by suffixing @ site-id to a login name or path name. They have also modified cp, mail, and write to accept "@" themselves. For example, % command|@site-id] arg1[@site-id] arg2[@site-id] ... % cp prog.c@ss23 b.c % Ipr@ea23 text % login yoko@ss69 There are also network status commands. A redesign effort is currently underway to implement: (1) more software in kernel space and use an overlay kernel, (2) a more powerful user interface, (3) inter-network functions to connect to other local networks, and (4) terminal interface processors and file and print servers. 18 January 1982 Votume 7, Number 1 slogin: Host-Remote: A Satellite Processor System Charles R. Price, Storage Technology Corp. MD 3T, 2270 So. 88th St., Louisville, CO 80027 303-673- 5698 Host-Remote is an implementation of a V7-based satellite-processor system for PDP-11’s. It is a software system to execute and control a user program in a satellite processor connected to a UNIX host. This system is similar to that described by Lycklama and Christensen in the “Bell System Techni- cal Journal". The remote has a minimal control program to provide communication with the host. System calls from the remote program are transmitted back to the host for servicing. In the host there is a remote link driver in the kernel and a remote coordinating process to handle the system calls and catch and perform actions on host signals to the remote. The remote processors are typically LSI-11/2’s and /23’s with 60 Kb of memory. They are used for real-time applications and may or may not have a terminal attached. Remote programs are compiled in the host as if they were standard programs. They are linked in a special way to provide for the memory layout of the remote processor. A user logs in and calls the host control program to download the remote program. If necessary, the user can debug the remote program by using a slightly-modified version of adh The use of this system has allowed real-time applications to be developed in the friendly UNIX environment. Future directions indicated are towards non-PDP-11 remotes (or hosts!) and a better teal-time non-UNIX system interface. The wucp Communications Protocols Explained, or uucp on a Z80? Lauren Weinstein, POB 2284, Culver City, CA 90230, 213-641-6300 lauren@ucla-security, ucbvax!ucla-s!lauren This talk described the internals of the uucp protocol. The protocol is not openly documented; the papers that do exist do not accurately reflect the production versions of uucp Information from the V7 manual and available papers was not repeated in the talk. The information presented came from direct conversations with the authors of the various uucp segments and experiments, not from the UNIX code. A basic implementation of the uucp packet driver has been written independent of the Bell code. It is written in BDS C for the 8080/Z80 and runs on CP/M'™ and MARC". It can run half duplex at high or low speeds. [The following notes are taken straight from the foils presented with the talk. Errors in copying are mine...Scribe] Opening and protocol selection Assuming no “security” sequence and only packet protocol "g". [A security sequence, if it existed, would be a request for call-back validation. "g" is the standard protocol; others may be negotiated.] <nul>:0, <syn>:020 slave: <syn>Shere<nul> master: <syn>S<sitename> -Q0<null> slave: <syn>ROK<nul> . <syn>Pg<nul> [request to use protocol "g"] master: <syn>Ug<nul> [response: use protocol "g"} slave sends inita until inita from master slave sends initb until initb from master slave sends initc until initc from master protocol is on! 8 bit paths are always required. Data segments range from 32-4096 bytes: 32" (2k) k is a 3 bit number indicating segment size Volume 7, Number 1 January 1982 19 slogin: Packet sequences packet sequence numbers are constrained to 3 bits (i.e., mod 8) Control byte bit 76543210 ttxxxyyy tt meaning 00 control packet 10 data packet (long) 1 short data packet ol alternate channel! (not used) For control packets: xxx name yyy 1 close n/a 2 i last correct rec. seq. # 3 srj seq. # to resend (obsolete) 4 Ir last correctly rec. seq. # 5 initc window size 6 initb data segment size 7 inita window size low numbered xxx sent first rj = reject (use yyy to update) tr = receiver ready window size between | & 7 packets inclusive (actually this is max size) up to 9600 baud, window size of 2 is optimal if data segment > 32 bytes receiver selects segment and window size long data packet <control byte ><data segment > short data segment (may have 0 data bytes) (difference between data count and segment size < = 127) <control byte> <count difference byte > <data segment > short data packet (difference between data count and segment size > = 128) <control byte > <diff. byte 1 > <diff. byte 2> <data segment> diff. byte 1 has high bit on, then low 7 bits of diff count diff. byte 2 has remaining bits of diff count Note: for short data packets, unused bytes of data segment are always sent and are always check- summed. After initial synchronization Receiver sends mod 8 [incremental?] counter "R"=0 Sender sends similar counter "S"=1 R always equals the number of the last correctly received packet S is the packet sequence number of the next packet to send W=window size (may be different for each sender if desired) Sender transmits seq. # packets in range S to (S+W-1)mod 8. Receiver expects seq. #’s in range (R+1)mod 8 to (R+W)mod 8. Packets must arrive in seq. # order and will only be ACK’d in order. (Next packet receiver will accept is (R+1)mod 8.) Receiver ACK’s receipt of packet by sending its R value to sender, where it updates senders S value. If bidirectional flow, can be sent as yyy value of data packets (control byte). Other- wise, sent as yyy value of rr control packet. If receiver detects error, it can: a. rely on transmitter (sender) timeout and retransmission, or 20 January 1982 Volume 7, Number 1 jlogin: b. send rj packet. [rj is a selective NACK packet] The rj yyy field replaces S value of sender and is a request for retransmission starting at that sequence number. ("go-back-N"[?]) Receiver ignores duplicate packets. (The packet driver was originally an experiment at "cleaning" up X.25.) Most UNIX systems use segment size=64, window =3. Framing for asynchronous serial lines <syn><k><c0><cl><c><x><data segment, if any> magic = 0125252 <syn>: 020 <k> (log, segment size)-4, i.e., 1<=k< =8 If (k=9) this is a control packet with no data segment <c>: control byte <x>: <k>*<c0>*<cl>"<c> — [* means XOR] <c0>: low order 8 bits checksum <cl>: high order 8 bits checksum Checksums (checksum is 16 bits) For control packets: checksum = magic - <c> For data packets checksum = magic - (chksum segment” (0377&<c>)) Packet driver checksum (from early packet driver doc but still accurate) chksum (s,n) register char *s; register n; register short sum; Tegister unsigned short t; register short x; sum = -l; x = 0; do { if (sum < 0) { sum <<= 1; sum ++; } else sum <<= 1; t = sum; sum += “s+ + & 0377; x += sum‘n; if (Cunsigned)sum <= t) { sum “= x; } } while (--n > 0); return (sum); Typical file transfer master: S /s/lauren/test /tmp/test lauren - D.randvaxn5672 644° S means send /s/lauren/test is source name /tmp/test is destination name lauren is the user name - is a hyphen D.randvaxn5672 is the data file 644 is the source file mode > is an apostrophe and the blanks from the S on are where you see them Volume 7, Number 1 January 1982 21 slogin: slave: cy’ master: H’ slave: HY’ master: HY’ Packet driver off. See V7 manual for more details on this. Status of the Network News System Mark Horton, Bell Labs, Room 2C-249, 6200 E. Broad St., Columbus, Ohio 43213, 614-860-4276, ucbvax!cbosgd!mark, mark @berkeley Matt Glickman, Computer Systems Research Group, Evans Hall, University of California, Berkeley, CA 94720, 415-642-7780 (messages), glickman@berkeley, ucbvax!glickman Network News, or USENET, is used for announcements, queries, bug reports and fixes, mailing lists, ongoing discussions, and interest groups. It started at Duke over wucplinks in 1978. It has grown since then, and a new version, version B, has come into use and offers personal newsgroups. Another version is being created which keeps follow-ups to articles together and provides a gateway. There are lots of different news groups; the one named net.all lists all USENET-wide news groups. To join USENET you find a site willing to send you news, get the software, get it running, tell your connection to start sending you news, then post an announcement that you exist to the net. You can get the software from your contact site or one of these public sources: /ust/spool/uucppublic/news/bnews.tar [archive file’s pathname] SRC-UNIX (ARPANET) chico(UUCP net) Brian Redman, BTL WH, 201-386-2884 decvax(UUCP net) Bill Shannon, DEC, 603-884-5044 If you want to run version B, be sure to get a copy of the released version. Version A from Duke is more suitable for small systems. Introduction to CSNET Michael T. O’Brien, The Rand Corp., 1700 Main St., Santa Monica, CA 90406, 213-393-0411, obrien@Rand-UNIX, randvax!obrien David Crocker, Dept. of Electrical Engr., University of Delaware, Newark, Delaware 19711, 302-738-8913, 302-738-2405 (messages) DCrocker@UDel CSNET is a logical network designed to provide communication via telephones, public nets like Telenet, and TCP-based networks. It is NSF funded and is expected to be self-sufficient within 5 years. It runs under 4.1BSD on a VAX. [My notes on this talk were inadequate; look for more information in a future issue of jlogin:...Scribe] Virtual Terminals in a UNIX Network Gary Crockett, Bell Labs, Naperville, Illinois, 312-979-5981, ucbvax!ihnss!ihidt!gbc The work is being taken over by: Alan Hewett, Bell Labs, 6200 E. Broad St., Columbus, Ohio 43213, 614-860-2675, ucbvax!cbosg!apwh This talk described a system where a host talks to virtual screens in a terminal handler, and the handler maps from these virtual images to the users real terminal. The host does its reads and writes as usual but uses a virtual CRT language for cursor movements. There is a special line discipline to talk to the terminal handler to provide multiple logical channels on the link. Special joct/calls are provided for special functions such as to get the window size. The user can create and delete windows on her/his terminal and specify the host name or function associated with each window. There is also the ability to change window size or location, switch control between windows, look back through a window history, and change window display characteristics (e.g., to fold or truncate long lines). 22 January 1982 Volume 7, Number 1 slogin: A terminal handler based on a 68000 can handle several terminals. At least 64Kb are needed for each terminal. The terminal driver compares the actual and desired screen images and uses termcap ter- minal descriptions and an enhanced version of the curses package to update the users screen. UNIX/RSCS Networking Joseph Boykin, Computer Science Dept., The Pennsylvania State University, University Park, PA 16802, 814-865-9723, allegra!psuvax!wizard, PPUVAX1%WIZARD on BITNET This talk described connecting UNIX to various IBM systems on BITNET through an emulation of RSCS. BITNET is a large network of university machines around Pennsylvania, New York, Connec- ticut, etc. RSCS is synchronous, oriented to largish blocks (“1000 bytes), auto routing, and runs at 9600 baud. Write, mail, file transfer, RJE, and command execution are supported. By connecting UNIX through RSCS their machine can appear to the network as a peer host, not just a work station. Vendor Presentations Session [The foils for these presentations were not available to me...Scribe] 3Com Ethernet Network Bruce Borden, 3Com Corporation, 1390 Shorebird Way, Mountain View, CA 94043 3Com offers a complete UNIX-Ethernet package. They offer transceivers to tap into the ether, transceiver cables, controllers for QBUS'™ and UNIBUS'™, and DOD standard IP/TCP software for UNIX. The transceiver utilizes standard N-series cable TV connectors (rather than a tap) both to reduce EMI and for reliability. The cable speed is 10’ bits per second; maximum size packets sent back-to-back go at about 9.6Mbs. A wansceiver isolates the connected device from the cable. The QBUS and UNIBUS controllers each appear as 32Kb of dual ported memory to the host processor. The memory is logically divided into 16 packet buffers, any combination of which may be used for transmit, receive, or main memory. A starter package for a QBUS or UNIBUS with all cables, connectors, drivers, etc., runs around $6300- $7300, 3Com also has UNET software that works with this hardware; it costs about $5000 for the first copy. A Description of the YARD Relational Database Management System Gary Donnelly, RLG Corporation, 1760 Reston Ave., Reston, VA 22090, 703-471-6860 YARD is designed for smallish data bases (<~3000 records) like those typically found in the office environment. It is well suited for applications such as personal DBMS, and can handle repetitive letter generation with variable fields, report writing, etc. The data base itself is a UNIX file. The YARD programs can be used as filters. Various programs are provided with YARD including: a rela- tional screen editor (oriented to the VT100), programs to search, manipulate, and audit the data, and an interface to nroff Sequitur Joaquin Miller, Pacific Software Mfg. Co., 2608 Eighth Street, Berkeley, CA 94710 Sequitur'™ is a fully relational data base system that runs on V7 and most V7 look-alike 16-bit systems. All communication with Sequitur is through a single user interface. A full screen editor is used to make entries or changes. The Sequitur system combines relational completeness according to Codd with the best features of Zloof’s query by example. Selections use the concept of entity. This concept allows the same data to be viewed in different ways depending on the query. The result of a relational operation such as selection is a virtual table that may be displayed just like any other table. Changes in the virtual table are also made in the underlying table from which the data came. Volume 7, Number 1 January 1982 23 jlogin: Sequitur includes integrated text processing, sort, report generator and form letter generator. The editor automatically inserts nroffcommands into the text. It is available primarily through OEM’s. The cost ranges from about $3500 on ONYX to about $9000 on PDP-11’s larger than an 11/45. A UNIX-like, CP/M-compatible Operating System for 8080/Z80 Microcomputers Lauren Weinstein, Vortex Technology, POB 2284, Culver City, CA 90230, 213-645-7200 MARC" is a UNIX-like operating system that was designed to fill the gap between CP/M and UNIX for 8080 and Z80 microcomputers. MARC is initially booted up under an existing CP/M system (either single-density 1.4 or any version 2.x CP/M). MARC then absorbs the CP/M Basic I/O System (BIOS) and becomes a separate operating system, completely independent from CP/M itself. MARC needs at least 48K (but not more than 64K) of memory and will run with either hard or floppy disks. MARC will transparently support the vast majority of existing CP/M programs. In particular, pro- grams which access CP/M system calls via the “standard” low memory calling sequence will generally run. MARC has a UNIX-like file system and command interpreter. It supports I/O redirection, “wild- cards", shell scripts, and pipes. A modified BDS C compiler, oriented towards the MARC environment, and a complete set of system calls are provided. There is also a large set of utilities. An optional CRT-oriented display editor, patterned after the EMACS editor, is available. Tentative pricing for the binary, in single quantities, is $250[!], including the BDS C compiler. The dispiay editor, MINCE, is tentatively priced at an additional $100. Delivery media will probably be 4-5 single density floppys. The exact date of availability is (not recorded...Scribe]. Microsoft XENIX Gordon Letwin of Microsoft [I have no notes, foils, abstract, or paper for this talk...Scribe] The PasPort Cross-compiler System Morris E. Kranc, Intermetrics, Inc., 733 Concord Ave., Cambridge, Mass 02138, 617-661-1840, x2388 [I had the foils for this talk...Scribe] This talk described a system to develop and test software for dedicated microprocessors in a UNIX environment using PASCAL. The typical target processor is "embedded" in some larger hardware system and does not provide a suitable environment for software development. With the PasPort system microprocessor software is created in PASCAL in the friendly program development environment of a minicomputer (PWB, V7, V32, RSM-11M, VMS). The PasPort com- piler front end translates PASCAL into an interactive form similar to P-code. The back end generates assembly code for the target machine (INTEL 8086 using INTEL MCS 86 assembler or MICROTECH ASM 86 assembler or MOTOROLA 68000 using MICROTECH assembler). This assembly code may be assembled on the host or the target. The PasPort compiler is ISO (draft) standard PASCAL compa- tible plus offering separate compilation and shared global data. In the host the program can be executed interpretively from the intermediate language. Various Tun-time tools are provided. Host to target communication is provided over a RS-232 line. The cost is approximately $5000, depending on the host and options. For more information con- tact Rosemary Jenseth at the address above. 24 January 1982 Volume 7, Number 1 slogin: HCR: Products, Services, UNIX ports, and Future Directions Mike Tilson of Human Computing Resources Corp. [I have no notes, foils, abstract, or paper for this talk...Scribe] LOGIX - Relational] Database Management for UNIX Douglas I. Kalish, Logical Software, Inc., 1218 Massachusetts Ave., Cambridge, MA 02138, 617-864- 0137 [I have only the abstract for this talk...Scribe] LOGIX provides a set of tools for integrated interactive and programmatic database management. With LOGIX a user can define relations, enter and edit data, create new relations, and select items from a relation according to complex conditions. Logix also provides user-specifiable integrity and authorization constraints on the items of a relation. Items of a relation may be marked with a time stamp, providing a history of all changes. If errors are discovered in entered or deleted items a relation can be “rolled back" to a time before the changes were made. The Q Programming Language is provided for processing queries, updating relations, and writing reports. Three dialects of Q are offered, including a query language compiler which pre-compiles queries into linkable object modules that can be bound together with C functions to produce data management programs. LOGIX commands may be freely mixed with UNIX commands through I/O redirection, pipes, and filters. LOGIX is available now for the ONYX C8002 for $5000, and will be available soon for the PDP- 11 series. Word Processing Session Litigation Support John Levine, Interactive Systems Corp., 52 Shepard Street, Cambridge, MA 02138 This talk described a system being developed for lawyers to keep track of internal legal docu- ments. It will be able to store documents, search for keywords, dates, words or phrases (in the manner of fex{?]), and do flexible report generation, including customizing of formats. The retrieval system will be menu driven. Report generation will follow the dictum of "what you see is what you get". The system is expected to be available this summer. j- Just an Editor Carol Tozer, Ivie Computer Corp., 460 N. University Ave. #1, Provo, UT 84601, 801-373-1313, and Computer Science Dept., 230 Talmage Building, Provo, UT 84602 This talk described the implementation of a full screen editor that emphasizes power through sim- plicity. The simplicity of the editor allows substantially better machine utilization that existing editors with similar features. For example, viuses 2-4 times as much CPU on every benchmark they ran. The editor utilizes a split-file internal representation of files and an "input module" - "editing machine" - "screen module" organization. The former yields the CPU gains mentioned and the latter facilitates ter- minal and user-interface independence. j uses a file to define the characteristics of the keyboard. The editor uses fermcapand runs on V32 and VMS and the Z8000 and 68000, Volume 7, Number 1 January 1982 25 jlogin: The Automated Office as a Management Tool Mary Ann Jackson, M.A. Jackson & Associates, 372 N. Bundy Drive, Los Angeles, CA 90049, 213- 476-4168 The automated office covers a variety of functions from database management to MIS systems to networking to specific applications such as mail, calendar scheduling, and text processing. The talk dis- cussed the results of a study done of the time used by various levels of management and their support personnel in the areas that an automated office might be used. They found a potential time savings of 20% would be possible by automating just the specific applications. Equiptment and system criteria were established and a pilot program is being installed at the establishment where the study was done. The things that the managers interviewed wanted automated were: data base interface, project management, mail, individual data bases, word/text processing with document transfer, calendar and scheduling, file management, and, lastly, graphics. Hum - A Concordance Package for UNIX Bill Tuthill, Computing Services, University of California, Berkeley, CA 94720, g.tut@berkeley, ucbvax!g:tut This talk discussed a package of programs for literary and linguistic computing. They are particu- larly useful for the preparation of concordances’ and supporting documents. Both keyword-in-context and keyword-and-line generators are provided, as well as exclusion routines, a reverse concordance module, formatting programs, a dictionary maker, and lemmatization facilities. There are also word, character, and digraph frequency counting programs, word length tabulation routines, a cross reference generator, and other related utilities, The programs are written in C and implemented on several V7 systems at Berkeley. They have been ported to a 4BSD VAX and an Onyx system. They should be portable to any system having a C compiler that supports some kind of pipe mechanism. Use of the package on various languages, the -ms macro package, and fermcap were shown. The following names in termcap were shown to occur more than once: 2621, 300, gsi, and teleray. There was also mention of some bugs fixed in refer and an improved version of -ms that loads fas- ter because it loads only the commonly used things and .so’s the other things only when needed. Another New Text Editor Michael D. Tilson, Human Computing Resources Corp., 10 St. Mary St., Toronto, Ontario, M4yY 1P9 Canada, 416-922-1937, decvax!her!mike This talk described a new screen editor that is oriented to good typists. The editor is always in input mode; other operations are done with escape functions. The basic elements of the interface are: control functions for cursor positioning, the cursor is always in a position to replace the last item erased, a “multiply” function to increase the size of the unit to be operated on (e.g., from a character to a word to a line), and escape functions to perform other operations, The design features include terminal independence (using termcap), very simple user interface, compatibility with UNIX tools, and a command language for more complex operations. The goal was to make it possible for a typist with no prior knowledge of the editor to perform useful work after 15 minutes of training. The editor is scheduled to be available in March, 1982. Hemingway’s Rating by Style and Diction: An Analysis of The Sun Also Rises James Joyce of ITS, 415-621-6415 Bill Tuthill of UCB, 415-642-9801 Ernest Hemingway’s The Sun Also Rises is widely acclaimed as an example of good modern prose fiction. This talk presented information from the Writer's Workbench programs style and dictum on the book. These programs are described in Bell Computer Science Report #91 [2]. The printout is “an alphabetical list of all the important words of a book or author, with references to the passages in which they occur 26 January 1982 Volume 7, Number 1 jlogin: reproduced below so future users can have something to measure their own work against. readability grades: (Kincaid) 2.7 (auto) 1.6 (Coleman-Liau) 4.0 (Flesch) 5.7 (92.6) sentence info: no, sent 7354 no. wds 68551 av sent leng 9.3 av word leng 3.91 no. questions 763 no. imperatives 68 no. nonfunc wds 35087 51.2% av leng 4.94 short sent (<4) 10% (748) long sent (>19) 8% (594) longest sent 197 wds at sent 2737; shortest sent 1 wds at sent 1721 sentence types: simple 75% (5519) complex 11% (843) compound 10% (714) compound-complex 4% (278) word usage: verb types as % of total verbs tobe 26% (2964) aux 15% (1692) inf 8% (935) passive as % of non-inf verbs 3% (314) types as % of total prep 9.2% (6295) conj 3.8% (2582) adv 7.4% (5056) noun 21.2% (14563) adj 9.6% (6611) pron 14.2% (9824) nominalizations 0% (113) sentence beginnings: subject opener: noun (3401) pron (1976) pos (180) adj (187) art (465) tot 84% prep 2% (179) adv 3% (253) verb 3% (185) sub_conj 2% (138) conj 1% (72) expletives 4% (283) Applications Session A UNIX-based Image Processing System Philip A. Dondes, Lockheed Palo Alto Research Labs, Lockheed Missiles and Space Co., 3251 Hanover St., Palo Alto, CA 94304 This Lockheed Lab has 1 11/44 running UNIX. They run a general purpose image processing system called UPIPS on this system. It consists of a DeAnza Image Array Processor and programs and FORTRAN. and C-callable subprograms to manipulate images and to utilize the DeAnza. The DeAnza is connected directly to the UNIBUS and looks like 8Kw of regular memory to the CPU. Access to the data is via a phys system call buried deep in the user routines. User Psychology Elizabeth Howell, Science Applications, Inc., 1710 Goodridge Drive, McLean Virginia 22102, 703-734- 5960 This talk dealt with how users (both new and experienced) perceive a computer, and how, from this knowledge, to design applications programs that will be used. Very naive users seem to feel that the terminal is the computer, that they can "break" the com- puter by typing the wrong thing, and that they must respond as fast as the computer does in a dialogue. This is in conflict with their need to attain and maintain control of their environment. As the users experience increases the desire for control over the computer increases and they often resent messages that indicate that the computer is in charge. They also dislike disguising the computer as a person, or getting praise from a computer. Intelligently planned menus are useful. These displays should be simple, present only one idea per display, and should fit the perceptual, cognitive, and emotional characteristics of the people who Volume 7, Number 1 January 1982 27 slogin: will be using them. the people who will be using them. Ideally such displays will be as similar as possi- ble. Involving a representative user in the design and test phases can help immensely. The conflict between novice-oriented easy-to-learn and experienced user-oriented easy-to-use menus can be resolved through the following: (1) menu items that show equivalent commands, (2) prompts for com- mands that are not entered, (3) allowing short cuts of more that 1 response to prompts, and (4) 2 or more interfaces to the same functions. Good menu systems will have the following characteristics: (1) a set of standard choices (e.g., help, exit, go back to previous menu), (2) at most 6 other choices per menu, (3) a hierarchical system so the user knows where he/she is coming from and where she/he’s going, and (4) at most 3 levels (giving a maximum number of menus on the system of 1+6+ (6X6) =43). Error messages should be: clear, specific, concise, brief, polite, comprehensive. They should pro- vide positive reinforcement instead of punishment and should be constructive [amen]. For example, "date out of range” is much less useful than “date must be in the range 1970-1999". A typical user will wait approximately 7 times the average response time before becoming bored or panicky. For longer response times it is useful to print a "working..." message. Implementation of the 1979 Proposed SIGGRAPH Core Standard for Graphics Stephen Daniel, Micro Electronics Center, POB 12889, Research Triangle Park, NC 27709, Duke!swd This talk was about work in progress on implementing the 1979 SIGGRAPH proposal core. Their work adheres strictly to the proposed standard. The system is two dimensional and supports output to level 3b with most raster extensions, and input to level 3, The routines are not written for beginners, but do perform extensive error checking. Flexibility has been provided instead of speed, where a choice had to be made. A program writes a device independent segment file, which is in turn fed to a device driver. Currently the Ramtek 9400 and HP 7220 plotter are supported. The package runs on V7 and V32. Software Scaffolding Management System Peter J. Nicklin of the University of California, ucbvax'g.nicklin Inquiries should be mailed to 2700 Bancroft Way, Berkeley, CA 94704 The Software Project Management System (SPMS) provides a convenient environment for up to 10 programmers working on relatively large software projects in a variety of languages. It will accom- modate programmers with widely varying levels of experience, but is still simple to learn and easy to use. It has been used extensively for 12 months on a project with about 10 programmers and over 100,000 lines of Fortran. It runs under 4BSD. SPMS uses a project directory hierarchy and commands that know about this hierarchy. It can automatically create makefiles for libraries and programs and will provide automatic updating of libraries. It provides protection against performing operations in the wrong directories. Progress may be recorded via a logging facility. There are four types of SPMS commands: environment control, information, file manipulation, and program control. There are also facilities to tailor SPMS to different programming environments and to change the structure of things during a project. There are plans to interface SPMS to sccs UNIX-based Environments for Data Analysis and Statistics Richard Becker of Bell Labs Alan R. Wilks of Princeton University People attempting to do data analysis and statistics need a variety of tools and statistical tech- niques. A new package called S has been developed at Bell to fill this need, and is available. The S system is designed for doing data analysis, particularly exploratory analysis, and for doing research on new techniques in statistics and statistical computing. It emphasizes interactive analysis and 28 January 1982 Volume 7, Number 1 slogin: the use of graphical techniques. Its design reflects both the statistical interests of S’s users at Bell and many current ideas in computer science. The main strengths of S are the simplicity and generality of the language, the emphasis on interaction and graphics, the automatically-maintained, self-describing general data structures, and the facilities for the extension of S to new techniques. S is not designed around special classes of statistical problems; rather it provides a software environment in which extensions to new areas should be straightforward. S will run on largish V7 and later UNIX systems. A VAX is preferred, although it will run on an 11/70 or 11/45 with limitations on the size of single datasets. The system needs to have roughly 10,000,000 bytes available to hold the S system. It is very desirable to have some reasonably high- quality graphical hardware; the S user’s manual lists supported graphics devices. A request form and agreement for obtaining S are available from: Bell Laboratories Computer Information Service 600 Mountain Ave. Murray Hill, NJ 07974 A tape, user’s manual, and installation instructions will be provided in return for payment of a service charge of $150. The user’s manual can be purchased separately for $25. ABCD - A Better Circuit Description Jothy Rosenberg, Microelectronics Center, POB 12889, Research Triangle Park, NC 27709, duke!menc!jothy ABCD is a symbolic circuit design language for describing the structure and physical aspects of integrated circuits. It is based on a “virtual-grid" layout methodology. It provides a one-to-one correspondence between one line of the language and one circuit element, making interactive editing of circuit descriptions possible. The language has been implemented in a suite of library routines accessi- ble to all design tools in the system. This implementation technique has been fruitful since all pro- grams use the same parser and related routines. A designer work station consists of a VAX with 2Mb of memory and 30Mb of disk, a high- resolution color graphics system with an attached data tablet, and some alphanumeric terminals. A designer manipulates his/her design almost exclusively via the data tablet using a menu-driven interac- tive graphics editor. Blit: A Graphics Terminal for UNIX Rob Pike, Bell Labs 2C521, Murray Hill, NJ 07974, ucbvax!research!rob, CSVAX.rob@berkeley Blit is a 800x1024 bitmap terminal with a graphics mouse. It contains an MC68000 CPU with 256Kb of RAM and 24Kb of ROM. It does not have hardware graphics support or 2 disk or bus or backplane or memory management or a network interface (but one may be added). What it does offer is a reasonable terminal that can be programmed to do what you want it to. It is programmed in C which is compiled with mcc (which is being released). Blit can put several independent "layers" (win- dows) on the screen at once. Each layer is asynchronous. The lessons learned in this project are: (1) graphics can be cheap, (2) the right software can do it all, if the hardware is designed with the software in mind. Volume 7, Number I January 1982 29 slogin: Languages Session An EDISON Implementation Under UNIX Bruce Carneal, c/o WICAT, POB 539, 1875 South State, Orem UT 84067, 801-224-6400, x231 [I have only the abstract for this talk...Scribe] This talk described an implementation of the EDISON language using /ex and yacc It focused on the interface between existing UNIX tools and a retargetable code generator developed at the University of Wisconsin at Madison. The code generator uses an attribute grammar based machine description to achieve portability and tight code. Also dis- cussed were problems encountered implementing the concurrent programming features of EDISON and their possible grafting into C. Installation of the FORTH Programming Language Under UNIX Rod Schiffman, c/o 230 TMCB, Computer Science Dept., Brigham Young Univ., Provo, UT 84602 FORTH features an integrated programming environment and operating system. Although it was originally designed for programming process control applications, it has begun to find acceptance for many other applications. A FORTH interpreter{?] is normally written in assembly language and run on a dedicated machine, not under an operating system. Because of the threaded nature of coding FORTH words, up to now there has not been a faithful version of FORTH using a high-level language. The use of C and the tools available under UNIX have allowed the creation of a transportable version of FORTH. They found that they really needed an abstract data type. Interpretive Parsing of Procedure Invocations using YACC Berry Kercheval, Zehntel, Inc., 2625 Shadelands Dr. Walnut Creek, CA 94598, decvax'sytek!zehntel!berry An application required the implementation of subroutines in an interpreter. When a subroutine is encountered the seek offset for it is stored in a symbol table. When a subroutine is called the /ex buffer is cleared, the current position is stored on a stack, and then a seek is done to the beginning of the text of the routine. When the routine is done the address of the call is pulled off the stack and a seek back is done. Forward referencing is not allowed. Sign Extension and Portability in C Hans Spiller, Microsoft, Inc., The Microsoft Building, 10700 Northup Way, Bellevue, WA 98004, decvax!microso!hans The definition of the C language has left confusion regarding type casts, sign extension, and the char type. This talk discussed these problems and the lack of consistency in existing C compilers. Problems arise when converting from a shorter to a longer type: what will the high order bits be set to? If unsigned char or inline type casts are used, everything is clear. Unfortunately not all C com- pilers support declarations or casts of unsigned types. Further, not all C compilers that support these types use the same algorithm for choosing the conversion. Bell’s intent, as communicated by Dennis Ritchie to the speaker, is that C sign extend when the operand is signed and zero extend only when the source is unsigned. Several inconsistencies were pointed out between V7 PCC, V7 C, and S3 C. The solutions pro- posed were: (1) change the C Reference Manual to more clearly define chars as signed and unsigned chars as unsigned and to better define conversion of types; and (2) for the time being, if you need to write portable code do sign and zero extensions explicitly. 30 January 1982 Volume 7, Number 1 slogin: Creating a Production-Quality Cross-Compller in the UNIX Environment Morris E. Kranc, Intermetrics, Inc., 733 Concord Ave., Cambridge, Mass 02138, 617-661-1840, x2388 This talk described various problems encountered when creating their PasPort System [described in an earlier talk]. They found that the UNIX tools were useful for design, development and test, but when it came to production the tools needed were too general-purpose and inefficient to be included in their end products. An Abstract Data Type Facility for the C Language Bjarne Stroustrup, Bell Labs, 600 Mountain Ave., Murray Hill, NJ 07974, research!bs This talk described the C classconcept. A class is defined using standard C data types and func- tions. A class provides a way of restricting access to a structure to a specific set of functions associated with it, without incurring significant overhead at compile or run time. Classes are described in Bell Computing Science Technical Report #84. They have been in use for about one and a half years. They are available to universities [only?], take about 30 minutes to install, and run on the 11/70, VAX, 68000, and possibly other machines. They are implemented by an intermediate pass of cc called the class pre-processor, which is invoked when the directive #classis found in a C source file, and by a run-time library. A New Small LISP Under UNIX Alan D, Samples, Naval Postgrad School, Code 0131, Monterey, CA 93940 NAVLISP is a new small subset of LISP written under UNIX. The interpreter came from LISP 1.5, the functions from Maclisp, and UNIX provided the file system. NAVLISP is seen as an instruc- tional tool. It provides a variety of LISP functions and has such system functions as TRACE and UNTRACE, SAVE, RESTORE, and memory allocation. Since many system functions normally coded within a LISP system are accessible as UNIX processes, NAVLISP is much smailer than conventional LISP systems. It is written in C and runs on an 11/50 with separate I&D space, although it takes a maximum of 55Kb so could run on a non-separate I&D machine. Database Management Sesslon The Query Language for the Sequitur Relational DBMS Derek Wright of Pacific Software, Inc. [I have no notes, foils, or paper for this talk...Scribe] The FORMS Subroutlne Package Matthew Diaz, Johns Hopkins University, Applied Physics Lab., Bldg. 6-116, Laurel, MD 20707 The FORMS package is a general purpose set of subroutines allowing simplified input of data through screen oriented forms. Applications range from simple menu driven programs to large data entry systems. It provides automatic data checking. FORMS has been made terminal independent through the use of fermcap A form creator creates a layout file with the form as it is to appear on the screen. This is run through a program to make a template file. This template file can be edited to specify, for example, the case, range, or length of the data to be entered in each field. Three basic subroutines are provided for the actual displaying of the form and accepting the data. There is also a program to print the form. The package is in daily use by administrators. FORMS may be on the distribution tape. Volume 7, Number 1 January 1982 31 jlogin: Information Change Control System Evan Ivie & Rich Hyde, Brigham Young Univ. & Ivie Computer Corp., 460 North University Ave., Provo, UT $4601, 801-373-1313 This talk dealt with the need for a more flexible software change control mechanism and a new one, iccs, that they have produced. The objectives were to provide the following: flexible version nam- ing, change identification (who, when, why), storage efficiency, access control, sysgen help, prevention of accidental deletion, and visibility of changes. Iccs has been in use for 5-6 months at BYU and is being used at 2 other locations. It has reverse deltas (i.e., an “undo”), a simplified interface, and a tool approach. It is suitable for an individual or a project. Future directions will be towards automatic backups, an expanded “undo”, deadlock resolution, automatic audits, and file name extensions, UTMOST Office Automation System Walter D. Lazear, Air Force Data Services Center, The Pentagon, Room 1D988, Washington, DC 20330, 202-695-3652 UTMOST is a hierarchical system of user-friendly menus designed to aid the beginning or infre- quent user of UNIX, as well as the busy executive. The user progresses through a series of prompts until the desired command is completed. The menu program reads a script file, prints a tableau on the terminal, and then requests a choice from the user. Arguments following the program name are forwarded to the program at execution. Prompts and symbolic arguments are supported, along with automatic help file access and escapes to the shell. The program has been optimized to make low baud rate use tolerable. Part of the impetus behind UTMOST was the fact that UNIX is not particularly friendly towards novice and occasional users. Also, the myriad of commands increases training time. UTMOST was written for generalized office functions, although it is expandable for specific applications. A menu script consists of header lines, choice lines, and a question. The menu program is writ- ten in C and is available by sending a tape and prepaid return mailing package to the above address. UTRACKITT Samuel H. Praul, DEC, 500 Sylvan Ave., Bridgeport, CT 06606, 203-371-6947 Until May 1, 1982: ITT-PTC, 1600 Oronoque Lane, Stratford, CT 06497, 203-375-0200, decvax!ittvax'!shp UTRACKITT was developed to keep track of, and respond to, user reported problems. It pro- vides a way to let users see what has been done on their problem, and to keep track of all work per- formed while solving a problem. UTRACKITT is modeled after UCB Mail with problems and tasks taking the place of mail mes- sages. A user enters a problem into a system-wide problem file, supplying such information as problem type, priority, and a description of the problem. The “problem staff" is notified via mail when a prob- lem enters the system. The problem solution is sent via mail to the person who wanted the problem solved. A record of all work done on a problem is kept in a separate problem logfile. Problem headers (who, what, when) are kept in 2 files: current (unresolved) and archived (resolved). There is also a contact file with the name and full address of each person who has sent a problem. UTRACKITT is not available now but copies of the manual pages may be requested at the above uucp ot US mail address. 32 January 1982 Volume 7, Number 1 slogin: Review of Netnews BOF Session By Andy Tannenbaum, floyd!trb The USENET BOF session was much like the USENET itself; some useful information, some flames, some hilarity; too much information to digest in one sitting. We were forced to move the large audience from a BOF room to the main conference hall, for lack of space. Mark Horton (cbosgd!mark) of Bell Labs Columbus took his usual dictator’s stance behind the lectern, and did a fair job of control- ling the madding crowd. Mark held a short "name the net" contest, no one seemed to have much of a preference, and USENET was voted upon as the official name. Mark suggested the prospect of net., pers., and ug. newsgroups, for network, personal (netplay?), and underground (ugly?) newsgroups respectively. These distinctions would separate news that is strictly work related from news that is more frivolous from news that is downright vulgar. We con- cluded that we should not make these distinctions until we felt a pressing need. Argument from the pro-morality and pro-choice lobbyists was postponed until the session’s end. Rob Kolstad (uiucdcs!kolstad) and Ray Eissick (uiucdcs!eissick) of University of Illinois - Champaign/Urbana gave the most entertaining (though long) presentation of the conference on their replacement for the fledgling Netnews B system. Their systern is based on the PLATO Notesfile sys- tem, and has a nicer terminal interface and saner message ordering than Netnews B. The audience seemed pretty impressed with the description of the Notesfile system, but the implementation is brand new and there were murmurs of skepticism. Matt Glickman (ucbvax!glickman) of UC Berkeley talked about Netnews B. This new version of netnews is running in gamma test all over the continent and has been doing a respectable, if not bug free job. I consider it a public relations faux pas to have revealed both debutantes at the same ball. The last part of the session became the much anticipated "Battle of the Network Stars". Lauren Weinstein (ucla-s!lauren) alluded to ancient horror stories of the ARPANET concerning censorship of wine and phone phreak newsgroups, and how an ounce of prevention would be worth a pound of cure. Andy Tannenbaum (floyd!trb) of Western Electric stood in defense of free speech, truth, justice, and the American Way; a network divided will not stand, and all that. Andy also gave an impassioned tes- timonial about how great netnews is and how it has brought the quality of his life to hitherto unima- gined heights. There was much screaming, laughter, and gnashing of teeth. No conclusions were reached; after all, the participants were netnews readers. A good time was had by most. Volume 7, Number 1 January 1982 33 slogin: 1982 Application for New Membership USENIX Association Individual or Public Membership {] Individual ($12, Institution has Source License) Institutional Affiliation: Nature of Affiliation: [] Individual ($12, Institution has Binary License Only) Institutional Affiliation: Nature of Affiliation: [] Public ($12, Not covered by Non-Disclosure) Mailing Address (Individual Members must use institution address): Name: Phone: [] Overseas airmail, add $5.00 [] Invoice required, add $3.00 bookkeeping charge for invoice or receipt (] Receipt required Check enclosed: $ Return completed form to: USENIX Association Box 8 The Rockefeller University 1230 York Avenue New York, NY 10021 (For Institutional Membership or membership renewal contact the Association offices at the address above or at 212-570-8934.) Volume 7, Number 1 January 1982 35 USENIX Association Rockefeller University Box 8 1230 York Avenue New York, New York 10021