registered by australia post publication no....

5

Registered by Australia Post Publication No. NBG6524

The Australian UNIX* systems User Group Newsletter

Volume 5 Number 5

October 1984

CONTENTS

Editorial 2

Message from the President 2

Next AUUG Meeting 3

New Magazine 3

Books 4

Nets 7

Next AUUG Meeting - Call for Papers 14

AUUG Meeting in Melbourne - Abstracts 15

Domain Addressing in SUN III 28

From the USENIX Newsletter (;login:) 33

System V Performance Enhancements 36

Trivia Quiz 42

From the EUUG Newsletter 45Nijmegen Conference Summary 46

Clippings 63

Netnews 66

Minutes of the AUUG General Meeting 76

Final AUUG Constitution 78

Who’s Who 83

AUUG Membership and Subscription Forms 85

Copyright (c) 1984o AUUGN is the journal of the Australian UNIXsystems User Group. Copying without fee is permitted providedthat copies are not made or distributed for commercial advantageand credit to the source is given. Abstracting with credit ispermitted. No other reproduction is permitted without the prior

permission of the Australian UNIX systems User Group.

UNIX is a trademark of AT&T Bell Laboratories.

AUUGN Vol 5 No 5

Editorial

Well, finally, the Australian UNIX systems User Group is official.(Hooray) The office-bearers are:

John Lions - PresidentGreg Rose - SecretaryChris Maltby - TreasurerColin Webb - Returning OfficerJohn O’Brien - Assistant Returning OfficerJames Mann - Auditor

The Management Committee consists of the President, the Secretary, theTreasurer and four General members. The General members elected to theManagement Committee were:

Robert Elz, Ken McDonell, Piers Lauder and Tim Roper

I have reproduced the minutes of the meeting and the amended AUUG constitutionat the end of this issue, along With the inevitable forms for foundingmembership, membership and newsletter subscription. I have also included alist of normal and founding members, and a list of subscribers who qualify forfounding membership status.

All correspondence should be addressed to

Greg RoseHonorary Secretary, AUUG8 Meadow StConcord NSW 2137Australia

Message from the President

I would like to thank those members who attended the meeting in Melbournein August, who accepted the new constitution substantially as presented, andwho chose me as AUUG’s first president. I shall endeavour to serve you, and,in conjunction with the new management committee, to make the constitutionwork effectively°

Since the August meeting, much has happened. I attended the EuropeanUNIX system User Group’s meeting in September in Cambridge, at the invitationof David Tilbrooko This was an excellent conference, very well organised,with well-prepared talks, and a majority of speakers from North America. AoT.& To was there in strength. The glamour spot was Sam Leffler’s description ofrecent developments at Lucasfilm, finishing up with the showing of a shortcartoon of astonishing technical virtuosity. The graphics presentations fromC. Huang of UC San Francisco Computer Graphics Laboratory, and from GregChesson of Silicon Graphics, were also memorable. The most thought provokingpaper was given by Mike O~Dell on UNIX IPC: past, present and future. My ownpaper, a survey of some recent developments in this country, seemed to be wellreceived. More details of this conference will be published later.

The commercial exploitation of the UNIX system is creating many newactivities and opportunities. Early in September I learned that"’Computerworldp~ in Australia had decided to hold a UNIX-related exhibition

Vol 5 No 5 AUUGN

and conference in Sydney in May, 1985. Since then I, and more recently thewhole management committee, have met with Mr Stephen Moore of Computerworld.We have negotiated an agreement that should prove mutually beneficial to bothparties° The Computerworld conference will emphasise the commercialapplication of UNIX, and should complement, not compete with, the AUUG’straditional conferenceS. The AUUG, through its management committee and otherinterested members, wil% participa~ a~tively in organising the programme forthe May conference, and in particular, the set of tutorial sessions. You willhear more on this in due course, Fo~ ~ow~ may I ask any AUUG member who wouldlike to particpate in the organisation and/or presentation of particulartutorials at th~ May conference to contact me as soon as possible.

The organisation of the Februrary AUUG conference in Wollongong is nowwell in hand - a ¢~!! ~or papers appears elsewhere in this issue. I wouldparticularly like to encourage people w%th working, effective applications ofUNIX outside the university environmsnt to come forward and describe what theyare doing - there are many people out there who haven’t heard it all before,and who will be very inter@Bred to learn from your experiences.

Yours sincerely,

John Lions.

Next AUUG Meeting

The next AUUG Meeting will be held in Wollongong in early February 1985.Further information and the ca!! for papers appears on page XX.

New Magazine

A new glossy magazine called "UNIX/WORLD" has hit the streets. Itsdefinitely worth the introductory subscription fee (US$18 plus postage) andfor further information you should write to

Cheryl HoganCirculation DirectorUNIX/WORLD289 S. San Antonio Rd.Los Altos CA 94022U.S.A.

The network mail address of the President/publisher, John M. Knapp, is

decvax!vortex!u-world!johnk:mulga orvax135!ihnp4!dual!u-world!johnk:mulga

Contributions

As usual, more contributions please!

Opinions expressed by authors and reviewers are not necessarily those ofthe Australian UNIX systems User Group, its Newsletter or the editorialcommittee.

AUUGN Vol 5 No 5

Books

Keep an eye out for the October 1984 Bell System Technical Journal° Itis another special edition on the UNIX system and associated things,

This time we have swags more books to add to the listo If you are notkeeping your list up to date, don~t worry, I will publish the complete list inthe next issue°

Books on UNIX

19o The Business Guide To The UNIX SystemJean Lo Yates and Sandra Lo EmersonAddison Wesley

20° The UNIX Guide (2nd Edition)Pacific Micro

21o The UNIX Operating System BookMoFo Banahan and Ao Rutter

22° Operating Systems Pocket Guide: UNIXLaurie Blackburn and Marcus TaylorPitman Publishing

23° UNIX For PeoplePo Birns, Po Po Brown and John Co MusterPrentice-Hall (1984)

24° Real World UNIXHalamka(due for release late 84)

25° A Business Guide to XenixYates eto alo(due for release late 84)

26° UNIX on the IBM PCTwitty(due for release late 84)

27° Exploring The UNIX Operating SystemStephen Go Kochan(due for release late 84)

Books on C

iio C Programming GuidelinesThomas PlumPlum Hall (1984)

12~ A Book On CAI Kelley and Ira PohlBenjamin/Cummings

Vol 5 No 5 AUUGN

13. C Programmer’s LibraryJack Jo Purdum et. al.Que Corporation

14. Understanding CHunter

15° Introduction to CChirlian

16. C Programming Standards And GuidelinesThomas Plum

17. The C Programming Reference ManualSamuel P° Harbison and Guy L. SteelePrentice-Hall (1984)

18o C Programmer’s HandbookHogan(due for release late 84)

19. Programming In C On The IBM PCPollack(due for release late 84)

20° C Language UserPs HandbookWeber Systems(due for release late 84)

Related Books

7. The Small C HandbookJames HendrixReston Publishing Co, Inc (1984)(Australian Distribution through Prentlce-Hall)

8o Comparing And Assessing Programming Languages:Ada, C and PascalAlan R. Feuer and Narain GehaniPrentice-Hall (1984)

9. UNIX Applications Software Directory (2nd edition)Edited by Ray Ao JonesOnager Publishing

i0o The UNIX System Encyclopedia(This a vendor directory - Ed)Yates Ventures

iio Operating System Design:The Xinu ApproachDouglas ComerPrentice-Hall (1984)

12o Using The Horizon(TM) Spreadsheet WithThe UNIX Operating System

AUUGN Vol 5 No 5

Don BeilPrentice-Hall (1984)

13. Word Processing On The UNIX SystemKreiger(due for release late 84)

Vol 5 No 5 AUUGN

Nets

The following sites have notified me of alterations to their site

information. Most changes result from the installation of a new PABX atU.N.S.W.

Name: bio23Address:School of Biological Sciences

University of New South WalesPO Box 1Kensington NSW 2033

Phone: +61 2 697 2008Machine:

PDP 11/23 + FPU., RL02, Tektronix 4662 plotter, UNIX level 7 AUSAMContacts:Karl Redell (karl:bio23)

Name: cadvaxAddress:School of Electrical Engineering and

Computer ScienceUniversity of New South WalesPO Box 1Kensington NSW 2033


VAX 11/780, CDC 9766 via EMULEX SC21, TU45, LPAII-K,AED colour graphics terminal, Ramtek monitor, HP 7580a plotter,HP 7221c flat bed plotter, UNIX 32v/4.1bsd mixture + AUSAM

Contacts:Graham Hellestrand (hell:cadvax)Peter Maxwell (peterm:cadvax)

Name: civilAddress:School of Civil Engineering



PDP 11/40, PERTEC disks, 2*TUIO, UNIX level 6 AUSAMContacts:Damian McGuckin (damianm:civil)Weeks White (weeks:civil)Colin Wingrove (colinw:civil)

Name: comm34Address:Faculty of Commerce



DEC PDP 11/34, CDC 80Mb, AMPEX 80Mb, Pertec Tape drive, UNIX level 6 AUSAMContacts:Jimmy Sadeli (jimmy:comm34)

AUUGN Vol 5 No 5

David Sanchez (david:comm34)

Name: comm40Address:Faculty of Commerce

University of New South WalesPO Box iKensington NSW 2033


DEC PDP 11/40, RK05, Pertec (20 megabytes), UNIX level 6 AUSAMContacts:Vincent Lawrence (vince:comm40)

Name: csu40Address:Computing Services Unit

University of NSWPO Box iKensington NSW 2033


PDP-II/40, 2*RKO5-J, RKO5-F, DJ-II, 124Kw core.Unix level 7 Ausam

Serves as SUN switching node - no user accounts. (Has i0 nodes!)Contacts:So F. Mok (mok:csu60)

Name: csu60Address:Computing Services Unit

University of NSWPO Box 1Kensington NSW 2033


PDP-II/60, 2*RKO5-J, Ampex DM980 with AED 8000 controller,TUIO, 2*DZII, LVII, DPII, DRII-B, user control store.Unix level 7 Ausam

The CSU production machine - takes over from ’°csu40" except network.Contacts:So Fo Mok (mok:csu60)

Name: csuvxOAddress:Computing Services Unit



VAXII/780Contacts:

Vol 5 No 5 AUUGN

Name: csuvxlAddress:Computing Services Unit



VAXII/780Contacts:

Name: csuvx2Address:Computing Services Unit



VAXII/780Contacts:

Name: deakcmAddress:Division of Computing and Mathematics

Deakin University,Waurn Ponds VlC 3217AUSTRALIA


PDP 11/60, RK07, RLOI, TMII, DZII.UNIX level 7 AUSAM

Contacts:Craig Bishop (craig:deakcm)

Name: dslAddress:Digital Systems Laboratory

School of Electrical Engineering andComputer ScienceUniversity of New South WalesPO Box iKensington NSW 2033


PDP II/34A, AMPEX DM9100 + MSCIIO0, MDB DZ, hp 2631a serial printer,

UNIX level 7 AUSAMContacts:Jeff Skebe (jeffs:dsl)Peter Ivanov (peteri:elecvax)

Name: elec35Address:School of Electrical Engineering and

Computer ScienceUniversity of New South WalesPO Box iKensington NSW 2033


PDP 11/35, AMPEX DM9100 + MSCIIO0, UNIX level 7 AUSAM

AUUGNVol 5 No 5

Contacts:Peter Ivanov (peteri:elecvax)Keith Titmuss (keitht:elec35)

Name: elec40Address:School of Electrical Engineering and



PDP 11/40, RK05, UNIX level 7 AUSAMContacts:Peter Ivanov (peteri:elecvax)Kevin Hill (kev:elec7Oa)

Name: elec70aAddress:School of Electrical Engineering and

Computer ScienceUniversity of New South WalesPO Box IKensington NSW 2033


PDP 11/70, CDC 9766 + EMULEX sc70, TUI6, MDB DZ, LP05, Diablo 630 ECS,UNIX level 7 AUSAM

Contacts:Kevin Hill (kev:elec7Oa)Peter Ivanov (peteri:elecvax)

Name: elec70bAddress:School of Electrical Engineering and



PDP 11/70, RP04, TEl6, 2 * qume micro 5, UNIX level 7 AUSAMContacts:Kevin Hill (kev:elec7Oa)Peter Ivanov (peteri:elecvax)

Name: elecvaxAddress:School of Electrical Engineering and

Computer ScienceUniversity of New South WalesPO Box IKensington NSW 2033


VAX 11/780, RP06, TU77, Data Products B900 printer + Datasystems DLP-II,tektronix 4015-1, UNIX 32V/4olbsd mixture + AUSAM

Contacts:Kevin Hill (kev:elecvax)

Vol 5 No 5 AUUGNI0

Michael Rourke (michaelr:elecvax)Peter Ivanov (peteri:elecvax)

Name: food23Address:School of Food Technology



LSI 11/23, Pertec D4000 20Mb, AED floppy controller,(8" dbl sided dbl density), Sanders Media 12/7, HP7450A (A4 plotter),

UNIX level 7 AUSAMContacts:Ronald G. Bowrey (ron:food23)Michael So Kearney (mike:food23)

Name: mathvaxAddress:School of Mathematics



VAX 11/750, RM80, RM03, TSII, PERTEC T9640, UNIX 4.1BSD + AUSAM

Contacts:Veronica Paul (veronica:mathvax)

Name: mechAddress:School of Mechanical and Industrial Engineering


Phone: +61 2 697 4153Machine:Contacts:David Herd (davidh:mech)

Name: sriAddress:Sugar Research Institute

Nebo RoadMackayQueensland

Phone: +61 79 521511Machine:

VAX 11/750 3Mb FP750 2 Unibuses, UDA50 disk controller - RASI (456Mb),RA60 (205Mb) to come, TU80 mago tape, LP25 printer, DZll + 2 DMF32

Contacts:Colin Murphy (colin:sri)

AUUGNii

Vol 5 No 5

Name: srlAddress:School of Electrical Engineering and

Computer ScienceUniversity of New SouthWalesPO Box 1Kensington NSW 2033


PDP II/34A, RLOI, UNIX level 7 AUSAMContacts:Peter Ivanov (peteri:elecvax)Kevin Hill (kev:elec7Oa)

Name: sysconAddress:Department of Systems and Control

School of Electrical Engineering andComputer ScienceUniversity of New South WalesPO Box IKensington NSW 2033


PDP-II/34, 2 x rlOl, 2 x r102, 3 x dzll,i x AD-IIK analog-digital converter, I x AA-IIK digital-analog converter,i x KW-IIK programmable clock, NDK 4000 and DEC LAI20 printers

Contacts:Jeff Ko B. Lee (jeffl:syscon)

Name: tictocAddress:TIMEo Office Computers (Research)

6th Floor221 Miller St.North Sydney


VAX-II/750, 2 Mb, UNIBUS with TSII/TUSO lookalike (Keystone)and 2 x VMZ/32N, Emulex SC750 with Fujitsu 2351A Eagle (474Mb)and CDC RSD (80Mb pack), Dataproducts B600 line printer;UNIX System V Release 2.0

Contacts:John Mackin (john:tictoc)Geoff Cole (geoff:tictoc)Ray Loyzaga (ray:tictoc)

Name: timelandAddress:TIME. Office Computers (Software)

7th Floor221 Miller St.North Sydney


8 ECS5100 Z80 main processor, 256K main memory, Z80 network processor,Ethernet controller, i ECS5800 as for ECS5100, plus, Z80 disk processor,32 Mbyte + 12 Mbyte Winchester drive, 2 ECS5600 as for ECS5100,plus Z80 disk processor, 32 Mbyte Winchester drive,i Mbyte Floppy disk drive

Vol 5 No 5

12AUUGN

Contacts:Nell Russell (neilr:timeland)

Name: unswpowerAddress:Power Department

School of Electrical Engineering andComputer ScienceUniversity of New South WalesPO Box IKensington NSW 2033


PDP 11/40, RK05, RL02, DRIIb, ARII, TAll, UNIX level 7 AUSAMContacts:Ted Spooner (teds:unswpower)

AUUGN13

Vol 5 No 5

CALL FOR PAPERS

Australian UNIX* systems User Group1985 Summer Meeting

The 1985 Summer Meeting of AUUG will be held at the Department of ComputingScience of the University of Wollongong, Wollongong, N.S.W. on Monday,February ii and Tuesday, February 12, 1985.

The meeting will be devoted to topics of interest to the UNIX community.Presentations are invited on all aspects of the UNIX system and itsapplications. Presentations in the following categories are especiallyencouraged:

UNIX SystemsImplementation of network or distributed systems; porting of UNIX to newcomputers; system management and performance; system standards.

UNIX ApplicationsGraphics; database systems; statistical systems;business applications, transaction systems.

office systems;

UNIX Programming ToolsNew utilities; programming environments; new programming languages;their implementation.

Selection of papers for presentation will be based on the submission of asynopsis. A synopsis (extended abstract) must contain sufficient detail toenable the program committee to determine the suitability of the submissionfor presentation. A synopsis should not exceed 1,000 words. Each synopsisshould contain the following information: Title; Name of Author; Affiliationof Author; Mailing Address; Phone Number; Network Address (if available).

Abstracts must be submitted by Friday, December 7, 1984 to the addressesbelow, by either conventional or electronic mail. Authors will be notifiedconcerning acceptance by January i, 1985.

The program committee also intends to schedule panel discussions,tutorials and review or overview presentations° We are open to suggestionsfrom the UNIX user community as what sessions should be included. Suchcomments should be submitted as soon as possible.

AUUG ConferenceDepartment of Computing ScienceUniversity of WollongongP.O. Box 1144WOLLONGONG N. SoWo 2500Australia.

(042) 270 859

Network Address for enquiries,information and submission ofsynopses and suggestions: auugm:uowcsa

UNIX is a trademark of AT&T Bell Laboratories

Vol 5 No 5

14AUUGN

Winter 1984 AUUG Meeting.Programme

Monday, Auff~ust, 27

10:30: Introductory Session, Chair: Robert Elz

Introduction, Welcome, and General Business

Rob Pike, AT~I’ Bell Laboratories

The Blit: Merging Bitmap Graphics and UNIX

Introduction to the Business Meeting: John Lions

12:15: Lunch

13:45: Business Meeting: John Lions

14:30: Break

14:45: Technical Session (1): Chair: Ken McDonell

Piers Lauder, Basset Dept of Computer Science, University of Sydney

Domain Addressing in SUN III

Peter lvanov, Dept of Computer Science, University of New South Wales

A UNIX Network Information Database - or how to waste more time thanreading news.

Glenn Trewitt, Basser Dept of Computer Science, University of Sydney (on leavefrom Stanford University)

Internetwork Protocols - or how I spent my summer

16:00: Break

16:25: Technical Session (2): Chair: Piers Lauder

T.R. Cordingley and D. W.E Blatt, Maths, Stats, and C.S., Univ Newcastle

A General Purpose Multiprocessor Kernel Written in C for a UNIX Pro-gramming Enviroment

A. J. Hurst, Computer Science, ANU

JAS - A Modula Based Single User System

Keynote Address: Rob Pike, AT~I" Bell Laboratories

cat -v Considered Harmful

Close at approximately 18:00

AUUGN15

Vol 5 No 5

-2-

-Fuesda y, Auff ust, 2809:00: Business Meeting (2): John Lions

09:45: Break

10:00: Technical Session (3): Chair: Tim Long

John O ’Bri~n, Fawnray Ltd

The Architecture of the UNIX Software Factory

Dr Y Kuan Oon, Community Medicine, lt/lonash University

Computer Records Considered Harmful Under UNIX

11:00: Break

11:30: Technical Session (4): Chair: Peter Ivanov

Ron Batter, C.S.I.R.O. Division of Maths ~ StatsA Review of MH - Real Communicators Don’t Use mail

Glreg Roar, Tara Elxsi

Some Concurrency Issues in Multi-processor UNIX

MeDon,II, Dept of Computer Science, Monash University

The Pyramid 90x: An Overview and Assessment

12:45: Lunch

14:30: Technical Session (5): Chair: Ross Green

D e o FiSzG e raid, Desmond FitzGerald and Associates P/L.

An Interactive Graphics Mining Ore Reserves System

John 0 ’Brien, Fawnray Ltd

Fear and Loathing on the 32016

16:00: Conclusion

UNIX is a trademaxk of AT&T Bell Laboratories.

Vol 5 No 516

AUUGN

AUUG(Winter 84) Abstracts of Talks AUUG(Winter 84)

NAMEAustralian Unix-system Users’ Group Winter Meeting, 1984. Talk Abstracts.

SYNOPSIScat-v <<’!Page!ll!’ ! more

DESCRIPTIONThe following pages contain abstracts for talks scheduled to be given at thewinter meeting of the AUUG, 1984.Some of these were obtained over networks, and thus can reasonably be trusted.Some were obtained on paper, and transcribed. These may contain transcriptionerrors. Others are purely fictio!!

CAVEATSMany of the words in the following abstracts are registered trade marks of variousorganizations. Prominent amoung those are UNIX (AT~T Bell laboratories), DECand VAX (Digital Equipment Corporation), XENIX (Microsoft), and OSx (PyramidTechnology Corporation). The "Blit" is commercially known as the Teletype5620 Dot Mapped Display terminal.

BUGSThe order of the following abstracts is mostly governed by a desire to save print-ing costs by compressing two abstracts onto one page wherever possible. Thus,for most purposes, the order should be considered random.

DIAGNOSTICSQuiet warnin~ when a speakers time is almost up.has expired. Physical violence if he refuses to stop.

Loud warnings when his time

SEE ALSOThe actual talks.

August 27, 1984 AUUG 1

AUUGN Vol 5 No 5

17

Rob Pike

Bell Lab8 2C-521Murray Hill NJ 07974


UNIX is a multiprogramming system. A user can run several programs simultane-ously, programs that can interact (such as programs in a pipeline) or can beindependent (such as parallel compilations). The syntax and semantics of pipe-lined processes provide a powerful and convenient form of multiprogramming, butUnix’s current mechanisms for dealing with parallel independently executing pro-grams are weak: there is no convenient way to control several processes. The"job control" mechanism of the C-shell merely provides a way to describe whichof several processes the user wishes to work with now, and does not provide acapability for letting several programs run simultaneously without interferingwith, say, each other’s terminal i/o.Bitmap displays, as they have been traditionally used, take a natural first steptowards controlling a multiprogramming system. "Window systems" enable auser to store multiple program contexts on the same screen, but they have only(with a couple of exceptions) been static contexts, and are therefore incapable ofhandling multiprogramming.The extension of the window system idea to supporting multiprogramming is sim-ple conceptually, but surprisingly difficult to implement. There are interestingproblems to solve in the areas of

inter-process communicationgraphics supportuser interface.

This talk will address the problems and how they have been solved on the Blitterminal, a bitmap display built specifically for improving the user interface toUNIX. It will also discuss some of the extensions of the ideas developed to otherareas, such as game playing and text editing.

Vol 5 No 5 AUUGN18

Rob Pike



Special shorter abstract in Large, Easy-to-Read-Type:The Blit terminal developed at Bell Labs by Bart Locanthi and RobPike aims at the middle ground between time-sharing and personalcomputing, providing the advantages of high-speed interactive graph-ics against the familiar backdrop of the UNIX time-sharing system.The terminal has very inexpensive hardware, cheap and simpleenough to take home, but designed with software in mind by the peo-ple who planned to write the software and use the terminal. Theresult is a working environment which augments UNIX rather thancompete with it. Two general improvements introduced to UNIX bythe Blit world are¯ interactive graphics for (potentially) any user¯ a multiprogramming terminal to assist the multiprogramming

operating system.

This talk will focus on issues of software design (particularly the divi-sion of labor between hardware and software, terminal and operatingsystem) and user interface, and will be peppered with examples ofBlits in action.

Vol 5 No 5AUUGN 19

John O’Brien

Fawnray Ltd.

The Architecture of the UNIX Software Factory

It is intended that this talk inform members of the UNIX community of theexistence and organizational structure of the UNIX factory. Following the pressrelease earlier in the month, explanation of some details which were not disclosed.Why should Australia establish a UNIX factory?Numerous arguments justify a specialist UNIX software house. Reasons include,explosive growth in utilization of UNIX, support of local manufactures, portabilityand standardization, economies of scale, reduced duplication of effort, and utilisa-tion of research undertaken at tertiary institutions. Commercial UNIX environ-ments require software tools intrinsically different to those provided by ATg~T.What are the primary requirments of the UNIX factory?Specialist talents are required to fulfil special needs. Talents of this type havebeen cultured unwittingly by Universities. System Progammers and SystemSupervisors within these institutions usually have extensive UNIX experience.Tapping this expertise requires an organisation that understands the needs ofstaff, and customers.When should this corporation be established?It was essential that the organisation be established rapidly. Manufacturesidentified the need to have UNIX ported to their processors. The cost for eachmanufacturer porting their own UNIX is astronomical. Porting UNIX is only aminor difficulty compared with aquiring good application software. Porting UNIXand system software to manufactures hardware is essential. If the talent is notutilised now, it will go offshore. Australia will drive out it’s UNIX expertise.With whom do you start?Australian software companies tend to be under capitalised. Why Fawnray?Why AIDC?

Vol 5 No 5 AUUGN2O

Piers Dick-L~uder

Basser Department of Computer ScienceUniversity of Sydney

Domain addressing in SUN III

Much work has gone into the implementation of domain addressing in SUN HI.The introduction of domains has led to significant routing efficiencies, and enablesthe dynamic routing functions of SUN to be extended to cover a growth in thenumber of nodes to several thousand.The presentation will cover the design, routing capabilities, and installation ofdomains, and, in particular, will discuss the actual domains to be used in ACSnet.

Ken 2 McDonell

Department of Computer ScienceMonash University

The Pyramid 90x: An Overview and Assessment

The Pyramid 90x is one of an emerging class of machines designed principally torun the UNIX operating system. The Pyramid architecture features a blend ofnovel RISC-based ideas, bit-slice componentry and third-party input-output sub-systems. Together these form a machine whose base hardware is significantly fas-ter than a DEC VAX 11/780. The more unusual aspects of the hardware will bepresented, along with some insight into the potential for future speed enhance-ments.Pyramid’s UNIX port (OSx) is innovative in that it attempts to provide concurrentsupport for both AT~T’s System V and Berkeley’s 4.2BSD versions. This supportrelies upon an extension of the Berkeley symbolic link concept to conditionallymap critical parts of the filesystem (e.g. /bin, /usr/bin, /usr/lib)onto differentdirectories depending upon the system (System V or 4.2BSD) that a procss thinksit is running in. The kernel is 4.2BSD based, but all System V facilities have beenprovided for the kernel interface, the utilities and the libraries.

Like any new machine and/or UNIX port, the Pyramid has had its teething prob-lems. An attempt will be made to outline the current state of the system basedupon user experiences, and to indicate likely future developments. The perfor-mance of the current system relative to a VAX 11/780 running 4.2BSD will bediscussed.

Vol 5 No 5AUUGN21

Des FitzGerald

Desmond FitzGerald and Associates P/L

An Interactive Graphics Mining Ore Reserves System

OREX is a computer based ore reserves system for underground metalliferousmines. OREX makes use of an amalgam of software techniques. Software Toolsmethods are employed, thus the code is written in Ratfor with one extra prepro-cessor pass added for backwards and forwards user prompting support. A rela-tional data-base that mostly binds at compile time is also employed. Graphicsroutines were developed to support the display of pointed to data structures (e.g.polygons). The details of the low level graphics library are hidden from the appli-cation by a consistent set of macros. Linking to another graphics library does notrequire a rewrite, but simply the framing of a new set of macro definitions, and arecompilation.

This talk will give an introduction to the OREX system, and explain the motiva-tion for the use of the software tools methedology.

Glenn Trewitt

Basser Dept of Computer ScienceUniversity of Sydney(On leave from Stanford f.)niverMty)

Internetwork Protocolsor

How I Spent My Summer

This talk will present a comparison of some widely used internetwork protocols,including IP/TCP and X~NS. Details of an implementation of the Xerox XNS pro-tocol for System V may be presented.

Vol 5 No 522

AUUGN

Rob Pike


cat-v Considered Harmful

The UNIX system provides a method of programming- the use of tools- thathas been much discussed in books and the literature. As the system ages("matures" is inappropriate) and is applied to new problems, the command set ismodified and extended to provide new functionality.The cat program is one of the simplest UNIX commands, and its various versionsillustrate many of the issues that arise when designing programs for the UNIXenvironment. In particular, the -v option (make control characters visible) foundin some versions brings out the difficulties that arise when new functionality isdesired, such as the question of whether to write a new command or extend anexisting one, and how to design the facility to fit best in the established environ-ment.The problems of dealing with output to 9600 baud asynchronous terminals alsopoint out some of these issues. It is clear that all programs should not be modifiedto produce their output a screen at a time, but trying to centralize the solution soall programs have equal but transparent access to such a facility poses new prob-lems. The "right" answer is hard to find, but the lessons from existing tools inthe UNIX environment help decide what is right.

Greg Rose

Tara Elzsi

Some concurrecy issues in Multiprocessor UNIX

END( is a port of UNIX system V, under development in Sydney. This port runson the ELXSI 6400 Multiprocessor Computer. For leadup, this talk will give anoverview of the EMBOS operating system, and how ENIX worms it’s way in.Some implementation details pertaining to UNIX on an architecture without aprivileged mode will be discussed. The decoupling of the Enix kernel from theuser processes it controls, and the asynchronous behaviour resulting therefrom, ismentioned. A general overview of some other interesting features of this port willalso be touched.

Vol 5 No 5AUUGN 2 3

Peter Zwnov

Depertment of Computer ScienceUniversity of New South Wales

A UNIX Network Information Databaseor

How to waste more time than reading netnews

This talk will run through the history, current status and apparent trends inAustralia’s connection to, and use of, the world wide UNIX computer network.The history traces how the selfish acts of a few can lead to the profound confusionof many, and how other well meaning and intelligent people can achieve the sameresult. The implementation, use and maintenance of a UNIX network informationdatabase will be explained and an attempt will be made to sort out some of theconfusion experienced by novice users in their efforts to contact friends and rela-tions overseas.

A. J. Hurst

Department of Computer ScienceAustralian National University.

JAS - A Modula Based Single User System

JAS is a UNIX-like single user operating system implemented in Modula. It wasdesigned to provide a suitable experimental environment for the development ofsoftware systems on a Burroughs BI700 architecture.One essential aspect to the design of JAS was that it provide operating systemprimitives appropriate to the implementation of intermediate languages. Inter-mediate languages are used on architectures like the B1700 to provide a "soft"high level environment for the implementation of source languages such as Pascaland Modula, and facilities for compiler construction by migrating some complexrun time mechanisms from the compiled code to the machine architecture. Thegenerated code of the compiler is thus made simpler, at the expense of maintain-ing a microcoded architecture for that language via a suite of interpreters.Operating systems for such environments must acknowledge the existence of suchinterpreters, and support both their construction and run-time environmentthrough the provision of appropriate operating system primitives.This paper describes the design of JAS, its implementation in Modula, and somecomments (both objective and subjective) on the experience thereby gained.

Vol 5 No 524

AUUGN

T.R. ~ordingley ~nd D. W,E. BI~

Department of Mathematics, Statistics and Computer Science

University of Newcastle, N.S.W.

A General Purpose Multiprocessor Kernel Written in C fora UNIX Programming Environment

The project described in this paper aims to build a high level language environ-ment for user programming of a multiprocessor system.To make this feasible with limited resources, the system is based on "off the shelf"board level microprocessor products and available software.

The kernel is being developed using the C programming language with assemblersupport for saving and restoring process environments, interrupt interfaces, andlow level synchronization constructs. At the higher level UNIX-like interfaces willbe maintained to the extent that is possible, so that existing applications in nor-mal high level languages can be ported to the system easily.The hardware requirement for the system is a multiprocessor system with sharedmemory for interprocess communication and process management. The i/o dev-ices need no special configurations.The kernel, unlike that of UNIX, is being implemented as a set of processes thatcan be linked in from an object library depending on whether they are needed inan application or not. These processes include device drivers, process schedulingand message buffering processes, real time clock handler and UNIX file systemdrivers. The basic idea is to make an application configure a kernel for itselfthrough linking the appropriate processes at compile time.

Process synchronization and communication constructs are similar to those thatare used in ADA. They will be maintained in libraries that are linked to the userapplication at compile time also, and are being implemented, using explicitscheduling and semaphore primitives which are provided at the lowest level in thekernel. Initially program protection is to be maintained only by the mechanismssuch as type constraints enforced by the compilers. Any memory managementwill have to be performed by the application. These are not important factors inthis system because it is for a single application environment and normal multi-user problems will not occur.Development is all being done in a UNIX environment and the system will con-tinue to support UNIX in a single processor mode on a subset of the multiprocessorapplication hardware. The multiprocessor kernel is then bootable in the sameway that UNIX is booted using the stand alone support programs. This maintainsa high level of user support for the program development environment.

Vol 5 No 5AUUGN 2 5

Dept. Community Medicine,Monash University

Computer Records Considered Harmful under UNIX

Much lament has been heard about the lack of record handling under UNIX/C.There are no standard ISAM file facilities or even a file of records declaration aspossible in Pascal. Whether it was an intentional design goal or a wondrousaccident - this absence of record handling under UNIX/C encourages a new styleof computer programming where computer records are considered archaic andharmful.Much work in this department in the past three years involves the design andimplementation of medical records. The mistake that has often been repeated(until PORTA came along) is to confuse a medical record with a computer record.The fixation on computer records is a curse on the computer industry for the sim-ple reason that it locks data onto one computer system and makes portability ofdata a re-keying exercise. The portability of data is not only of relevance in themedical field - the portability problem comes in again each time you switchhardware of operating system. The handle on the portability problem of com-puter records is a FILE OF ASCII CHARACTERS or in essence, a UNIX regularfile to represent the data you would normally hold in a computer record. The fol-lowing are presented as further arguments for using the concept of data filesinstead of one file of records.1) Massive savings in programming effort as files are accessed, deleted via system

calls.2) Logical organization of data files using hierarchical tree directories.

3) Reliability, security and data integrity - as solid as a computer file. We canrely on UNIX file access control for owner, group, and outsiders.

4) Damage control- lose a traditional file, you may have lost all the records.

5) Key to UNIX - data kept as a file has as a handle the file name.

6) File repair and integrity checks are system utilities.

7) Backup simplified by incremental dump.

8) The use of shell programming makes processing of files as convenient as theold computer record system.

9) Organization of data into files makes possible the use of data languagesdesigned along lines or programming languages to lead to universal portabilityof data. Porta for medicine - Veta for vets? Denta for dentists?

10) Easy networking- file transfer across networks is a more solid propositionthan transfer of a computer record.

AUUGNVol 5 No 5 26

CSIRO, Division of Maths and Stats

Review oi~ MH- real communicators don’t use mail.

MH is a message handling system that can be used instead of the more usual’mail’ commands. Some of the features that make it different are:

instead of being a single command that then offers the user a series of options,MH provides a set of separate UNIX commands for reading, replying forward-ing, scanning headings, and so on. This means that the user-interface is theshell so that aliases and shell scripts can be used to modify this interface

instead of keeping multiple message in a single file, MH keeps each message ina separate UNIX file, This allows easy cross-referencing using links betweenfiles.

messages can be stored in folders (directories) and then grouped into sub-folders (sub-directories).

The MH system seems to have many advantages for users who handle a consider-able amount of mail, and where it is important to maintain a well organizedrecord of correspondence.

John O’Brien

Fawnray Ltd.

Fear and Loathing on the 3201(1

A talk on the trials and tribulations of porting to the National Semiconductor32016 (16032). If you like mystery and intrigue this talk is for you. Find out thenice features, the bad features, and those features which cause you to wish youhad never started the project.A brief outline of the 32000 chip family architecture, high-lighting the benefitsand short comings of the design. A history of the development that was undertaken by Fawnray. Why try and port anything besides UNIX itself. What toolsare required to undertake this work with a reasonable degree of success.The port has been completed and is currently on Beta site testing. Method ofpresentation will be the view held by the frustrated programmer. Frustrationcaused by trying to make a complex VLSI circuit behave as described in the datasheets. The treatment will be very light hearted, proving constantly that the pro-grammer is always right, the machine is just stupid.

Vol 5 No 5AUUGN 27

Domain Addressing in SUN III

Bob Kummerfeld

Piers Lauder

Sydney University

ABSTRACT

A form of hierarchical addressing employing the concept of domain

has been introduced in SUN III. Domains can be equivalent togeographical addresses, and allow a uniform presentation ofaddresses that are universally valid.

io INTRODUCTION

Computer message addresses are changing. As computer networks areinterconnected to form a world-wide net, there is a need for computer messageaddresses that will be as universally valid and as easy to use as postaladdresses or telephone numbers.

Until now, those of us using the Sydney UnixI Network2 have been livingin a simple community, as though everyone lived in the same street and it wasonly necessary to know people’s names and house numbers to identify themuniquely. Now a city has grown up around us, with links to other cities andcountries, and street addresses are no longer unique.

The concept of a domain has been introduced3 to describe the arrangementof addresses within computer networks. A domain is a grouping of computers tosupport a common purpose, such as all those computers running a particulartype of network software, or all the computers in a university campus, or allthe computers in a particular country. Domains enable us to generate acomputer network address that can not only be used to deliver a message to alocal destination, but will also deliver a message to the same destinationfrom anywhere in the world.

For example, the following table shows a traditional postal address withthe components distinguished by separate lines, together with the equivalentcomponents from a network address:

Piers LauderComputer ScienceSydney UniversityAus tr al ia

piersI

su

I. UNIX is a trademark of AT&T Bell Laboratories.

2. The latest is version III and will be referred to as SUN III.

3. ARPA RFC 882

AUUGNVol 5No 528

- 2 -

When presented to the network, the address would appear as

piers.cs.su.oz

(the line separators have been replaced by periods.)

Previously, the network address for this destination would have been

piers :basser

which has only two components and is probably easier to remember, but is only

valid in Australia on SUN sites.

The :basser is a node identifier-the name of a particular computer-and itis not something everyone should be required to remember.

There are potentially thousands of network nodes in Australia alone, and

for this address form to work, there must be some data-base that knows how todeliver a message to every one of them.

By contrast, for the domain addresses to work anywhere in the world, alocal data-base need only retain knowledge of the routes to those major

domains outside, and to each of the domains contained within, its own domain.An analogy is telephone switching, where each exchange need only remember its

own local numbers, and know how to switch calls out to other area codes.

We have sacrificed some "’user friendliness’’ to reduce a computing task,but consider the problem of communicating with other continents. Here is theaddress that must be used to reach a colleague in California at UC San Diego

Computer Science from anywhere in Australia:

decvax! ucbvax! sdcsvax! sdamos ! john :mulga

Here is a more arcane example:

decvax ! uc bvax ! @SU-SCORE. ARPA : j ohn%unc .csne t@csnet-relay :mulga

This routes first via SUN to mulga, then to decvax and ucbvax by UUCP, then byCSNET to csnet-relay, then to uncocsne/ using CSNET, which then sends to SU-

SCORE via ARPANET for delivery to user john. Caveat sende__r.

The domain version of this would be

john o SU-SC ORE o ARPAo CSNET. UUCP

but this just reproduces the problems of explicit routing, using domainsinstead of nodes. What would be best of all is the domain version of thepostal address:-

john. c s ¯ s tanfo rd .usa

Although addresses have become slightly more complex for communicating withinAustralia, they will become much less complex for the general case. And of

course there are abbreviated forms for addresses within a local domain. Inthe same way that a letter addressed to someone in Sydney from someone inMelbourne need never specify "’Australia’’, a message from Melbourne to Sydney

AUUGN29

Vol 5 No 5

- 3-

need not specify "’oOZ~’. So, for example, here are the addresses needed tOreach the author from various places:

Message source

Computer Science, Sydney UniversityPsychology Department, Sydney UniversityComputer Science, Melbourne UniversityBell Laboratories, N J, USA

Addresspierspiers .cspiers.cs.supiers.cs.su.oz

The domains taking part in this form of addressing are known as hierarchicaldomains. That is, each domain is fully contained within another, and can beconsidered as a geographical mapping. At any one level, there is a domain todescribe every area in the world. There are also non-hierarchical domains.For instance, all those sites taking part in the Australian Computer ScienceNetwork belong to the domain "’acsnet’’, and this domain crosses geographicalboundaries. One use of non-hierarchical domains is to consider them asspecial interest groups, and one may, for instance, address messages toeveryone within them. Thus the address

netgurus .* .acsnet

will deliver a message to the identity "’netgurus’’ at every site belonging tothe domain "’acsnet’’.

2. DOMAIN ROUTING MECHANISM

The underlying transport mechanism of SUN III knows how to deliver messages tohandlers at nodes. Nodes are linked to neighbouring nodes to form a network.Nodes correspond to computers, and handlers embody protocols that can addressusers.

SUN III implements domains by attaching a list of accessible domains toeach node. The route to a domain is therefore the same as the route to thenearest node (in the network routing sense) in that domain. Nodes are thelowest level in the domain hierarchy, and can be considered as domains withone member.

2.1 Primary and Secondary Domains

While a node may belong to many domains, it is considered to have one primarydomain which specifies the set of nodes from which this node will be directlyaddressable. Any other domains are secondary and specify all other domainswhose members will be directly addressable from this node.

Some of the domains will be fully contained within others, as a ComputerScience Department is contained within a University, which is contained withina country. These domains, one of which must be the primary, are considered tobelong to a local hierarchy. All other domains to which the node belongs areconsidered to be non-hierarchical. The hierarchy nominates which domains aresub-domains, each domain in the hierarchical list being completely containedwithin its successor.

The hierarchy is used to detect sub-domains in domain lists presentedfrom other nodes, and to reject different domains with the same name. Anobvious example of this problem arises where there are two local domains

Vol 5 No 5 AUUGN30

-4-

called "’cs" , but one is Computer Science at Melbourne University, and the

other is Computer Science at Sydney University.

2.2 Source Address Construction

As messages proceed through the network, they may cross domain boundaries. Ateach boundary, it is necessary to augment the source address so that themessage (or a reply) may be correctly returned to its source.

The routing mechanism at each node notices when a new destination doesnot belong to the same primary domain as the source (or most recent node inthe route), and appends an appropriate part of the local domain hierarchy tothe source address. Every time a message arrives at a node, the sourceaddress is scanned from the right hand end, and each domain to which the localnode belongs is removed. In this manner, at any one node in the route, thesource address always contains the minimum set of domains to identify thesource uniquely.

An example is given by the progress of a message addressed to a node"’snb’’ in the domain "’btl’’ inside "’usa’’ from the node "’psych23" inside

the domains "’psych" , su and "’oz" :

Node

psych23p sych44basser40bassetresearchsnb

DomainsPrimary Hierarchy

psych psych.su.oz

su psych.suooz

SH CS oSUoOZ

OZ CS.SU.OE

usa btl .usabtl btl .usa

Addresses

Source Destination

psych23 snb .btl .usa

psych23, psych snb .b tl .usa

psych23 .psych snb obtl .usa

psych23.psychosuooz snb.btl.usa

psych23, psych.su.oz snbpsych23, psych, su.o z

The source address is built up at "’psych44’’ from where the message crosses

out of the domain "’psych’’ into the domain "’su’’, .and at "’basser’’ fromwhere the message crosses out of the domains "’su" and "’oz’’ into the

domains "’usa’’ and "’btl’’. Notice that as each destination domain isreached, it is removed from the destination address.

3. INTER-NETWORK GATEWAYS USING DOMAINS

Most of the problems with current addressing mechanisms for computer messagesstem from the interfaces required at gateways between different networks. TheSUN III domain mechanism allows gateway handlers to be attached to the name of

a domain at a node. Then instead of being delivered locally, a messageaddressed to such a domain will be passed to its handler. The handler maymassage the message and its address to conform to the new network, and pass it

Thus the domain "’UUCPp" is considered to include all the nodes thatcommunicate via the UUCP network. Those nodes with interfaces to the UUCPnetwork from the SUN network will attach a gateway handler to the domain"’UUCP", and pass messages from SUN to UUCP via the handler.

Vol 5 No 5AUUGN 31

- 5-

From SUN, the gateways to UUCP are identified by their declared

membership of the domain "’UUCP’’, and messages may be routed to the nearestnode supporting the gateway.4 A simple example of an address that would makeuse of a domain gateway is

john o d ecv ax. UUC P

Such an address form is an expediency, pending the introduction of geographicdomain addressing on the other network.

4. ROUTING EFFICIENCIES

In practice, the introduction of domains has reduced the numbe~ of nodesvisible at the highest level by a factor of two. With O(n ) routingalgorithms, this is a great saving. Better still, for nodes at l~wer levels,the amount of routing information has been cut by up to a factor of ten,making network membership a much more affordable option.

There is another benefit in the area of network topology maintenance. Abroadcast address is defined as one that delivers its message to every node inthe primary domain of the sender (unless overridden by explicitly naming adomain for the broadcast). This mechanism considerably reduces networkrouting traffic, which uses broadcast addressing to distribute topologychanges, as messages that previously were sent to every node may now beconfined within the relevant domain.

4. Of course, the gateway handlers must be fairly intelligent aboutmanipulating the UUCP addresses to correspond to the alternate points ofentry to an explicitly routed network, but that’s another story.

Vol 5 No 5 AUUGN32

loginThe USENIX Association Newsletter

Volume 9 Number 3July 1984

CONTENTSUSENIX-Sponsored Workshops ......................................................................................................

UNIX and Distributed Systems Workshop .................................................................................UNIX and Computer Graphics Workshop ..................................................................................Communications and Networking Workshop .............................................................................

Future Meetings of the USENIX Association .................................................................................Future Meetings of Other UNIX Users Groups .............................................................................

Australian UNIX-Systems Users’ Group .................................................................................European UNIX Users Group .................................................................................................

System V Performance Enhancements ..........................................................................................User Level DMA I/O .............................................................................................................Faster exec System Call ...........................................................................................................Improved Read-Ahead ............................................................................................................Process ID Map ......................................................................................................................Optimum PID Allocation Strategy ..........................................................................................Dialup Line Security ...............................................................................................................

On the Design of the UNIX Operating System ..............................................................................European UNIX System User Group Meeting Report ...................................................................EUUG Nijmegen 1984 - A Report ..............................................................................................Trivia Quiz .....................................................................................................................................First Ever USENIX GO Tournament Results .................................................................................Summer 1984 USENIX Conference Survey Results .......................................................................USENIX Conference Proceedings Available ...................................................................................Summary of the USENIX Association Board of Directors Meeting ................................................Local User Groups .........................................................................................................................

3344555566778

1011121427323437383943

AUUGN

The deadline for submissions for the September issue of ;Iogin: is September 4

33Vol 5 No 5

;login:

UNIX and Computer Graphics Workshop

December 13-14, 1984

DoubleTree HotelMonterey, CA

USENIX is sponsoring a limited-enrollment workshop on current and future developments ininteractive computer graphics under UNIX, including:

¯ Large scale graphics databases¯ Real-time implementations¯ UNIX as a graphics development environment

® High speed data transfer¯ Future developments and directions.

The workshop will be structured to facilitate in-depth discussions of technical issues, and will havepresentations in a number of formats, with ample time for questions and responses. There will be acomputer graphics film and video presentation on Friday night.

In order to cover the extra expenses entailed in providing high quality visual presentations, theregistration fee will be $200, which will include a reception. The hotel rate for this conference is a spe-cial $65/night for either single or double occupancy.

For further details and application information, contact the Program Chair:

Reidar J. BornholdtRoom 7-444Columbia UniversityCollege of Physicians & Surgeons630 West 168 StreetNew York, NY 10032{harpo,cmcl2}!cucard!reidar or {ucbvax,decvax}!usenix!reidar

Program Committee:Reidar Bornholdt, Columbia University, ChairLou Katz, Metron ComputerwareTom Duff, Bell LaboratoriesPeter Langston, Lucasfilm Ltd.

Communications and Networking Workshop

October 11-12, 1984

Golden, CO

USENIX is sponsoring a limited-enrollment workshop on current and future developments in com-munications and networking aspects of UNIX.

The program chair is:Doug McCallum, NBI Inc.nbires!mccallum

Further information on this workshop will be available through the USENIX office and will be posted tonet.usenix.

4 July 1984 Volume 9, Number 3

Vol 5 No 5 AUUGN

;login:

Future Meetings of the USENIX Association

The Winter 1985 Conference of the USENIX Association will be held January 23-25, 1985, at theFairmont Hotel in Dallas, Texas. This conference is being held in the same city and at the same timeas the /usr/group sponsored trade show, UniForum. Arrangements for cross-registration for thosewishing to attend both events are being discussed with/usr/group.

The Summer 1985 Conference will be held June 11-14, 1985, in Portland, Oregon.

Future Meetings of Other UNIX Users Groups

Australian UNIX-Systems Users’ Group

The 1984 winter meeting of the AUUG will be held in the Department of Computer Science atthe University of Melbourne on August 27 and 28, 1984. An exhibition of UNIX-related computerhardware and software will be held in conjunction with the meeting. The conference dinner will beheld Monday; reservations for it must be made with advance registration. A limited number of roomsare available in the University Colleges. The meeting cost will be $30 for advance registrants, $50 onsite. For more information, contact

or

Robert ElzDept. of Computer ScienceUniversity of MelbourneMelbourne, Vic., AustraliaPhone: (03) 341 5225, International +61 3 341 5225

Prue Downie(same address)Phone" (03) 341 5232

European UNIX Users Group

The EUUG and /usr/group are sponsoring a conference and exhibition at St. Catherine’s andPembroke Colleges, Cambridge University in the United Kingdom on September 19-21, 1984. Theinvited speakers are: John Lions, Steve Bourne, Pier Dick-Lauder, Tom Killian, Mike Karels and SamLeffier.

The entrance fees are: technical sessions only - UKL 90 (students 70); technical and industrialsessions - UKL 120 (students 100); plus 15% VAT. USENIX members pay the same rate as EUUGmembers. Nonmembers fees are UKL 40 additional.

Accommodations are available at the College Residents. Registration and requests for accommo-dations should be received by the EUUG Secretary before September 3. For information contact:

Mrs. Helen GibbonsOwls HallBuntingford, Hefts. SG9 9PL United Kingdom

Phone’ 0763 73039

Volu n~U9~NN u m be r 3 July 1984

35Vol ; No 5

;login:

System V Performance Enhancements

Ken Goodwin

Senior Systems ProgrammerN.J. State Medical Underwriters, Inc.

2 Princess RoadLawrenceville, NJ 08648

Described below are a series of modifications made to the UNIX System V kerneland several commands. Changes to the kernel have resulted in a 12% decrease in sys-tem overhead, while command changes have increased usability and security. Allchanges were made on a DEC PDP-11/70 minicomputer, but are applicable to anyUNIX system. Percentages and times were obtained using the clock subroutine undersingle user conditions.

User Level DMA I/O

A facility that allows user programs to specify Direct Memory Transfers for disk operationsinvolving regular files has been implemented. It is enabled through a bit flag in the open or fcnt! sys-tem calls. DMA operations may occur for any read or write operation that begins on physical diskblock boundaries and whose transfer size is at least the same size as a physical disk block. However, norestriction is placed on the user program to insure that its transfers meet these criteria. As the I/Orequest is broken down into transfers to specific blocks by bmap, a decision is made as to whether aDMA transfer can take place from/to the disk block. If a DMA transfer can not take place, 6itherbecause the transfer does not start at a zero block offset or the count of bytes remaining to betransferred is less than the physical size of the block, then the transfer is done through the BufferCache as before. If a DMA transfer can take place, then a call to thedma subroutine is made. Thedma subroutine checks the request ~’or validity, initiates the I/O operation asynchronously through thephybio subroutine, a modified version of the standard physio subroutine, and then ’updates the count,offset, and base fields in the Per Prbcess Data Area (_u). While this transfer takes place, dma checksto see if a Read-Ahead transfer can also be done. This is determined by the presence of a read-aheadblock number in dma’s parameter list and if the updated count field is still greater than or equal to thephysical size of a disk block on the filesystem. If read-ahead can be done, another asynchronous I/Ooperation is queued through the phybio subroutine and the count, base, and offset fields are againupdated, dma then waits for all the I/O requests that it has initiated to complete. On errors, thecount, offset, and base fields are backed up to the point they were at before the error occurred andu_error is set. In this way, up to two disk transfers can be completed per invocation of the dma sub-routine. This has the effect of minimizing the number of dma calls performed and halves the numberof loops performed within the readi and writei subroutines. Changes required to implement DMA I/Owere minor. They consist of:

1. A modified version of physio (phybio) which permits asynchronous DMA queueing of I/Orequests between the Disk and user I-Space, D-Space, Kernel I-Space, Kernel D-Space, Super-visor I-Space, or Supervisor D-Space.

2. A phywait subroutine implements the iowait and error functions from the physio subroutine.3. A dma subroutine which handles the queueing of the requests, updating the relevant fields,

and dealing with error conditions.4. Changes to the readi and writei subroutines which allow them to determine if DMA I/O is

desired and permitted.

Vol 56No 5 July 198436

Volumz~t~6I~umber 3

;login:

5. A single line change to bmap to turn off Read-Ahead calculations if DMA I/O has beenselected and the next block in the file is the last block and is partially filled.

This facility has been added to the cp, dd, and cpio commands. For any filesystem using 512 or1024 byte disk blocks, the performanc6 increase for programs using this facility is approximatelytwenty-five percent. It also has the added advantage that corruption of the buffer cache by these pro-grams no longer occurs and cache hit ratios thereby increase for other programs. This facility is not foruse by every program. Candidates for DMA I/O include programs such as cp which never reference adisk block more than once. A possible modification to the stdio library to allow the selection of DMAI/O operations is anticipated. Since stdio already does buffering, there is little need in most cases foradditional buffering by the kernel. Higher performance increases are possible with larger physical blocksizes. A port of the algorithm to a Berkeley 4.2BSD system is planned.

Faster exec System Call

The exec system call now uses the new DMA I/O facility to directly load programs into their pro-cess space. A great deal of memory-to-memory overhead is thereby avoided. The performanceincrease for exec is greater than thirty percent. Since exec does not have the system call overhead ofthe standard read system call, it gains a greater performance improvement than a user level DMAoperation. No actual timing comparisons were made to calculate the performance increase for exec.For user level DMA I/O requests, each doubling of the read count resulted in a one percent perfor-mance improvement. This has been extrapolated to yield the thirty percent figure based on the analogythat an exec call translates to a single read call of process-size bytes. The performance increase maytherefore be much greater.

Improved Read-Ahead

A change to the standard method of calculating read-ahead for files has been implemented. Onstandard UNIX systems, the last logical block referenced in a file is stored in the incore inode structureas i lastr. Although this is quite adequate for One-Program One-File scenarios, it has the tendency totur~-off read-ahead all together when more than one process is referencing the same file. The bmapsubroutine determines that read-ahead should be initiated if i_lastr+l is equal to the current block thatthe process wants (i.e., the file is apparently being read sequentially). If two processes are reading thesame file sequentially, but are several blocks apart in the file, then read-ahead is turned off for the pro-cess that is further along in the file. This is due to i_lastr being flip-flopped between the last block readby each process, such that i_lastr+l never equals the block number desired by either process, The trail-ing process gains only partial read-ahead. The amount of this read-ahead depends on how fast otherprocesses gobble up buffers containing the blocks that this process has yet to reference and how muchfurther along in the file the leading process is. If the leading process is more than NBUF blocks aheadof the trailing process, then read-ahead will be totally turned off for both processes.

This standard algorithm has been modified to allow read-ahead calculations to be computed on aper-process basis. The i lastr disk address has been .replaced by a u_lbr disk address and an array ofdisk addresses u lastr[N~)FILE] in the per-process data area (_u). The rdwr subroutine has beenmodified to copy-the contents of u_lastr[FD] to u_lbr before calling readi or writei and to copy u_lbrback to u lastr[FD] when readi or writei returns. The dup and fcnt! system calls now copyu lastr[OLI~FD] to u Iastr[NEWFD] and open sets u_lastr[FD] to zero. The bmap subroutine nowuses u lbr instead of i lastr. This modification has the added advantage of freeing up much neededdata sp-~ce since the PeT Process Data Area is not a permanent physical part of kernel data space whilei lastr was. The amount of data space released is NINODE,sizeof(daddr_t). The exec system call setsu lbr to zero. This is done to allow read-ahead to proceed if DMA exec’s are not used. There is nop~rformance change for the One-Process One-File scenario, but this change increases the read-aheadperformance of the Many-Process One-File scenarios that are an integral part of large scale databasesystems.

Volume 9, Number 3 July 1984 7

AUUGlq Vol 5 iqo 537

;login:

Process ID Map

The standard Process ID (PID) allocation method in UNIX is to compare the desired new processid against the process ids already allocated in the Process Table. At best, this involves doing(v_eproc-&proc[0]) comparisons during the first MAXPID processes. On any system which managesto age past MAXPID processes, the number of comparisons performed greatly increases. This is due toPID collisions that begin to occur which make the code branch out of the process table scanning loop inorder to select an alternate PID. This new PID may also collide.

This allocation method has been repl.aced by a Process ID map strategy. The process table scan-ning is now reduced to a single linear search to locate an empty slot and to count up the number ofactive processes associated with the Process group. This eliminates the PID retry code above the pro-cess table scanner and an IF-GOTO statement within the process table scanner. This IF-GOTOstatement consumes about 2.7 microseconds on a PDP-11/70.

Originally, there were two process ID maps. One was used to hold process IDs available for useand the other was used to hold process IDs that had already been used. Two pointers were used toreference one as a New PID map and the other as an Old PID map. These pointers were initializedduring system generation.

struct map pidl [PMAPSIZ] = {mapdata(PMAPSIZ)};struct map pid2[PMAPSIZ] = {mapdata(PMAPSIZ)};struct map *newpid = &pidmapl;struct map *oldpid = &pidmap2;

The newpid map was initialized during system boot by an mfree(newpid, MAXPID, 1) call inmain. Since the size of items allocated and freed in the process ID maps is always of size one and inorder to minimize overhead, special versions of the malloc and mfree subroutines were created. Theyare called pid_alloc(map) and pid_free(map, pid). The exit system call freed used PID’s into the oldpidmap when a process died, pid_free(oldpid, p_pid). This insured that new process IDs remained uniquefor as long a time as possible. The newproc subroutine used pid_alloc(newpid) to allocate a process IDwhen creating the new process. When the newpid map was exhausted, a switch of the newpid and old-pid pointers was made. This moved the contents of the oldpid map into the newpid map and reinitial-ized the oldpid map.

struct map *swmap;swmap = newpid;newpid = oldpid;oldpid = swmap;

Another pid_alloc(newpid) was then done and should succeed. A panic situation was generated ifthis pid_alloc failed. However, the only way this could occur is if something overwrote the maps or ifthe pid_free in exit could not free a significant number of old PIDs into the oldpid map because PMAP-SIZ was too small. PMAPSIZ had to be roughly 30% greater than NPROC to allow for long term frag-mentation.

For oldpid and newpid maps which were fragmented and contained around seventy entries, thebreak-even point for this algorithm was 66 active processes in the process table. If standard malloc andmJ?ee subroutines are used to manage the PID maps, then the break-even point rose to 71 activeprocesses. This break-even point was only for the first MAXPID processes. It declined once MAXPIDwas exceeded since collisions would begin to occur at this point under the old algorithm. This algo-rithm was obviously not for small UNIX systems.

Note: two microseconds were trimmed off the average malloc subroutine call by changing themalloc code to put the size parameter in a register.

The times below are in microseconds as computed from clock subroutine calls. The tests wererun single user and are adjusted for extraneous times caused by instructions used to run the timing

8 July 1984 Volume 9, Number 3

Vol 5 No 5 AUUGN38

;login:

tests. "Frag." is short for fragmented and indicates that test was run on a fragmented map of about 70members. If not specified, then the test was run on an unfragmented map. "Alloc" is for a malloc orpid alloc call and "Free" is for m~ee or pid2free calls. "Breakeven" is the number of active processestha-~ must be present for the map strategy to break-even over the old algorithm during a single scan ofthe process table. Breakeven -- Total Frag. / 2.7/zs. "Aver." indicates the average overhead of mak-ing the subroutine call on an unfragmented map. The column headers are: "Old" - using standardmalloc/mfree subroutines,"New" - using improvedmalloc subroutine,"Pid" - using

pid_ a lloc/pid_free.Test Times

Test Old New PidAver. Alloc 34.8 32.8 29.8Aver. Free 47.75 47.75 42.19Alloc Frag. 35.54 34.43 30.53Free Frag. 153.84 153.84 146.6Total Frag. 189.38 188.27 177.13Breakeven 70.14 69.73 65.6

Note that the overhead of a free operation on a fragmented map is seventy eight percent of thetotal time in this strategy. This was deemed unacceptable and the problem was subjected to intenseanalysis. The above PIDMAP algorithm was modified as follows. The pid_free(map, pid) was removedfrom exit since this represented seventy eight percent of the overhead. The data structures werechanged to:

struct map pidmap[MAPSIZ] = {mapdata(PMAPSIZ)};int usedpids [NPROC + 2]; ,

PMAPSIZ should now be NPROC+4. The pidmap is still initialized in main by a mfree(pidmap,MAXPID, 1) call. m, wproc calls pid_alloc to allocate a process id (p->p_pid = pid_alloc0;), pid_allocnow does all the dirty work. If the pidmap has not yet been exhausted, then it returns the next avail-able PID. Otherwise, it regenerates the pidmap from the contents of the process table. The processtable is scanned and every p_pid that is greater than or equal to STARTPID is placed into a slot in theusedpids array. STARTPID is a define for the first PID which is considered in regenerating the pidmap.It is set to two on my system since PID number 1 is always in use by init. It represents the lowerbound for the range of recurrently usable PIDs. MAXPID is the upper bound for this range. Theusedpids array is then sorted via a shell sort and the sorted contents used to generate the correct entriesin the pidmap. Since this operation is only performed once in (MAXPID-NPROC) process genera-tions, great speed was not deemed necessary. Once the pidmap has been regenerated, then pid_allocreturns the next available PID as before. This modification resulted in an eighty three percent perfor-mance increase over the previous pidmap strategy.

The following test results were obtained by simulating the algorithm under three types of loads."WC" is a worst case scenario: NRPROC was 400, the number of filled slots in the process table was350, and ve proc was set to the address of proc[NPROC] so that every process table slot was examined."BC" is a b-est case scenario" NPROC was set to 200, the number of slots filled was 150, and ve_procwas set to the address of proc[150]. "NC" is a normal case scenario which simulates the tests rununder the original PIDMAP strategy by forcing the regenerated pidmap to have seventy entries’NPROC was set to 100, number of processes was 70, and ve_proc was set to the address of proc[70],For all tests, the process table was initialized with non-sequential decreasing value PIDs. This was doneso that the maximum size pidmap would result and the sort would be forced to totally invert the con-tents of the usedpid array. Because of this, the results below should be higher than what would beobtained in actual use. Under live conditions there should be many sequential PIDs in the processtable.

"Regen Time" is the time necessary to regenerate the pidmap once it has been exhausted."Alloc Time" is the average time necessary to fetch a pid from the pidmap while it still has entries in

Volume 9, Number 3 July 1984 9AUUGN Vol 5 No 5

39

;login:

it. "RT-pid" is the average time to regenerate the pidmap per pid gained (Regen Time /(MAXPID--nproc)). "Breakeven" is the number of process table entries that have to be occupied inorder for the algorithm to breakeven with the original linear search. Breakeven = (RT-pid+alloc.time) / 2.7/zs.

Test TimesTest WC BC NCRegen Time 33294.65 16638.65 16640.65Alloc Time 37.35 27.35 25.35RT-pid 1.12 .56 .56Breakeven 14.25 10.34 9.6

Note that the average breakeven point is ten processes in the process table. Small UNIX systemscan now take advantage of a PIDMAP algorithm. Also, this new strategy consumes less data space thanthe original PIDMAP strategy. In case the high Regen times on the pidmap are causing you concern,please note the following. Suppose we assume that we maintain ninety processes in the process tableduring the first MAXPID processes and the breakeven point is ten. Also, because PIDs have yet towrap around, we will experience no PID collisions. This means that each newproc call will be saving 80times 2.7 microseconds of CPU time for a total of 216 microseconds (90 processes minus 10 requiredto breakeven). With MAXPID set to 30000, which is standard for System V, this means we will use up30,000 PIDs before exhausting the map and forcing a pidmap regeneration. This means that the totalCPU time saved before regeneration is 30,000 times 216 microseconds, or 6,480,000 microseconds.After the first regeneration we will be ahead of the original algorithm by over 6,463,359.35microseconds.

One final note, this is not the optimum PID allocation algorithm. The optimum algorithm couldnot be implemented on my system as it would require 3,752 bytes of data space. Such data space ishard to come by in a PDP-11/70 System V kernel.

Optimum PID Allocation Strategy

The above algorithm can be vastly improved by replacing the memory map structure (struct mappidmap) with a bitmap where each bit represents the current status of a PID. An off bit state wouldindicate that the PID was either in use or had been recently discarded by exit. A on bit state wouldindicate that the corresponding PID was available. The bitmap is represented by an array of integers.

# define BPINT 16 /* number of bits in an integer */# define BITON 0177777 /* All bits in an int on (can be -1) */# define PMAPSIZ ((MAXPID + (BPINT - 1)) / BPINT)int pidmap[PMAPSIZ];int *pidoff;

pido.ff" is an integer pointer used to indicate the first non-zero slot in the pidmap array so that alinear search will not be necessary. Initialization and regeneration are now easy. First one turns on allbits in every integer, then one clears the bits that correspond to PIDs already in use (including PIDzero), and finally pidoff is set to the first non-zero entry of pidmap. To select a PID, the contents ofthe word pointed to by pidoff are scanned for an on bit. This bit is cleared and the new pid is

((pidoff - pidmap) ¯ BPINT) + (bit offset in *pidoff of cleared bit)

If *pidoff is now zero, then pidoff is incremented to the next non-zero entry. When pidoff exceeds theupper bound of the pidmap array, then the map is regenerated as described above. Most of the abovecan be implemented as macro calls. Since the entire algorithm can be implemented as in-line code innewproc the subroutine overhead is eliminated. Also, no sort is required. This should therefore be thefastest algorithm.

voll~ No 5 July 1984 Volume 9, Number 3AUUGN

40

;login:

Dialup Line Security

gettyThe getty command has been modified to allow a parenthesized ENVIRONMENT list to be

included as part of it’s command line. This was done in order to ease implementation of the dialupsecurity feature in login. The TERM environment variable is set for each getty line in the inittab filefor the specific terminal connected to the line. For dialup lines, the TERM variable is set to dialup.

/etc/getty ... ’(’ TERM =vtl00 TERMDEV =/dev/tty00 ’)’ .../etc/getty ... ’ (’ TERM =dialup TERMDEV=/dev/tty01 ’)’ ...

For environments with various terminal types, this allows naive users to float from terminal toterminal without worrying about the type of terminal they are logging onto.

IoginThe Iogin command now passes the environment from getty down to the shell. It also examines

the TERM variable to see if it is a dialup. If TERM is a dialup, then a dialup line security system isinvoked. This change replaces an undocumented security feature that was present in the original Sys-tem V Iogin. An /etc/dialups file which has the same format as the /etc/group file has been created. It isdivided into four colon-separated fields. The first field is the device name of a phone line (/dev/tty??).The second field is an encrypted password field, the third field is a privilege level field, and the last fieldis a comma separated list of login names for users permitted to use this dialup line. If TERM is dialup,then TERMDEV is compared against each line in this file. If no match is found, then no securitycheck is done. Otherwise, the name (/dev/tty??) of this line is displayed to help in answering the pass-word or in determining why permission to login was denied. If the password is present, then the user isprompted for the password to this line. If the privilege field is present, then the user’s privilege level inthe /etc/passwd file (currently group number) must be less than or equal to the privilege number in thedialups file for this line. If the list of users (field four) exists, then the user’s login name must be onthat list. These features may be used in any combination. If the user fails any of the security checks,then a permission denied notice is printed and the system hangs up the phone line. This can make itvery expensive for someone to try to break into the system. If the user succeeds in passing all the dia-lin security checks, then Iogin proceeds with the user name and password checks. At maximum protec-tion level, a person must know the name and password for an account on the system, must know thepassword for the dialup line that the person is authorized to use, and must know it’s telephone number.Combined with IMM modem security devices, this system provides a more formidable obstacle tointruders than standard UNIX systems. It also allows administrators to assign dialups to particular usersor groups to prevent one group from hogging the phone lines.

A modified version of the passwd command handles passwords for both the group and dialupsfiles. Modified versions of the group file subroutines provide access to the dialups file.

A dialname shell command file is called by the shell during the login procedure if TERM isdialup. This shell allows naive users to set their terminal type (TERM) when dialing into the system ina user-friendly manner. It prompts for the termcap terminal type and compares it against a known listof terminals attached to the system. If the terminal specified is not on the list, the user is allowed asecond chance to change the entry. This second chance is not checked and the entry is assumed to becorrect. This allows users using terminals not known to the system to log in properly. If done fre-quently, then the System Administrator should be requested to add the terminal type to the known ter-minal list. A RETURN entered to the prompt generates a two column list of known terminals andtheir termcap equivalents.

Volume 9, Number 3 July 1984 11AUUGN Vol 5 No 5

41

;login:

Trivia

The following quiz was distributed at the Salt Lake City conference by Rob Pike. Prizes wereawarded to the people with the most correct answers. The submission with the most correct answers(60) was from I. P. Stubbies (at team comprising David Tilbrook, Sam Lettler, and presumably others).Since they used a silly name and tried to put one over on the judges, they got a silly prize: a trophylabeled "world’s best kibitzer." Jim McKie had the best score for an individual (57) and was awardedan authenticated 1972 DECtape containing UNIX Version 2. Finally, Ron Gomes had 56 correctanswers and received an original engraved "Bill Joy" badge, which once belonged to Bill himself, fromSun Microsystems.

.

2.3.4.5.6.7.

8.9.

10.11.12.13.14.15.16.

17.18.19.20.

21.22.23.24.25.26.27.28

29.

The answers to this quiz will appear in the next issue of ;login:.The source code motel: your source code checks in, but it never checks out. What is it?

Who wrote the first UNIX screen editor?Using TSO is like kicking a [what?] down the beach?What is the filename created by the original dsw(1)?

Which edition of UNIX first had pipes?What is - =O =- ?Which Stephen R. Bourne wrote the shell?Adam Buchsbaum’s original login was sjb. Who is sjb?What was the original processor in the Teletype DMD-5620?What was the telephone extension of the author of mpx(2)?Which machine resulted in the naming of the "NUXI problem"?What customs threat is dangerous only when dropped from an airplane?

Who wrote the Bourne shell?What operator in the Mashey shell was replaced by "here documents"?

What names appear on the title page of the 3.0 manual?Sort the following into chronological order: a) PWB 1.2, b) V7, c) Whirlwind, e) System V, f)4.2BSD, g) MERT.

The CRAY-2 will be so fast it [what?] in 6 seconds?How many lights are on the front panel of the original 11/70?

What does FUBAR mean?What does "jolT" stand for?What is "Blit" an acronym of?

Who was rabbit!bimmler?Into how many pieces did Ken Thompson’s deer disintegrate?

What name is most common at USENIX conferences?What is the US patent number for the setuid bit?What is the patent number that appears in UNIX documentation?Who satisfied the patent office of the viability of the setuid bit patent?

How many UNIX systems existed when the Second Edition manual was printed?

Which Bell Labs location is HL?

32AUUGN

July 1984

42

Volume 9, Number 3Vol 5 No 5

;login:

30. Who mailed out the Sixth Edition tapes?31. Which university stole UNIX by phone?

32. Who received the first rubber chicken award?33. Name a feature of C not in Kernighan and Ritchie.34. What company did cbosg!ccf work for?

35. What does Bnews do?36. Who said "Sex, Drugs and UNIX"?37. What law firm distributed Empire?38. What computer was requested by Ken Thompson, but refused by management?

39. Who is the most obsessed private pilot in USENIX?40. What operating system runs on the 3B-20D?41. Who wrote find(l)?42. In what year did Bell Labs organization charts become proprietary?43. What is the UNIX epoch in Cleveland?44. What language preceded C?45. What language preceded B?46. What letter is mispunched by bcd(6)?

47. What terminal does the Blit emulate?48. What does "trb" stand for (it’s Andy Tannenbaum’s login)?49. allegra!honey is no what?50. What is the one-line description in vs.c?51. What is the TU10 tape boot for the PDP-11/70 starting at location 100000 (in octal)?52. What company owns the trademark on Writer’s Workbenchtm Software?

53. Who designed Belle?

54. Who coined the name "UNIX"?55. What manual page mentioned Urdu?56. What politician is mentioned in the UNIX documentation?57. What program was compat(1) written to support?58. Who is "mctesq"?

59. What was "ubl"?60. Who bought the first commercial UNIX license?61. Who bought the first UNIX license?62. Who signed the Sixth Edition licenses?63. What color is the front console on the PDP-11/45 (exactly)?64. How many different meanings does UNIX assign to ’.’?65. Who said, "Smooth rotation butters no parsnips"?66. What was the original name for cd(1)?

67. Which was the first edition of the manual to be typeset?68. Which was the first edition of UNIX to tiave standard error/diagnostic output?

Volume 9, Number 3 July 1984Vol 5 No 5

43

33AUUGN

;login:

69. Who ran the first UNIX Support Group?

70. Whose Ph.D. thesis concerned UNIX paging?

71. Who (other than the obvious) designed the original UNIX file system?

72. Who wrote the PWB shell?73. Who invented uucp?

74. Who thought of PWB?

75. What does grep stand for?

76. What hardware device does "dsw" refer to?77. What was the old name of the "sys" directory?

78. What was the old name of the "dev" directory?

79. Who has written many random number generators, but never one that worked?

80. Where was the first UNIX system outside 127?

81. What was the first UNIX network?82. What was the original syntax for "Is -1 I pr -h"?

83. Why is there a comment in the shell source "/* Must not be a register variable */"?84. What is it you’re not expected to understand?

AUUGN44

Vol 5 No 5

EUUGEuropean UN~I Systems User Group

Newsletter Vo| 4

Spring 1984

No 1

AUUG 1984 Winter Meeting AnnouncementEuropean UNIX System User Group MeetingEUUG - Nijmegen, 1984The Future of UNIXOn the Design of the UNIX Operating SystemInformation About EUUG Services

12

19243234

! UNIX is a Trademark of Bell Laboratories.Copyright (c) 1984. This document may contain information covered by one or more licences, copyrights andnon-disclosure agreements. Copying without fee is permitted provided that copies are not made or distributed forcommercial advantage and credit to the source is given; abstracting with credit is permitted. All other circulationor reproduction is prohibited without the prior permission of the EUUG.

AUUGNVol 5 No 5 ~5

European UNIX System [~ser Group MeetingFaculty of Science, University of Nijmegen, 16/18 April 1984

Peter CollinsonSecretary

IntroductionThis was a very good conference, and if you missed it, then you missed a large number of very goodtalks, the biggest exhibition at a EUUG conference to date and, of course, some Dutch beer.

This report is being done from my incomprehensible notes and mostly from the abstracts whichwere submitted before the conference began$. I must confess to missing some of the sessions; still,that is always going to happen. I also feel that this report is not up to the usual standard because Iam doing it too long after the event and this makes it difficult to precis the talks. So, where I am indoubt I have kept quiet. If have got any names wrong, then I am sorry.

However, the intention is to publish a full conference proceedings in the near future. Meanwhile,this can serve as a summary of what happened.

Day 1- 16th April 1984Emrys Jones officially opened the conference and chaired the first session.

Item 1: 10.00am Michael J. Kelly, AT&T/Teletype Corp

An Intelligent Windowing Graphics Terminal for the UNIX systemAbstract

An important feature of the UNIX System is per-user multiprogramming; that is, eachuser may control several concurrently executing processes. However, this feature breaksdown at the user interface. UNIX systems rely on "dumb" or semi-smart terminals asthe primary user interface, and these are not able to maintain several concurrent inter-faces. The solution found in BSD, job control, still does not adequately solve the prob-lem of maintaining display contexts for concurrently executing processes.

This talk was about AT&T 5620, the Teletype Cow’s version of the Blit terminal. It is a worksta-tion with a high resolution green screen, a mouse and has a reasonably powerful machine to drive it.The machine does not run UNIX because the device is a terminal and not a working CPU in itsown right. The processor is a WE 320001 CPU with 64K bytes of ROM, 256K bytes of RAMexpandable to 1 Megabyte. The terminal also has an RS232 interface.The main power of the terminal derives from an interface to UNIX System V, which allows severalwindows to be placed on the screen. Each window has its own control software running in the ter-minal and also a user level protocol handler running in the host.

Q. Is the protocol specified and available?A. Not yet

Q. Are there any cross development tools for the 32000 CPU?A. Yes.

Q. What is the availability in Europe?A. Olivetti will distribute it.

Q. will the software run on any UNIX system other than System V?

Thanks to Jaap Akkerhuis for finding them in a machine readable form and sending them to me.

2 EUUGN Vo14 Nol

AUUGN46

Vol 5 No 5

A. No comment.

Item 2: 10.30am P.Freund, Hewlett Packard

A Layered Implementation of the UNIX Kernel on the ~ Series 500Abstract

An implementation of the UNIX operating system kernel has been layered on top of anexisting operating system kernel for the HP9000 series 500 computer. The mapping ofUNIX functional requirements onto the capabilities of the underlying OS are presentedin this paper, including the changes and extensions necessary to support UNIX semanticand performance requirements. The paper covers in retrospect the advantages anddisadvantages of a layered approach.

This talk discussed HP’s approach to the implementation of UNIX System III (with those familiarBerkeley enhancements - i.e. vi). The hardware is based on a single chip 32-bit CPU with a stackbased architecture. A configuration can consist of several multiple CPU’s. HP wanted to supportoperating systems other than UNIX, and have developed an internal kernel called SUN (no relationto those other folks, folks) onto which UNIX has been layered.

The SUN kernel has memory management, process management, a file system supporting multipledirectory formats, device drivers, some I/O primitives, a real-time clock and interprocess messagepassing. It does not have a human interface because is it designed to support operating systems andnot humans. Also, there is no means to load programs.

The talk then described the ins and outs of the implementation which I hope will be reproducedelsewhere. I was left with the feeling that the system worked, but perhaps someone out there inUNIX-land might like to give a slightly less biased report.

Coffee (and a peek at the exhibition)

Session 2 was chaired by Adrian Freed, Ircam, France. I missed the next person’s name, sorry.

Item 3: ll.31amFuture directions for UNIX at Amdahl

Abstract

Donald St..?, Amdahl Corp

This talk will cover future plans for UNIX on Amdahl.

The talk started by summarising the history of UNIX running on Amdahl machines. The system iscalled UTS and runs in a virtual machine under the VM operating system, the latest release is UTS2.2 and UTS 2.3 will be released shortly. The current release has ’good V7 compatibility’. The ideaof marketing UNIX is to take advantage of an internal product which had been developed for in-house engineering use, to increase their reputation as a software vendor rather than their beingknown as simply a hardware supplier, and to make inroads into the academic community. Futureplans are to: continue leadership in the large system UNIX market and to maintain compatibilitywith the Bell Labs product at current release levels. I.e. they are working hard on System 5, whichis running in-house and at some installations of early customers.

Q. Pricing?A. An AT&T license is required, plus $1500 per month.

Q. European support?A. Yes.

EUUGN Vo14 Nol 3

AUUGNVol 5 No 5 47

Item 4: ll.53am Larry L. Crume, AT&T Bell LabsUNIX* System V Release 2.0 and Future Directions

AbstractEnhancements to UNIX System V Release 1.0 will be reviewed. These enhancementswhich are to be released in April 1984 include feature updates and improvements in thefollowing areas: C Compilation System; Job Control/Virtual Terminals; Shell; Com-mands; Cron Facility; Curses/Terminflo Package; Standard Disk and Tape Names;Accounting Package; Performance; and New Documentation.Future Directions: Future enhancements to the UNIX System will focus on the userinterface. The paging system under development at AT&T Bell Laboratories shows onedimension of the user interface for systems programmers. The architecture must be gen-eral enough to support both paging and swapping kernels and many different memorymanagement units.

The work on command syntax and error message handling provides for a consistent userinterface and to easily determine and recover for errors.

Work on unbundling and repackaging the UNIX System will provide for a consistentuser view of the UNIX System.

To fill that in a little. This year’s system from AT&T is called System V, release 2. There areseveral new applications programs which come with the system and some enhancements to theoperating system.The biggest development objective is to maintain upwards compatibility while improving perfor-mance. This does not necessarily mean that the increased speed for increased size trade-offs will bedone, but AT&T are looking at some of the UCB enhancements.Job control has been introduced. This has been done in a totally different way from the UCBimplementation because it was not desirable to introduce the necessary new signals. AT&T arecommitted to support and not extend the current set of system calls. Job control is done by havinga number of layers which define virtual terminals. On login, the user talks to a control layer andhas the ability to start a number of shells in other layers. Input and output from these virtual ter-minals canbe controlled independently.The new C compiler will have long variable names. Also, there will be a C cross compiler for theM68000.

Larry then talked about the current ideas of unbundling UNIX. The pieces will consist of a basicset of utilities plus the kernel and yes, your favourite command is bound to be missing. There willthen be several add-on pieces, such as the C language tools, the various workbenches, and other util-ity sets.

On the list of things to be looked at in future releases include: record and file locking, this will ini-tially be the/usr/group standard; bad block handling; and file system integrity, such as protectionfrom unexpected halts, ordered writes to discs, timely flushing of buffers and improved detection ofcorrupt file systems. A big thing on the list is a paging kernel in order to provide a large addressspace. Here, the main aim is to not affect users who don’t wish to have paging in their machine.To this end, an architecture for memory management has been developed, with the idea that thepaging should be easily configurable in or out. This is not on the current release, because it wasn’tgood enough.This was an interesting talk, really, packed with a lot of stuff which I feel there is no room to puthere. AT&T seem to be very responsible with the developments which they propose, it is perhapspossible that they are trying to generate too many new systems and are not leaving things to settleenough. My other main criticism is that most of the things coming out are fairly mundane andordinary, the interesting leading edge of technology stuff is staying under wraps until it becomessafe and boring. I suspect that as an academic user, I would like to have Edition 8.

4 EUUGN Vo14 Nol

AUUGN 48, Vol 5 No 5

Lunch (and a bottle of beer)

This session was chaired by Bjorn Eriksen.

Item 5: 2.05pm Bill Murphy, AT&T InternationalUNIX Licensing

Abstract

What you can and cannot do for your $43,000, $68,000 etc.Well, all Bill did was show his face and get off. The idea was that people could tackle him outsidethe main hall. Which I suppose they did.

Item 6: 2.08pm Robert Ragan-Kelley, Pyramid Technology Corp.

OSx: Towards a single UNIX system for super-minisAbstract

OSx is a dual-port of 4.2BSD and System 5 onto the pyramid 90x computer, a high-endsuper mini. OSx is designed to be fully compatible with both 4.2 and System 5 in afashion that neither suffers performance penalities from the coexistence of the other.This paper discusses some of the details of this design, both internal to the kernel and atthe user interface level, along with some of the problems we faced in its implementation.

The idea is to implement ’universes’, one called btl and the other ucb. These two names are used ascommands to switch between the two universes. It is also possible to have a command line contain-ing commands from one universe in the other, by prepending the alien command by the appropriateuniverse name.The implementation started from 4.2BSD and emulates System V. The main reasons for startingfrom 4.2BSD are the demand paging, the fast file system, flexible file name lengths and the largerblock size. Also, the 4.2BSD networking would be difficult to implement on a System V.

The main problems are: the differences in the directory structure, System V FIFO’s (named pipes),signal handling, System V IPC and worst, the differences in terminal handling and iocfl’s.

Item 7: 2.40pro Eric Allman, Britton-Lee, Inc.

The special advantages and difficulties with databases in UNIX (1)Abstract

Many applications maintain some long term state in the form of a database. In manycases ad hoc algorithms are sufficient (e.g., sequential scans of the password file are ade-quate on most systems), but often more sophisticated algorithms must be considered(e.g. mailboxes must be locked while mail is being delivered; the dictionary is too largeto be practically searched sequentially).Although ad hoc approaches are acceptable for small applications, larger applicationsoften find it convenient to utilize a full-blown database system. Such systems mayinclude such features as efficient access methods, logical independence from data struc-ture, aggregation, protection, integrity constraints, multi-file capability, concurrency con-trol, crash resilience, audit trails, and transaction control.

The structure of a database system incorporating most of these features is examined.Interfaces, data models, cost/performance tradeoffs, and the special advantages anddifficulties UNIX offers to database systems are discussed.

This, the first of two talks, gave a general introduction to database terminology and operations. Itseems to me that it would be silly to attempt to summa_rise his talk here, we’ll wait for the paperwhich will no doubt be considerably more comprehensible than anything I can write.

EUUGN Vo14 Nol 5

AUUGNVol 5 No 5 49

Coffee "~

Item 8: 3.42pm Eric Alhnan, Britton-Lee, Inc.The special advantages and difficulties with databases in UNIX (2)

The second part of the talk was concerned with the facilities which are provided by data base sys-tems and the trade-offs inherent in such systems.

Item 9:. 4.01pm P.B. Pynsent, University of East Anglia

The Norwich Renal Unit ProgranuneAbstract

In Europe 120 people per million of the population suffer from chronic renal disease andof those 80% depend on an artificial kidney machine for survival. We have developed aUNIX based computer system which not only provides access to a patient database butalso controls kidney machines during the haemodialysis of patients.The objective of the Norwich Renal Unit project is to improve patient care using com-puter technology. First we have provided facilities for computer controlled kidneymachines to optimise dialysis therapy to the individual patient and secondly we haveprovided an easy to use patient database to aid the physician in his assessment ofpatients. The UNIX operating system has proven an ideal environment satisfying boththe multitasking and data processing requirements of our project.

I really liked this talk. It is so rare at UNIX gatherings to see people who are doing something realwith computers. I think that I mean that the majority of talks at EUUG conferences are really’Computer Science’ and I would like to see more applications oriented presentations.

Item 10: 4.31pm Andrew Hume, AT&T Bell Labs Computer Research

Eric: an experimental information manipulation systemAbstract

Eric is a testbed for a model of how the user interacts with a computer system. Themajor components are the filing system, multi-tasking, the use of forms as the onlymeans of data input and a user interface dependent on a bit mapped graphics display.

The abstract does not do justice to the talk, but my notes are even worse because I spent most ofthe time concentrating on what was being said.

End of Day 1 (and onto the Hotel Erica for free drinks)

6 EUUGN Vo14 Nol

AUUGN50

Vol 5 No 5

Day 2 - |7th AprilWell, I managed to make it out of bed to chair the first session of the day.

Item 11: 9.39am Kirk McKusick, University of California, Berkeley

The Dynamic profiling systemKirk’s talk centred on the new profiler gprof which comes with 4.2BSD, and described how he hadbeen using it to improve kemel performance. The original UNIX profiler presents a flat profile ofprogram performance with the emphasis of the amount of time spent in a particular routine. Gprofdoes better than this by tracing the path through the code and giving statistics for: how often rou-tines are called; from where; and in turn, which routines were called by the routine under considera-tion. (Having used it to analyse program performance, it’s really good).Kirk then described a scientific investigation into UNIX kernel performance. He found that namei,the main directory search routine in the kernel took one quarter of the system time in 4.2BSD. Hedescribed various attempts make this go faster, pointing out that some obvious solutions appearedto improve some aspects of system peformance (i.e. Is appeared to be better) while profiling showedthat overall system performance had not really improved.’Make it work and then make it go faster’ is an old Bell Labs axiom, perhaps we should add: ’then.show it really does go faster under all circumstances’.

Item 12: lO.05am A. Burns, University of Bradford

A Comparison of the UNIX and APSE Approaches to SoftwareAbstract

An important aspect of the Ada project is the attempt to design and implement a stan-dard support environment for the development and maintenance of Ada programs. Anumber of Ada Programming Support Environment (APSE) projects exist; many areusing UNIX as a basis for the work and as the starting point for design. There are how-ever many important differences between the use of software tools under UNIX and thatenvisaged for an APSE. This paper is concerned with the use of software tools and theirinterfacing. Comparisons between a UNIX and APSE approach are given.

This was another, much needed, introductory talk.

Item 13: 10.36am Bill Weir, STC IDEC Ltd

C Unit Test HarnessAbstract

Module testing is an important and often neglected area of software testing. Tradition-ally, it has tended to be a largely undocumented operation in which the programmerpokes data interactively at a module until he believes it is working satisfactorily. Studieshave shown that tests conducted in this manner are seldom adequate in their coverage ofprogram paths. It is hoped that, by automating much of the process, and by relievingthe programmer of the drudgery of creating driver modules, collecting results, etc., moreextensive testing at a module level will be encouraged, with consequent reductions intesting and debugging costs at a later stage of the software cycle.

A talk full of interesting ideas. Bill presented a system where the testing of routines can be formal-ised and automated. I felt that I need something like this, if only to aid regression testing. Themain problem was the specification of tests.

Q. Are there any tools to help in building tests?A. No, not at present.

EUUGN Vo14 Nol 7

Vol 5 No 551

AUUGN

Q. What is the availability of this?A. Sorry, don’t know.

Coffee

The session chairman was Teus Hagen.

Item 14: ll.26am M.A. Rathwell, University of BradfordDistributed Decision Making under UNIX

AbstractDistributed Decision Making attempts to meet the need for supporting tasks whichinvolve cooperation and conflict between differentiated organisational units. A DDMsystem provides a mechanism for linking several decision support systems in an organi-sation, so enabling groups which are not necessarily linked in a hierarchical manner tocooperate with one another. This is particularly significant in planning operations whichrequire information from different people dispersed throughout an organisation. Itenable independent decision makers to semi-automate their work, explanations for deci-sions can be made widely available, and the resolution of conflict between nodes withdifferent interests and perspectives can be supported.

Item 15: ll.50am A.R. Pell, University of ReadingAn Interactive Information Retrieval System for UNIX

Abstract

Many problems exist in office and information systems for which an appropriate solu-tion is an information retrieval system. The aim of the first part of this project has beento build an easy-to-use interactive system. This has involved analysing the concepts andinformation structures needed, as well as considering the user interface. The emphasisthroughout has been to construct the system in such a way that it is easy for a noviceuser to handle. Building on the established system, the second part of the project willinvolve experimenting with differing input devices such as touch screens, mouse input,trackballs, voice, etc.

Item 16." 12.15~un Theo de Ridder~ IHBO "de MaereAutomatic Generation of Syntax Directed Screen Editors

Abstract

From a new effective and automatic error-recovery scheme for LALR(1)-parsers a pro-gram generator is developed that produces a syntax directed screen editor for anylanguage specification written in LEX and YACC.

Lunch

Session chair was Jim McKie.

8 EUUGN Vo14 Nol

AUUGN52

Vol 5 No 5

Item 17: 2.00pro J. R. Nicol, University of Lancaster

CRS - A Powerful Primitive For Resource Sharing in UNIXAbstract

This abstract focuses on a resource sharing system which we call ’CRS’ (ConnectRemote Shell). CRS is layered on top of the UNIX operating system and provides apowerful set of network services. The environment in which CRS was developed form-erly consisted of a number of PDP-11/44 mini-computers, each running UNIX. Auser’s computing activities were typically centered on one of these machines. Cir-cumstances changed when we obtained a Cambridge Ring local area network, since wewere then presented with the possibility of sharing the available computing resources.

Item 18: 2.37pm Brian E. Redman, Bell Communications Research

Honey Danber - The UUCP of the FutureAbstract

In 1978, Mike Lesk was considering a mechanism to aid in the administration ofsoftware on the growing number of computers running UNIX at Bell Labs. Heenvisioned a system that would automatically synchronise several machines with updatesfrom a single source. At the time, no networking software existed upon which to buildsuch a system, so he invented the UNIX to UNIX Copy program (uncp) to transfer filesamong machines. Little did he know that uncp would become the foremost file transferand remote execution facility for untold years to come. That which was created as atemporary measure to get data from one UNIX system to another ha.s endured throughtime as one of the most beleaguered, yet most critically required UNIX utilities.

Brian’s talk centred on a recent re-write of the uucp suite of programs which will be available onSystem 5, release 2. The re-write was undetaken by an adohoc committee and the programs are aproduct of ’software engineering’ and not just hacked together. The result is a much more flexible,faster and better controlled uncp.

Coffee ’~

Session chair was Keld Simonson.

Item 19:. 3.45pm P Tintel, Bell Telephone Manufacturing Company

EURONIX: A UNIX based system using European natural languagesAbstract

The UNIX system has gained enormous popularity. It is used in many places forsoftware development, and it is beginning to be used in office environments. However,the average office worker is no computer specialist and he has other demands concerningthe system then software developers.

The UNIX user interface as it is today has certain drawbacks for office applications andmore specific for office applications in Europe. The manuals are not very readable forsomeone not familiar with UNIX; all communication with the user is performed inEnglish (or American); and UNIX is not capable of working with the different Europeancharacters in a uniform way.

In the Euronix project, focus is on the second and third problems: EURONIX will com-municate with the user in the user’s natural language and will be able to handle in a uni-form way the special European characters.

The implementation is to alter UNIX from working in ASCII to working in the TELETEX charac-ter set which can cope with all the European ’funny letters’. In addition, all messages from pro-grams pass through a string data base in the user’s natural language.

EUUGN Vo14 Nol 9

Vol 5 No 553

AUUGN

Item 20:. 4.|6pro C. Roberts, Inf. Techn Task Force, EECSmndardisation of the national character sets

Abstract

A review of the European Standard policy for national character sets will be given. Theway it fits in the current EEC programs will be discussed: the general options of settingstandards in character sets, some examples of standards of character sets, as well as theimplementation policy (some keyboard experiments).

Item 21: 4.45pm Emrys Jones, Chairman EUUGEUUG Annual General meeting

Abstract

This is the official general meeting to present the new constitution.This meeting was held as a bootstrap device to get the new constitution off the ground. The prelim-inary constitution was passed and the new structure formally inaugurated.

And so to Dinner at the Erica ~

The idea of having a conference dinner was a good one. However, the red wine was awful. Therewere some after dinner speeches to make it taste better. Theo de Ridder made a speech which Ihave acquired in machine readable form. I am indebted to Jaap Akkerhuis for twisting his arm, legor some other piece of anatomy for it.

Item 22: 9.45pm? Theo de Ridder

After dinner with TheoDear delegates.In the past scientists used a very sensible language to express and exchange their ideas. The impor-tance of that old dead Latin was that you had to be conscious of its fixed syntax and semantics inorder to use it. At this moment I am permitted to make a speech in English, without muchknowledge of its syntactic or phonetic structure. I dare to do so because in a more interactive situa-tion no-one ever interrupts me with error messages whatever my mistakes.Looking around in an UNIX environment the simularity between a programming language and anatural one is remarkable. There is not any formal syntactic or semantic description available andstill programs are made and ported all over the world. In case of a programming error the system iskind enough not to complain about its exact type or place, it just gives you a wink that somethingwent wrong. Isn’t it a nice paradox that such an honourable human reaction is considered as typi-cally user-unfriendly?

Let me go on with an anthropomorphic view on UNIX. I am aware that most of you do have arather intimate relation with it. Using the statistical argument that for 90% you are male and willprefer the opposite sex, I conclude UNIX is female! Well gentlemen, what about your behaviourover the last decade? In any case you exploited her. Sometimes you even raped, suppressed or soldher. And some individuals had the courage to publish the insultant proposal to bring her in thepublic domain! In spite of certain parallel liberation movements in society UNIX was not able tofree herself from historical bounds into an independent respectable creature.

There is a more philosophic and fundamental aspect of the human condition than being male orfemale, and that is being mortal. So, UNIX is not eternal. She must be in one of the binary states,alive or dead, or else she is instable in illness. It is hard to prove where she is. Her growth andcontinuing changes indicate liveliness. The exponential increase however reveals a disease likecancer. And finally the cult of these meetings, the existence of gurus, and the need for myths syn-thesize the declaration of a posthumous holiness.

10 EUUGN Vo14 Nol

AUUGN54

Vol 5 No 5

After dinner it is fun to tell each other fairy tales. Maybe you need a tutorial example. I hope itwill be simple to apply the following to your own business.Once upon a time there was a princess called V6. She was considered small and beautiful by herpeople. Many a handsome academic prince came along to ask for her hand. But her mother, MaBell, locked her up to prevent disintegration of the empire. And so she became old and ugly ingrim electronic towers. Her only pleasure was looking out of a window into the silicon valley andwatching the play of the big cat AT&T with a lot of little licenced mice like ... you.

VoW4 11

AUUGNVol 5 No 5 55

Day 3 - 18th AprilWell, unlike yesterday, prolonged late night discussion kept me in bed to miss the first session. Thesession chairman was Joachim Wolff.

Item 23: 9.30am Joe Carfagno, Central Services OrganisationUsing UNIX on a large software project

AbstractThis talk is about the uses of the UNIX operating system in a large software project.Many different implementations and releases of the UNIX system, including the UNIX(1100) system, are used in a variety of ways from software development, testing, projectmanagement, site support, and others. This talk will show the versality, flexibility, andportability of the UNIX system.

Item 24: 10.05am Ludo Vemmekens, Amdald Nederland B.V.Large Systems UNIX: Opportunity for Innovation

Abstract

In bringing UNIX to the large mainframe world, there is a merging of two standards:the UNIX standard of openness, ease of use, ease of development, and the IBM largeoperating system standard of high reliability, security, performance, and support. Thecombined standards are a new challenge to the operating system products world.This paper will discuss in detail the technical issues in making UNIX a viable main-frame operating system. These include reliability, production operations management,communications, memory management, full duplex support, database, security, support,compilers, applications, coexistence with MVS, VM, and UNIX.

Coffee

I got to the hall just in time to see Andrew Hume, session chairman and contestant in the ’hairyknees of the conference competition’ make a small opening speech deploring the current fashion ofbeing rude about UCB. More power to his knees.

Item 25: ll.18am David Tiibrook, Imperial Software TechnologyThe 5 P~ffalls of Interactive Graphics

AbstractThe NEWSWHOLE system was created almost 10 years ago. A video tape of it hasbeen widely distributed and used to teach interactive graphics. One way it has beenused is to examine the way in which it avoids the 5 pitfalls of interactive graphics: Bore-dom, Confusion, Discomfort, Frustration and Panic. This presentation will discuss thosepitfalls and the design strategy used to avoid them.

The abstract does not point out the thing of which David is most proud. The system worked on ahigh resolution display and a different cursor shape was used to indicate different operations. Theone that springs to mind is the Buddha which meant ’please be patient, I am computing’. This ideais a goody, it’s one of those things which when you see you wonder why everyone doesn’t use it, butof course, you have to have the idea first.

12 EUUGN Vo14 Nol

AUUGN56

Vol 5 No 5

Item 26: ll.50am Brian E. Redman, Central Services Organisation

Behind every Binary License is the UNIX HeritageAbstract

Lately there seems to be some pessimism about the future of the UNIX system. Manywho have watched its development from the earliest days feel that the system appears togrow corrupt and is no longer a model of innovation in operating system design.Unix was originally designed by a talented fraternity with a clear and common visionfor a better environment. Ever since the system has been redesigned by a diversity ofpeople with different goals the tend to be less clear. UNIX has evolved from a simple,elegant model into one that is certainly complex and often seems convoluted. It nolonger constitutes a statement of smallness, but appears to be growing unrestricted ....

This was certainly the funniest talk of the conference, we hope to get a reprint. Contrary to popularopinion, Brian was never in the running for the hairiest knees of the conference award.

The afternoon session was chaired by Mike Banahan

Item 27: 2.02pm Andrew Hume, AT&T Bell Labs Computer Research

Processes considered as filesAbstract

Tom Killian has implemented images of running processes as full and legitimate ele-ments in the file system. The image for process nnnnn is accessed as ’/proc/nnnnn’.Read(2) and write(2) work normally except that some system data is write protected.Ioctl’s include stopping and starting a process, masking out signals that cause a stop,and returning a file descriptor for the text file (for the symbol table).

This is a neat idea costing 4K bytes in the kernel.

Item 28: 2.08pm Daniel Karrenberg, University of DortmundUniversity of Dortmund’s Spooling system

The University of Dortmund have several machines running several versions of UNIX but have fewprinters. They also have no Local Area Network, such as an ethernet. The talk described thespooling system which has been set up to cope with these problems.

Item 29: 2.15pm Andy Greener, Imperial Software TechnologyEUUG Benchmarks: some results

Abstract

The EUUG Bench mark tests have been run on a variety of VAXs running UNIX-5,BSD4.1, BSD4.2. Results are presented and discussed.

The tests were on VAXes and should be shown elsewhere in the newsletter.

Item 30: 2.29pm Johan P. Moelaert, Twente University of TechnologyA Semaphore Implementation in UNIX

Abstract

For certain purposes the UNIX system lacks strength in its possibilities of interprocesssynchronisation. Several processes waiting for one event require an abundancy of pro-cess control when implemented with signals, and this is not very reliable. Mutualexclusivity may be implemented using ’open’ and - if this fails - ’create’, but this is

EUUGN Vol4 Nol 13

Vol 5 No 5AUUGN

57

neither very elegant nor completely foolproof. The pipe mechanism offers a good instru-ment for synchronisation, but can only be used between processes that have hierarchicalrelationships. For these reasons we decided to implement Dijkstra’s .semaphores in theUNIX system.

This was an ingenious solution which added some system calls to do the semaphore user interface.The system uses the in-memory inode table to store state of the semaphore. The talk was the onlyone to actually put some C up on the screen, and for that reason alone, scored some points.

Item 31: 2.42pm Nell Mayhew, Bleasdale Computer Systems

Experiences With Implementing IBM Bisync IN UNIXAbstract

Bleasdale UNIX micros are used in a variety of situations commercial, scientific andacademic, and there is now increasing demand for distributed processing in the form ofconnecting micros to existing mainframe and database facilities.

Bleasdale’s first step towards meeting this demand was to promote file transfer facilities,including RJE (Remote Job Entry), using IBM 3780 Bisync.

Item 32: 2.55pm Theo de Ridder, IHBO "de Maere

MABENCH: a portable benchmark machineAbstract

In the computer science education (HIO) department of our institution we developed acomplete synthetic benchmark package BENCH. In BENCH it is possible to specifyarbitrary workloads with any number of parallel processes. Scriptfiles can be made byediting or by running application oriented scriptfile generators. In the output all thecharacteristic performance values (throughput, response time, service time) are given intable format.

The MABENCH system is a small portable machine which can be connected to the system undertest via normal terminal connections. The small processor (6809) then sends several scripts to thetest machine while performing measurements.

Item 33: 3.10pm Nick Nei, University of Glasgow

Measuring the Disk I/O on a VAXAbstract

This paper describes a project under way at Glasgow University to gather statisticsabout disk performance on a VAX running Berkeley UNIX 4.1. These results will beused to construct a stochastic model for the behaviour of the disk subsystem. We hopethat by modifying the parameters on the model and studying the results we can discovernew ways of improving the disk and file system performance.

It seems that the measurements show no really discernable statistical model which is applicable todisc performance.

Coffee

14 EUUGN Vo14 Nol

5~Vol 5 No 5

Item 34: 3.30pro Panel Session chaired by David Tiibrook, IST

Is there a future for UNIX?

During this session, I had to go to catch a plane. Richard Hellier from the University of Kentkindly agreed to take notes and produce a report. So here it is:

The panel was:L.L.Crume, AT&TR.Raglen-Kelly, PyramidK.McKusick, UCBH.J.Thomassen, U of Nijmegen CS Dept.M.Banahan, The Instruction Set Ltd.A.Freed, IRCAM.

Eachof the panel members made a short statement on the subject:

Does UNIX have a future, and, if so, which way is it going?

Larry Crume expects further developments in networking tools and support and much greater use ofwindowing software at every level; Many novice interfaces would be required in future. He alsomentioned the unbundling of UNIX and the simplification of the licencing process.Roger Raglen-Kelly was concerned about people hacking UNIX for the sake of UNIX itself. Hethought that UNIX was already too big and that something should be done to arrest the growth.What he wanted to see: was better internal support for multiprocessing and true networking; func-tional and object-oriented programming languages & shells.Kirk McKusick reminded everyone that the days of formal releases of code from Berkeley were overand that they were returning to being a research institute.Adrian Freed stressed the importance of separating UNIX from UNIX-based applications; With thepreponderance of commercial and industrial users of UNIX, he felt that only a minority of UNIXusers cared what the underlying system was. All they are interested in is their Spreadsheet, Data-Base or whatever.

H.J.Thomassen followed up this line, later amplified by Teus Hagen, and pointed out that theAcademic Community was moving in a different direction from the business community.Questions and comment were taken from the audience.Emrys Jones introduced a point of information, namely that Computer Magazines & Journals, as agroup, were now outselling "girlie" magazines. He asked,

Did the panel fe!! that the "hobbyist" section of the user community wouM ever have much impacton the UNIX community as a whole?

Due to the fragmentation of the enthusiast sector, no-one anticipated any significant developmentsfrom this area.

Teus Hagen pointed out that although business users may be moving one way, any individual userwill still be free to follow his own path.

Another speaker emphasised that UNIX should be viewed as a way of doing things rather than as astatic entity.Following a prediction of researchers moving away from UNIX towards, say, expert and knowledgebased systems, Eric Allman noted that all this new code would have to be developed somewhere,and probably on UNIX systems.

Kirk McKusick spoke of possible further developments of the UNIX kernel to support concurrentrunning for tightly-coupled multiprocessor systems.

Replying to a question on the conformity of AT&T products to/usr/group standards, Larry Crumesaid that AT&T were part of /usr/group and so their code would be 100% compatible with thoserecommendations.

EUUGN VoI4 Nol 15

AUUGNVol 5 No 559

Several speakers expressed concern that the UNIX tradition of distributing source code, even of thekernel, would not be upheld by the commercial users and software-houses. Larry Crume affirmedthat AT&T would continue to supply source code with System V and its successors. Many atten-dees wanted some form of pressurisation on business users to distribute sources of their products.Before taking up the legal aspects of this topic, Mike Banahan observed that few business users careabout source code; All they want is a tool for a job, he felt.

The next question was:

How can software developers protect their investment unless they restrict source?Eric Allman, speaking for Britton-Lee, pointed out that small firms simply could not afford evenone lawsuit to test a copyright case. He quoted ’one week to liquidation’ if his firm ever becameinvolved in such an action. Only the giants, like AT&T, could afford such a case. Britton-Lee willsell the source, but at a high price.

There was then a brief discussion of the impact of APSE technology on the UNIX community.Several speakers feel that even if the project fails to achieve its goals, like Multics, it will contributemuch to the industry.

In response to the alleged unchecked growth of the UNIX kernel, Kirk McKusick observed that sizemust be traded off against functionality, i.e. that a kernel with a given set of services must be of atleast a certain size.

The final topic was the future of Inter-Process Communication, instigated by Dave Tilbrook. LarryCrume felt that, in the current absence of any formalism for describing IPC we still don’t knowwhich way to go. None of the panel members would be drawn on this one.

Eric Allman observed that IPC enables software developers to write code that runs in user spaceand then move it into the kernel if memory allows.There was a general view that there must be a logical separation between particular applications andthe IPC mechanisms they employ. IPC enables us to communicate rather than convert software.That is, when some new service becomes available we converse with that rather than its predecessor,and to keep the applications small.

This spawned a nostalgic side-discussion about the good-old-days of Version 6; Eric Allmanobserved that much of the "elegance" of that system arose from its implementation on a particularmachine architecture, i.e. PDP 11, and that many of the techniques employed were simply the onlyways to proceed on such a machine.

As a postscript, there were a few questions about the purpose, or lack of it, of having future EUUGmeetings.

16 EUUGN Vo14 Nol

AUUGN6O

Vol 5 No 5

Tutorial sessionsA number of tutorial sessions were run is parallel to the main meeting. A summary of each sessionis given here. The summary is derived from the meeting programme as I cannot be in two places at "once (sometimes, I can’t even be in one place at once).

Day 1 - April 16th

Item 1: 2.00pro Mike Banahan, The Instruction SetAdvanced editing: ed, ex, vi, etc.

The common aspects of line-oriented, screen-oriented and more advanced editors will be given.How to write your own editing macros, how to handle key stroke definitions and how do you pro-gram in your favourite editor’s very own command language.

Item 2: 3.45pm Bill Murphy, AT&T InternationalLicensing, workbenches and UNIX System V 2.0

An overview of all the UNIX packages from AT&T Int. are given. Prices, availability and futuredevelopments to be expected. Most of the topics about licensing will be addressed.

Day 2- April 17th

Item 3: 9.30am Mike Banahan, The Instruction SetAdvanced Shell programming

Just using one command with some arguments is easy. How you can make use of all the features ofthe UNIX command interpreter is some more difficult. It is addressed how you can make yourcommand life easy - no flags, just combinations of existing commands. Yes, you can program inShell.

Item 4: ll.15am Jim McKie, Centrum voor Wiskunde en InformaticaUNIX 4.2 BSD

What 4.2BSD gives you, doesn’t give you, gives you too little of, and, of course, what it gives youtoo much of.

Day 3 - April 18th

Item 5: 9o30am Nigel Martin, University College LondonThe UNIX market

An overview of the market situation concerning machines with UNIX will be given. How do theydiffer and what kind of choice should be taken? The direction of this market. Slides of the rivalswill be shown.

Item 6: ll.15am Teus Hagen, Centrum voor Wiskunde en Informatica

UNIX networking with UUCP

How do you connect your machine to the outside world. Maintenance, structure, software and con-nection costs for an UUCP link. Statistics, software layers and tools are also addressed.

EUUGN Vol4 Nol 17

AUUGNVol 5 No 5 61

Item 7: 2.00pro Jaap Akkerhuis, Centmm voor Wiskunde en Informatica

Advanced Text processing

Text processing is not like word processing. To layout your text nicely, you should know moreabout the possibilities of n/troff, eqn, tbl.

EndpieceWell, that’s it for another EUUG conference. The papers which constute the proceedings will bepublished separately.

Thanks are due many people who worked very hard to make the event a success. Hendrik-JanThomassen and George Roll headed up a team of tireless workers. David Tilbrook did the pro-gramme organisation aided and abetted by Teus Hagen. The EUUG secretariat, Helen and Debbie,did their usual good job.And the winner of the ’hairy knees of the conference’ award? Well, it was a close run thing. Butsince there were only two competitors, and both were Australian, the winner must be RichardGrevis.

1~ EUUGN Vo14 Nol

Vol 5 No 5AUUGN 62

Clippings

Clippings this issue are

1984.ENHANCEDSUPERMICROSEmail Computer Systems has an-nounced a range of enhancementsto its range of Unison supermicrocomputers to increase speed andreliability. The Unison 5.25 in Win-

chester disc system with the ST506controller can control up to twodrives ranging in capacity from 10to 160 Mbytes. The controller,which includes the Motorola 68450DMA controller and Western Digi-tal’s 1010 VLSI device, enablesdisc access at up to five times thespeed of the IMI Winchester drivescurrently used in the Unison range.The SMD-IMI translator board pro-vides current Unison users with anupgrade path to obtain higherperformance from an IMI drive andretain their current Winchesterdiscs. New magnetic tape controllerboards have a resident M68000processor to buffer the I/O logicand will form the basis of thePICOBUS interface to drive 9-trackstreaming tape units. Another pro-duct soon to be released is a distri-buted processor approach to an8-channel VDU controller whichhas its own M68000 processor onboard and will speed up I/O trans-actions. Email has two new-.f, astmemory boards; a 512 Kbit un-mapped, zero-wait state systemmemory board designed to run theUNIX kernel; and a 128 Kbit fastmanaged RAM board developed toeliminate all memory wait states.Email has also been developingand benchmarking I0 and 12 MHzversions of the CPU board for theUnison product range (the Unisoncurrently uses a 8 MHz CPU).These enchancements will enablethe Unison range to support up to16 users on the UNIX operatingsystem. Unisam, a powerful filehandler, supplements UNIX byproviding a multi-user record man-agement system that can be inter-faced to a variety of languages andhas a hardwareqndependent VDUI/O system. Email is also develop-ing an interface which will enableUnison computers to communicatevia Ethernet, providing a completeoffice automation environment.Email Computer Systems.Cnr Canterbury & Liverpool Roads,Kils~h 3137

AUUGN

from "What’s New In Computing", July and August

FULL 32-BITMICROPROCESSORThe Motorola MC68020 microp-rocessor is presented as the firsttrue 32-bit design in that it includesnon-multiplexed 32-bit internal/external data and address paths --all 32-bit registers, all 32-bit arith-metic and logic units, all 32-bitprogramme counters and all 32-bitstack pointers. The MC68020 ismanufactured using a 2-micronHCMOS process that integratessome 200,000 individual transistorson a 375 x 350-mil die which ispackaged in a space-efficient,114-1ead, pin grid array package.The MC68020 operates at a 16.67MHz clock frequency (.60 ns clock

period), dissipates less than 1.5 W,and is completely upward user-object code compatible with earliermembers of the M68000 familywhich has always offered a 32-bitarchitecture and now provides thefull power of 32 bits with theMC68020. In addition, the deviceincludes many new features whichfully exploit the complete 32-bitdesign. The full 32-bit designstructure of the MC68020 providesfor direct linear access to 4 giga-bytes of logical memory and elimi-nates instruction timing differencesfor byte, word and long word op-erations. The device processes in-structions at a sustained rate of 2-3million instructions per second(MIPS) and at burst rates exceed-ing 8 MIPS. The MC68020 fullysupports virtual memory and vir-tual machine concepts. Virtualmemory gives each programmeaccess to the 4-gigabyte logical ad-dress space while allowing the sys-tem to contain significantly lessphysical memory. The MC68020provides a means to extend its ar-chitecture to off-chip devicesthrough its co-processor interface.This interface allows devices suchas the MC68881 floating pointco-proc~essor to execute instruc-tions as a part of the main instruc-tion stream. The 256-byte instruc-

tion cache allows simultaneousdata and instruction accesses andexecution as well as overall im-provement of the performance ofthe system. The MC68020 con-tains a bus interface that provides,on a cycle-by-cycle basis, the abil-ity to adjust its data bus width toaccommodate 8-or 16-or 32-bitdevices. The programmer is nolonger required to develop prog-

rammes that are data bus depen-dent, as the MC68020 willdynamically make the necessaryadjustments. Additionally, existing8 and 16-bit periphera~l subsystemscan be used. with the 32-bitMC68020 by taking advantage ofthis feature. The MC68020 alsooffers extra addressing modes andinstructions to further support highlevel language development. Inaddition, 32-bit extensions toexisting instructions are provided.The additional addressing modesinclude full 32-bit displacements,true memory indirection and scaledindexing. The new instructions in-clude an entire family of bit-fieldoperators, double-ended boundschecking, BCD data compressionand expansion, module supportand enhanced system calling func-tions. To efficiently handle taskswitching, as well as to separatetask-related exceptions iromsystem-related exceptions, twosystem stack pointers are availableto the supervisor programmes. Th~master stack-pointer is associatedwith the user task so thal all task-related exceptions are carriedwithin the user’s process controlblock. When a non-task related ex-ception occurs, the interrupt stackis used for the remainder of systemlevel processing until a new usertask is initiated. Motorola offerscross support under its Umxoperating system-derived systemV/68 operating system and Its realtime Versados operating system.These operating systems are avail-able on either the Exormacsmulli-user development system orthe VME/10 microcomputer sys-tem. A high-performance operatingenvironment is offered in the formof the Benchmark 20 system,which provides the capability ofevaluating the MC68020. Thissystem contains a high-performance CPU board as well asone megabyte of dynamic RAMMotorola Semiconductor Products.250 Pacific Highway,North Sydney 2060

63Vol 5 No 5

UNIX=BASEDSOFTWARE FAMILYThe Ventures Division of Cincomhas released the CX/Xtend family ofsoftware, designed specifically forUNIX-based operating environ-ments. The fully integrated family ofproducts includes both applicationdevelopment aids and end-userproductivity tools. CS/DBX is a re-source efficient data base systemthat is fully compatible with Cin-com’s Total data base managementsystem, accommodates networkand hierarchical data structures,and, through a sequential view pro-cessor, supports complete inversioncapabilities. Comprehensive log-ging, recovery, and restart featuresare built-in. Any number of usersmay access the data base concur-rently. A powerful application de-velopment aid, CS/TMX offers highlevel facilities for generating, coding,and maintaining CRT screen dis-plays independently of user-writtenprogrammes. CS/TMX also includesa comprehensive security systemthat can be used to restrict a user’saccess to only authorised program-mes, at authorised terminals.Facilities are also provided tomonitor a control network activity.Applications developed for use withCS/TMX are completely indepen-dent of terminal devices. CS/RMXprovides relational access to the database for inquiries and report writing.Also implemented on mainframesand minicomputers, the system al-lows end-users to quickly retrieveselected information by usingEnglish-like commands. Retrieveddata can be displayed on a terminal,directed to a printed report, or both.Users can specify multiple selectioncriteria, perform arithmetic opera-tions on the data as it is retrieved,and control the sequence of the out-put. Output formats to either thescreen or printed reports may begenerated automatically, or de-signed by the user. CS/Xpress is aninteractive, interpretive system de-signed to make it easier to createcomplete application systems. Auser can interactively design a com-plete screen format and describeeach field’s data edit characteristics.The user can enter and edit data andstore it in the data base. Data fieldsthat will be used as keys to the re-cords on file can be specified. CS!Xpress files are created dynamically,together with a directory describingthe characteristics of each new file.Users can display records and/orupdate or delete records that are al-ready on the data base. All opera-tions may be performed directlywithout any programming. CX!Xport provides control software topass information from one computerto another. A programme runningon one computer (which could be aPC, Unix-based system, or anothermini or mainframe) can directly ac-cess data maintained in a CS/DBXor Total data base on another com-

puter. Users can also pass data frommachine to machine, a message at atime. CS/Xport Can also be used tomove text files from one computer toanother, maintaining the files in thehost machine’s format. This productmakes it easier to implement a net-work of similar or differing machinesthat share access to a distributeddata base.Cincom Systems of Australia Pty Ltd.220 Pacific Highway,Crows Nest 2065

UNIX SUPERM~CROThe Morrow Tricept Supermicrosupports four to eight users runningthe UNIX System V operating sys-tem on the 16/32-bit MC68000microprocessor, and has optionalslave processor boards based on the80188 CPU and running the MS-DOS operating system. Hardwareincludes an MC68000 CPU runningat up to I0 MHz, with an on-boardMC68451 memory-managementunit~ 512 Kbytes of main memory(expandable to 2 Mbytes)~ an I/Ocontroller with four RS232C serialports (expandable to eight ports)~ aCentronics compatible parallelprinter port~ hard and floppy discDMA controllers~ and 80188-basedslave processors with 128 or 512Kbytes of on-board dual-port RAM.All boards plug into the 14-slotIEEE-696 (S-I00) bus backplane.Mass storage includes one to four 16or 34 Mbyte 51/~ in Winchester discdrives (up to 136 Mbytes storage)’,an optional 5 Mbyte removablehard-disc cartridge drive~ one to four400 Kbyte 5~4 in floppy-disc drives~and one to four optional 1.3 Mbyte 8in floppies. Unisoft has added suchenhancements as record-lockingand IEEE floating-point capability.An optimising C compiler comeswith the system~ other available lan-guages include BASIC, COBOL,FORTRAN 77, Ada and Pascal.Tricept’s serial I/O controller com-municates with terminals and prin-ters at rates of up to 19.2 Kbaud.The hard disc controller features aseek time of 85 ms with the standard16 Mbyte ddve, or 35 - 45 ms withthe optional 34 Mbyte drive; datatransfer rates are up to 625 KB/s.Planned enhancements includeboards providing Ethernet supportand PC graphics capability.Automation Statham Pry Ltd.47 Birch Street,Bankslown 2200

DESKTOPENGINEERINGWORKSTATIONSThe HP 9000 Series 200 line ofMotorola chip-based computershas been expanded with the model217 and the model 237. BASICand Pascal operating systems, aswell as the HP-UX operating sys-

tern (derived from UNIX), providea growth path across the entireline. The model 217 engineeringworkstation is a modular computerusing the MC 68010 processorwith memory management and 8MHz clock. It has a 14 in green-phosphor monitor with 512 x 390resolution, and 512 Kbytes ofRAM, expandable to 4 Mbytesusing a new I Mbyte RAM board.A mouse is available as an option.The model 237 offers a 17 in bit-mapped display and shares thesame operating system, peripher-als, interfaces and accessories, asother HP Series 200 models. Themodel 237 graphics workstationuses the MC 68000 processor at12.5 MHz with memory manage-ment and cache memory. It has a17 in, no-flicker monitor with a1024 x 768 bit-mapped displayand 512 Kbytes of RAM, expanda-ble to 7 Mbytes using the 1 MbyteRAM board. The mouse is stan-dard on this workstation. Otheradditional options include: afloating-point maths processor thatprovides up to three-fold im-provement in performance, whichis especially useful when using theseven-channel, 55,000-samples!sA/D card in data-acquisition appli-cations; and Rev. 3.0 BASIC andPascal operating environmentswhich offer up to 50% perfor-mance improvement over previousversions, and also support the 150cps ThinkJet printer and the HP9122D double-sided 31/2 in dualmicrofloppy disc drive. Extra HPsoftware for the Series 200 line in-cludes two new terminal emulatorsfor the DEC VTI00 and the TEK4010, and HP TechWriter, whichpermits merging of graphics andtext in the same document.Hewlett Packard Australia Ltd.31-41 Joseph Street,Blackburn 3130

C COMPILERC86 is a complete C compiler forthe IBM PC and machines runningCP/M-86 or MS-DOS which offers:the production of tight code; iden-tifier names up to 31 characterslong for better readability andmaintainability; a library sourcewith routines for Unix I/O, redirec-tion, 8087 support, sorting, mathand trigonometry; optional un-signed char and unsigned long datatypes for compatibility with popular8088 C compilers; programmeoverlay support, allowing largeprogrammes to run on smallmachines; the support of a nestedcomment option; command linename definitions for use of theconditional compilation features;and optional production of a listingof the source programme aftermacro substitution to simplify thedebugging of macros and condi-tional compilation commands.Software Source Pty Ltd.344-348 Oxford Street,Bondi Junction 2022

Vol 5 No 564

AUUGN

16-BIT MiCROSYSTEMThe Dual 83/80 multi-user, multi-tasking system provides support forfour users (expandable to 16), anMC68000 based central processorwith memory management (10MHz clock rate), 512 Kbytes ofdynamic RAM (expandable up to6.25 Mbytes), a four port serial se-rial I/O board with DMA, a 32/64Kbyte EPROM board containingsystem boot, a 20-slot IEEE 696/S-100 backplane, a nonvolatileclock/calendar, an SMD disc con-troller, an 80 Mbyte 8 in Winches-ter drive with 20 - 25 ms averageaccess time, a floppy disc control-ler, a 1.25 Mbyte floppy disc drive,a multi-user UNIX operating sys-tem licence, a UNIX (System V)operating system, a C language/compiler, and rack mountablecabinets. Options include addi-tional disc storage (to 160 Mbyteswith Dual drive), additional serialI/O ports, D/A and A/D converterboards, a nine track tape drive, anine track interface, a floating pointprocessor, a CAT 1600 Graphicsboard, a variety of operatingsoftware/languages (including RTK,UNIX System III, Forth,Fortram-77, Pascal, RM/COBOL,BASIC and Lisp), and applicationssoftware (LEX, MBSI, Viewcomp,MicrolNGRES, Unify and PrecisionVisuals). System 83/80 operates attemperatures up to 60°C andcomes with a 12 months warranty.Dual Systems Australia55 Phillip Street,Parramatta 2150

UNiX BUSINESSAPPLiCATiONSGENERATORToday, claimed to be the first busi-ness applications generator forUNIX, was developed on a Wicat200, by a team from bbj ComputerServices and Wicat. Today inter-faces to the UNIX file system utilityC-ISAM and is comprised of two

parts; the system administratormodule (for defining terminals tothe system, user passwords etc.)and the developer module, whichcreates the application. There willbe a dual approach, firstly to theuser who wants to utilise a broadrange of commercially acceptedapplications developed usingToday and running under a tun-time only version, and secondly tousers developing and running theirown applications using a full de-velopment version. Users will re-ceive comprehensive support fromWicat, including training, assistanceto new users and problem solving.Wicat Computer of Australia Pty Ltd.88 Christie Street,St Leonards 2065

DATA PROCESSINGPRODUCTSThe AT&T range of data proces-sing products includes a personalcomputer, an interface betweenpersonal computers and the 3Bline, and a local area and campusnetwork. Also available to end-users of its 3B2 and 3B5 comput-ers, are 3B network and protocolconverters to allow asynchronousterminals to communicate withsynchronous systems. The AT&TPersonal Computer runs the sameMS-DOS operating system andbusiness software as other leadingpersonal computers and acceptsthe same plug-in accessory circuitboards, however, it is said to havegreater speed, more features, and ahigher level of standard equipmentthan its leading competition. Thepersonal computer can operate inan integrated computing environ-ment with AT&T UNIX- based3B computers through the AT&TPC Interface, which allows thecomputer to act as one of up to 16workstations in a network with themore powerful 32-bit 3B superminicomputers. The InformationSystems Network (ISN) is a localarea and campus network that

combines fibre optics and existing,standard copper wire to link work-stations, terminals, PCs andminicomputers and communica-tions processors into one system.ISN also complements AT&Tcommunications systems such asSystem 75 and 85 and the Dimen-sion PBX family. AT&T also have acomprehensive series of softwareproducts for both the 3B and Per-sonal Computer product lines, in-cluding word processing andspreadsheet programmes, andindustry-specific software such asthe AT&T Gift Registry for retailers.

AT & T International (Aust) Ltd.60 Margaret Street,Sydney 2000

~ULTI-USERSUPERNilCROThe [CL CLAN supermicro com-puter system supports both thePICK and UNIX operating systems,is based on the Motorola 68000microprocessor and will initiallysupport up to 16 users concur-rently. A basic ICL CLAN systemconsists of a 40 Mbyte Winchesterdisc, 0.5 Mbytes of memory, a 20Mbyte cartridge tape and a basicI/O board which can support up tosix users via four asynchronousand two synchronous RS232 ports.

All facilities are contained in asingle compact free standingcabinet. Current enhancements in-clude the addition of 0.5 Mbytestore modules up to a maximum of2.0 Mbytes for PICK machines and3.0 Mbytes for UNIX systems. Afurther three Winchester discs mayalso be added, providing a totalcapacity of 160 Mbytes while asecond I/O board provides ten ad-ditional asynchronous RS232 portsfor local use. A wide variety of ap-plications software is readily avail-able under both PICK and UNIX.ICL Australia Pty Ltd.14 Rodborough Road,Frenchs Forest 2086

UNIX TRAININGSERIESThree series of training tapes intro-ducing the UNIX system, and exa-mining its operation and applica-tions, have been produced by Tele-media. UNIX Overview is a six partintroductory course which is suitablefor use either on a self-learning basisor in small groups and takes 6 - 9 h tocomplete. UNIX Fundamentals con-sists of 15 separate courses, includeshands-on experience and coverssuch areas as path names, directorycommands, file access permissions,file name generation and the 30most commonly-used UNIX com-mands. The series takes up to 30 h tocomplete and is designed to be usedon a self-instructional format or insmall groups. The UNIX Funda-mentals series provides the basicskills needed to proceed with furtherUNIX training, such as C languageprogramming. The courses providea complete introduction to all as-pects of the language and are suit-able for both UNIX and non-UNIX Capplications. Among the 16 courseheadings are: introduction to C lan-guage; creating a C programme;control statements; conversions;pointers and addresses; functions;storage classes; and structures andunions. The series takes a minimumof 24 h to complete. All three seriescan be purchased, rented as part of along term contract or rented on ashort term, one-off basis.Deltak Pty Ltd.53 Walker Street,North Sydney 2060

AUUGN65

Vol 5 No 5

Netnews

I have reproduced below some of my network mail and a few "netnews"articles that I thought may be of interest to Australian UNIX userso I havedeleted some of the less meaningful data generated by various mailers and newsprograms. No responsibility is taken for the accuracy (or lack thereof) ofanything below.

From jr@forosloUUCP Fri Sep 28 13:55:10 1984Date: Fri, 28-Sep-84 13:55:10 AESTNewsgroups: netolangoc,netounix-wizardsSubject: Master listing of predefined CPP symbols

Hio As promised (a *long* time ago), here’s my updated list ofpredefined CPP symbols, which are generally used to allow machineand/or operating system specific code to be #ifdef’edo Very few ofthese are actually documented anywhere; the purpose of this list is totry to take some of the "folklore" and make the information availableto everyone. The data here is collected from a number of sources;please see the "acknowledgements" list at the end of this article° Idon’t have any data on anything earlier than V7o

THE LIST:

name description availability

DATEFILELINEPAGE

AOSVSaOSVS

cpmDATAGENERALdatageneraldecusDGUXdguxgcosi bminterdatahp9OOOs200hp9OOOs500kllOlintm68000m68kmbb ????mc68000

mertnomacargON SELorlon

date of compilation Decus Ccurrent source file name most CPP’sline number within current source file most CPP’spage number within sourceData General AOS/VS operating systemData General AOS/VS operating systemCP/M operating systemData General hardwareData General hardwareDecus C (PDP-II - RSX & RT-II)Data General UNIX (DG/UX)Data General UNIX (DG/UX)Honeywell 6000 GCOS oposysoIBM (and Amdahl?) mainframesInterdata 8/32Hewlitt Packard 9000Hewlitt Packard 9000DEC-20 KLI0 processorUNIX’s lintMotorola M68000 familyMotorola M68000 familyBBN C70Motorola MC68000

Multi-Executive Real Time??CPP doesn’t support macro argsGould Concept 32 (obsolete OS?)ORLON supermicro (4olc BSD)

Data General C’sData General C’sData General C’s"p" in Dr. Dobbs Jul-84Data General C’sData General C’sDecus CDG/UXDG/UXAT&T C compilers?AT&T C compilers?AT&T C compilers?

HP-UXUoUtah PCC?most UNIXesCCI’s 68000Motorola SysV portBBN UNIX?Sun Microsystems,

Fortune, other portsAT&T C compilers?Decus C?ORLON UNIX

Vol 5 No 5

66AUUGN

os

PDPIIpdpll

PWBRESrsx

RTselselports un

TM DPS6TM L66to~s20TSTS GCOSTS MOD400tssu370u3bu3b2u3b5univacunixvax

vaxllcvms

z8000

IBM’s 0S/360 and /370DEC’s PDP-II minicomputersDEC’s PDP-II minicomputers

Programmer’s WorkbenchBell Labs" Compo Scio Research Group?DEC’s RSX operating system on PDP-IIUNIX/RT (real time)Gould Concept 32Gould Concept 32SUN Microsystemstarget machine is Honeywell DPS 6target machine is Honeywell Level 66TOPS-20 operating system for DEC-20UNIX/TS (timesharing system)target system is Honeywell GCOS 8

AT&T C compilers?UNIX V7BTL C/UNIX, Decus C for

RSX and RT-II, earlyPlexus ports?

PWB/UNIXAT&T UNIXDecus C for RSXUNIX/RT???Waterloo compilersWaterloo compilersUoUtah PCC?AT&TWaterloo compilers

target system is Honeywell GCOS 6 mod 400 Waterloo compilersIBM’s Time Sharing System (for 360/370) AT&T?UNIX on IBM/370?UNIX on AT&T 3B-20UNIX on AT&T 3B-2UNIX on AT&T 3B-5Univac/llO0 UNIXThe you-know-what operating system

AT&TAT&TAT&TAT&TAT&T?most UNIX’s

DEC VAX-II minicomputers (UNIX or VMS) UNIX, VAX-II C, someearly Unisoft 68k’s

DEC’s VAX-II C compiler VAX-II CDEC’s VMS operating system for VAXen VAX-II CZilog Z8000 Zilog C compiler?

MY LIST OF SUGGESTED ADDITIONS:

name description

ccpm86cpm68kcpm80cpm86gnui808018086180186180286mc68008mc68010mc68020mpmmsdospcdosxinuz80zSO0

Concurrent CP/M-86CP/M-68KCP/M-80CP/M-86Stallman’s (sp?) GNU (GNU’s Not Unix)Intel 8080-compatible: 8080, 8085, Z80Intel 8086 and 8088 processorsIntel 80186 and friendsIntel 80286 and friendsMotorola MC68008 processorMotorola MC68010 processorMotorola MC68020 processorMP/MMicrosoft’s MS-DOS operating systemIBM and/or MicrosoftPs PC-DOS operating systemPurduePs XINU (Xinu Is Not Unix)Zilog Z80Zilog Z800, if they ever ship any

ACKNOWLEDGEMENTS: The data in the list is from the one in Steve Bourne’s

AUUGN Vol 5 No 567

"The UNIX System", and from Usenet articles and/or mail messages fromthe people listed below° If you mailed me something and donPt see yourname listed, then the mail got lost (so please resend it)o

DBrown@HI-MULTICSoARPA, Mike Brzustowicz <mab@aids-unixoARPA>,John Gilmore <gnu@sunoUUCP>, Bob Gray <bob@hwcsoUUCP>, TonyHansen <hansen@pegasusoUUCP>, Guy Harris <guy@rlgvaxoUUCP>, BobLarson <BLARSON@USC-ECLBoARPA>, J Lepreau <j@utah-csoUUCP>,Michael Meissner <mrm@datagenoUUCP>, Martin Minow<minow@decvaxoUUCP>, Craig Partridge <craig@lokioUUCP>, JohnRogers <jr@forosloUUCP>, George Rosenberg <george@idisoUUCP>,Donn Terry <donn@hp-dcdoUUCP>, Tom Truscott <trt@rti-seloUUCP>,Mike Zaleski <mzal@pegasusoUUCP>

I plan to maintain this list, so if anyone has any additions or corrections,please send them to me at:

UUCP: {ihnp4,cbosgd,harpo,dual,amd}!fortune!forosl!jrARPANET: hpda!fortune!forosl!jr@Berkeley (untested)ENET: RHEA::DECWRL::"amd!fortune!forosl!jr" (untested)

Happy hacking!JR (John Rogers)

Vol 5 No 568

AUUGN

From ag5@pucc-i Sat Sep 29 04:25:22 1984Newsgroups: net.mailSubject: UUCP ==> BITNET gateways found!!

Since I posted my request for UUCP/BITNET gateways some timeago, I have accumulated some information, which is listed below:

Apparently, two gateway sites exist for this purpose. TheUUCP site at Penn State University (psuvaxl) and another site(wjhl2) operate gateways. The impression I get is that one canmail thru psuvaxl in the following manner:

o o . !psuvaxl!bituser%bitsite. BITNET

The wjhl2 site is just in the process of installing theirBITNET mailer. They have two possible formats for mailing;you may want to try first

.. o !wjhl2!BITSITE!bituser

Please notice that the BITNET sitename is REQUIRED to be inupper case.

In a few weeks, you should be able to mail like the following:

o o . [email protected]

Since the "@" often causes trouble with mailers which yourmessage may have to pass through, you can simply mail a letter tothe letter.

Until their mailer is functioning entirely (when you canuse the second and third formats), there will not be a return pathgenerated in the message sent to the bitnet user (i.eo, there wil!be no "Return-Path: <blah blah blah>" line.

Henry C Mensch I Purdue University Computing Center{decvaxiucbvaxlsequentlicalqa l inuxc l uiucdcs l ihnp4} !pur-ee!pucc-i,ag5

AUUGN69

Vol 5 No 5

From ag5@pucc-i Sat Sep 29 04:35:32 1984Newsgroups: net.mailSubject: BITNET <==> ARPA/CSNET gateway info

In my inquiries about gateways to/from UUCP, ARPA/CSNET,and BITNET I have come across a variety of helpful information.That which is below describes wiscvmoARPA, which acts as a gatewayfrom/to ARPA/CSNET and BITNETo This seems to work from UUCP sitesthru the ARPA gateway at Berkeley, also.

BITNET - CSNET ELECTRONIC MAlL RELAY

The University of Wisconsin - Madison will provide electronic mailrelay service between BITNET and CSNET beginning September i0, 1984.The gateway will reside on the WISCVM system (an IBM 4341 runningVM/SP relo 3) which is a node on both CSNET (Arpanet componenet) andBITNET.

All CSNET sites including those on Arpanet, Phonenet and Telenet willbe serviced by the relay. CSNET sites need not modify their currentmail systems. Mail originating on BITNET must be preceded by a BatchSMTP header and must conform to RFC 733 or RFC 822.

Communication between BITNET hosts and the gateway, WISCVM, is achievedvia the IBM RSCS Networking Program. Communication between CSNET sitesand WISCVM is accomplished via the SMTP/TCP/IP protocols (in the caseof CSNET Phonenet, mail will also pass through the CSNET Phonenet relay,CSNET-RELAY).

Procedure for sending mail from CSNET hosts to BITNET hosts:

Recipients at BITNET hosts should be addressed as:

user id%bitnet [email protected]

Including the domains ("bitnet’° and °’arpa") is preferred but notnecessary.

Example: Mail to be sent to Jones at CUNYVM should be addressed as:

jones%[email protected]

Mail text lines greater than 80 characters will be folded beforeforwarding to BITNET hosts.

Procedure for sending mail from BITNET hosts to CSNET hosts:

The mail relay runs as a disconnected virtual machine, SMTPUSER,on WISCVMo Mail to be relayed to CSNET and ARPANET hosts should bePUNCHed, NoHeader, Class M, to SMTPUSER at WISCVM.

Mail must be in Batch SMTP format (see example below). The actualSMTP mail header must be a legal RFC 822 or RFC 733 header.

Vol 5 No 570

AUUGN

The mail relay will strip off the Batch SMTP commands and re-write

any RFC 733 headers to be in compliance with RFC 822.

All BITNET addresses will be re-written so that they can be replied

to from CSNET hosts. Example:

Jones@CUNYVM will be re-written by the relay as:jones%cunyvm.bitnet@wiscvmoarpa

Undeliverable mail will be returned to the address specified in the

Batch SMTP "MALL FROM" command.

Batch SMTP Example:

HELO CUNYVM. BITNETTICK 0001VERB ONMAIL FROM:<JONES@CUNYVM. BITNET>RCPT TO:<[email protected]>DATADate: Wed, 25 Jul 84 17:02:23 cdtTo: ward@uwvaxFrom: [email protected]: bsmtp example -!

!-> Batch SMTP Commands

!-> SMTP Mail Header

Mail text (Note: a blank line between mail header and text is required.A single character line containing only a period mustfollow the mail text)

I hope this proves helpful to someone out there in net-land!.

Henry C Mensch I Purdue University Computing Center{ dec vax i ucbvax I sequen tI i cal qa l in~xc l uiucdcs l ihnp4 } !pur-ee !pucc- i,ag5

AUUGN71

Vol 5 No 5

From john:tictoc Thu Sep 6 17:33:51 1984To: auugn:elecvaxSubject: contribution

Here is a copy of some mail I sent to Robert Elz which mightbe of interest to people at sites with SC750 controllers and/orFujitsu Eagles.

From john Sat Sep 1 15:54:15 1984To: kre:munnariSubject: SC750 and Eagle glitches

Robert:

Here is the information on the problem we had with our SC750 as Imentioned to you at the AUUG meeting° The problem first manifested itselfin this way: we would get "Device error on Eagle drive 0 slice x°’ messages,with erl = 4 (Register Modification Refused)° These would tend to happenespecially at times when disk activity suddenly increased (e.go, the oneuser on the system finished an edit and did a make)° We eventually trackedit down to be due to the fact that, after a soft ECC error, sometimes themassbus byte count register in the controller contains 0xFEO00000 (whichseems very odd on the face of it: the drive still has 512 bytes to go butthe transfer into memory is complete)o

Under these conditions the driver was restarting the I/O. This meantthat you would get a subsequent "Invalid Map" error, since the transferwas 64K long and it never sets up any map registers except the first couple°That in turn was resulting in the "Register Modification Refused", sinceit thinks it must have Drive Ready after the error but in that case itdoesn’t, so the Drive Clear command is ignored and causes the RMR bit tobe set, which is picked up later on°

We applied the following change to io/gdhpoc:

225c225< if (mp->mbabcr) {

> if (mp->mbabcr & OxFFFF) {

which has worked very wello

We also had a fair amount of trouble booting the Eagle at first.This was due to the fact that, as soon as the boot issues a read command,it calls a routine called "rdy" which reads RMCSI and loops until DRYis set. The problem is, with the SC750 and Eagle (it doesn’t happen withour CDC 9710 RSD), sometimes the bit has not gone No zero by the firsttime it is read, so the routine returns immediatelyJ We fixed this(and added an error check) in the following manner (recalling that spacein the boot is short):

Change to /usr/src/stand/vax/boots/gdboot2bos:

40d36< °set pERR, 14200,202d195

Vol 5 No 5

72AUUGN

< movl< rdyO :< bbs

$63,r12 # tictoc - insert some delaysobgeq rl2,rdy0$pERR,rO,rperr # tictoc

I hope all this is of some interest to you. If anyone is having problemswith Eagles on SC750s, feel free to put them in touch with us: ours isworking well now, and if we had known what we now know when we first

got the machine we would have had a lot less headaches!

Regards,

John Mackino

From stephenf:elec70b Fri Sep 7 12:07:19 1984To: auugnSubject: Note for AUUGNcc: judy:basser

You might like to put a note in AUUGN about the following book

(Geoff Whale has a copy and you might like to check it out)° The bookis "Starting with UNIX" by PoJ. Brown, published by Addison Wesley.

There is a section in Chapter 2 titled "Finding other people’spasswords" which suggests writing a.dummy login program to catch yourfriends, or better yet, root, because then you can change anyone’s files.

In another section, it suggests creating files called "*" in the

directory of your friends, so that when they go to remove the file,they will remove all their files.

Sydney Uni uses this book as a text. Many of the students who

have tried this in the last week or so (and have been brought beforethe powers that be for doing it) have gotten the idea from this book.

- Steve

AUUGN73

Vol 5 No 5

From [email protected] Fri Sep 14 20:17:26 1984Date: 13 Sep 1984 16:55:59-EDTFrom: [email protected]: [email protected]: UNIX is a trademark

From the July 1984 issue of "$ echo", published by the Software Salesand Marketing organization of the Computer Systems division of AT&TTechnologies, Inc.

Use of the Trademark UNIX

UNIX is an unregistered trademark of AT&T Bell Laboratories used to identifyits particular brand of software. The trademark is used in conjunction withseveral time-sharing operating systems developed at Bell Laboratories andlicensed by AT&T Technologies, and might be used in the future on other kindsof software and products.

A trademark identifies the source of a product. Some trademark owners licensetheir trademarks for use by others. A product marked with such a trademarkmight come from either the trademark owner or from one of its licensees.However, currently it is AT&T’s policy not to license parties outside thecompany to use the trademark UNIX to identify their products. There arespecific provisions in our software agreements for UNIX operating systems onthis point.

Notwithstanding this policy, anyone may use the trademark UNIX to refer to theUNIX operating systems developed at AT&T Bell Laboratories. However, toprotect Bell Laboratories" interest in the trademark, we must ask that othersuse the trademark correctly. Following are several comments on correct andincorrect use of the trademark. The comments are organized in outline form forconvenient reference.

- The trademark UNIX must always appear in a form that istypographically distinct.

- The trademark UNIX must be clearly and legibly identified as atrademark of AT&T Bell Laboratories at least once in any article,advertisement, or document in which the trademark appears, preferablythe first time such trademark is used.

- The trademark UNIX is an unregistered trademark of AT&T Bell(R)

Laboratories. It is incorrect to use the symbol in connection withthe trademark UNIX or to state that UNIX is a registered trademark orservice mark.

- Parties outside AT&T may not state or imply that they furnish UNIXoperating systems to others and may not use the trademark UNIX in thename of software that they furnish to others. Even if such partiesare licensed by AT&T to use UNIX operating systems or to furnishobject code derived from such operating systems to others, they arenot licensed to use the trademark to identify their product.

Vol 5 No 574

AUUGN

- The trademark UNIX may not be used in the name of a publication,business, or other organization (such as a user group).

- The trademark UNIX may not be used as a noun, but must always be usedas an adjective modifying a common noun as in "UNIX operating

..system.

- The trademark UNIX must always be used to modify a common name forsomething that is a product with which the trademark is used. Forexample, it is incorrect to refer to "a UNIX user, .... UNIX terminals,"or "UNIX support." Correct usage is "a user of UNIX operatingsystem." "terminal on a computer running a UNIX operating system," or"support for UNIX operating system."

- A way to check whether a use of the trademark is correct is tomentally insert the word "Brand" between the trademark and the commonname. "UNIX Brand operating system" sounds reasonable but "UNIXBrand user" does not.

- The trademark UNIX may not be used in a hyphenated expression such as"UNIX-based" or UNIX-like."

- The trademark UNIX may not be combined with the trademark of anotherparty unless the independence of the trademark is clear.

- Reference to "the UNIX operating system" is inappropriate. There areseveral UNIX operating systems. For a collective term, use "UNIXoperating system, if that is what is meant.

- It is inappropriate to use the trademark UNIX in any label (such asfile name, subroutine call or the like) in any software.

AUUGN75

Vol 5 No 5

Minutes of the AUUG General Meeting

These are the minutes of the first General Meeting of the Australian UNIXsystems Users Group, held at the University of Melbourne on August 27, 1984.

Minutes of the Inaugural meeting.

Meeting opened 13:45 on the 27th August 1984.

Convener John Lions took the chair.

Amendments to the draft constitution as published in AUUGN:(13) replace "A general meeting of the AUUG may"

by "An ordinary general meeting of the AUUG shall".Moved Ken McDonell, Seconded Robert Elz.Carried.

(15) replace "six" by "twelve".Moved Colin Webb, Seconded John O’Brien.Carried.

(14) replace "three calendar months" by "two calendar months".Moved John O’Brien, seconded Chris Maltby.Carried.

Motion that "the constitution as amended be adopted."Moved Juris Reinfelds, Seconded Robert Elz.Carried.

Motion that "the Management Committee seek legal opinion on theconstitution and report back to the next meeting of the AUUG."Moved Juris Reinfelds, Seconded Greg Rose.Carried.

Motion for a "vote of thanks to John Lions and others involved inin drafting the constitution."Moved Colin Webb, Seconded by general acclaim.

Election of officers and committee of management.

No records kept of nominators, seconders, acceptances or the orderof nominations.

As there were two positions for returning officers, and two nominations,the returning officers assumed their positions for the counting ofsubsequent written ballots.

President:Secretary:

Treasurer:

Management Committee:

John Lions (elected unopposed)John MackenGreg Rose (elected)Chris Maltby (elected)Geoff Cole(four members to be elected)Peter Ivanov (declined)Ken McDonell (elected)Ross Nealon

Vol 5 No 576

AUUGN

Returning Officers:

Auditor:

David HorsfallRobert Elz (elected)Ron BaxterDoug RichardsonPiers Dick-Lauder (elected)Tim Roper (elected)Rod CurtinPhil Chadwick(two to be elected)John O’Brien (elected unopposed)Colin Webb (elected unopposed)James Mann (elected unopposed)

Meeting adjourned 14:55.

Meeting re-opened 09:00 on the 28th of August 1984.

Motion that "current subscribers to AUUGN may become financial members toJanuary I, and that the cost for Ordinary members be $45, $30 for Studentmembers.Moved by Peter Ivanov, seconded John Lions from chair.

Amendment that "$45" become "$50".Moved Robert Elz, Seconded Richard HibbardoAmendment carried.

Amended motion carried.

Suggestions for subsequent meetings:

Wollongong Feb 85.Queensland Aug 85Perth Feb 86

Motion that "The first Annual General Meeting be held on or about the29th August 1985 in Brisbane."Moved Richard Hibbard, Seconded Robert Elz.Carried.

Motion that "the next meeting be held in Wollongong in February 1985."Moved John Lions from chair, Seconded Greg Rose.Carried.

The elected officers were announced.

Meeting closed 9:30.

AUUGN77

Vol 5 No 5

Adopted 27/8/84Rules and By-Laws for

the Australian Unix systems User Group

I. RULES

(1) The association shall be known as the A~’~ U~b~ srys~eme U$�~" (]roup~ abbreviated hereinafter to AUUG.[UNIX is a trademark of A.T. g~ T. Bell Labor~tories.]

(2) Office of the Association.The office of the AUUG shall be at Room 343E, School of Electrical Engineering, University of New South Wales,Kensington, New South Wales, or at such other place as shall from time to time be determined by the ManagementCommittee.

(3) Definitions.In these rules, unless otherwise stated:"he", "him" and "his" shall also be construed to mean "she", "her" and "her" respectively;"Financial year" means the period from 1 June to 31 May;"By-Laws" shall refer to the By-Laws of the AUUG;"General Committee Member" shall mean a general member of the Management Committee;"mail" shall imply the transmission of information in written or printed form, first-class pre-paid, via the general postor public or private courier service;"unfinancial member" shall mean any member whose most recent term of membership has expired and who has not yetpaid the subscription for the next twelve month period;"voting member" shall mean any member entitled to cast a vote.

(4) Aims.The aims for which the AUUG is established are to promote knowledge and understanding of the UNIX system, and ofsimilar or related computer systems.

For the furtherance of these aims and to achieve its purposes, the AUUG may carry out any or all of the followingactivities: conduct technical meetings, conferences, discussion groups, panels, lectures and other types of meeting;prepare and distribute a newsletter and other publications; collect software and distribute said software to its membersfor their use; verify licenses of members for the purposes of administering the services of the AUUG; subscribe to orcooperate with or affiliate with or amalgamate with other associations formed elsewhere with similar aims; accumulateassets; and establish and promote other activities not included in the above list consistent with its aims for the benefit ofits members.

(5) Eligibility for Membership.Any individual or organisation who subscribes to the aims of the association, and who agrees to be bound by its rulesand regulations and who has not been previously expelled from the association shall be eligible to join the AUUG.

(6) Application for Membership.An application for membership shall be in writing on the form approved by the Management Committee and shallprovide such information as shall from time to time be prescribed by the Management Committee.

(7) Commencement of Membership.Membership shall become current on the first day of the month following the date on which a valid membershipapplication accompanied by payment of the appropriate entrance fee plus annual membership subscription is received bythe Secretary, and shall continue for twelve months from that date.

(8) Renewal of Membership.Upon completion of the initial membership period and any subsequent periods, membership may be renewed for afurther period of twelve months by payment of an additional annual membership subscription.

(9) Termination of Membership.A member may resign his membership at any time by giving notice in writing to the Secretary. No member whoresigns shall have any claim for a refund of subscriptions paid.A member who has been unfinancial for more than two calendar months shall be deemed to have resigned hismembership, and shall no longer be entitled to any privileges enjoyed by members.Former members who have resigned will be entitled to rejoin the AUUG on the same basis as new members joining theAUUG.

(10) Amount of Guarantee.Each member of the AUUG undertakes to contribute to the assets of the AUUG in the event of its being wound up whilehe is a member or within one year after he ceases to be a member for payment of the debts and liabilities of the AUUGcontracted before he ceases to be a member, and for the costs, charges and expenses of winding up and for theadjustment of the rights of contributories among themselves, such amount as may be required but not exceeding fiftydollars.

Vol 5 No 578

AUUGN

(11) Expulsion of Membern.Upon receipt of a petition so requesting from twenty or more members, or half the membership, whichever is less, theManagement Committee shall call upon any member to explain any alleged misconduct, and the ManagementCommittee shall have power to suspend or expel any member who in its opinion has either been guilty of misconduct orhas acted prejudicially to the interests of the AUUG or who h~ wilfully infringed any of the Rules or By-Laws of theAUUG.

(12) Annual General Meetlng.The Annual General Meeting shall be held within the second half of each calendar year. The date and general locationof each Annual General Meeting shall be determined at the preceding Annual General Meeting but either the date orlocation or both may be changed by the Management Committee if it proves impossible or highly inconvenient to meetat the location previously selected or on the date previously selected.

(13) Ordinary General Meetlng~.A ordinary general meeting of the AUUG shall be called by the Management Committee in conjunction with anytechnical meeting or conference or other function where attendance by a quarter or more of the voting members isexpected by the Management Committee.The business that may be conducted at such a meeting shall be as prescribed in the By-Laws. Notice of such meetingstogether with the agenda shall be sent to al! voting members by mail at least four weeks before the date set for themeeting.

(14) Extraordinary General Meetings.Upon receipt of a petition so requesting from twenty or more members, or half the membership, whichever is less, theSecretary shall call an Extraordinary General meeting of the AUUG for a date no later than two calendar months afterreceipt of the petition, and the business of the meeting shall be confined to matters described in the petition and to othermatters specifically provided for in these rules and recorded in the written agenda sent to all members by mail at leastfour weeks before the date set for the meeting.

(15) Quorum for a General Meeting.For each general meeting, the quorum shall be twelve members personally present and entitled to vote.

(1O) Officers.The Officers of the AUUG shall be: the President! the Secretaa’y! the Treaaua’er! the Returning Offic!r! theAssistant Returning Officer| and the Audltor.

(17) Management Committee.The management and control of the business and general affairs of the AUUG shall be vested in a ManagementCommittee of seven members, namely: the President; the Secretary; the Treasurer; and four General CommitteeMembers.

(18) Elections.The election of Officers and General Committee Members shall be by postal ballot, under conditions defined by the By-Laws.The term of office for all Officers and General Committee Members except the Auditor shall be for one year, from July1 to June 30.

(19) Auditor.The Auditor shall take office after the end of the Annual General Meeting following his election and shall hold officeuntil the end of the Annual General meeting following.If at any time the position of Auditor becomes vacant, the Management Committee shall at its earliest opportunityappoint as auditor a certified public accountant who is not a member of the AUUG, and he shall hold office until thenext annual general meeting of the AUUG.At least once in each financial year the Auditor shall examine the accounts and financial records of the AUUG. TheAuditor shall certify as to the correctness of the accounts of the AUUG and shall report thereon in writing to theSecretary and to the members at the Annual General Meeting.

(20) Vacancies on the Management Committee.The position of any General Committee Member shall be vacated if the member fails to attend any ManagementCommittee meeting without furnishing a satisfactory explanation as to the cause of his absence, and if the ManagementCommittee resolves that his office be vacated.

If at any time any of the principal Officers (President or Secretary or Treasurer) be unable to continue in office for anyreason, then the Management Committee shall appoint one of their number to the vacant office.Should a vacancy occur among the other Officers but excluding the Auditor, or among the General members of theManagement Committee, then the Management Committee shall appoint an Ordinary Member of the AUUG to fill thevacancy.The Management Committee shall make the approval of such appointments an order of business for the next GeneralMeeting of the AUUG if any such meeting will be held before the next election of Officers and General CommitteeMembers.

(21) Management Committee Meetings.The Management Committee shall meet formally at least twice per year. Notification of time, place and agenda foreach meeting shall be made in writing to each member of the Committee by the Secretary at least four weeks inadvance. All members of the AUUG are entitled to be present at such meetings, and may speak when invited by theChairman, but only members of the Management Committee may vote. The quorum for such meeting shall be four.

AliGN --2-- Vol 5 No 579

Resolutions of the committee shall require a simple majority of the members present and voting. The chairman shallhave a casting vote in the event of a tie.

(22) Distribution of Income.The income and property of the AUUG however derived sh~ll be applied solely towards the aims and purposes of theAUUG as set out in these Rules, and no portion thereof shall be paid or transferred directly or indirectly by way ofdividend to any member of the AUUG at any time.The AUUG shall not appoint a person who is a member of the Management Committee to any office in the gift of theassociation to the holder of which there is payable any remuneration by way of salary, fees or allowances.Notwithstanding the above the AUUG may compensate the reasonable expenses actually incurred by any member in theconduct of the business of the AUUG under the direction of the Management Committee.

(23) Chapters,Ten or more members of the AUUG may petition the Management Committee to form a eh&pte~" of the AUUG.General rules for the organisation, operation, obligations and privileges of chapters shall be as resolved by theManagement Committee or the membership as a whole from time to time.Each chapter shall appoint a chapter committee consisting of at least a Chapter Chairman and a Secretary/Treasurer.The chapter committee may convene meetings consistent with the aims of the AUUG, but may not enter into anyfinancial commitments on behalf of or in the name of the AUUG except with the written approval of the ManagementCommittee.

(24) Affiliation or Amalgamation with other organisations.The Management Committee may at any time seek or discuss the possibility of affiliation or amalgamation with anyother organisation whose aims are similar to or compatible with those of the AUUG. No agreement for affiliation oramalgamation may be finalised until the matter has received the assent of two-thirds of the members voting in a postalballot.

(25) Dissolution of the AUUG.Upon receipt of a petition requesting the dissolution of the AUUG from twenty or more members, or half themembership, whichever is less, the Secretary shall arrange for the question to be put to the membership by ballot nolater than one month after the date that he receives the petition.If two-thirds of the members voting agree, the AUUG shall be dissolved. If upon the dissolution of the AUUG thereremains after satisfaction of all its debts and liabilities any property whatsoever, the s~me shall not be paid to ordistributed among the members or Chapters if any, but shall be given or transferred to some public educationalinstitution, or other institution to be determined at or before the time of dissolution by resolution of the membership.

(26) Changes to the Rules and By-Laws.Changes to these Rules and By-Laws may be initiated at the request of a General meeting, or by the ManagementCommittee. All proposed changes must be approved by a two-thirds majority of the votes received in a postal ballot ofthe members before having effect.

(27) Interpretation of the Constitution.If any doubt arises as to the proper construction or meaning of any clauses in these Rules or By-Laws, the decision ofthe Management Committee thereon shall be final and conclusive provided such decision be reduced to writing andrecorded in the minutes of a meeting of the Management Committee.

Adopted 27/8/84Rules and By-Laws for

the Australian Unix systems User Group

II. BY-LAWS.

(28) Classes of Membership.There shall be four classes of members: Ordinary members, Institutional members, Student members and Honorary LifeMembers.

(29) Ordinary Members.Any person who is eligible to be a member may become an Ordinary Member.

(30) Institutional Members.Any person or organisation who is eligible to be a member may become an Institutional Member.

(31) Student Members.Any full-time student who is eligible to be a member may become a Student Member.

(32) Honorary Life Members.Any person who is an Ordinary Member of at least five years standing and who has rendered special services to theAUUG may be elected via a ballot of the members as an Honorary Life member.

Vol 5 No 53

AUUGN

(33) R|ghts of IV[embers.Each member shall be entitled to attend all meetings of the AUUG, including meetings of the Management Committee,provided any prescribed attendance fee is paid.Each member shall be sent a copy of the association’s newsletter.Each member entitled to vote in a ballot shall be sent notice in writing of all ballots and copies in writing of the annualreports of the Secretary, Treasurer and Auditor.

(34) Obl|gat|ons of Members.Each member shall abide by the Rules and By-Laws of the AUUG as they may from time to time appear. Each membershall respect licensing obligations.Each member shall inform the Secretary of changes to his postal address.

All Ordinary, Institutional and Honorary Life Members whose membership is current shall be entitled to cast one vote.Any voting member may award his proxy to another voting member for the period of a single General meetingproviding he so notifies the Secretary in writing at least 24 hours before the appointed time of commencement of themeeting.

(36) Mernbersh|p Subscrlpt|ons and Fees.The Management Committee shall determine before the commencement of each financial year a scale of fees forentrance to the AUUG, for annual subscriptions and for the attendance at meetings, for each class of members to beapplied during that financial year.

(37) Chairman oi~ Meet|ng~.At all General meetings of the AUUG and at all meetings of the Management Committee except where otherwiseprovided, the Chair shall be taken by the President, or in his absence, by a member elected by the meeting.

(38) Duties of the Secretary°The Secretary shall keep or cause to be kept a register of members setting forth the names and addresses in full of allmembers of the AUUG.The Secretary shall furnish to the Returning Officer a complete list of all voting members whenever this is required forthe conduct of a ballot.The Secretary shall keep or cause to be kept full and correct minutes of all resolutions and proceedings at Generalmeetings and Management Committee meetings of the AUUG.The Secretary shall conduct correspondence on behalf of the AUUG.The Secretary shall, during his last month of office, prepare a written report on the state of the affairs of the AUUG fordistribution to the membership.

(30) Duties oi’ the Treasurer.The Treasurer shall keep or cause to be kept correct accounts and books and records showing the financial affairs of theAUUG.The Treasurer shall notify the President and Secretary in writing of the usual location of said accounts, books andrecords whenever this location is changed.The Treasurer shall receive all fees and subscriptions and all other monies on account of the AUUG and provide receiptsfor the same. The Treasurer shall deposit all monies received into a bank account maintained by the AUUG.The Treasurer shall receive accounts for payment for services rendered to the AUUG, and as directed by theManagement Committee arrange for payment from the AUUG’s account.The Treasurer shall, during his last month of office, prepare or cause to be prepared a written report on the financialaffairs of the AUUG for approval by the Auditor and subsequent distribution to the membership.

(40) Execution of Contracts.The Management Gommittee, except as otherwise provided in these Rules and By-Laws, may prospectively orretroactively authorise any Officer or member of the AUUG to enter into any contract or execute and satisfy anyinstrument, and any such authority may be general or confined to specific instances, except that any contract whosedollar value exceeds an amount predetermined by the Management Committee must be specifically authorised inadvance by the Management Committee.

(41) Disbursements.S~gnlng O~eer~ for the AUUG’s accounKs shall be the President, the Secretary, the Treasurer and one other GeneralCommittee Member chosen by the Management Committee.All cheques, drafts, and other orders for payment of money out of the funds of the AUUG, if for less than a limitestablished by the Management Committee, may be signed by only one Signing Officer.For other amounts, each such instrument must be signed by at least two Signing Officers.

(42) Conduct of General lYieetlng~.Written notice of the time and place for each meeting and its agenda shall be mailed to each voting member of theAUUG at least four weeks before the date of the meeting.Business conducted at such meetings shall be confined to matters included in the written agenda, reports from Officers,and resolutions instructing the Management Committee to conduct a formal ballot of the membership on matters ofsubstance. Such resolutions shall not be binding on the Management Committee unless the meeting was attended by atleast twenty voting members, or half the membership, whichever is less, and the resolution was supported by at leasttwo-thirds of the members voting.

4AUUGN Vol 5 No 5

81

(43) Voting.All voting by the members with respect to the election of Officers and General Committee Members, with respect to theelection of Honorary Life Members, with respect to changes to these Rules and By-Laws, and all other substantivematters shall be conducted by postal ballot.Every voting member of record as of the date of entry of a ballot into the mails shall he entitled to vote in the ballot.On all questions to be put to a ballot, the Secretary shall designate a date for the ballot to he placed in the mails, andthe due date shall be four weeks after that date. The Returning Officer shall nominate the address to which voters shallreturn completed ballot papers by mail. A ballot will not be counted if it is received after the due date or if the ballotpaper does not comply with the instructions printed on it.The ballots will be received by the Returning Officer, and counted by him and the Assistant Returning Officer. TheReturning Officer vball report the result of the ballot in writing to the Secretary no later than two weeks after the duedate.

(44) Conduct of Elections.Elections shall be held annually for all positions of Officer and General Committee Member.Nominations for each position shall be received by the Secretary up until the first day of May each year. Eachnomination must be in writing, must name the position or positions vought, must be signed by at least three votingmembers, and must be countersigned by the nominated member who must be a financial voting member of the AUUG.The Management Committee shall ensure that at least one valid nomination is obtained for each position such that if nofurther nominations are received all offices and positions may be filled. Where only one valid nomination is received fora particular position by the close of nominations, the nominee shall be declared elected forthwith, and no ballot for thatposition shall be held.Within first seven days of May, the Secretary shall advise the Returning Officer of all valid nominations received, and ifa ballot is required shall advise him of a date no later than the fifteenth day of May for the ballot for all contestedpositions, and shall provide him with a list of voting members.While any Ordinary Member may be nominated to more than one office or position, no person shall be elected to morethan one position. Ballots shall be determined in the following order: for President, for Secretary, for Treasurer, forGeneral Gommittee Member, for Returning Officers, and for Auditor.

(45) Election of Honorary Life Members.If before the first day of May the Secretary receives a petition from at least twenty voting members requesting theelection of a member of the AUUG to the position of Honorary Life Member, then he shall arrange a ballot of themembership on this question to be conducted in conjunction with the annual election of Officers and General CommitteeMembers.

Vol 5 No 55

82AUUGN

Who’s Who

The following subscribers, to Volume 5 of AUUGN, are eligible to becomefounding members of the AUUGo I have NOT included institutions in this list.

Apply to the AUUG Secretary for consideration°

Ros AndersonTrevor BartonPeter Jo BillamColin BoswellStephen M. BradyKeith BristerChris CampbellDro Eddy Ko S. ChanDr° Chris ColesR E M CooperKevin DawsonWayne EdwardsM.C. ErDesmond FitzgeraldDro Ivan FrisMr J. Di GiacomoIan GriggRobert HegedusBill HibbertS.K. HockleyDavid HorsfallPeter IvanovIan JohnstoneMartin KennyCarl Do KneippSteven LandersProf. John LionsPeter MasonDavid McSweeneyDavid MillsomDr. R B NewellMr. Paul ObrienPeter PammentMr. Bill PetheramMichael Jo Fo PoulsenRoy RankinTed RigbyKen RobinsonTim RoperJim RutherfordDavid SanchezWarren SimonGraham SmithArmando Po StettnerPhil SutherlandCarole Sweaney

Ro BalsdonDavid BassellEdd BirchBrian BoutelDaniel BranissPerry BrownMalcolm CardisRoger Ao ClarkeDavid ColhounPhilip CountyMr John DeAnoHo Do EllisJohn FieldStephen FredeLeslie Bo FrohoffPaul GillisLindsay HarrisDavid HerdRoger Go HicksD P HodgsonSteven HudsonDennis JarvisSteve JordanHarry KhouryBob KummerfeldMr Yong Hiong LeongDr. RoJo LobbCraig McGregorFelicia MeagherLyn MoonKazuhiko NishiokaAlan Owenlan Paton

Christopher BarterMichael BelferDo BlackmanDon BowenMike BrennanHenry Wo and Edith BurkDavid CarringtonJeffrey CohenPeter CollinsonDro Cameron DavidsonLeeanne DiggelmannM. Jo EllisLeon FittinghoffAdrian FreedRoss GaylerRichard GrevisCoG, HartmannProf° J. Bo HextKevin HillJohn HoldenDavid HuntSteve JenkinShirley KeetingJohn KnaggsRobin LamacraftM J LiebeltTim LongJim McKieG MichalkGraham NealeAlbert NymeyerWo David OwenVeronica Paul

Michael A. Podhorodecki Zdravko PodolskiChris PriceHamish Reidlan RobertsMichael A. RobinsonMichael RourkeColin RuthvenGershon ShamayLionel Singerlan SmithRick StevensonPeter SwainProf. Go Tate

Mro Milton F. Thrasher K C TohColin Webb Peter WebbDro Bradley W. White Oki WidjajaTo Willoughby Norman Wilson

Greg QuinnKevin RevilleDavid RobinsonJohn RogersChris RowlesClaude SammutMichael SidhomAnne SmithMalcolm SmithTom StrongGeoff SwanDerek ThomasBob TrewinRob WebbNigel WilliamsClive Winkler

AUUGN83

Vol 5 No 5

Richard Wolff John Wulff

The following subscribers have been granted "founding membership" of theAUUGo

Derek Austin Peter D. BarnesBruce Butterfield Phil ChadwickRobert Elz Darryl GodfreyEoin Hyden Greg KableKen McDonell Willma NelowkinRobert Posener Greg RoseDavid Stirling lan F. Turner

Rod Bilson B.CoP. BorunGeoff Cole Tom CrawleyClary Harridge Glenn HuxtableMichael Kearney Chris MaltbyDr. Yo Kuang Oon Rob PikeMunro Saunders Tim SegallSteffan Po Weiss

The following people have been accepted as "normal members" of the AUUG.

Ko W. Anderson Ron Baxter Robert DouglasRichard Co Hibbard James Do Mann Graham MenhennittGregory Sharp Mr. Robert Lo Smith Peter Wishart

Gordon Helliwell,Stephen Prince

Finally we have two subscribers to the newsletter, Rick Southern and ToAo Nemetho

Vol 5 No 5

84AUUGN

Australian UNIX* systems User Group(AUUG)

Current Subscriber Membership Application

I, wish to becomea founding ordinary member of the Australian UNIX systems User Group and agreeto be bound by the rules of the association, as adopted by the meeting held onAugust 27 and 28, 1984, especially with respect to non-disclosure ofconfidential and restricted licensed information. I understand that, as acurrent subscriber to the Australian UNIX systems User Group Newsletter, I donot have to pay any membership dues for the remainder of 1984 and that, shouldI wish to remain a member of the association after this time, I will have topay appropriate membership dues after January I, 1985.

Signed Date

Name

Mailing address for AUUG information

UNIX Network address

I agree to my name and address being madeavailable to software/wardware vendors

YES NO

Office use only 10/84

* UNIX is a trademark of AT&T Bell Laboratories

AUUGN85

Vol 5 No 5

Australian UNIX* systems User Group(AUUG)

Membership Application

I, do hereby applyfor ordinary($50)/student(30)** membership of the Australian UNIX systems UserGroup and do agree to abide by the rules of the association especially withrespect to non-disclosure of confidential and restricted licensed information.I understand that the membership fee entitles me to receive the AustralianUNIX systems User Group Newsletter and I enclose payment of $ herewith.

Signed Date

Name

Mailing address for AUUG information

Telephone number (including area code)



YES NO

Student Member Certification

I certify that

student at

is a full-time

Expected date of graduation

Faculty signature Date

Office use only 10/84

* UNIX is a trademark of AT&T Bell Laboratories** delete one

Vol 5 No 5 AUUGN86

Australian UNIX* systems User Group Newsletter(AUUGN)

Subscription Application

I wish to subscribe to the Australian UNIX systems User Group Newsletter andenclose payment of $ herewith for the items indicated below.

Signed Date

One years subscription (6 issues) $30.00

available on microfiche or paper

Back issues of Volume i (6 issues) $24.00

available only on microfiche

Back issues of Volume 2 (6 issues) $24.00


Back issues of Volume 3 (6 issues) $24.00


Bacm issues of Volume 4 (6 issues) $24.00

available on microfiche, some paper copies

Back issues of Volume 5 (6 issues)available on microfiche or paper

$24.00

Subscribers outside Australia must add an extra $I0.00to cover surface mail costs

Subscribers outside Australia must add an extra $30.00to cover air mail costs

Name

Mailing address

Telephone number (including area code)



YES NO

10/84

* UNIX is a trademark of AT&T Bell Laboratories

AUUGN87

Vol 5 No 5

Peter IvanovAUUGN EditorSchool of EE and CSUniversity of New South WalesPO Box IKensington NSW 2033AUSTRALIA

+61 2 697 4040(and eventually +61 2 697 4042)

Vol 5 No 5

88AUUGN

registered by australia post publication no....

Documents