Australian Unix systems

G Ne letter

Vo 7

Registered by Australia Post Publication No. NBG6524

The Australian UNIX* systems User Group Newsletter

Volume 7 Number 6

April 1987

CONTENTS

AUUG General Information ...................... 2

Editorial ............................ 3

AUUG Winter 1987 Meeting Announcement ................. 4

Adelaide UNIX Users Group Information .................. 5

Rock C Music .......................... 6

ASCII vs UNIX ......................... 8

Taking Performace Evaluation out of the "Stone" Age .............12

Cake: a fifth generation version of make .................. 22

UNIX Menu System ........................ 32

From the ;login: Newsletter - Volume 12 Number 2 .............. 44

MIND(: A UNIX Clone with Source Code for the IBM PC ..........45

The DASH Project: Design Issues for Very Large Distributed Systems .......52

Book Review - The Nutshell Handbooks ................ 54

General Meeting Minutes ....................... 58

Letters to the Editor ........................ 60

AUUG Membership Catorgodes ..................... 79

AUUG Forms .......................... 81

Copyright © 1987. AUUGN is the journal of the Australian UNIX* systems User Group. Copyingwithout fee is permitted provided that copies are not made or distributed for commercial advantage andcredit to the source must be given. Abstracting with credit is permitted. No other reproduction ispermitted without prior permission of the Australian UNIX systems User Group.

* UNIX is a registered trademark of AT&T in the USA and other countries

AUUGN 1 Vol 7 No 6

AUUG General Information

Memberships and SubscriptionsMembership, Change of Address, and Subscription forms can be found at the end of this issue.

All correspondence concerning membership of the AUUG should be addressed to:-

’ The AUUG Membership Secrekary,P.O. Box 366,Kensington, N.S.W. 2033.AUSTRALIA

General CorrespondenceAll other correspondence for the AUUG should be addressed to:-

The AUUG Secretary,Department of Computer Science,Melbourne University,Park,Alle, Victoria 3052.AUSTRALIA

ACSnet: auug@munnari.oz

AUUG Executive

Ken McDonell, President

kenj@moncsbruce.ozMonash University, Victoria

Robert Elz~ Secretary

kre@munnari.ozUniversity of Melbourne, Victoria

Chris Maltby, Treasurer

chris@gris.ozSoftway Pty. Ltd., N.S.W.

Chris Campbell, Committee Member

chris@olisyd.ozOlivetti Australia, N.S.W.

John Lions~ Committee Member

johnl@elecvax.ozUniversity of New South Wales, N.S.W.

Tim Roper~ Committee Member

timr@labtam.ozLabtam Limited, Victoria

Lionel Singer, Committee Member

lionel@pta.ozLionel Singer Group, N.S.W.

Next AUUG Meeting

(Temporary address is kjmcdonell@er.waterloo.cdn)(University of Waterloo, Canada)

(This does not work)

The next meeting will be held at NSWIT on the 27th and 28th of August.Futher details are provided in this issue.

Vol 7 No 6 2 AUUGN

AUUG General Information

EditorialIt has become obvious to me that many people in the UNIX community are NOT aware of the UserGroup. This is especially true amongst commercial vendors and users of UNIX. I think the Groupshould try to improve the situation. On a personal level, tell people you know who use UNIX, but arenot. members, about the AUUG. Please show them a copy of this newsletter, and encourage them tojoin. The Group as a whole could promote itself more at wider forums such as the A.C.S., in theelectronic news, and at commercial UNIX seminars.

People that do not know that we exist cannot possibly become members

Special thanks to those who contributed to this issue, without them this Newsletter would be very shorton AUSTRALIAN content.

Please help the Newsletter by sending me a contribution.

REMEMBER, if the mailing label that comes with this issue is highlighted, it is time to renew yourAUUG membership.

AUUGN CorrespondenceAll correspondence reguarding the AULIGN should be addressed to:-

John CareyAULIGN EditorComputer CentreMonash UniversityClayton, Victoria 3168AUSTRALIA

ACSnet: auugn@monul.oz

Phone: +61 3 565 4754

ContributionsThe Newsletter is published approximately every two months. The deadline for contributions for thenext issue is Friday the 12th of June 1987.

Contributions should be sent to the Editor at the above address.

I prefer documents sent to me by via eleclronic mail and formatted using troff-mm and my footermacros, troff using any of the standard macro and preprocessor packages (-ms, -me, -ram, pic, tbl, eqn)as well TeX, and LaTeX will be accepted.

Hardcopy submissions should be on A4 with 35 mm left at the top and bottom so that the AUUG~!footers can be pasted on to the page. Small page numbers printed in the footer area would help.

AdvertisingAdvertisements for the AUUG are welcome. They must be submitted on an A4 page. No partial pageadvertisements will be accepted. The current rate is AUD$ 200 dollars per page.

Mailing ListsFor the purchase of the AUUGN mailing list, please contact Chris Maltby.

DisclaimerOpinions expressed by authors and reviewers are not necessarily those of the Australian UNIX systemsUser Group, its Newsletter or its editorial committee.

AUUGN 3 Vol 7 No 6

AUUGWinter Meeting

1987

Sydney, August 27 and 28.

The Winter 1987 AUUG meeting will be held in Sydney, August 27 and 28(Thursday/Friday) 1987.

The meeting is being hosted by the New South Wales Institute of Technology. Localconference organisation is under the direction of Greg Webb, gregw@nsMtgould.oz.

More detailed information about this conference will be in the next issue of AUUGN,and posted to the newsgroup aus.auug.

We are now actively seeking papers for this conference. The programme committeechairman is Bob Kummerfeld from the University of Sydney.

Please send abstracts of papers to him at bob@basset.oz. Paper abstracts can be sentto

Dr R.J. Kummerfeld,Basser Department of Computer Science,University of Sydney,NSW 2006,Australia.

The deadline for abstracts is Jul 10 1987. Authors will be notified of acceptance byJuly 31.

Authors of papers given at the conference will receive complimentary admission to theconference dinner. Authors who provide a written version of their paper by August 21will have the conference registration fee waived.

In addition, AUUG has decided to hold a competition for the best paper by a full timestudent at an Australian educational institution. The prize for this competition will bean expenses paid trip to the AUUG meeting to present the winning paper. Studentsshould indicate with their abstract that they wish to enter the competition, and thenshould provide the full written paper to the programme committee (which will be thesole judge) by August 14. AUUG reserves the right to not award the prize if noentries of a suitable standard are forthcoming.

It is hoped that this will become a regular feature of AUUG conferences.

Vol 7 No 6 4 AUUGN

Adelaide UNIX Users Group

The Adelaide UNIX Users Group has been meeting on a formal basis for 12 months.Meetings are held on the third Wednesday of each month. To date, all meetings havebeen held at the University of Adelaide. However, it was recently decided to changethe meeting time from noon to 6pm. This has necessitated a change of venue, and, asfrom April, meetings will be held at the offices of Olivetti Australia.

In addition to disseminating information about new products and network status, timeis allocated at each meeting for the raising of specific UNIX related problems and fora brief (15-20 minute) presentation on an area of interest. Listed below is a samplingof recent talks.

D. JarvisK. MaciunasR. LamacraftW. HoskingP. CheneyJ. Jarvis

"The UNIX Literature""Security""UN/X on Micros""Office Automation""Commercial Applications of UNIX""troff/ditroff"

The mailing list currently numbers 34, with a healthy representation (40%) fromcommercial enterprises. For further information, contact Dennis Jarvis(dhj@aegir.dmt.oz) on (08) 268 0156.

Dennis Jarvis,Secretary, AdUUG.

Dennis Jarvis, CSIRO, PO Box 4, Woodville, S.A. 5011, Australia.

PHONE: +61 8 268 0156UUCP: {decvax,pesnta,vax135} !mulga!aegir.dmt.oz!dhjARPA: dhj % aegir.dmt.oz! dhj@ seismo.arpaCSNET: dhj@aegir.dmt.oz

AUUGN 5 Vol 7 No 6

Rock C Music

Bruce EllisAT&T Bell Laboratories

There are some frightening parallels between the Rock Music industry and theComputer industry. A quick look at the local newsstand reveals startling similarities.Unix Review is a lot like Rolling Stone. A software review in the former reads muchlike a record review in the latter.

I was sitting in a bar on 8th Street, slowly sipping a Long Island Iced Tea. To the leftof me were three members of a Heavy Metal band, to the fight two guys talking aboutthe financial modelling package they were working on. The conversations were verysimilar. The guys to the left were priming the jukebox with Hendrix and gruntingbass lines to each other. The guys on the fight were playing the Doors on the box andsketching screens and menus on the coasters. The most apparent difference betweenthe two groups wass the money. The guys on the left were not short of smart leatherjackets but they were scrounging to pay for the next round of Bacardi and Cokes. Theguys on the fight did not have this problem. They would nod at the barman midsentence for their refills. They lived in Manhattan. I’m sure the guys on the left livedin Queens or Brooklyn, or even (God forbid it) New Jersey.

When we move on to the field of electronic musical instruments the parallel linesmeet. Fortunately a standard asynchronous information transfer protocol (MIDI) iswell established and more or less demanded for every product. MIDI interfaces areavailable for many types of PCs and lots of software, both good and bad, is availableand heavily pirated. This field is a micro hackers dream and the musical instrumentshows have turned into engineering shows. Don’t try and use any musical term atthese unless you are willing to back it up with a distributors name. Where do you buyyour leading notes?

Lets look at the end users. Last Tuesday night I was wiling away my time at a bar inthe Village, as is my custom. I sipped my Beer as I watched the next band set up."Do you have a cable with an XLR female on one end and a quarter inch male on theother?" Yes, but can I plug it into my Unibus? Finally the band is ready. The guy"doing" the PA hasn’t a clue what he’s doing, but he’s merely support staff and has along tradition of performing busy meaningless tasks to uphold. The users havebrought their own peripherals, so there is little he can do about security. He can’treally call a meeting in the middle of a song to discuss use of the midrange horns noris he likely to rewire the stage mid set so I guess the analogy falls down.

Anyway. Back to the band. They’re doing a plausible job of actually playing musicand the crowd is content. There are bugs, a bit of feedback now and then, but thesystem seems to be holding up. I ponder a while at the little box sitting on top of thesythesizer, the one connected in-to-out and out-to-in to the synth. Another drink,

Vol 7 No 6 6 AUUGN

another XTC clone and I realise. It is a MIDI-controlled synth module slaved to thekeeb. Only one of the MIDI chords is actually carrying data! What the hell? Itworks so why bother telling the user he doesn’t need all that hardware? Sell himsome more. Speaking of hardware the more-than-competent drummer has two bassdrums! A backup? Surely not. At the end of the second set the band did the usual"introduce the band and see how long they can solo for" song. The second bass drumwas for the "Flashy Demo". Sign him up to sell laser printers. ~

Let’s look at the industry watchers. After the Slayer concert at the Ritz the best Icould get out of the Black-Shirts was "They’re really good!", hardly a compellingproduct endorsement. What does it matter? They picked a good name. A couple ofthousand Black-Shirts belting acrosstown to the PATH, chanting "Slayer!" andbreaking Budweiser bottles is as good a promo as they’ll ever need. And they put ona great show. It is a bit sad that the best thing that can be said about a lot of bands is"What a nice guitar Jimmy has". But this is what the industry watchers do. This isdone all the time in the Computer industry, particularly with words like UNIX and C(I guess you were wondering what this has to do with AUUGN). Who cares about theprestige names: the Marshall’s the Strats the 386s? What’s is being done with thegear, what’s coming out the other end? Don’t tell me about your new machine, I’mquite happy using a VAX and never want to have to port another program in all mylife. Anyway, I like those bright red angular guitars that sound like banjos and don’tstay in tune.

So what can we conclude from all this? Buy Bon Jovi Computers I guess, and giveSUN a bad name.

AUUGN 7 Vol 7 No 6

ASCII vs UNIX~

Bob Buckley

School of Mathematics, Physics, Computing and Electronics,Macquade University,Sydney, NSW 2109.

bob@mqcomp.oz

Introduction.The UNIX System has been with us for a while now and some of its initial advantages seem to be

fraying with time. This is an attempt to indicate a few places where repairs are needed.The motivation for this comes from a persistent problem of inexperienced users and their difficul-

ties with printers and printer support software. However, the problem spills over into a number ofrelated areas. We seem to have a number of models for ASCII files coexisting (and undocumented) inthe UNIX environment.

I’m worded about file types. This is a naughty thing to say since there are no file types in thiscontext. We all know that a UNIX file is just a string of 8-bit quantities. This means that we can easilycopy, concatenate or do other simple things to files. Though this seems like a good idea, it turns out tobe a too simple to be completely practical.

This article is more a warning than a report. It was presented (before being written) at the Ade-laide AUUG meeting. It is less ready for printing than I would like.

ASCII interpretation.

Most of us feel we understand use of ASCII on UNIX. However, there are several issues whichare not generally addressed.

UNIX likes to remove CR characters from its input. This simplifies recognition of line termina-tors. It gives an excuse for pretending the CR character doesn’t exist. Unfortunately, this ostrich atti-tude doesn’t always work. More and more, files and software is being imported to the UNIX context.Some data and software prefers to use CR to achieve overprinting while most UNIX software uses BS.Typically, CR isn’t correctly managed by UNIX utilities. How many programs reset their columncounters when they see CR? Pr doesn’t tackle the problem (it is tricky - in multicolumn output, doesCR mean CR or ’start-of-column’).

Using CR for overprinting raises another question. Should we interpret spaces as being destruc-tive or non-destructive? At the moment, for physical reasons, we have a mixture: terminals tend toassume destructive spaces while printers have non-destructive spaces. We seem to get by, but some-times it really matters. It would be nice to have a consistent model.

Another problem character is FF. Mostly, this is ignored by UNIX but sometimes it causes trou-ble. It didn’t used to be there but later versions of troff seem to be aware of page boundaries. Also,BSD pr will insert FFs (but seems to not like them in the input). The problem here is that the modeldoesn’t determine whether FF moves to column zero (output devices vary on this). Again, pr has aproblem with this character. Should FF start a new column or a new page?

UNIX is a trademark of Bell Laboratories.

Vol 7 No 6 8 AUUGN

At the moment, vertical motions are not consistent. NL is generally assumed to move to columnzero (except by col) while other motions ( ESC 7, 8 or 9 and VT don’0. Much of the rest of the ASCIIcontrol codes are ignored except by the tty drivers (and that’s a whole new ball-park). UNIX seems tomanage TABs pretty well.

UNIX file types°

There have always been a few special UNIX file types. The first obvious example is a directory.There are many restrictions on what can be done to a directory by a user program. There are some spe-cial programs which deal with directories, eg. Is, mv, cp ....There are a few restrictions, like notwrite(2) hag.

Other special file types are the special files. These allow different operations (via ioctl(2)) andare really special. Pipes, sockets, etc. are different again.

Another group of file types known to the kernel is the executable files. An executable file can beexec (2)ed - others can’t. The kernel knows they are executable because they contain type information.

UNIX is full of file types when you consider the utilities. Look at the manual decription of fileformats (it used to be section 5); as well as a.out(5), you will find things like ar(5), tarO), dump(5),wtmp(5) and utmp(5). All of these are file types.

This is OK. The UNIX kernel doesn’t know (or care) about these. It is all up to the programmersresponsible for the system software. We just need to be a little more honest: UNIX does have lots offile types but the kernel doesn’t care. The utilities care.

Implicit File Types - the Problem.

UNIX has many implicit file types. Further, these types aren’t always documented and peoplearen’t conscious of their existence. Many programs are unexpressive of their limitations.

Several programs (eg. ed, vi and pr) expect ASCII files ie. files containing spaces, printable char-acters and NL (provided NLs aren’t far apart). A few other characters are acceptable, in particular TABand BS. There are common ASCII characters that are not generally acceptable (eg. CR and FF). Suchfiles present few problems provided lines don’t get too long.

Actually, such file have different types. C source, Pascal source and English text are differenttypes. Of course, the UNIX kernel doesn’t care but other software does, eg. the C compiler. The file (1)utility attempts to recognise the difference.

There are other anonymous file types managed by UNIX utilities. Nroff is good at producing spe-cial file types - by default it produces files intended to be sent, in raw mode, to a TTY37 (whatever thatwas). Control characters have different meanings (particularly LF). Extra characters may be used, par-ticularly CR, SI, SO, VT and ESC (with 7,8 or 9). The interesting thing is that nroff’s TTY37 outputcan be used as input to other programs, particularly col and pr ( ul and more on BSD systems) Then,with luck, col’s output may be suitable input for pr!

Nroff-Txxx produces a different file type and its output should be sent directly to a xxx device.Though such a file contains only ASCII characters, it is not UNIX’s idea of an ASCII file (despite whatfile(l) says). A related problem arises with graph(l) or plot(3) output. Due to poor supportlimited/infrequent use this present fewer problems, in practise.

We pretend there aren’t file types. For some utilities this is true. Programs like cp, od, tr, etc.genuinely don’t care about their input.

The real problem is that there are lots of different file types and there are lots of ways of describ-ing them. What determines a file type? Is it determined by the programs or devices which can processit? Is it determined by its contents or its intended interpretation? Each approach has problems.

TTY37 files are a sort of intermediate form and have a file type which is partially documentedand supported. Output for other printer types is not generally supported and file types are not defined.The problem is generally regarded as ’too difficult’. As a result, users are expected to know a file’stype and to process it accordingly. Many utilities could object to nonsense input.

AUUGN 9 Vol 7 No 6

What to do.There are several things that need fixing now. These are minor but need to be fixed consistently.

File (1) utility is a rarely used and usually out-of-date program. It needs updating and a bit of promo-tion. Several programs need to improve their image. Pr(1) should complain about CR and FF withmulti-column output. (What do CR and FF mean in multi-column output?)

The TRY37 model of ASCII is broader than we generally need. It is broader than we can easilyhandle (few printers handle reverse motions or special characters, some don’t backspace and a few can’teven overprint). There are probably three major sub-types. The simplest is a basic file for editing.Such a file contains only printing characters (040-0176), TABs and NL. Most source code, data andnroff/troff input is like this. This material can be easily manipulated - edited, printed, etc.After this comes fries directed to simple printers. As well as the above, they may include overprintingvia BS (perhaps FF should also be allowed). A program like pr should be able to handle this as input.Character widths are fixed. Font handling for normal, bold, italics and underline should be included(note: bold and underline are currently expressed as oxierprinting but it should be explicit, especially nowthat continuous underlining is supported). Programs which understand BS should allow overprintingusing CR (this is pretty easy and available on other systems).The TTY37 model allows SUSO special character handling. This can be merged with the bold!italicfont handling above.

The TI’Y37 model supports reverse motions and half-line motions. Note: reverse motions can be elim-inated using col(l) so only half-line motions are necessary.

Other nroff output is aimed at specific devices. This should be explicitly indicated so lpr, etc.can check that output is going to appropriate devices. Other checks are also needed - eg. no printing ofexecutable (non-ASCII) files unless these are some sort of download file for the device. Col and otherutilities should complain about unsuitable input. Files requiring particular hardware (fancy fonts, finemotions, proportional spacing, etc.) should be made explict. With so many (nearly) compatible printersthis gets complicated. Checking to see that output is suitable for a particular printer is a real headache -but we need to face this problem. There are problems ensuring fonts are properly downloaded and thatthe printer is in the right mode, etc.

If we consider files intended for bit-mapped screens or ’intelligent’ terminals, the problem getsworse.

This boris down to a need for explicit file types in the UNIX environment. Simple ASCII (edit-able files) are probably a basic type. It is usually easy to see what these are about. Even so, it doesn’tmake much sense to cat C source code and nroff input together (just as it isn’t sensible to append a fileto an archive). Merging and ASCII file with a printer file may be sensible but it could require signifi-cant work (is this what desk-top publishing is abou0. Like TTY37 files, PostScript and plot (5) fries areintermediate forms. Should we expect to be able to combine these file types? This is the stuff thatdreams are made of.

More needs to be said about file types. Documentation should be fixed up and most references toTTY37 should be deleted. People tend to ignore stuff about devices they don’t have.

A rather specific problem is that output programs should handle file types automatically. Conver-sions for italics, bold, underline, etc. should be standard for all devices. Ideally, this is done as late aspossible - perhaps in the device driver (after all, tty drivers do just about everything else) or in the verylast program. When this isn’t possible, warnings could be posted. A major contender for improvementis the lpr/lpd software (consider/usr/games/worms piped into lpr). Surely, Berkeley’s printcap (andtermcap, for that matter) needs conversions for TTY37 oddities (reverse motions, half-motions, etc.).

As a final remark, obtaining device specifications from the environment doesn’t quite work. Itfails for most redirected output - output piped to lpr or directed to another terminal. Networks canmake the problem even worse. This is not an easy problem to solve.

Vol 7 No 6 10 AUUGN

ConclusionThe UNIX model of ASCII files was based around the TTY37. This terminal has departed (or was

never here) but its memory is enshrined in the UNIX environment. It served us well but the advent of’advanced’ printers and displays show the need for change. If this is mismanaged, we may neverrecover.

In most cases, the utilities are the problem. The above recommendations hardly effect the UNIXkernel. The utilities have been derived from a large user base. It is difficult to maintain a consistentmodel over the time they’ve been developing and such a large development team. There might be fewerproblems if the model were more explicit.

You may feel that this approach is totally (or partially) wrong. This article will have served it’spurpose if you think about it.

AUUGN 11 Vol 7 No 6

TAKING PERFORMANCE EVALUATION OUT OF THE STONE" AGE

Ken J. McDonelltDepartment of Computer Science

Monash UniversityAUSTRALIA

kenj@moncskermit.oz

ABSTRACT

Predicting the performance of any computer system is critical to rational equipment acquisition by purchasers andsuccessful product delivery by vendors. This paper takes a brief but critical look at "figure of merit" performancemetrics, especially with respect to their reliability and predictive usefulness.Necessary prerequisites for serious performance evaluation and prediction are identified. The architecture of theMUSBUS benchmark suite is described with particular emphasis on the technical considerations that allow MUSBUSto be tailored to accurately predict multi-user system behaviour in specific operational environments.

1. Performance Evaluation GoalsAll computer system performance evaluation is directed to one or more of the following specific goals,

(G-l) Compare the measured performance of heterogeneous systems executing specific identical tasks.

(G-2) Compare the anticipated performance of heterogeneous systems executing the same "typical" tasks.

(G-3) Collect diagnostic evidence to substantiate hypotheses about anomalous performance (either very good or verybad) for one or more tasks executed on a particular stable system.

Irrespective of the specific tests employed most performance metrics are based upon resource consumption (e.g. cputime), throughput (e.g. as measured by elapsed time) or some related measure (e.g. number of users supported ormega-grunts per second).

Goal G-2 typically implies performance prediction based upon performance measurement, and this is by far the mostuseful application of performance evaluation. Purchasers want reliable estimates of expected system performance intheir anticipated operational environment. This would be useful not only when new systems are being acquired, butalso when upgrades are considered, e.g. "what demonstrable improvement can we expect from adding 2Mbytes ofmemory or a second disk controller?". On the other hand, vendors need reliable estimates of system performanceacross a range of designated application environments to guide marketing and system tuning activities.

The central thesis of the first half of this paper is that G-2 is the most widely sought, but seldom realized, goal ofcurrent performance evaluation activity in the Ur,ax~ community. An approach to achieving this goal in any opera-tional environment is described in the later sections.

2. Some Performance Tests and MeasuresThe UNix system and the C programming language combine to provide a stable software execution environment onmachines across the full price-performance spectrum. The consequent ease with which portable software can bedeveloped has fostered a large class of tests purporting to measure system performance by a single "figure of merit"metric. These tests fall into two basic classes,

* This paper will be presented by Ken at the next Usenix meeting, Phoenix, Arizona, 3une 1987 and will beprinted in the proceedings - AUUGN Editor.

t Currently on leave at the Department of Computer Science, University of Waterloo, Ontario, CANADA,kjmcdonell@er.watedoo.cdn or kjmcdonell@waterloo.csnet

~t UNtx is a Registered Trademark of AT&T.

Vol 7 No 6 12 AUUGN

(a) The "one liners" that are easy to type in, use standard UNIX programs and measure cpu time using either theshell built-in time function or/bin/time. Some common examples are shown in Figures 1 and 2.

(b) Synthetic tests such as the "stone" family (whet[3], dhry[9, 12], dhamp[5] .... ). ’Irrespective of which class they come from, these tests may be characterized as follows,(a) The test is easy to run, and is guaranteed to produce a value for the performance metric.(b) The value obtained is statistically unreliable due to an unknown and often large measurement error; worse still,

the relative error may vary between different machines.(c) The performance metric typically measures some combination of

¯ cpu arithmetic speed, and

¯ C compiler quality.Unfortunately, other important factors (as identified below) are totally ignored.

(d) System performance under real operating loads may be, but most often is not, well correlated with the test andperformance metric[6].

Clearly these tests potentially satisfy the performance evaluation goal G-1, and with careful use could assist with goalG-3. However the majority of people running and interpreting these tests appear to believe the results have somepredictive value as per goal G-2. The compilation and publication of tabulated results from these tests under theheading of "UNtx benchmark results" is highly misleading because what has been measured is influenced by only afew of the many factors contributing to system performance - this is the fundamental weakness common to all thesingle "figure of merit" approaches. These test programs and performance evaluation suites are essentially of nomore use than common sense and guesswork in predicting the performance of a real system under actual load condi-tions.To be fair, it is the use of the tests and interpretation of the results that is most commonly at fault. The tests haveoften been constructed for a specific purpose, and in that role are both accurate and useful. Despite the pleas of theircreators (see for example[8,10,11]), and caveats in the code, it is the adoption of the test for an unsuited role (i.e.general performance prediction) that is the problem.Another class of tests has evolved from recognition of specific areas of weakness in some UNiX implementationsand/or factors perceived to be important influences on performance, for example$ filesystem throughput¯ system call overhead

main ( ){

int i;for (i = O; i < i000000; i++)

;

Figure 1: The "count to a million" test.

$ time dc99k2vpq1.414213562373095048801688724209698078569671875376948073176679737990732\478462107038850387534327641572

9.2 real 1.3 user 0.2 sys

Figure 2: The "square root of 2 to 99 decimal places" test.

AUUGN 13 Vol 7 No 6

® fork() and exec0 speed® pipe throughput

o memory access bandwidthThese tests are clearly aimed at goal G-3, and any wider intel~retation of their results cannot be made. Even in thisrestricted usage, these tests can be tricked by implementors aiming for a competitive edge in commonly used bench-marks (e.g. cache the results from getpid0). In some cases the tests are simply misguided, measuring behaviour thatis uncommon in many operational U~,ax environments (e.g. random file I/O).Some attempts have been made to provide test environments in which many G-3 style tests are performed, and theresults combined using relative weights of importance [1,4, 7]. The disadvantages of this approach are,(a) the tests are not statistically independent (interaction between factors is not measured), and(b) accurate assignment of the weights of importance is more difficult than constructing a user-level workload pro-

file as suggested below.Finally, there have been some G-1 type tests developed for comparing heterogeneous systems executing the same setof end-user tasks, for example [1,2]. The predicitive value of these tests depends upon the extent to which the sup-plied end-user tasks are representative of a particular operational environment.

3. Improving the Methodology

In the performance of various Ur,rtx systems running the same task was accurately measured, the differences in theobserved results may be attributed to some of the following factors,

® processor performance; includes raw speed, configuration options (e.g. FPU, data cache, co-processor) and interruptservicing overheads

. disk subsystem performance; device characteristics, bus bandwidth and channe!/controller configuration

® C compiler; the quality may vary dramatically with revision level® U~rr~ kernel implementation; quality varies between base versions, ports and release levels

® filesystem configuration; allocation of filesystems across spindles and filesystem age

o real memory available to user processes~ configuration parameters; most notably disk buffer cache size and filesystem block size(s)

Reliable performance evaluation tests must be sensitive to all the above factors, because the performance delivered tothe end-user can be seriously degraded by any one of these factors. The simplest test meeting this criterion is tomeasure the time required to perform some mixture of typical processing tasks from the anticipated operationalenvironment. In this way, total system performance is measured directly, rather than attempting to isolate and meas-ure the performance in each of the critical areas.

Whilst there undoubtedly exist classes of U~rtx users with similar patterns of system usage, it is unrealistic to expectthat one test or one mix of processing tasks will be representative for all operational environments. Rather, weshould be aiming for tools that help us create, realistically execute and instrument the running of a representative col-lection of tasks on a variety of system configurations.

Serious performance evaluation requires,

(a) Definition of the anticipated workload profile.

(b) A test environment that will execute randomized tasks, chosen from the desired workload profile, for variouslevels of system load and record statistically sound measures of resource consumption. This test environmentmust be portable and extremely robust to maximize its usefulness and to encourage vendors to run user-specificbenchmark tests, often at remote locations.

(c) Careful documentation of the environment in which the test was conducted (hardware configuration, revision lev-els of the operating system and C compiler, workload profile, sysgen configuration parameters, filesystem parti-tioning, etc.).

Vol 7 No 6 14 AUUGN

A workload profile may be characterized by a set of independent user-level tasks, each typically corresponding to oneor more program executions. For each task, the following information is required,

® the particular programs involved

representative test data (data files, user input, patterns to search for, directory contents, etc.)relative frequency of execution

Identifying and describing the anticipated workload profile is a task of varying difficulty. In some environments, his-torical records (e.g. process or shell accounting) or known application usage provide accurate data from which theworkload profile may be constructed. In other cases, informed guesswork is required.

For the MUSBUS multi-user test described below, a workload profile consists of an annotated shell1 script with allassociated data files. Tasks with high relative frequencies may appear more than once in the script.

4. MUSBUSThe Monash University Suite for Benchmarking U~r~x Systems (MUSBUS) is a public-domain benchmark suitedeveloped originally for equipment comparison during acquisition procedures.The suite supports all three goals of performance evaluation with a simulated multi-user testbed facility and a batteryof specific diagnostic tests.The diagnostic tests have been designed to measure raw speed in very specific areas. Their execution is controlled bya shell script and parametedzed so that the default values effecting test selection, size and duration may be over-ridden by command line options and environment variables. Table 1 provides a brief summary of these tests.

Of all the tests in MUSBUS, the simulated multi-user test is the by far the most complicated, most realistic and mostlikely to uncover operating system bugs. It is also the test specifically engineered to provide reliable predictions ofanticipated performance (goal G-2) since it may be easily configured to perform "typical" tasks for any operationalenvironment and then run on heterogeneous systems.

Once a workload profile has been defined (as described in the previous section), several (typically 4) scripts areautomatically created, each comprising a randomized permutation of all the tasks in the workload profile. A controlfile (workload) is also created to describe how each script should be run (refer to Figure 3).

The multi-user test simulates a variable number of users, each executing their own job stream. The job streams arechosen by cyclic selection from the scripts.

Control over the multi-user test rests with the program makework (refer to Figure 4) that performs the following func-tions.

(a) Read the workload and script files into dynamically allocated buffers.

(b) Make cloned copies of itself (via fork()) to run the job streams for groups of users (necessary due to per processopen file limits).

(c) Start each user shell with its input coming from makework via a pipe.

(d) Send random chunks of input to the job streams, controlled so that the aggregate rate across all simulated usersdoes not exceed a specified rate in characters per second.

(e) All output from the shells and echoing of all input is directed to one or more real tty devices to ensure that anappropriate number tty output interrupts occur. See Figure 5.

(0 When all script input has been sent, wait for all user shells and makework clones to terminate.

All MUSBUS tests are run under the control of a large Bourne shell procedure charged with.

(a) Executing each test several times (the default is 6 or 3, depending on the particular test), recording the/bin/timeresults then computing the mean and standard deviation of the total (user plus system) cpu and elapsed times.

1 The choice of "shell" is truly arbitrary, and may include any interactive application environment, e.g. an SQLdatabase query language interface.

AUUGN 15 Vol 7 No 6

Test Controlling Variables DescriptionName and Default Values

arithloop [1000] A family of tests that compute the sum of a series of termssuch that the arithmetic is unbiased towards operator type.Each major loop in the computation involves summing 100terms; there are $adthloop major loops. Repeated for allflavours of ints and floats.

dc Compute the square root of 2 to 99 decimal places using dc.This test is due to John Lions (University of New SouthWales) who has suggested it as a good first order measure ofraw processor speed.

hanoi ndisk [ 17] A recursive solution to the classical Tower of Hanoiproblem. Sndisk provides a list of the number of disks for aset of problems.

syscall ncall [4000] Sit in a hard loop of $ncall iterations, making 5 system calls(dup(0), close(i), getpid0, getuid0 and umask(i)) periteration.

p~ it [2048] One process (therefore no context switching) that writes andreads a 512 byte block along a pipe $io times.

spawn children [100] Simply repeat $children times; fork a copy of yourself andwait for the child process to exit.

execl nexecl [100] Perform $nexecl execs using execl0. The program to beexec’d has been artificially expanded to a reasonable size.

context switch [500] Perform 2 x $switch context switches, using pipes forsynchronization. The test involves 2 processes connected via2 pipes. One process writes then reads a 4-byte(descending) sequence number, while the other process readsthen writes a sequence number.

C Measure the time for each ofcc -c cctest.c

andcc cctest.o

where cctest.c contains 124 lines of uninteresting C code(108 lines of real code after cpp).

seqmem poke [100000] These tests try to measure memory read accesses per realarrays [8 64 512] second. Spoke accesses are made into arrays of Spoke x

1024 ints. A cyclic sequential access pattern is used.randmem Like seqmem, but uses random access patterns.fstime blocks [62 125 250 500] Sequential file write time, file read time and File copy time

where [.] for files of $blocks Kbytes. Temporary files will be createdin the directory Swhere. The copy time for the larger files isthe best indicator of throughput and reflects the type of diskactivity most commonly generated by compilers, editors,assemblers, etc.

Table 1: MUSBUS diagnostic tests.

Vol 7 No 6 16 AUUGN

/bin/sh -ie <script.l/bin/sh -ie <scripto2/bin/sh -ie <script.3/bin/sh -ie <script.4

Figure 3: Typical specifications for executing scripts (workload).

script

makework

¯¯¯7

¯

user #jshell

makeworkclone #1

¯!

user #kshell

File I/O ~,Pipe I/O ..... ~

makeworkclone #2

I ¯I

I

user #mshell

user #1shell

Figure 4: Overall architecture of the MUSBUS multi-user test.

AUUGN 17 Vol 7 No 6

_ -

..- ., \ Pipe I/O .... :~

~ ~ ~ iI~~

user #j I [ I

Figure 5: Directing terminal output to a physical device.

(b) Reconfiguring the multi-user tests to allow tty and filesystem activity to be distributed across an arbitrarynumber of physical devices.

(c) Performing tests with different control parameters, e.g. varying the number of job streams in the simulatedmulti-user test.

(d) Monitoring completion status and standard error output to detect failed tests.

5. Issues Related to Test Engineering

The development of the MUSBUS multi-user test in particular has highlighted a number of issues related to bench-mark test design in the UNiX environment.

Quiescent system configuration. Some tests must be run as super-user to avoid per user limits (e.g. maximumnumber of processes). However, given the performance prediction goals, the tests should be run on an otherwiseunloaded machine in multi-user mode. This ensures that mandatory daemon activity will be present during testmeasurements.

Interactive input rate limitation. Limiting the rate at which input is presented to the shell and other interactiveprograms is an important factor influencing the predictive accuracy of the multi-user test results. Without this con-straint, an interactive program’s contribution to resource consumption for the job stream may be significantly reduced(e.g. artificially short program residency leads to higher buffer cache hits rates during exec0 and application file I/Ofor repeated program executions, and reduced swapping and/or paging activity). Of course the ideal situation wouldbe to simulate demand driven (i.e. no typeahead) and rate limited input. Unfortunately there is no portable and cheap(in terms of resource consumption) software technique2 for one process to determine that another process is waitingfor input, and so simulating demand driven input is not possible.

Bogus file sharing. If tasks in the job streams require access to the same data file, private copies should be madeunless the files are truly shared in the application environment, otherwise buffer cache hits will artificially reduce thecost of file I/O. For example, if all N job streams contain an edit task on a sample data file, there should be Ncopies of the file made, one per simulated user.

Multiplexed standard input. When two processes compete in time for the one source of standard input (see Figure6) serious problems may arise if the input generator (i.e. makework) is not response-driven. In general makework

Although external hardware "stimulators" have been used in some cases.

Vol 7 No 6 18 AUUGN

cannot tell whether the current "chunk" of input text is intended for the user’s shell or some program invoked fromthat shell or a mixture of both. With reference to Figure 6 there are many pathological situations, the worst beingprogram K consumes in one read some input that includes it’s own termination command and some of the followingtext intended for the shell once program K has finished - the shell never sees that text! The architecture shown inFigure 7 has been used to overcome this; keyb includes the rate-limited text generation algorithm from makework andallows separation of shell and application input. However to retain control over the shell’s rate of execution, the shellscript must be padded with comments by the number of bytes in the input stream to program K.Testing for failure. Makework checks the results of every system call, has a SIGPIPE handler and checks the statusreturned via wait(). If any error is detected, makework kills off all shells and the makework master kills off all clones(and their dependent shells). There is a certain degree of paranoia in this error checking, fostered by several badexperiences in which bizarre Urnx implementation bugs resulted in very good, but incorrect, predicted performance (if

makework

user #ishell

IIII

Pipe I/O ..... :~

program Kfor

user #i

Figure 6: Multiplexing standard input in a job stream.

makework

!

I

user #ishell

File I/O ~~,Pipe I/O ..... ~

program Kfor

user #i

keyb

Figure 7: Multiple input sources for a job stream.

AUUGN 19 Vol 7 No 6

only a fraction of each job stream is executed, the work can be completed in a very short time!). No program or sys-tem call can be assumed to always execute correctly.

Randomizing the processing. Particularly misleading results are produced when a number of identical job streamsare executed in effective synchrony. In some other benchmark suites, this has been used as a cheap way of increas-ing the "work" performed in a test. MUSBUS randomizes the processing load by using permuted scripts and ran-domizing the input rates to individual shells.

Using standard tools. MUSBUS uses many standard U~IX tools and utilities, in particular the Bourne shell, awk,sed, grep and a particularly bland vanilla dialect of C that is very portable. Uses include,

® permuting tasks to construct scripts

o checking standard error output for unexpected messages

® producing statistical summaries of repeated test results

~ post-processing results to automatically produce tbl input for summary tables and tables comparing system perfor-mance

® the driving script, controlled by command line arguments and environment variables.Constructing portable software. Since MUSBUS was specifically designed for comparing performance betweenheterogeneous U~,nx systems, software portability was always an issue of importance. Despite the apparent uniformityof the C and U~,ax interfaces, and considerable prior experience in building portable systems, a number of hiddenincompatibilities were revealed in early MUSBUS usage. Some of the more notable problems included,® /bin/time produces different format output, which means different awk scripts are required to produce the statistical

summaries.The behaviour of wc when given a single argument is not consistent.

Trying to measure short elapsed time intervals varies between, impossible, hopelessly unreliable and grosslyobscene code.

The total lack of standardization in cpp predefined macros to reflect environment parameters (cpu and Ur,ax fla-vour) led to the creation of yet another redundant set of cpp macros that must be checked by hand before thesoftware can be installed.

6. Performance PredictionAll MUSBUS performance predictions are based upon the multi-user test results for a varying number of job streams.Provided sufficient data points have been collected (4 or more) over a range of "number of job streams" that movesout of the linear region of performance behaviour, reasonable extrapolated results can be obtained for each of themeasures described below.

System throughput: the elapsed time for a particular number of job streams.

System saturation: can be deduced from the ratio of cpu to elapsed times.

Relative response time degradation: can be determined directly from the ratio of elapsed times for 1 and N jobstreams.

These predictive measures may be extrapolated to answer the following sorts of questions.

® With 48 simulated users, which system offers best throughput?

¯ Which system supports most simulated users at 0.85 cpu utilization?

® Which system supports most simulated users at the point where response times have deteriorated by 50% over thesingle user performance?

Accurate interpretation of measured performance requires considerable skill and awareness of factors such as the fol-lowing.

(a) Particular hardware configurations, versions of the same Unix port and C compilers vary with time to such anextent that labelling one set of figures as from Brand X Model Y is misleading to all concerned.

Vol 7 No 6 20 AUUGN

(b) MUSBUS is intended to be reconfigured in the multi-user simulated workload test to reflect the work profile ofa particular user site. Whenever different workloads are used the results cannot be compared.

(c) Deliberately the MUSBUS tests are in two distinct categories, raw speed and multi-user. The former are usefulfor diagnostic purposes only and give little useful information for a potential purchaser. The latter test givesgood predictions of system performance.

(d) Changing Unix configuration parameters (e.g. cache size, filesystem architecture, filesystem age, etc.) may havedramatic effects on the observed performance.

(e) Beware of simulating too few users in the multi-user test. Useful information about system throughput and per-formance under heavy load conditions can usually be obtained by extrapolation of various measures computedfrom the CPU and elapsed times for the multi-user tests with various numbers of users. However this assumesthe machine has been sufficiently loaded to move out of the linear part of the performance curves. For very fastmachines, this may require emulation of a large number of users in the multi-user test.

(f) Beware of simulating too many users in the multi-user test. This can result in unexpected resource depletion(e.g. serial line bandwidth) that does not accurately reflect the likely operating conditions.

(g) Serious testing has been known to "break" UNIX ports. Causes have been identified as implementation (confi-guration) limits in the system being tested (e.g. proc slots), real bugs in the port or MUSBUS errors.

7. Concluding CommentsMUSBUS was originally developed to assist in equipment selection decisions. In that role it has proven to be mostuseful, and by empirical standards, an accurate predictive tool.However the use has grown to include technical performance criteria to be met in contractual acceptance conditions,system check-out during installation, in-house performance measurement and kernel-exercising by several vendorsduring product evolution.

References

.AIM Technology, AIM Benchmark Suite II - Evaluating UNIX Computers, 1984.

L. F. Cabrera, Benchmarking Unix - A Comparative Study, in Experimental Computer Performance Evaluation,D. Ferrari and M. Spadoni, (eds.), North-Holland, Amsterdam, 1981.

3. H.J. Curnow and B. A. Wichmann, A Synthetic Benchmark, Comp. J. 19,1, (Feb. 1976), 43-49.

4. G. Dronek, Relating Benchmarks to Performance Projections, Proc. USENIX, Salt Lake City, Utah, Jun., 1984.

5. R.J. Eickemeyer and J. H. Patel, Dhampstone, USENET, Newsgroup comp.arch, Article <500001@ uicsg>, 14Feb., 1987.

o

J. Mashey, Re: 01/31/87 Dhrystone Results and Source, USENET, Newsgroup comp.arch, Article<ll2@winchester.mips.uucp>, 9 Feb., 1987.M. F. Morris and P. F. Roth, Computer Performance Evaluation - Tools and Techniques for Effective Analysis,Van Nostrand Reinhold, New York, 1982.

J. H. Patel, Re: Dhrystone and Dhampstone, USENET, Newsgroup comp.arch, Article <500002@uicsg>, 26 Feb.,1987.

9. R. Richardson, Dhrystone, USENET, Newsgroup comp.arch, Article <153@homxb.uucp>, 14 Mar., 1987.

10. R. Richardson, Re: 01/31/87 Dhrystone Results and Source, USENET, Newsgroup comp.arch, Article<2366@homxb.uucp>, 7 Feb., 1987.

11.

12.

R. Richardson, Re: 01/31/87 Dhrystone Results and Source, USENET, Newsgroup comp.arch, Article<2387@homxb.uucp>, 14 Feb., 1987.

R. P. Weicker, Dhrystone: A Synthetic Systems Programming Benchmark, Comm. ACM 27, 10, (Oct. 1984),1013-1030.

AUUGN 21 Vol 7 No 6

Cake: a fifth generation version of make

Zoltan SomogyiDepartment of Computer Science

University of Melboumezs@mulga.OZ

Abstract

Make is a standard Unix1 utility for maintaining computer programs.Cake is a rewrite of make from the ground up. The main difference isone of attitude: cake is considerably more general and flexible, and canbe extended and customized to a much greater extent. It is applicable to awide range of domains, not just program development.

1. IntroductionThe Unix utility make (Feldman, 79) was written to automate the compilation andrecompilation of C programs. People have found make so successful in this domain that theydo not wish to be without its services even when they are working in other domains. Sincemake was not designed with these domains in mind (some of which, e.g. VLSI design, did noteven exist when make was written), this causes problems and complaints. Nevertheless,implied in these complaints is an enormous compliment to the designers of make; one doesnot hear many grumbles about programs with only a few users.

The version of make described in (Feldman, 79) is the standard utility. AT&Tmodified it in several respects for distribution with System V under the name augmentedmake (AT&T, 84). We know of two complete rewrites: enhanced make (Hirgelt, 83)and fourth generation make (Fowler, 85). All these versions remain oriented towardsprogram maintenance.

Here at Melbourne we wanted something we could use for text processing. We hadaccess only to standard make and spent a lot of time wrestling with makefiles that kepton getting bigger and bigger. For a while we thought about modifying the make source, butthen decided to write something completely new. The basic problem was the inflexibility ofmake’s search algorithm, and this algorithm is too embedded in the make source to bechanged easily.

The name cake is a historical accident. Cake follows two other programs whosenames were also puns on make. One was bake, a variant of make with built-in rules forVLSI designs instead of C programs (Gedye, 84). The other was David Morley’s shell scriptfake. Written at a time when disc space on our machine was extremely scarce, and full filesystems frequently caused write failures, it copied the contents of a directory to /trap and

1 Unix is a trademark of AT&T Bell Laboratories.

Vol 7 No 6 22 AUUGN

invoked make there.

The structure of the paper is as follows. Section 2 shows how cake solves the mainproblems with make, while section 3 describes the most important new features of cake.The topics of section 4 are portability and efficiency.

The paper assumes that you have some knowledge of make.

2. The problems with make

Make has three principal problems. These are:

(1) It supports only suffix-based rules.

(2) Its search algorithm is not flexible enough.

(3) It has no provisions for the sharing of new make rules.

These problems are built deep into make. To solve them we had to start again fromscratch. We had to abandon backward compatibility because the make syntax is not richenough to represent the complex relationships among the components of large systems.Nevertheless, the cake user interface is deliberately based on make’ s; this helps users totransfer their skills from make to cake. The functionalities of the two systems aresufficiently different that the risk of confusion is minimal9.

Probably the biggest single difference between make and cake lies in their generalattitudes. Make is focused on one domain: the maintenance of compiled programs. It has alot of code specific to this domain (especially the later versions). And it crams all itsfunctionality into some tight syntax that treats all sorts of special things (e.g.. SUFFIXES) asif they were fries.

Cake, on the other hand, uses different syntax for different things, and keeps the numberof its mechanisms to the minimum consistent with generality and flexibility. This attitudethrows a lot of the functionality of make over the fence into the provinces of other programs.For example, where make has its own macro processor, cake uses the C preprocessor; andwhere make has special code to handle archives, cake has a general mechanism that justhappens to be able to do the same job.

2.1. Only suffix-based rules

All entries in a makefile have the same syntax. They do not, however, have the samesemantics. The main division is between entries which describe simple dependencies (how tomake file a from file b), and those which describe rules (how to make files with suffix . xfrom files with suffix . y)3. Make distinguishes the two cases by treating as a rule anydependency whose target is a concatenation of two suffixes.

For this scheme to work, make must assume three things. The first is that allinteresting files have suffixes; the second is that suffixes always begin with a period; the thirdis that prefixes are not important. All three assumptions are violated in fairly commonsituations. Standard make cannot express the relationship between file and file. c(executable and source) because of assumption 1, between file and f il e, v (working fileand RCS file) because of assumption 2, and between file. o and ../src/file. c (objectand source) because of assumption 3. Enhanced make and fourth generationmake have special forms for some of these cases, but these cannot be considered solutions

This problem, called cognitive dissonance, is discussed in Weinberg’s delightful book (Weinberg, 71).

For the moment we ignore entries whose targets are special entities like .IGNORE .PRECIOUS etc.

AUUGN 23 Vol 7 No 6

because special forms will always lag behind demand for them (they are embedded in themake source, and are therefore harder to change than even the built-in rules).

Cake’s solution is to do away with make-style rules altogether and instead to allowordinary dependencies to function as rules by permitting them to contain variables. Forexample, a possible rule for compiling C programs is

~ .o: % .ccc -c %. c

where the % is the variable symbol. This rule is actually a template for an infinite number ofdependencies, each of which is obtained by consistently substituting a string for the variable %.

The way this works is as follows. First, as cake seeks to update a file, it matches thename of that file against all the targets in the description file. This matching process givesvalues to the variables in the target. These values are then substituted in the rest of the rule4.(The matching operation is a form of unification, the process at the heart of logicprogramming; this is the reason for the fifth generation bit in the title.)

Cake actually supports 11 variables: % and % 0 to % 9. A majority of rules in practicehave only one variable (canonically called %), and most of the other rules have two(canonically called %1 and %2). These variables are local to their rules. Named variables aretherefore not needed, though it would be easy to modify the cake source to allow them.

ExampleIf cake wanted to update prog. o, it would match prog.o against %. o, substitute progfor % throughout the entry, and then proceed as if the cakef±le contained the entry

prog. o : prog. ccc -c prog.c

This arrangement has a number of advantages. One can write

%.0: RCS/%. c, vco -u %.ccc -c %.c

without worrying about the fact that one of the files in the rule was in a different directory andthat its suffix started with a nonstandard character. Another advantage is that rules are notrestricted to having one source and one target file. This is useful in VLSI, where onefrequently needs rules like

%. out : %.in %.circuitsimulator %.circuit < %.in > %.out

and it can also be useful to describe the full consequences of running yacc

4 After this the rule should have no unexpanded variables in it. If it does, cake reports an error, as it

has no way of finding out what the values of those variables should be.

Vol 7 No 6 24 AUUGN

%.c%.h: %.y

yacc -d % oymv y.tab.c %.c

mv y.taboh %.h

2.2. Inflexible search algorithm

In trying to write a makefile for a domain other than program development, the biggestproblem one faces is usually make’s search algorithm. The basis of this algorithm is aspecial list of suffixes. When looking for ways to update a target file. x, make searchesalong this list from left to right. It uses the first suffix . y for which it has a rule . y. x andfor which f il e. y exists.

The problem with this algorithrn manifests itself when a problem divides naturally into anumber of stages. Suppose that you have two rules . c. b and . b. a, that file. c existsand you want to issue the command make file. a. Make will tell you that it doesn’tknow how to make file. a. The problem is that for the suffix .b make has a rule but nofile, while for . c it has a file but no rule. Make needs a transitive rule . c. a to go directfrom file.c to file.a.

The number of transitive rules increases as the square of the number of processingstages. It therefore becomes significant for program development only when one addsprocessing stages on either side of compilers. Under Unix, these stages are typically the linkeditor ld and program generators like yacc and lex. Half of standard make’ s builtinrules are transitive ones, there to take care of these three programs. Even so, the builtin rulesdo not form a closure: some rare combinations of suffixes are missing (e.g. there is no rule forgoing from yacc source to assembler).

For builtin rules a slop factor of two may be acceptable. For rules supplied by the userit is not. A general-purpose makef±le for text processing under Unix needs at least sixprocessing stages to handle nroff/troff and their preprocessors ibl, bib, pic, tbl,and e qn, to mention only the ones in common use at Melboume University.

Cake’ s solution is simple: if filel can be made from file2 but file2 does notexist, cake wi!l try to create file2. Perhaps file2 can be made from file3, whichcan be made from file4, and so on, until we come to a file which does exist. Cake willgive up only when there is absolutely no way for it to generate a feasible update path.

Both the standard and later versions of make consider missing files to be out of date.So if filel depends on file2 which depends on file3, and file2 is missing, thenmake will remake first file2 and then filel, even if filel is more recent thanfile3.

When using yacc, I frequently remove generated sources to prevent duplicate matcheswhen I run egrep ... *. [chyl]. If cake adopted make’ s approach to missing files,it would do a lot of unnecessary work, running yacc and cc to generate the same parserobject again and again5.

Cake solves this problem by associating dates even with missing files. The theoreticalupdate time of an existing file is its modify time (as given by stat(2)); the theoretical updatetime of a missing file is the theoretical update time of its youngest ancestor. Suppose the

5 In this case make is rescued from this unnecessary work by its built-in transitive rules, but as shown

AUUGN 25 Vol 7 No 6

yacc source parser .y is older than the parser object parser. O, and parser, c ismissing. Cake will figure that if it recreated parser, c it would get a parser, c whichtheoretically was last modified at the same time as parser, y was, and since parser, o isyounger than parser, y, theoretically it is younger than parser, c as well, and thereforeup-to-date.

2.3. No provisions for sharing rules

Imagine that you have just written a program that would normally be invoked from a makerule, such as a compiler for a new language. You want to make both the program and themake rule widely available. With standard make, you have two choices. You can hand outcopies of the rules and get users to include it in their individual makefiles; or you canmodify the make source, specifically, the file containing the built-in rules. The first way iserror-prone and quite inconvenient (all those rules cluttering up your makefile when youshould never need to even look at them). The second way can be impractical; in thedevelopment stage because the rules can change frequently and after that because you want todistribute your program to sites that may lack the make source. And of course two suchmodifications may conflict with one another.

Logically, your rules belong in a place that is less permanent than the make source butnot as transitory as individual makefiles. A library file is such a place. The obvious wayto access the contents of library files is with #include, so cake filters every cakefilethrough the C preprocessor.

Cake relies on this mechanism to the extent of not having any built-in rules at all. Thestandard cake rules live in files in a library directory (usually/usr/lib/cake). Each of thesefiles contains rules about one tool or group of tools. Most user cakefiles #define somemacros and then include some of these files. Given that the source for program prog isdistributed among prog. c, auxl. c, aux2. c, and parser, y, all of which depend ondef. h, the following would be a suitable cakefile:

#define MAIN prog#define FILES prog auxl aux2 parser#define HDR defoh

#include <Yacc>#include <C>#include <Main>

The standard cakefiles Yacc and C, as might be expected, contain rules that invokeyacc and cc respectively. They also provide some definitions for the standard cakefileMain. This file contains rules about programs in general, and is adaptable to all compiledlanguages (e.g. it can handle NU-Prolog programs). One entry in Main links the object filestogether, another prints out all the sources, a third creates a tags file if the language has acommand equivalent to ctags, and so on.

Make needs a specialized macro processor, without one it cannot substitute the properfilenames in rule bodies. Fourth generation make has not solved this problem but itstill wants the extra functionality of the C preprocessor, so it grinds its makefiles throughboth macro processors ! Cake solves the problem in another way, and can thus rely on the Cpreprocessor exclusively.

above this should not be considered a general solution.

Vol 7 No 6 26 AUUGN

The original make mechanisms are quite rudimentary, as admitted by ~eldman, 79).Unfortunately, the C preprocessor is not without flaws either. The most annoying is that thebodies of macro definitions may begin with blanks, and will if the body is separated from themacro name and any parameters by more than one blank (whether space or tab). Cake isdistributed with a fix to this problem in the form of a one-line change to the preprocessorsource, but this change probably will not work on all versions of Unix and definitely will notwork for binary-only sites.

3. The new features of cake

The above solutions to make’s problems are useful, but they do not by themselves enablecake to handle new domains. For this cake employs two important new mechanisms:dynamic dependencies and conditional rules.

3.1. Dynamic dependenciesIn some situations it is not convenient to list in advance the names of the files a target dependson. For example, an object file depends not only on the corresponding source file but also onthe header files referenced in the source.

Standard make requires all these dependencies to be declared explicitly in themakefile. Since there can be rather a lot of these, most people either declare that all objectsdepend on all headers, which is wasteful, or declare a subset of the true dependencies; which iserror-prone. A third altemative is to use a program (probably an awk script) to derive thedependencies and edit them into the makefile. (Walden, 84) describes one program thatdoes both these things; there are others. These systems are usually called makedepend orsome variation of this name.

The problems with this approach are that it is easy to alter the automatically-deriveddependencies by mistake, and that if a new header dependency is added the programmer mustremember to run makedepend again. The C preprocessor solves the first problem; thesecond, however, is the more important one. Its solution must involve scanning though thesource file, checking if the programmer omitted to declare a header dependency. So why notuse this scan to find the header dependencies in the first place ?

Cake attacks this point directly by allowing parts of rules to be specified at run-time. Acommand enclosed in double square brackets6 may appear in a rule anywhere a filename or alist of filenames may appear. For the example of the C header files, the rule would be

%.o: %.c [[ccincl %.c]]cc -c %.c

signifying that x. o depends on the files whose names are listed in the output of the commandccincl x. c7, as well as on x.c.. The matching process would convert this rule to

6 Single square brackets (like most specia! characters) are meaningful to csh: they denote characterclasses. However, we are not aware of any legitimate contexts where two square brackets must appeartogether. The order of members in such classes is irrelevant, so if a bracket must be a member of sucha class it can be positioned away from the offending boundary (unless the class is a singleton, in whichcase there is no need for the class in the first place).7 Ccincl prints out the names of the files that are #included in the file named by its argument.

AUUGN 27 Vol 7 No 6

X.O: x.c [ [ccincl x oc]]

cc -c x. c

which in turn would be command expanded to

X.O: x.c hdr.h

cc -c x. c

if hdr. h were the only header included in x.c.Command pattems provide replacements for fourth generation make’s

directory searches and special macros. [[find <dirs> -name <filename> -print] ] does as good a job as the special-purpose make code in looking up source filesscattered among a number of directories. [ [basename <filename> <suffix>] ] cando an even better job: make cannot extract the base from the name of an RCS file.

A number of tools intended to be used in just such contexts are distributed together withcake. Ccincl is one. Sub is another: its purpose is to perform substitutions. Itsarguments are two pattems and some strings: it matches each string against the first pattern,giving values to its variables; then it applies those values to the second pattem and prints outthe result of this substitution. For example, in the example of section 2.3 the cakefileMain would invoke the command [ [sub .X X.o FILES] ] 8, the value of FILES beingprog auxl aux2 parser, to find that the object files it must link together to create theexecutable prog are prog. o auxl. o aux2. o parser, o.

Cake allows commands to be nested inside one another. For example, the command[ [sub X.h X [ [ccincl file.c] ] ] ] would strip the suffix .h from the names of the

header files included in file. C9.

3.2. Conditional rules

Sometimes it is natural to say that f il e 1 depends on f il e 2 if some condition holds. Noneof the make variants provide for this, but it was not too hard to incorporate conditional rolesinto cake.

A cake entry may have a condition associated with it. This condition, which isintroduced by the reserved word if, is a boolean expression built up with the operators and,or and not from primitive conditions.

The most important primitive is a command enclosed in double curly braces. Whenevercake considers applying this rule, it will execute this command after matching, substitutionand command expansion. The condition will retum true if the command’s exit status is zero.This runs counter to the intuition of C programmers, but it conforms to the Unix convention ofcommands returning zero status when no abnormal conditions arise. For example,{ {grep xyzzy file}} returns zero (i.e. true) if xyzzy occurs in file and nonzero(false) otherwise.

8 Sub uses X as the character denoting variables. It cannot use %, as all %’s in the command will

have been substituted for by cake by the time sub is invoked.9 As the outputs of commands are substituted for the commands themselves, cake takes care not to

scan the new text, lest it find new double square brackets and go into an infinite loop.

Vol 7 No 6 28 AUUGN

Conceptually, this one primitive is all one needs. However, it has considerable overhead,so cake includes other primitives to handle some special cases. These test whether afilename occurs in a list of filenames, whether a pattem matches another, and whether a filewith a given name exists. Three others forms test the internal cake status of targets. Thisstatus is ok if the file was up-to-date when cake was invoked, canto if it wasn’t butcake knows how to update it, and noway if cake does not know how to update it.

As an example, consider the rule for RCS.

%: RCS/%,vco -u %

if exist RCS/%,v

Without the condition the rule would apply to all files, even ones which were not controlled byRCS, and even the RCS files themselves: there would be no way to stop the infinite recursion(% depends on RC$/%, v which depends on RCS/RC$/%, v, v ...).

Note that conditions are command expanded just like other parts of entries, so it ispossible to write

%: archive if % in [[art archive]]ar x archive %

4. The implementation

4.1. PortabilityCake was developed on a Pyramid 90x under 4.2bsd. It now rims on a VAX under 4.3bsd, aPerkin-Elmer 3240 and an ELXSI 6400 under 4.2bsd, and on the same ELXSI under SystemV. It has not been tested on either System III or version 7.

Cake is written in standard C, with (hopefully) all machine dependencies isolated in themakefile and a header file. In a number of places it uses #ifdef to choose between piecesof code appropriate to the AT&T and Berkeley variants of Unix (e.g. to choose betweentime ( ) and gettimeofday ( ) ). In fact, the biggest hassle we have encountered in portingcake was caused by the standard header files. Some files had different locations on differentmachines (/usr/include vs. /usr/include/sys), and the some versions hncludedother header files (typically types, h) while others did not.

As distributed cake is set up to work with csh, but it is a simple matter to specifyanother shell at installation time. (in any case, users may substitute their preferred shell byspecifying a few options.) Some of the auxiliary commands are implemented as c sh scripts,but these are small, and it should be trivial to convert them to another shell if necessary.

4.2. Efficiency

Fourth generation make has a very effective optimization system. First, it forks andexecs only once. It creates one shell, and thereafter, it pipes commands to be executed to thisshell and gets back status information via another pipe. Second, it compiles its makefilesinto intemal form, avoiding parsing except when the compiled version is out of date withrespect to the master.

The first of these optimizations is an absolute winner. Cake does not have it for thesimple reason that it requires a shell which can transmit status information back to its parentprocess, and we don’t have access to one (this feature is provided by neither of the standard

AUUGN 29 Vol 7 No 6

shells, sh and csh).

Cake could possibly make use of the second optimization. It would involve keepingtrack of the files the C preprocessor includes, so that the makefile can be recompiled if oneof them changes; this must be done by fourth generation make as well though (Fowler, 85)does not mention it. However, the idea is not as big a win for cake as it is for make. Thereason is as follows.

The basic motivations for using cake rather than make is that it allows one to expressmore complex dependencies. This implies a bigger system, with more and slower commandsthan the ones make usually deals with. The times taken by cake and the preprocessor areinsignificant when compared to the time taken by the programs it most often invokes atMelbourne. These programs, ditroff and nc (the NU-Prolog compiler that is itself writtenin NU-Prolog), are notorious CPU hogs.

Here are some statistics to back up this argument. The overhead ratio is given by theformula

cake process system time + children user time + children system timecalve process user time

This is justifiable given that the cake implementor has direct control only over thedenominator; the kernel and the user’s commands impose a lower limit on the numerator.

We have collected statistics on every cake nan on two machines at Melbourne1°.These statistics show that the processes and system calls invoked by cake take on averageabout 70-80 times as much CPU time as the cake process itself. This suggests that the bestway to lower total CPU time is not to tune cake itself but to reduce the number of childprocesses. To this end, cake caches the status returned by all condition commands{ {command} } and the output of all command pattems [ [command] ]. The first cache hasa hit ratio of about 50 percent, corresponding to the typical practice in which a condition andits negation select one out of a pair of rules. The second cache has a hit ratio of about 75percent; these hits are usually the second and later occurrences of macros whose values containcommands.

Cake also uses a second optimization. This one is borrowed from standard make:when an action contains no constructs requiring a shell, cake itself will parse the action andinvoke it through exec. We have no statistics to show what percentage of actions benefit fromthis, but a quick examination of the standard cakef±]_es leads us to believe that it is over50 percent.

Overall, cake can do a lot more than make, but on things which can be handled bymake, cake is slightly slower than standard make and a lot slower than fourth generationmake. Since the main goal of cake is generality, not efficiency, this is understandable. Ifefficiency is important, make is always available as a fallback.

4.3. Availability

Cake has been fairly stable for about six months now. During this time it has been usedwithout major problems by about twenty people here at Melbourne. It will be posted to the netin the near future, complete with auxiliary programs and manual entries.

10 On munmurra (an EXLSI 6400), the main application is Prolog compilation; on mulga (a Perkin-

Elmer 3240), the main applications are text processing and the maintenance of a big bibliography (over36000 references).

Vol 7 No 6 30 AUUGN

5. AcknowledgementsJohn Shepherd, Paul Maisano, David Morley and Jeff Schultz helped me to locate bugs bybeing brave enough to use early versions of cake. I would like to thank John for hiscomments on drafts of this paper.

This research was supported by a Commonwealth Postgraduate Research Award, the AustralianComputer Research Board, and Pyramid Australia.

6. References

(AT&T, 84)

(Feldman, 79)

(Fowler, 85)

(Gedye, 84)

(Hirgelt, 83)

(Walden, 84)

(Weinberg, 71)

Augmented version of make, in: Unix System V - release 2.0 support toolsguide, AT&T, April 1984.

Stuart I. Feldman, Make - a program for maintaining computer programs,Software - Practice and Experience, 9:4 (April 1979), pp. 255-265.

Glenn S. Fowler, A fourth generation make, Proceedings of the USEN1XSummer Conference, Portland, Oregon, June 1985, pp. 159-174.

David Gedye, Cooking with CAD at UNSW, Joint MicroelectronicsResearch Center, University of New South Wales, Sydney, Australia, 1984.

Edward Hirgelt, Enhancing make or re-inventing a rounder wheel,Proceedings of the USENIX Summer Conference, Toronto, Ontario, Canada,June 1983, pp. 45-58.

Kim Walden, Automatic generation of make dependencies, Software -Practice and Experience, 14:6 (June 1984), pp. 575-585.

Gerald M. Weinberg, The psychology of computer programming, VanNostrand Reinhold, New York, 1971.

AUUGN 31 Vol 7 No 6

UNIXTM MENU SYSTEM

Keith GodfreyTelecom Australia Educational Fellow

University of Western Australia (keith~trlluna.oz)

Peter Y. F. HuiPrincipal Computer Systems O~cer

Telecom Australia Research Laboratories (hui~trlsasb.oz)

(~) Australian Telecommunications Commission 198~’Permission to reprint in the AUUGN is kindly acknowledged.

ABSTRACTThis paper describes the implementation of a "user friendly" interface to the UNIXsystems. It allows non-technical users to utilize the UNIX operating system withminimal training.

A powerful menu driven system has resulted which encompasses most of the capabil-ities required by such users without encountering a shell prompt. On-line help is alsoavailable. The system produces compilable C code from a menu script file - a speciallanguage. The compiled menu system is fast, flexible and friendly.

1 Introduction

The Telecom Australia Research Laboratories in Melbourne have a number of computerswith the UNIX operating system. These machines are used to support research work, toexchange electronic mail with other research organisations, and to provide a programmingenvironment for software development.

Most of the managerial staff and researchers are not familiar with UNIX shell commandsand have no desire to learn them. They only want to use the computer as a tool to captureand analyse data, then carry on with their administrative or research work.

The problem is that these users run into difficulties as soon as they need to do anythingthat is outside their normal operations. Often the required task is very simple, perhapsto create or remove a directory, copy or rename a file, or merely change the password oftheir account. But they cannot quite remember the command. In vain they try severalcommands that sound similar, say "password", "pw", "pwd", "newpass" or "pass", thenpanic and call the system manager for help.

Trying random commands is generally harmless, but it can cause a lot of trouble if theuser executes a valid command that means something else. Executing "pwd" instead of"passwd" will merely display the name of the working directory. Trying "cat" for a catalogof files (instead of "ls") will lock the terminal until Control-C or Control-D is typed sinceit will copy stdin to stdout. Unfamiliar users are not likely to deduce that.

~rMUNIX is a registered trademark of AT&T in the USA and other countries.

AUUGN 32 Vol 7 No 6

The aim of this menu driven interface is to perform all the necessary commands withoutthe user needing to know the commands and parameters.

All the programs have been written in C under Ultrix~’M Version 1.2 on a MicroVAX II.

2 Menu Operation

A menu system in a computer is rather like a menu in a restaurant. Presentation is veryimportant. Menus should look elegant, with the title and list of choices clearly shown.Although it may be desirable to give a description of each item, it should be kept toan absolute minimum otherwise it will become cluttered and the user will get confused.Menus should be clear and concise.

The selection process must be very flexible; users need to be able to make their choiceswith ease. Since there are many types of user, the menu system should be responsive toseveral different styles of selection.

This menu system has been designed with these points in mind.

The screen display can be broken up into several distinct sections; the menu number, title,list of choices, description of selected choice, and instructions on how to choose. A typicalmenu screen is shown in figure 1. Due to problems of reproduction, text which would bein inverse video is represented in boldface.

The user selects an item by moving the "highlight" up or down to the desired choice thenpressing the RETURN key to confirm it.

The highlight can be moved in several ways:

- By pressing the UP or DOWN arrows. (The most logical way.)

- By pressing SPACE to move down or BACKSPACE to move up. (This method wasincluded to suit the people who are familiar with the Wang Menu System.)

- By entering the FIRST LETTER of the item’s name. (This is a quick way to skipdown the menu.)

- By entering the NUMBER of the item. (It is also possible to go directly to any otherplace in the menu system using this method.)

The highlight (shown in boldface in figure 1) will rotate back to the beginning of the listif it is moved off the last line and vice-versa. If any intervening items are missing fromthe menu, the highlight will automatically skip across the gap.

Each time the highlight is moved, a brief description of the highlighted choice is displayednear the bottom of the screen. This provides the user with additional information aboutthe list of choices without cluttering the screen.

~’MUltrlx is a trademark of Digital Equipment Corporation.

AUUGN 33 Vol 7 No 6

Menu number Selection -->

0 Help1 Choose Directory2 Examine Dbeectory3 View File4 Protect File5 Delete File6 Copy File7 Move File8 Print File9 Locate Files

10 Classify File11 Quit

Selection 2: Examine the contents of the working directory

Press ARROW KEYS to select, RETURN to execute, PF4 or DIVIDE for previous menu.Alternatively type the number of your selection and press RETURN.

Figure 1: Sample Menu Screen

3 Menu Tree

The UNIX operating system has a large number of commands, which cannot all fit in asingle menu. It is therefore necessary to have menus of sub-menus, arranged in a treestructure.

This system allows the menus to linked together in many ways. A logical way is to separatethe UNIX commands into functional groups:

File Handling CommandsDirectory Handling CommandsPersonal Account DetailsSystem InformationSpecial ApplicationsPrinter CommandsMail System CommandsNews System CommandsEditor Commands

(Is [-alR], cat files, rm files, ...)(mkdir dir, rmdir dir, rm dir/*, ...)(whoami, ps-x, quota, groups, ...)(uptime, w-h, ps-augx, vmstat 4, ...)(man, sh -c command, csh)(lpr file, lpq, lprm)(mail: send, read, delete, ...)

(vi file)

The menu tree is then constructed accordingly, figure 2 shows an abbreviated representa-tion of such a tree.

Menus or items are identified uniquely by their number. Number 0 is the top of the tree

AUUGN 34 Vol 7 No 6

/ Choose Directory/ Examine Directory __/ Long Listing(y/n)

/ View File \ All Entries (y/n)/ : \ Group Owners (y/n)

Files ____/ : \ Subdirectories(y/n)/ \ Copy File

/ \ Locate Files ./ Search for User\ Classify File \ Search for Name

/ Choose DirectoryDirectories _/ Make Directory/ \ Remove Directory

/ \ Empty DirectoryMain

Selections \\ / Who Am IPersonal ___/ :

\ :\ Kill Process

\

and so on

Figure 2: A Typical Menu Tree

(the Main Selections menu). Subsequent levels are indicated by numbers preceded by aperiod (".").

A typical numbering system for the tree above is shown in figure 3.

4 The Design

The requirements of the menu system were formulated after examination of several existingsystems and discussions with many users. The system should:

- operate rapidly.

- be easy to use.

- allow the system manager to tailor menus easily.

- be able to execute a sequence of UNIX commands.

- cater for UNIX commands requiring flags or other parameters.

AUUGN 35 Vol 7 No 6

Main Selections0 Help InformationI File Commands

I .0 Help InformationI. 1 Choose DirectoryI .2 Examine Directory

I .2.0 Help1.2.i List Directory

::

1.2.6 Subdirectories1.2.7

I .3 View File::

I .g Locate Files1.11 quit

2 Directory Commands::

4 System Informationetc.

Figure 3: Numbering of The Menu Tree

5 Implementation

Generally there are two ways to implement a menu system:

- Compiler Reads a file of menu definitions and creates an executable menu system.- Interpreter Loads menu definition files while running.

Each has several advantages and disadvantages. It was decided to build a compiler because:

- The resulting menus operate much faster.- All menu definitions can be contained in a single file.- Compilation time is small (about 5 minutes on a MicroVAX for a complicated system).

The Programs

The menu system uses a two-stage compiler:

Stage 1. menucoml Condenses the menu script file menu.inand produces a temporary file menu.out

Stage 2. menucom2Processes the condensed script file menu.outand the runtime function library file menu.includeand reads all specified message files, menu.help.,then produces C source code file menu.c

AUUGN 36 Vol 7 No 6

The C compiler cc is then used to compile the source code menu.c into an executableprogram menu. Figure 4 shows the compilation process.

menu.in

menucoml

menu.include ~" menu.out

menu.help.,)I menucom2

Figure 4: Flow Chart of the Menu Compilation Process

Two satellite programs have been included to perform specialised tasks while conformingto the screen format of menu:

ct Operates in a similar manner to cat but includes paging andfiltering of escape sequences.

chmode Performs the same task as chmod but displays the currentfile mode and visually adjusts it via a menu, instead of askingfor a four digit octal number.

These can be executed in place of the normal UNIX commands.

7 Menu Script Language

The menu layout is specified in a file called menu.in. It contains the definitions of all theitems in all menus, listed one after another. They do not need to be in numeric order.

Each item definition will require at least two lines of the file. Most items, especially UNIXcommands, will require more.

The first line contains the number, name, and description of the item. This has the form:

number name: description

AUUGN 37 Vol 7 No 6

Example:

2.4 Empty Directory: Remove all the files within a directory

T̄his causes menu number 2 to display "4 Empty Directory" as the fourth choice. Selectingthis option (by moving the highlight on to it) produces the explanation

Selection 4: Remove all the files within a directory

at the bottom of the screen.

The second and subsequent lines of the item definition determine what the item will dowhen it is chosen. Some items will call up another menu (for example, the 1st choice of theMain Selections menu will display the Files menu). Others will display help informationor other messages. The majority will perform UNIX commands.

The syntax of the second line is:

type [parameters]

where "type" refers to the type of task that the item will perform and "parameters" areadditional information if required.

There are currently 10 types of task supported which are defined briefly in Tables 1, 2 and3.

MENU

GOTO <item>

GO <item>

UP

MESSAGE <file>

The item is a sub-menu, or branch down the tree from the menu the item isin.

This provides cross-branching between menus. Instead of an item being asub-menu, it can refer to any menu or item, anywhere in the tree.

Same as GOTO <item>.

UP is a special form of GOTO. It is equivalent to GOing to the parent menu,one hop up the tree.

The file is read during compilation of the menu script and will be displayed asa text message whenever this option is chosen. This is the best way to presenthelp information. Message files may contain special characters to adjust thescreen attributes or display graphics symbols.

Table 1: Menu Script Tasks for Sequencing

The ultimate purpose of the menu system is to execute UNIX commands. These arehandled by the COMMAND, EXECUTE and LOOP instructions illustrated in Table 3.

AUUGN 38 Vol 7 No 6

FLAG <x>

THREE <x>

Many UNIX commands have toggles or flags that can change the performanceof the command. This item type will determine how those parameters are setaccording to the following presets:

FLAG 0 (Item is initially ~off")FLAG 1 (Item is initially ~on")

A THREE is a special form of a FLAG. It has three possible states; set, reset,or neither. This is used by commands that can switch a feature on, off, orleave it unchanged. The definitions are:

THREE +THREE -THREE.

(Item is initially ~’set")(Item is initially ~reset")(Item is initially ~no change")

Table 2: Menu Script Tasks for Setting Flags

COMMAND

EXECUTE

LOOP

Following the word COMMAND there may be as many separate lines of shellcommands as are required. After they have all been executed the user isprompted to press any key to continue with the menus (so that the terminaloutput is not lost).

EXECUTE is similar to COMMAND but does not wait for a key to be pressed.The menu re-appears as soon as the command has finished.

If LOOP is specified at the very beginning (prior to the first COMMAND orEXECUTE), the whole lot will repeat until the user directs it to stop.

Table 3: Menu Script Tasks for Process Initiation

AUUGN 39 Vol 7 No 6

A menu item may contain several COMMANDs and EXECUTEs, in any order, each witha list of many shell commands. This allows for pauses between commands and, whencombined with functions (described shortly), provides a very powerful way to executegroups of UNIX commands intertwined with user input. An example of this approach isshown in figure 5.

8.1 Read News: Use the News systemCOMMAND

echoechoechoechoechoechoecho ’ to continue:echo ’ to skip to next:echo ’ to quit:echo " for help:echo

EXECUTEecho ’Getting news.’echovne ws

’You are about to enter the news system.’¯

’News articles are presented one page at’"a time. You will be asked "more?" at the"’end of each page.’

press RETURI~ (more).’press "n" (next) .’press "q" (quit) . °press "?" (help) . ’

Figure 5: An Example of The Use of COMMAND & EXECUTE

There are two stages to this item. The first echoes the instructions and waits for the userto read them; the second puts the message "Getting news." on to the screen and loadsthe news system. When the user exits vnews, the menu will re-appear without waiting.

An extension of the EXECUTE and COMMAND types is the LOOP type which allowscontinual repitition of the commands.

8 Functions

Parameters are passed to UNIX commands via functions. There are several functionsdefined by the menu system. Each returns a text string that is included as part of thecommand to be executed.

Functions have the form:

@fu n ction (parameter)

where "function" is the name and "parameters" are any parameters that it needs. Whena function appears in a UNIX command, it is processed and replaced by its result.

Example: the "Make Directory" command.

AUUGN 40 Vol 7 No 6

2.2 Make Directory: Create a new DirectoryEXECUTE

mkdir ©ask("Enter the name o~ the directory to be created - ")

When this item is chosen it will:

Ask the user the question "Enter the name of the directory to be created - " andread the answer.

Substitute the answer into the UNIX command in place of the @ask(...) such thatif the user answers "xyz", the command becomes "mkdir xyz".

Operate the UNIX command and return immediately to the main menu.

The ©ask( "question" ) is a function which asks a question and returns the answer.

Functions are defined in the file menu.include and are illustrated in Table 4.

three(n umber, "set", "reset", "neither")

~ask( "question"

file( "question"

files( "question")

~confirm(~question")

~exit0

The ~flag function determines the state of the item<number> which must be defined as FLAG, and sub-stitutes <on> if on or <off> if off. Example: See the"Is" command further on.

The ~three function is very similar to the ~flag function,except that it works on items defined as THREE insteadof FLAG.

A simple question-answer system is provided by the @askfunction. It asks the <question> and substitutes theanswer.

~file displays a list of the files in the working directoryand lets the user select one. Alternatively, the user maytype the name of any file anywhere in the machine, inresponse to the <question>.

The ~files function allows for several files to be selectedfrom a displayed list.

~confirm allows the user to abort a command if it is notdesired. This may be useful for preventing accidentalmistakes. It returns nothing if okay, or aborts the itemif not.

The ~exit function terminates the menu system. Itshould be used in conjunction with the ~confirm func-tion,, to ensure the user doesn’t accidentally drop out.

Table 4: Functions Pre-defined In menu.include

The "ls" command demonstrates the usage of flags. It is defined in the menu "1.2 ExamineDirectory" which is shown in Figure 6.

AUUGN 41 Vol 7 No 6

1.2 Examine Directory: Examine the contents of the working directory

1.2.0 Help: How to interpret the contents of the directoryMESSAGE menu. help. ls

1.2.1 List Directory: List the files in the working directoryCOMMAND

echo-n ’Directory of ’; pwd; echois ~flag(l.2.30"-l","") ~flag(l.2.40"-a","") \©flag ( I. 2.5, "- g", "" ) ~flag( I. R. 6, "- R", "" )

1.2.2 Choose Directory: Select worklnE directoryEXECUTE

chdlr ©subdir("Enter the name of the new working directory - ")1.2.3 Long Listing: Displays mode,owner,slze and other details

FLAG II .2.4 All Entries : \

Lists all files (including names which start with a period)FLAG I

I .2.5 Group Ownership: Includes group owner with Long ListingFLAG I

1.2.6 Sub-Directories: Recurslvely lists all sub-directoriesFLAG 0

1.2.7 quit: Go back to File MaintenanceUP

Figure 6: Script for Examine Directory - part of menu.in

Note that a backslash "\" at the end of a line in the file menu.in indicates continuationon to the next line.

Item 1.2.3 is defined as FLAG and can be toggled by the user. The function @flag(1.2.3,"-l","") determines its state and substitutes "-l" if it is on, or "" if it is off. Similarly theother items.

The initial state comprises flags 1.2.3 on, 1.2.4 on, 1.2.5 on, and 1.2.6 off. The resultingcommand at item 1.2.1 would therefore be "ls -1 -a -g". This will change with each changeof the flags.

All functions within a COMMAND or EXECUTE group are substituted before the wholegroup is executed. By careful usage of COMMAND, EXECUTE, LOOP and functions itis possible to specify a very wide variety of tasks.

9 The Include File

The file menu.include contains all the functions that the menu system requires to operate.It is copied directly to the start of menu.c.

Included are:

AUUGN 42 Vol 7 No 6

- cursor strings (cursor movement, underlining etc.)

- procedures required by MENU, FLAG / THREE, COMMAND / EXECUTE, MES-SAGE. (menu display, flag toggling, wait for key, message display).

- procedures required by ’@’ functions within commands. (flag, three, ask, confirm,exit, subdir, file, files.)

As mentioned earlier, the functions provide much of the power of the menu system. Param-eters are passed to them from the definitions in menu.in and their results are substitutedinto the UNIX commands.

The menu compiler adjusts the function name and calling parameters to suit the require-ments of (3 compiler. If the function specified in menu.in is

(~ask("question")

the way it will be called in menu. e will be

ask_( "question" .result)

where result is a pointer to a character string in which to store the answer. All functionsare called with this extra parameter. The string placed there will be substituted into theUNIX command by the caller.

The function name has the ’~’ removed to make it begin with a letter (as required by theC compiler). It is distinguished from other procedures in menu.include by the addition ofthe ’_’.

There are a number of subroutines in menu.include that can be called by the functions.These perform special operations on the screen such as graphics, highlighting, displayinginstruction messages and selection.

10 Conclusion

The system has been successfully tested by a number of users. It is expected that it willbe shortly installed on many of the UNIX computers at the Telecom Australia ResearchLaboratories.

AUUGN 43 Vol 7 No 6

loginThe USENIX Association Newsletter

Volume 12, Number 2 March/April 1987

CONTENTS

MINIX: A UNIX Clone with Source Code for the IBM PC .............................................3Andrew S. Tanenbaum

Program for the Phoenix Technical Conference ..................................................................10Ten Years Ago in UNIX NEWS ..........................................................................................12The DASH Project: Design Issues for Very Large Distributed Systems ............................13

David P. Anderson and Domenico FerrariBook Review: The Nutshell Handbooks .............................................................................15

Lou KatzSummary of the Board of Directors’ Meeting October 1-2, 1986 .......................................19Summary of the Board of Directors’ Meeting January 19-20 & 22, 1987 ..........................20Future Meetings ....................................................................................................................22Financial Statements of the USENIX Association ..............................................................23WEIRDNIX Competition .....................................................................................................26Publications Available ..........................................................................................................27Software Tapes ......................................................................................................................274.3BSD UNIX Manuals ..........................................................................................................284.3BSD Manual Reproduction Authorization and Order Form ..........................................29Local User Groups ................................................................................................................30

The closing date for submissions for the next issue of ;login: is April 24, 1987

THE PROFESSIONAL AND TECHNICAL

UNIX® ASSOCIATION ¯

Vol 7 No 6 44 AUUGN

;login:

MINIX: A UNIX Clone with Source Code for the IBM PC

Andrew S. TanenbaumDept. of Mathematics and Computer Science

Vrije UniversiteitAmsterdam, The Netherlands

Usenet: minix@cs.vu.nl

ABSTRACT

This article describes a new operating system, called MINIX, that is functionallycompatible with Version 7 UNIX®. It has been rewritten completely from scratch. Neitherthe kernel nor the utility programs contain any AT&T code, so the source code is free fromAT&T licensing restrictions and may be studied by individuals or in a course. The systemruns on the IBM PC, XT, or AT, and does not require a hard disk, thus making it possible forindividuals to acquire a UNIX-like system for home use at a very low cost. If a hard disk isavailable, it is fully supporied, however.

Internally, MINIX is structured completely differently from UNIX. It is a messagepassing system on top of which are memory and file servers. User processes can sendmessages to these servers to have system calls carried out. The paper describes themotivation and intended use of the system, what the distribution contains, and discusses thesystem architecture in some detail.

Introduction

MINIX is a new operating system for theIBM PC, XT, and AT. Functionally, it issystem-call compatible with Version 7 UNIX,but inside it has been rewritten from scratch.It contains no AT&T code at all, neither in thekernel nor in the utilities. Furthermore, theinternal structure is also completely different(it is much more modular). The source code isbeing released without a restrictive licence forthe benefit of those people who would like tohave access to the source code of a UNIX-likesystem. This point is discussed in more detailat the end of this paper.

Another feature of this system is that ithas been designed to run with inexpensivehardware. Many people whose work involvescomputers also have a computer at home.While many of these people have an ego thatsays "VAX" their wallets often say "IBM PC."MINIX has therefore been designed to run on a256K IBM PC with one floppy disk if it has to,but the system is then highly restricted. On a6401( IBM PC with two floppy disks, it runsquite well and can even recompile itself fromthe source code provided, using its own Ccompiler. On a hard disk system or a PC-AT it

works even better, of course. It also runs onthose clones that are 100% hardwarecompatible with the PC, XT, or AT.Experiments have shown that about 80% of allclones are compatible, but 20% are not.

As a natural consequence of this "small isbeautiful" philosophy, I decided to haveMINIX be compatible with Version 7 ratherthan, say, 4.3 BSD or System V. Making a 4.3BSD or System V compatible system that runson a 256K IBM PC with one 360K floppy diskis left as an exercise for the reader. Besides,there are many people who believe thatVersion 7 was not only an improvement on allits predecessors, but also on all its successors,certainly in terms of simplicity, coherence, andelegance.

MINIX implements all the V7 system calls,except ACCT, LOCK, MPX, NICE, PHYS, PKON,PKOFF, PROFIL, and PTRACE. The othersystem calls are all implemented in full, andare exactly compatible with V7. In particular,FORK and EXEC are fully implemented, soMINIX can be configured as a normalmultiprogramming system, with severalbackground jobs running at the same time(memory permitting), and even multiple users.

AUUGN 45 Vol 7 No 6

;login:

The MINIX shell, is compatible with theV7 (Bourne) shell, so to the user at theterminal, running MINIX looks and feels likerunning UNIX. Over 60 utility programs arepart of the software distribution, including ar,basename0 cat, cc, chmem, chmod,cho~n, cmp,- comm, cp, date, dd, df,echo, grep, head, kilt, ln, togin,tpr, is, make, mkdir, mkfs, mknod,mount, mv, od, passwd, pr, pwd, rev,rm, rmdir, roff, sh, size, steep,sort, spt it, stty, su, sum, s}’nc,tail, tar, tee, time, touch, tr,umount, uniq, update, and wc. A full-screen editor loosely inspired by emacs, a fullKernighan and Ritchie compatible C compiler,and programs to read and write MS-DOSdiskettes are also included: All of the sourcesof the operating system and these utilities,except the C compiler source (which is quitelarge and is available separately), are includedin the software package.

In addition to the above utilities, over 100library procedures, including std i o,areprovided, again with the full source code.

To reiterate what was said above, all ofthis software is completely new. Not a singleline of it is taken from, or even based on theAT&T code. I personally wrote from scratchthe entire operating system and some of theutilities. This took about three years. Mystudents and some other generous peoplewrote the rest. The C compiler is derivedfrom the Amsterdam Compiler Kit (CACM,Sept. 1983), and was written at the VrijeUniversiteit. It is a top-down, recursivedescent compiler written in a compiler writinglanguage called LLGEN and is not based on orin any way related to the AT&T portable Ccompiler, which is abottom-up, LALRcompiler written in },ace.

Overview of the MINIX SystemArchitecture

UNIX is organized as a single executableprogram that is loaded into memory at systemboot time and then run. MINIX is structuredin a much more modular way, as a collectionof processes that communicate with each otherand with user processes by sending andreceiving messages. There are separateprocesses for the memory manager, the filesystem, for each device driver, and for certain

other system functions. This structureenforces a better interface between the pieces.The file system cannot, for example,accidentally change the memory manager’stables because the file system and memorymanager each have their own private addressspaces.

These system processes are each full-fledged processes, with their own memoryallocation, process table entry and state. Theycan be run, blocked, and send messages, just asthe user processes. In fact, the memorymanager and file system each run in user spaceas ordinary processes. The device drivers areall linked together with the kernel into thesame binary program, but they communicatewith each other and with the other processesby message passing.

When the system is compiled, four binaryprograms are independently created: thekernel (including the driver processes), thememory manager, the file system, and in it(which reads /etc/ttys and forks off the loginprocesses). In other words, compiling thesystem results in four distinct a.out files.When the system is booted, all four of theseare read into memory from the boot diskette.

It is possible, and in fact, normal, tomodify, recompile, and relink, say, the filesystem, without having to relink the otherthree pieces. This design provides a highdegree of modularity by dividing the systemup into independent pieces, each with a well-defined function and interface to the otherpieces. The pieces communicate by sendingand receiving messages.

The various processes are structured infour layers:4. The user processes (top layer).

3. The server processes (memory manager andfile system).

2. The device drivers, one process per device.

1. Process and message handling (bottomlayer).

Let us now briefly summarize the function ofeach layer.

Layer 1 is concerned with doing processmanagement including CPU scheduling andinterprocess communication. When a processdoes a SEND or RECEIVE, it traps to thekernel, which then tries to execute the

Vol 7 No 6 46 AUUGN

;login:

command. If the command cannot beexecuted (e.g., a process does a RECEIVE andthere are no messages waiting for it), the calleris blocked until the command can be executed,at which time the process is reactivated.When an interrupt occurs, layer 1 converts itinto a message to the appropriate devicedriver, which will normally be blocked waitingfor it. The decision about which process torun when is also made in layer 1. A priorityalgorithm is used, giving device drivers higherpriority over ordinary user processes, forexample.

Layer 2 contains the device drivers, oneprocess per major device. These processes arepart of the kernel’s address space because theymust run in kernel mode to access I/O deviceregisters and execute I/O instructions.Although the IBM PC does not have usermode/kernel mode, most other machines do,so this decision has been made with an eyetoward the future. To distinguish theprocesses within the kernel from those in userspace, the kernel processes are called tasks.

Layer 3 contains only two processes, thememory manager and the file system. Theyare both structured as servers, with the userprocesses as clients. When a user process (i.e.,a client) wants to execute a system call, it calls,for example, the library procedure read withthe file descriptor, buffer, and count. Thelibrary procedure builds a message containingthe system call number and the parametersand sends it to the file system. The client thenblocks waiting for a reply. When the filesystem receives the message, it carries it outand sends back a reply containing the numberof bytes read or the error code. The libraryprocedure gets the reply and returns the resultto the caller in the usual way. The user iscompletely unaware of what is going on here,making it easy to replace the local file systemwith a remote one.

Layer 4 contains the user programs.When the system comes up, in it forks offtog in processes, which then wait for input.On a successful login, the shell is executed.Processes can fork, resulting in a tree ofprocesses, with init at the root. WhenControl-D is typed to a shell, it exits, andinit replaces the shell with another toginprocess.

AUUGN

Layer 1 -. Processes and Messages

The two basic concepts on which MINIX isbuilt are processes and messages. A process isan independently schedulable entity with itsown process table entry. A message is astructure containing the sender’s processnumber, a message type field, and a variablepart (a union) containing the parameters orreply codes of the message. Message size isfixed, depending on how big the unionhappens to be on the machine in question. Onthe IBM PC it is 24 bytes.

Three kernel calls are provided:

RECEIVE(source, gmessage)SEND(destination, gmessage)SENDRE~(process, &message)

These are the only true system calls (i.e., trapsto the kernel). RECEIVE announces thewillingness of the caller to accept a messagefrom a specified process, or ANY, if theRECEIVER will accept any message. (Fromhere on, "process" also includes the tasks.) Ifno message is available, the receiving processis blocked. SEND attempts to transmit amessage to the destination process. If thedestination process is currently blocked tryingto receive from the sender, the kernel copiesthe message from the sender’s buffer to thereceiver’s buffer, and then marks them both asrunnable. If the receiver is not waiting for amessage from the sender, the sender isblocked.

The SENDREC primitive combines thefunctions of the other two. It sends a messageto the indicated process, and then blocks untila reply has been received. The replyoverwrites the original message. Userprocesses use SENDREC to execute system callsby sending messages to the servers and thenblocking until the reply arrives.

There are two ways to enter the kernel.One way is by the trap resulting from aprocess’ attempt to send or receive a message.The other way is by an interrupt. When aninterrupt occurs, the registers and machinestate of the currently running process aresaved in its process table entry. Then ageneral interrupt handler is called with theinterrupt number as parameter. Thisprocedure builds a message of typeINTERRUPT, copies it to the buffer of thewaiting task, marks that task as runnable

47 Vol 7 No 6

;login:

(unblocked), and then calls the scheduler to seewho to run next.

The scheduler maintains three queues,corresponding to layers 2, 3, and 4,respectively. The driver queue has the highestpriority, the server queue has middle priority,and the user queue has lowest priority. Thescheduling algorithm is simple: find thehighest priority queue that has at least oneprocess on it, and run the first process on thatqueue. In this way, a clock interrupt willcause a process switch if the file system wasrunning, but not if the disk driver wasrunning. If the disk driver was running, theclock task will be put at the end of the highestpriority queue, and run when its turn comes.

In addition to this rule, once every 100msec, the clock task checks to see if thecurrent process is a user process that has beenrunning for at least 100 msec. If so, that useris removed from the front of the user queueand put on the back. In effect, compute bounduser processes are run using a round robinscheduler. Once started, a user process runsuntil either it blocks trying to send or receive amessage, or it has had 100 msec of CPU time.This algorithm is simple, fair, and easy toimplement.

Layer 2- Device Drivers

Like all versions of UNIX for the IBM PC,MINIX does not use the ROM BIOS for inputor output because-the BIOS does not supportinterrupts. Suppose a user forks off acompilation in the background and then callsthe editor. If the editor tried to read from theterminal using the BIOS, the compilation (andany other background jobs such as printing)would be stopped dead in their tracks waitingfor the the next character to be typed. Suchbehavior may be acceptable in the MS-DOSworld, but it certainly is not in the UNIXworld. As a result, MINIX contains a completeset of drivers that duplicate the functions ofthe BIOS. Like the rest of MINIX, thesedrivers are written in C, not assemblylanguage.

This design has important implications forrunning MINIX on PC clones. A clone whosehardware is not compatible with the PC downto the chip level, but which tries to hide thedifferences by making the BIOS callsfunctionally identical to IBM’s will not run an

unmodified MINIX because MINIX does notuse the BIOS.

Each device driver is a separate process inMINIX. At present, the drivers include theclock driver, terminal driver, various diskdrivers (e.g., RAM disk, floppy disk), andprinter driver. Each driver has a main loopconsisting of three actions:

1. Wait for an incoming message.2. Perform the request contained in the

message.3. Send a reply message.Request messages have a standard format,containing the opcode (e.g., READ, WRITE, orIOCTL), the minor device number, the position(e.g., disk block number), the buffer address,the byte count, and the number of the processon whose behalf the work is being done.

As an example of where device drivers fitin, consider what happens when a user wantsto read from a file. The user sends a messageto the file system. If the file system has theneeded data in its buffer cache, they are copiedback to the user. Otherwise, the file systemsends a message to the disk task requestingthat the block be read into a buffer within thefile system’s address space (in its cache).Users may not send messages to the tasksdirectly. Only the servers may do this.

MINIX supports a RAM disk. In fact, theRAM disk is always used to h01d the rootdevice. When the system is booted, after theoperating system has been loaded, the user isinstructed to insert the root file systemdiskette. The file system then sees how big itis, allocates the necessary memory, and copiesthe diskette to the RAM disk. Other filesystems can then be mounted on the rootdevice.

This org~inization puts importantdirectories such as/bin and/tmp on the fastestdevice, and also makes it easy to work witheither floppy disks or hard disks or a mixtureof the two by mounting them on /usr or /useror elsewhere. In any event, the root device isalways in the same place.

In the standard distribution, the RAM diskis about°240K, most of which is full of parts ofthe C compiler. In the 256K system, a muchsmaller RAM disk has to be used, whichexplains why this version has no C compiler:

Vol 7 No 6 48 AUUGN

;login:

there is no place to put it. (The /usr disketteis completely full with the other utilityprograms and one of the design goals was tomake the system run on a 256K PC with onefloppy disk.) Users with an unusualconfiguration such as 256I( and three harddisks are free to juggle things around as theysee fit.

The terminal driver is compatible with thestandard V7 terminal driver. It supportscooked mode, raw mode, and cbreak mode. Italso supports several escape sequences, such ascursor positioning and reverse scrollingbecause the screen editor needs them.

The printer driver copies its input to theprinter character for character withoutmodification. It does not even convert linefeed to carriage return + line feed. Thismakes it possible to send escape sequences tographics printers without the driver messingthings up. MINIX does not spool outputbecause floppy disk systems rarely haveenough spare disk space for the spoolingdirectory. Instead one normally would print afile fby saying

l pr <f 8,

to do the printing in the background. The lprprogram inserts carriage returns, expands tabs,and so on, so it should only be used forstraight ASCII files. On hard disk systems, aspooler would not be difficult to write.

Layer 3 -- Servers

Layer 3 contains two server processes: thememory manager and the file system. Theyare both structured in the same way as thedevice drivers, that is a main loop that acceptsrequests, performs them, and then replies. Wewill now look at each of these in turn. .~

The memory manager’s job is to handlethose system calls that affect memoryallocation, as well as a few others. Theseinclude FORK, EXEC, WAIT, KILL, and BRK.The memory model used by MINIX isexceptionally simple in order to accommodatecomputers without any memory managementhardware. When the shell forks off a process,a copy of the shell is made in memory. Whenthe child does an EXEC, the new core image isplaced in memory. Thereafter it is nevermoved. MINIX does not swap or page.

The amount of memory allocated to theprocess is determined by a field in the headerof the executable file. A program, chmem, hasbeen provided to manipulate this field. Whena process is started, the text segment is set atthe very bottom of the allocated memory area,followed by the data and bss. The stack startsat the top of the allocated memory and growsdownward. The space between the bottom ofthe stack and the top of the data segment isavailable for both segments to grow into asneeded. If the two segments meet, the processis killed.

In the past, before paging was invented,all memory allocation schemes worked likethis. In the future, when even smallmicrocomputers will use 32-bit CPUs and I Mx 1 bit memory chips, the minimum feasiblememory will be 4 megabytes and thisallocation scheme will probably becomepopular again due to its inherent simplicity.Thus the MINIX scheme can be regarded aseither hopelessly outdated or amazinglyfuturistic, as you prefer.

The memory manager keeps track ofmemory using a list of holes. When newmemory is needed, either for FORK or forEXEC, it searches the hole list and takes thefirst hole that is big enough (first fit). When aprocess terminates, if it is adjacent to a holeon either side, the process’ memory and thehole are merged into a bigger hole.

The file system is really a remote fileserver that happens to be running on the user’smachine. However it is straightforward toconvert it into a true network file server. Allthat needs to be done is change the. messageinterface and provide some way ofauthenticating requests. (In MINIX, the sourcefield in the incoming message is trustworthybecause it is filled in by the kerne!°) Whe~running remote, the MINIX file servermaintains state information, like RFS andunlike NFS.

The MINIX file system is similar to that ofV7 UNIX. The i-node is slightly different,containing only 9 disk addresses instead of 13,and only 1 time instead of 3. These changesreduce the i-node from 64 bytes to 32 bytes, tostore more i-nodes per disk block and reducethe size of the in-core i-node table.

Free disk blocks and free inodes are kepttrack of using bit maps rather than free lists.

AUUGN 49 Vol 7 No 6

;login:

The bit maps for the root device and allmounted file systems are kept in memory.When a file grows, the system makes a definiteeffort to allocate the new block as close aspossible to the old ones, to minimize armmotion. Disk storage is not necessarilyallocated one block at a time. A minor devicecan be configured to allocate 2, 4 (or more)contiguous blocks whenever a block isallocated. Although this wastes disk space,these multiblock zones improve diskperformance by keeping file blocks closetogether. The standard parameters for MINIXas distributed are I K blocks and I K zones(i.e., just I block per zone).

MINIX maintains a buffer cache ofrecently used blocks. A hashing algorithm isused to look up blocks in the cache. When ani-node block, directory block, or other criticalblock is modified, it is written back to diskimmediately. Data blocks are only writtenback at the next SYNC or when the buffer isneeded for something else.

The MINIX directory system and format isidentical to that of V7 UNIX. File names arestrings of up to 14 characters, and directoriescan be arbitrarily long.

Layer 4- User Processes

This layer contains in it, the shell, theeditor, the compiler, the utilities, and all theuser processes. These processes may only sendmessages to the memory manager and the filesystem, and these servers only accept validsystem call requests. Thus the user processesdo not perceive MINIX to be a general-purposemessage passing system. However, removingthe one line of code that checks if the messagedestination is valid would convert it into amuch more general system (but less UNIX-like).

Documentation

Since one of the purposes of MINIX is toprovide a system that can be taught .in classesand studied individually ample documentationis essential. For this reason I have written atextbook (719 pages) treating both the theoryand the practice of operating system design.The bibliographic data is:

Title: Operating Systems:Design and Implementation

Author: Andrew S. TanenbaumPublisher: Prentice-Hall, Inc.Publication date: January 1987

The table of contents .is as follows:CHAPTERS1. Introduction2. Processes3. Input/Output4. Memory Management5. File Systems6. Bibliography and Suggested Readings

APPENDICESA. Introduction to CB. Introduction to the IBM PCC. MINIX Users GuideD. MINIX Implementers GuideE. MINIX Source Code ListingF. MINIX Cross Reference Map

The heart of the book is chapters 2-5. Eachchapter deals with .the indicated topic in thefollowing way. First comes a thoroughtreatment of the relevant principles (thoroughenough to be usable as a university textbookon operating systems). Next comes a generaldiscussion of how the principles have beenapplied in MINIX. Finally there is a procedureby procedure description of how the relevantpart of MINIX works in detail. The sourcecode listing of appendix E contains linenumbers, and these line numbers are usedthroughout the book to pinpoint the codeunder discussion. The source code itselfcontains more than 3000 comments, somemore than a page long. Studying theprinciples and seeing how they are applied in areal system gives the. reader a betterunderstanding of the subject than either theprinciples or the code alone would.

Appendices A and B are quickieintroductions to C and the IBM PC for readersnot familiar with these subjects. Appendix Ctells how to boot MINIX, how to use it, andhow to shut it down. It also contains all themanual pages for the utility programs. Mostimportant of all, it gives the super-userpassword.

Appendix D is for people who wish tomodify and recompile MINIX. It contains awealth of nutsy-boltsy information abouteverything from how to use MS~DOS as a

Vol 7 No 6 50 AUUGN

;login:

development system, to what to do when yournewly made system refuses to boot.

Appendix E is a full listing of theoperating system, all 260 pages of it. Theutilities (mercifully) are not listed.

Distribution of the Software

Software distribution is being done byPrentice-Hall. Four packages are available.All four contain the full source code; theydiffer only in the configuration of the binarysupplied. The four packages are:

* 640K IBM PC version(eight 360K diskettes)

® 256K IBM PC(no C compiler; eight 360K diskettes)

® IBM PC-AT(512K minimum; five 1.2M diskettes)

® Industry standard 9-track tape

The 640K version will also run on 512Ksystems, but it may be necessary to chmemparts of the C compiler to make it fit. Thetape version, in addition to the MINIXsoftware, also contains a complete IBM PCsimulator in C and .other software that allowsMINIX to be experimented with to some extenton a VAX or other time sharing computer,rather than a bare IBM PC. This option maybe useful for courses for which IBM PCs arenot available.

The book ($34.95) and the software($79.95) are being issued separately. The bookcan be bought in any technical bookstore, orordered specially. The book contains apostcard that can be sent back to Prentice-Hallto order the software.

A final word about the legal status of thecode is in order. The software does not comewith a 10-page licensing document that onlythe Dean of the Harvard Law Schoolunderstands. However, it is protected bycopyright. The software is not public domain.However, the publisher does not object to alimited amount of copying being done fornoncommercial use. In other words,professors may make copies of the system fortheir students, students may make copies fortheir professors, and you may make copies foryour friends. If you wish to port the softwareto another computer and then sell it, you needwritten permission from Prentice-Hall. Ingeneral they will be quite reasonable aboutgranting such permission.

A Usenet newsgroup called comp.os.minixhas been set up. This channel is being used bypeople wishing to contribute new programs,point out and correct bugs, discuss theproblems of porting MINIX to new systems,etc. Although the publisher does not object tothe network being used to broadcast a few filesthat have been improved, it is not intended topublish the full distribution (eight 360Kdiskettes) this way.

Acknowledgements

I would like to thank the following peoplefor contributing utility programs and advice tothe MINIX effort: Martin Atkins, ErikBaalbergen, Charles Forsyth, Richard Gregg,Michiel Huisjes, Patrick van Kleef, AdriKoppes, Paul Ogilvie, Paul Polderman, andRobbert van Renesse. Without their help, thesystem would have been far less useful than itnow is.

AUUGN 51 Vol 7 No 6

;login:

The DASH Project: Design Issues forVery Large D stdbuted Systems

David P. AndersonDomenico Ferrari

Computer Science DivisionDepartment of Electrical Engineering and Computer Science

University of California, BerkeleyBerkeley, California 94720

Introduction

A very large distributed system (VLDS) is a(currently hypothetical) system that:

® is large in the following senses: numerical (itcontains thousands or millions of connectedhosts), geographical (hosts may be thousandsof miles apart), and administrative (thesystem encompasses hosts and networksowned by many organizations andindividuals).

¯ offers access to non-local resources such asdatabases, processing power, software, andcommunication with remote human users.

is transparent in the senses that 1) at somelevel (perhaps the user interface) the samesyntax can be used to access both local andremote resources, and 2) there is littleperformance difference between local andremote access.

Such a system is preferable to a collection ofconnected but unintegrated local distributedsystems because it allows efficient resourcesharing on a much larger scale. However, aVLDS cannot be realized by extending .anexisting distributed system, because many of theassumptions underlying the designs of thesesystems do not hold for VLDS. Fundamentaldifferences exist in the areas of security, naming,communication paradigms and architectures, andkernel architecture.

VLDS design involves close interaction oflevels ranging from network hardware up to theuser programming model, and optimal solutionscannot in general be reached by extendingtechniques developed for small distributedsystems. Furthermore, a VLDS has significantadvantages over unintegrated collections of LANsystems, and a properly-designed VLDS restrictedto a LAN is potentially as efficient as a

specialized LAN system. For these reasons,VLDS design should be viewed as a distinct and.important research area.

Previous projects have considered VLDS-related problems such as scalable nameservers[3,6,7] and file services with many clients [4].Efforts at large-scale integration of existingcentralized systems are described in [8] and [5].These projects, for the most part, addressrestricted problems or develop solutions basedon technology that will soon be outdated.

In contrast, the DASH project at UCBerkeley is taking a unified approach to VLDSdesign, and is seeking solutions that will not bemade obsolete by foreseeable technologyadvances. The goals of the DASH project are to1) project the advances in computing and.communication hardware that will make a VLDSfeasible, and the software systems andapplications that will be possible in a VLDS; 2)identify a set of design principles for VLDS, 3)propose mechanisms based on these principles,and 4) develop a prototype VLDS that can beused to test and compare these mechanisms.

Principles and Research Areas

The following are some of the principles forVLDS design that we have arrived at; a morecomplete discussion can be found in [2]. TheDASH prototype incorporatesall of theseprinciples.

® Separate the levelsof’ netv~orkcommunication, execution environr;~_ent~execution abstraction, and kernel structu~’e,and provide an open framework wherepossible.

o Use a hybrid naming system using a tree-structured symbolic naming for globalpermanent entities, and capabilities tocommunication streams for other entities.

Vol 7 No 6 52 AUUGN

;login:

When possible, put communicationfunctions such as security and interfacescheduling at a host-to-host rather thenprocess-to-process level, and consolidatethese functions in a sub-transport layer.

Provide flexible support foi- stream-orientedcommunication.

o Provide a service abstraction that allows forreplication, local caching and fault-tolerance,but does not directly supply them.

* Support real-time computation andcommunication at every level.

Our discussion raises a number of researchareas that should be investigated before a VLDSis put in place:

* Exploring the limits of size and granularityin distributed computing, and identificationof possible bottlenecks (process creation,name resolution, authentication, networklatency).

. The design of high-performance servers fordistant access, and in particular the use ofreplication, streaming, and caching.

. Utilization of multiprocessors: howimportant is kernel parallelism, and howdoes performance depend on processorscheduling, locking mechanisms, and lockinggranularity?

® Assessing the usefulness of bundle-likestream mechanisms for long-distance high-performance services.

o Investigation of real-time networkperformance in terms of its implications fornetwork .and sub-transport layer design, itsimplications for process scheduling, and itspossible applications..

® Exploring the limits of network performancewith very .fast networks, network interfaces,and I/O systems.

Project Status

The DASH project currently consists of 2faculty members, 2 graduate students, andseveral undergraduates. The DASH prototypekernel is being implemented on Sun-3workstations in C++. We are using UNIX as ourdevelopment environment, and have made a

modified version of the UNIX dbx debugger thatallows us to do remote symbolic debugging of theDASH kernel running on bare machines. TheDASH kernel contains no UNIX code.

At this point (February 1987) the lowestlayer of the kernel (processes and message-passing) and of the network communicationfacility (security mechanism and networkdrivers) have been completed. We have recentlyperformed a study of the performance of ournetwork security mechanismsl described in [1].

References

[1] D. P. Anderson, D. Ferrari, P. V. Rangan and B.Sartirana, "A Protocol for Secure Communicationin Large Distributed Systems," UCB/ComputerScience Report No. 87/342, CS Division (EECSDept.) UC Berkeley, February 1987.

[2] D. P. Anderson, D. Ferrari, P. V. Rangan and S.Tzou, "The DASH Project: Issues in the Design ofVery Large Distributed Systems," UCB/ComputerScience Report No. 87/338, CS Division (EECSDept.), UC Berkeley, January 1987.

[3] A. D. Birrell, B. W. Lampson, R. M. Needham andM. D. Schroeder, "A Global AuthenticationService without Global Trust," IEEE Symposiumon Security and Privacy, 1986.

[4] M. Satyanarayanan, J. M. Howard, D. A. Nichols,R. N. Sidebotham, A. Z. Spector and M. J. West,"The ITC Distributed File System: Principles andDesign," Proceedings of the lOth Symposium _onOperating System Principles, Operating SystemsReview 19, 5 (December 1985), 35-50.

[5] R. E. Schantz, R. H. Thomas and Go Bono, "TheArchitecture of the Cronus Distributed OperatingSystem," Proceedings of the 6th InternationalConference on Distributed Computing Systems,May 1986, 250-259.

[6] M. D. Schroeder, A. D. Birrell and R. M.Needham, "Experience with Grapevine: theGrowth of a Distributed System," ACMTransactions on Computer Systems 2, 1 (February1984), 3-23.

[7] D. B. Terry, M. Painter, D. W. Riggle and S.Zhou, "The Berkeley lnternet Domain Server,"USENIX Summer Conference Proceedings, June1984, 23-31.

[81 T. Truscott, B. Warren and K. Moat, "A State-Wide UNIX Distributed Computing System,"Proceedings of the 1986 ’ Summer USENIXConference, June 1986, 499-513.

AUUGN 53 Vol 7 No 6

;login:

Book Review

The Nutshell Handbooks(Newton, MA: O’Reilly & Associates, 1986) $7.50 each

Reviewed by Lou Katz

Metron Computerware, Ltd.Oakland, CA

ucbvax!metron!lou

O’Reilly & Associates has created anambitious set of small volumes intended tosei’ve as a relatively basic introduction to anumber of important UNIXt facilities.Uniform in style and presentation, there arecurrently seven books:#1 Learning the UNIX Operating System

Grace Todino and John Strang#2 Learning the Vi Editor

Linda Lamb#3 Reading and Writing Termcap Entries

John Strang#4 Programming with Curses

John Strang#5 Managing UUCP and USENET

Grace Todino and Tim O’Reilly#6 Using UUCP and USENET

Grace Todino#7 Managing Projects with Make

Steve Talbott

The first book of this series, Learning theUNIX Operating System, declares its intentionto give a "good overview of ... UNIX survivalmaterials for the new user," "not tooverwhelm you with unnecessary details but tomake you comfortable as soon as possible inthe UNIX environment." In that respect, thebook accomplishes its aim. It is well-organized and flows in a logical manner. Thetext is simply written, and should make anovice user comfortable. I like the small (81/2"x 51/2") format, which is compatible with manyof the commonly available UNIX manuals.

However (now for the bad news), thisvolume is seriously flawed in detail. I get thevery strong impression that its authors are newto UNIX, mastered the one system they hadaccess to, and by virtue of being more facile

t UNIX is a registered trademark of AT&T. All sorts ofother things are trademarks of other companies.

than their friends came to delude themselvesthat they were experts. This seems clear to meby omission, for surely anyone with any depthof experience would have gone to some painsto. remark on the existence of different versionsof UNIX and to specify (at least in anintroduction or appendix) which version orversions this volume referred to. Althoughone can smile with wry amusement at thestatement "ed was first developed when textediting was done on a line printer," onewonders whether the authors were bornyesterday or just arrived from Mars.Statements of this sort certainly do not inspireconfidenc!! In fact, this book is loaded withinaccuracies in details or concepts, flaws whichcan easily lead a new or naive user toformulate a fundamentally incorrect model ofthe system. There is a blurring and mixing ofthe distinction between UNIX the operatingsystem, the shell user interface and other user-level commands which are supplied with aUNIX system. The assertion that "If youmake a mistake in specifying the options (to .acommand) UNIX (sic!) will display the correctform" is both conceptually and factuallyincorrect. Some commands will give a"usage: syntax" response when faced withunknown flags or missing but requiredarguments, but many commands do not do so,and certainly UNIX isn’t doing this service.

Almost all topics are explained innarrative and then at least one specificexample is presented. This is very useful, andis reasonably well done, though there areenough errors in detail to make me worry.The overall presentation of I/O redirection isgood and there is an excellent discussion of thedanger of qrm. The discussion of cd has agood comment regarding the fact that youcannot cd to a filename, but follows that withan example which shows a system responsewhich is incorrect. The description of t s -a

Vol 7 No 6 54 AUUGN

;login:

poses the common quesion "What are thesefiles ’.’ and ’..’?" explicitly, but then doesn’tanswer it. Furthermore, the parent directoryof the user’s directory is shown in an t s -tlisting as being owned by the user himself, ahighly unlikely organization ’of file systemownership.

Users are encouraged to try a terminal’sBREAK key, among others, if they need theINTERRUPT function, a practice which usuallywill not work, and will often cause bigproblems. The much-needed section on whatto do if your terminal seems hung orunresponsive contains a number of excellentsuggestions, but omits crucial ones: to trypressing LINE-FEED or control-J!

Typographically,. O’Reilly & Associateshave chosen to use a rather poor sans seriffont when displaying literal computer-userinteractions. I would have preferred greatlythe computer’s prompts and responses to bebold-faced and the user’s entries to be normalrather than the reverse scheme used. In thesection on the need for white space betweencommands and their arguments, the examplet s-t (without whitespace) was broken at themargin right after the t s, totally destroying thevisual information of the missing space andthe intelligibility of the example!

Although this volume is clearly and simplywritten and covers a very suitable selection oftopics for novice users, it is much too flawed.I cannot recommend it.

Volume #2, Learning the Vi Editor, coversthat common utility. Since I am not a v i user,I cannot vouch for its detailed accuracy.However, the discussion of cursor position onpage 3 is totally confusing. The WYSIWYGstatement on page 6 is wrong, and the table oncustomization is unclear. Some of theexamples in the regular expression section,though correct, were more complicated thanwas needed: to delete all trailing blanks, theysuggested :9/\(.*\) *$1s11\1/ while theexpression :g/ *S/s/// would work just aswell and didn’t need the saved sub-string \l.However, the overall description seemed goodenough that I expect to try use this book onthe next occasion that I have to cope with asystem which does not happen to have myfavorite editor but does have v i.

Volume #3, Reading and Writing TermcapEntries, is written for system administrators,albeit ones with limited experience. Itproceeds through the features and capabilitiesof the termcap system and gives expandedexplanations in rather clear English. The"Terminal Capabilities by Function" table is avery nice restatement of the capabilities codes.The blow-by-blow annotation of the entries fortwo different types of terminals is good, as arethe hints on how to write, test, and debugentries. The alphabetic list of capabilities atthe end also serves as an index to the booklet.In a few places, the descriptions get boggeddown -- the written discussion of the ’%’arguments being an example, though thefollowing examples partly compensate for theconfusion in the paragraph. In general thisvolume is a useful and helpful addition to thestandard documentation.

Volume #4, Programming with Curses, thecompanion volume to #3, is a different story.I actually used this book during a recentproject which required curses. The expandedexplanations were a great help in dealing withthe standard CURSES document in the UNIXreference manuals, but the illustrativeexamples were poor and badly explained.Detailed explanations of some of the functionswere either inaccurate or misleading, leadingme to believe that the author did not fullyunderstand, among other things, the gorydetails of terminal I/O.

Discussion of the c t earok ( ) function wasconfusing and left me no wiser than before Iread it. Physical echo does not mean that"characters are also echoed to the screenlocally by your terminal." The definition ofcrmode() says that AS, "Q, AC, ^Y go to thekernel for processing long before they aredefined in the text as flow control, intet~uptand quit, and there is NO mention of localvariability and freedom in assigning thesefunctions to the control key of your religiouschoice. "Raw mode is good if you do notwant to handle interrupts and quits and wouldrather ignore them" is a rather bizarre anddangerous view of this topic.

In general, the usage examples are poor.For me, the greatest lack was in not coming togrips with using curses for overlappingwindows. This topic was not treated in anyuseful fashion. Since curses is concerned

AUUGN 55 Vol 7 No 6

;login:

with the care and feeding of visual material,the lack of illustrations (each potentially worth1000 words) is regrettable.

The Quick Reference Table at the end ofthe book did serve as a partial index.Although seriously flawed, this book wassomewhat useful to me, and ! wouldrecommend it to experienced programmers,but only very cautiously to novices.

Volume #5, Managing UUCP andUSENET, and volume #6, Using UUCP andUSENET, are another pair of pamphlets, onetargeted towards the system administrator, theother towards a user who may not even be aprogrammer. I became concerned at theoutset with the technical breadth of experienceof the author because I found on page 3 ofVolume #5 the statement "we use the systemprompt # to indicate that the commands canonly be executed in the superuser modebecause of UUCP file permissions. Commandsthat are preceded by the system prompt unixT.can be invoked in multi-user mode." Anyonewho confuses permissions with operating mode(I have never heard single-user mode referredto as superuser mode), or who cannot find theright words to express this concept, makes mewary, as does someone who believes the 50foot limit on direct RS-232 connections. Thediscussion of null modems is too trivial (againlack of knowledge?), for a new systemadministrator really needs some discussion ofmodem control lines, not just how to crosssend-data and receive-data wires.

There are many detailed tidbits whichseemed strange, such as putting comment linesin /etc/passwd by starting a line with #, doinga setuname on every reboot from /etc/rc, orputting several entries for the same usernamebut with different passwords in /etc/passwdand expecting tog in to find the one whichmatched, getty monitors incoming lines, anddoes not start a tog in when a call out isinitiated. Setting the "time to call" field inL.sys does not enable uucico.

The output from uucico in debug mode isconfusing and not really explained in standardUNIX documentation, and this book addsnothing to that situation. A two pagereproduction of a session is dropped in theuser’s lap without so much as one line ofcomment, aside from dividing the printoutinto sections and identifying the major activity

underway (establishing contact, sending a file,etc). However, the table of STST andLOGFILE messages is good and useful.

As ! have never had to install or maintainnetne~s, I cannot vouch for the accuracy ofthe chapters on that subject. What I readseemed clear and useful. Appendix A, whichlists the names, formats and use of the uucpworking files is a welcome addition of usefulinformation on this cryptic system. Despitethe glaring flaws there is value in this book,and I give it a qualified recommendation.

The companion volume #6 is meant forusers, and suffers from the same defects as theother volumes. UUENCODE is not a UUCPcommand for sending binary files, and eventhe example shows encoding a file and thenpiping it through mail. One strongly suspectsthat much of the information that is presentedwas obtained by reading the documentationrather than by trying it.

The fact that tilde escapes like "! or"%put had to start on a new line was nevermentioned. The author seems not to haveknown that the ">: file diversion facility of c ucould be invoked without the trailing :, and sowastes considerable time explaining how torun scripts to see material, when "> enablesyou to see the input while capturing it in a file.If one never gets past the -%take and -%putoptions, one doesn’t quite understand the fullpower of the cu program. As with the otherbooklets, the discussion of netnews is quitethorough, but I was tired of looking for defectsby then. With the recent reorganization of theentire newsgroup naming conventions, some ofthe material is out of date, but that isn’t thefault of the author. This book is a usefuladdition to the standard documentation, butdon’t go to any special trouble to find it.

Volume #7, Managing Projects with Make,is a rather comprehensive tour through themake facility. Written in an entirely differe~tstyle from the standard UNIX doc’omerxtation,it provides a clear and comprehensivedescription of the flags, options, and featuresof make along with examples. The bookletdiscusses the less than obvious syntax of makeand its macros in some detail, and I learned afew things about maintaining libraries using i.t.My main criticism is that I would havepreferred more explanation of why certain

Vol 7 No 6 56 AUUGN

;login:

constructs were used in the final ratherelaborate example. All in all I wouldrecommend this book, especially for theexperienced programmer who may be workingalone and without much contact with a makeguru, and who need to get started using thisfacility.

In summary, O’Reilly & Associates havetackled many of the functions new orinexperienced users, programmers, and systemadministrators need to know in a coherent andunified fashion, and should be commended fortheir efforts. Each book is complete in itselfand modestly priced (about $7), though. the

cost for the entire set is no longer trivial. Eachvolume contains a Table of Contents at thebeginning and Summary pages at the’end, butnone contains an index. The subjects arecovered thoroughly and in detail and thewriting is generally clear and simple. This isnot just a re-phrasing of material found in thestandard UNIX manuals.

However, when examined closely, thebooks are riddled with inaccurate, misleading,or downright incorrect technical details orconcepts, so that their utility is in some casesseverely compromised. In a discipline whereliteral accuracy is required for learning byexample, this failing is inexcusable and cannotbe taken lightly. The printing style, photooffset onto small format stapled booklets withinexpensive paper should make revision lesscostly, and many of the problems noted aboveare correctable. With the exception of volume#1, the other six booklets are all more usefulthan flawed, and can be recommended to agreater or lesser degree. The table belowsummarizes my ratings for each of the books.The rating scale is:

Unacceptable 0Poor 1Satisfactory 2Good 3Excellent 4

#2 #3 #4 #5 #6 #7

Clarity of Presentation 2 3 3 3 2 3 4Organization and Style 3 3 3 3 3 3 4Examples 2 3 3 1 2 2 3Completeness 3 3 3 2 3 3 3Accuracy 1 2 3 3 2 2 3Overall Value 1.5 3 3 2.5 2.5 2.5 3.5

AUUGN 57 Vol 7 No 6

Minutes of the AUUG General MeetingFebruary 10, 1987

.

.

.

o

.

The meeting opened at 09:16. Present were an undetermined number ofmembers of the AUUG, and several others. The secretary, and one generalcommittee member (Chris Campbell) were present.

In the absence of the president, Chris Campbell was elected chairman of themeeting.

The minutes of the previous GM, the 1986 AGM (Canberra, September 1986)were read.

Moved (John Carey, seconded Peter Harding) That the minutes be accepted.Carried (with one abstention).

There was no business arising from the minutes, other than that alreadyscheduled on the agenda.

No presidents report was given, as the president was absent.

The secretary (Robert Elz) presented his report. There were 148 ordinarymembers, and 70 unfinancial members still owed newsletters on Sep 1. We nowhave 5 institutional members. There were 24 newsletter subscribers who werenot members. 10 newsletters are exchanged with other groups, or otherwise sentwithout payment. There are 144 members currently unfinancial.

The secretary made a brief report on progress with respect to negotiations withother user groups for reciprocal rights. These include USENIX/usr/groupNZUSUGI JUS EUUG SIN/X and THAINIX.

The secretary also mentioned the high number of unfinancial members, andindicated to members the method of determining their membership expiry datefrom the mailing label of the newsletter.

Moved (Peter Tyres, seconded Stephen Frede) That the secretaries report beaccepted. Carried without dissent.

In the absence of the treasurer, the secretary presented the treasurer’s report. Afinancial summary for the previous financial year, and budget for the currentyear were presented.

Moved (Michael Selig, seconded Taso Hatzi) That the treasurer’s report beaccepted. Carried without dissent.

Vol 7 No 6 58 AUUGN

8, There was considerable discussion on the issue of incorporation, and the motionmoved at the AGM in Canberra instructing the committee to hold a ballot ofmembers.

The chairman presented a brief summary of the issues.

An unfinancial member asked why the ballot had not been held, and attemptedto move a motion that the ballot be held earlier than the committee’s intendeddate of May. He indicated that he was an unfinancial member because ofconcern of the status of members in unincorporated associations.

The secretary indicated that legal advice was being obtained, and the resultswould be made available to members with the ballot when held.

The meeting expressed concern that incorporation be proceeded with as soon aspossible.

It was also suggested that the committee plan to hold meetings soon after eachgeneral meeting, to avoid delays such as that which was incurred here, wherethere was no committee meeting for 2 months after the AGM, so the committeewere unable to consider the direction for this period.

9. Meeting closed 10:13.

AUUGN 59 Vol 7 No 6

Letters to the Editor

Computer. CentreMonash UniversityClayton, Victoria 3168AUSTRALIA

Wednesday 18th February, 1987

Ryerson E. SchwarkAccount Executive - Software LicencingAT&T Unix Pacific Co., Ltd.No. 1 Nan-oh Bid., 5th Floor2-21-2, Nishi-ShinbashiMinato-ku, Tokyo 105 JAPAN

Dear Sir,

I enclose the following correspondence between Greg Rose and myself concerningpublishing AT&T literature in the AUUGN.

I am happy to publish press releases and related material concering AT&T UNIX*products and activities as a service to the AUUG members.

It would be appreciated if AT&T would consider providing some form of support tothe production of the AUUG’s Newsletter. My most urgent need is to upgrade theversion of Documenter’s Work-Bench I am currently using to Version 2.0. At themoment I am struggling to keep up with articles produced with grap and the mmmacros which respectively I currently do not have (grap) and have an old version(mm). Also a 3B2 or a UNIX-PC and a text previewer or a fast laser-printer dedicatedto Newsletter production would be wonderful.

I look forward to your reply.

Yours Faithfully,

John Carey,AUUGN Editor.

* UNIX is a trademark of AT&T Bell Laboratories

Vol 7 No 6 60 AUUGN

AT&T Unix Pacific Co.,Ltd.No. 1 Nan-oh Bldg., 5th FI.2-21-2, Nishi-ShinbashiMinato-ku, Tokyo 105 JapanTel : 03-431-3305Telefax :03-431-3680Telex : J34936 ATTUP

March Ii, 1987

John CareyComputer CentreMonash UniversityClayton Victoria 3168AUSTRALIA

Dear Mr. Carey,

I have spoken with Mr. Crume about your request, and we have agreedthat your request is quite reasonable. We are thereforegoing to givea free upgrade to Monash University from Documentor’s Workbench 1.0 toDocumentor’s Workbench 2.0. This is, of course, under theunderstanding that it is done for the purpose of supporting AUUGN, andnot as a gift to the university per se. The contracts involved inthis upgrade will follow in a few days.

I understand your need for some computer hardware, but AT&T UnixPacific does not sell hardware, so I am passing a copy of your letteron to Olivetti-Australia with the hopes that they might give you someassistance in this matter°

We appreciate your efforts in informing the UNIX~ System community.If there is anything I can do to assist you, please don’t hesitate tocontact me°

Tokyo-Japan-RS-hy

Sincerely,

Account ExecutiveSoftware Licensing

Registered Trademark of AT&T in the USA and other countries

AUUGN 61 Vol 7 No 6

Computer CentreMonash UniversityClayton, Victoria 3168AUSTRALIA

Tuesday 2 lth April, 1987

Ryerson E. SchwarkAccount Executive - Software LicencingAT&T Unix Pacific Co., Ltd.No. 1 Nan-oh Bid., 5th Floor2-21-2, Nishi-ShinbashiMinato-ku, Tokyo 105 JAPAN

Dear Sir,

Thank you for your generous offer to upgrade Monash University Computer Science’sDocumentor’s WorkBench to Version 2.0 for no charge to assist with the production ofthe AUUG Newsletter.

I have passed your two letters and the contacts to:-

Sue ReesAdminstrative OfficerDepartment of Computer ScienceMonash University

for processing.

Unfortunately Olivetti Australia have not made any comment as far as hardware isconcerned.

Thank you again for showing interest in the Newsletter.

Yours Faithfully,

John Carey,AUUGN Editor.

Vol 7 No 6 62 AUUGN

C.P. EXPORT PTY. LTD.INCORPORATED IN VICTORIA613 ST KILDA ROADMELBOURNE 3004VICTORIA AUSTRALIA

April 9th, 1987

The EditorThe Australian UNIX Systems Users Group NewsletterComputer CentreMonash UniversityCLAYTON VIC 3168

Dear Sir,

I am writing this letter with the intention of informing membersof the AUUG about the formation of CP Export, an internationalsoftware publishing company whose major objective is tosuccessfully identify, promote, distribute and sellAustralian-sourced software on the international market.

By way of background, CP Export was formed in late 1986 as ajoint venture between the Victorian Government and ComputerPower., providing the software developer with a sizeablemarketing, distribution and support presence in North America,Europe and Asia, thereby creating a ready made outlet forAustralian products.

We are looking for Australian software products developed eitherby individuals or companies which will compete well in exportmarkets, specifically in the UNIX area. We believe that someexcellent produc~s have been developed within this environmentand as such are very keen to identify them irrespective of theirsize or functionality. The product developed by an individualto address a specific problem may well have significantpotential.

If any of your members have a product which they believe isworth consideration or would like to have further informationregarding CP Export, we would be pleased if they could contactCP Export, telephone (03} 520.5480.

Yours sincerely,

Brian R. Nicholson

TEL. (03) 520 5333 TLX. AA 37159 FAX. (03) 520 5411

AUUGN 63 Vol 7 No 6

Australian UNiX systems User Group.P.O. Box 366, Kensington NSW 2033, Australia.

auug@mu nnari.oz.au {seismo,hplabs,mcvax,ukc} !mu nnari !auug*UNIX Is a registered trademark of AT&T in the USA and other coun|rles.

Mr Greg Rose,Managing Director,Softway Pty Ltd,P.O. Box 305Strawberry HillsN.S.W. 2012

Saturday 11th April, 1987

Dear Greg,

I refer to your letter to John Carey, the Editor, AUUGN, of January 27, in which youmake a complaint about the publication in AUUGN Volume 7 Issue 2-3 of an adver-tisement for AT&T without charge.

I wish to point out that that particular advertisement was considered by the AUUGManagement Committee at its meeting on November 17, and expressly authorised forpublication at no charge.

This was reported in the minutes of the meeting, published in the same AUUGN issue.I refer you to item 11, on page 31.

Thus, if you have a complaint, it would be more correctly addressed to the AUUGManagement Committee than to the Editor.

Yours sincerely,

Robert ElzHonorary SecretaryAUUG

cc: The Editor, AUUGN

Vol 7 No 6 64 AUUGN

AUUGAustralian UNiX systems User Group.

P.O. Box 366, Kensington NSW 2033, Australia.auug@rnunnari.oz.au {seisrno,hplabs,mcvax,ukc} !munnari!auug

*UNIX is a registered trademark of AT&T In the USA and other countries.

The EditorAUUGN.

Sunday 12th April, 1987

Dear John,

I enclose a paper from the NZUSUGI I received some time ago, together with a cover-ing letter from the secretary of the NZUSUGI, Keith Hopper.

I would appreciate it if you would arrange to publish this paper in the next issue ofAUUGN.

I was delaying this until I received a reply to a request I sent asking permission topublish this, however, after six months it appears that no reply is likely, so I think weshould go ahead and publish it now.

I would also be grateful if you would request that any readers who have comments onthis paper would forward them to me, either at the above address, or by electronicmail to

auug@munnari.oz

This will assist the management committee of AUUG to decide what position, if any,AUUG should take on this issue.

Yours sincerely,

Robert ElzHonorary SecretaryAUUG

Enc

AUUGN 65 Vol 7 No 6

NEW ZEALAND UNIX SYSTEMS USER GROUP, INC.

P.O. Box 13056University of WaikatoHAMILTONNew Zealand

8 October 1986

The SecretaryAustralian Unix Systems User GroupP 0 Box 366KensingtonNSW 2033

Dear Sir

UNIX STANDARDISATION

The Board of NZUSUGI has received conflicting suggestions aboutthe use and applicability of the standardisation efforts of IEEE inthe USA and the X/OPEN group in Europe.

I was asked to conduct a study of the documents and co-ordinate aposition paper, a copy of which is attached.

A number of detailed technical discrepancies are also underconsideration for incorporation in any interim standard.

Your comments are invited on this group’s position instandardisation. These may be addressed as above.

Electronic mail may be sent via JANET to kh@nz.ac.waikato.

Yours faithful ly

K. HopperSecretary

Vol 7 No 6 66 AUUGN

+

UNIX

STANDARDISATION

by

K. Hopper

University of Waikato, New Zealand

M~stract The ground rules for standarJisation of the UNIX

operating system are queried and one possible consistent

set suggested. The place of the existing informal

docu~nents on UNIX standar~lisation is investigated and an

outline plan for full formal standarJisation proposed.

Intr~uction

The recent initiatives to "standarJise" some facets of the UNIX operatinq

system are unfortunately, on very shaky ground. They have arisen in Europe

and the US for what are conceived to be urgent commercial reasons.

Before taking any action in regard to UNIX standardisation, however,

there are a number of ground rules which should be agreed. Most of these

are, at present, open questions.

Standarrls forThere are a number of viewpoints from which the need to star~ardise may

be seen’-

a. The commercial programmer wishing to invoke OS services.

b. The commercial package user wishing to make use of a package.

UNIX ~ a trademark nf AT&T Be|~ taborator~e~ in the USA and othe~

countr~et.

AUUGN 67 Vol 7 No 6

c. Any use~ wishing to use the UNIX tool-set.

d. Any user wishing to interact with a UNIX system.

These four different "users" may, of course, be one person at different

times.

Standardise What?

Is the attempt to "standardise" UNIX to be made from the point of view of

the UNIX implementers - o~ is it to be made from the point of view of the

eventual users (any or all of the kinds just described)? Whichever view is

taken wi!! result in quite different standards.

Standard in Relation to What?

All standards activities imply that there is necessarily some objective

measurement facility which can determine conformance. This offers

particularly intriguing situations when dealing with man-machine

interactions. Is measurement to be made against some non-proprietorial

"universal"? Is measurement to involve grades of conformance - allowing

sub-setting or super-setting? Is standardisation to be some minimum which

may be exceeded by some implementer providing for "optional extras" - or are

such extras’to be eschewed?

Why Standardise?

Although all the work done in the US & Europe expressed the objective

i~pl.-:,.ving software portability, there are a number of very important

additional questions:-

a. What about people portability?

b. Why restrict portability to one OS?

c. What about hardware portability? If not this then what about

firmware portability? What about a "UNIX machine" very close

to the raw hardware?

Vol 7 No 6 68 AUUGN

How Can a Standard be Specified?

In order to be able to test conformance it is a tautology to say that

there must be a specification. However, any new standard must itself be

specified in ter~s of some other "standard(s)" already defined.

The usefulness of a standard is strongly related to the range of peoplewho understand what it means (in terms ~qoYeYx of what is "written") because

they either know or have access to the standards 1½ which it is written.

Who Tests Conformance?This is the major question in setting standardisation ground rules. The

easy answer is to merely say "standards authorities". When it comes tb

measuring against the Inter~ational Standard Metre or Kilogram, say, little

problem arises, since with due care it is possible to set up Transfer

Standards which can be distributed to countries to produce in turn an

arbitrary number of National Sub-standards.

Attempting to standardise an operating system requires that a set of

standard tests are generated, which an implementation wishing to conform

must pass satisfactorily - in terms of the written standard. However, the

producer of programs for sale must also test that his progr~ - which

becomes an extension of the functionality of the computer system on which it

runs - also conforms to the expected standarJ usage of operating system

facilities by being an extension and no~ an alteration! This must be done

with every program sold. It is unlikely that every individual programmer

could afford to do this, therefore each country must have at least one test

facility to be able to affix a "standards label" to every conforming

program.

Does this imply the necessity of a Software Standards Laboratory in each

country, such as is being done in relation to Ada, Cobol, Fortran, Pascal &

Modula-2 programming language compilers? The compiler situation is

relatively easy since very few people write compilers and only a sprinkling

of test laboratories are required world-wide. Standardisirm! software

production of the kind envisaged in standardising UNIX requires a great deal

more effort (arid, presumably, cost). ’

Vol 7 No 6AUUGN 69

Who Uses the Standa~?

In order to be used, a standard must show advantage to its putative user

community. This returns the discussion neatly to the first ground rule.

Advantage may be measured in any appropriate way - but will, after a few

transformations, almost always turn into a monetary value or, occasionally,

only as a time-saver.

A little thought will show that the short-term immediate benefit arises

to commercial programmers who will be able to sell their efforts to run on a

wider range of machine hardware. The next most obvious beneficiary is the

hardware supplier since, assuming that he offers a duly certified operating

system implementation, he may compete more vigorously in a horizontal marketknowing that his potential customers’ software will not need changing.

The real beneficiary of all this in the long run is the end user who can

mix and match software and hardware more readily to his current needs,

,,without. any need for retraining/learner costs interfering with his

productivity.

THE ONLY WAY that this real benefit may be gained, however, is by THE

USER PAYING in cash terms for the COST OF CONFORMANCE TESTING! If the useris not prepared to pay a testing premium then the standard might almost as

well not have been written. If the user either can’t or won’t pay, the

standard won’t otherwise receive the use which it deserves.

Some Al~ers

Having posed a number of questions which aim at the ground-rules for

standardisation, rathec than the technical details which are very much a

secondary consideration at this early stage, it is useful to present one set

of possible answers as a starting point [o~ discussion.

Vol 7 No 6 70 AUUGN

It is, therefore, proposed that the following ground-rules should be

adopted -

a. The viewpoint of the end user wishing to interact with a UNIX

system should be chosen to express the needs which are to be

satisfied. This viewpoint may be broadly described as a need for

ma,~um~o~i~Ye transparency and ~o~Ypackage portability, where

transparency means that the user neither wishes to know about nor

cares exactly what hardware is running which operating system

implementation! Total portability is even more severe in that it

implies that the user wishes to be able to use packages in

identical ways i~-e~/~9~£/~~ of the run-time environment - ie

hardware and operating system independent!!

b. The things which must be standardised from the user’s

viewpoints are essentially all related to the OSCRL definition. It

may be necessary to offer a variety of ~/~YY~con~~n~ "

alternative interface processes until more progress is made in

developing self-adaptive systems. The OSCRL should be a formally

defined language - noZthe "list" of methods invoking commands

syntactically which is seen currently in all UNIX "shells". The

user wishes to see above all a uniform interface with no syntactic

nor semantic peculiarities. The alternative interface processes

are suggested in order to provide simple interfaces for those users

needing them and more sophisticated facilities for the expert.

c. A standard should be exactly and only one! There should be no

sub-setting and certainly no supersetting - at least until forma!

revision of the standard provides for increased functionality. Any

alternatives to this allow individual implementers to produce the

existing Tower of Babel yet again.

d. A standard should be presented in terms of the operating system

interfaces.

(1) With a human user via some expressly provided interfaceprocess, built upoh the following (2) interfaces.

AUUGN 71 Vol 7 No 6

(2) With other software non-human users in terms of primitive

"command and response" languages.

(3) With the underlying "UNIX machine" at the firmware or

hardware level. This is a vital interface all too oftenignored.

Given the user’s requirements for total software portability, the

functionality of the primitive interfaces must be defined in two

quite separate groups - those which are quite independent of what

may be the underlying operating system and those which, by their

nature, exercise operating system specific features.

e. Specifications should be written in terms of data abstractions

- i.e. data structures and formally defined routines. No attempt

should be made to use ~,~y"programming language" syntax for routine

specification. The use of programming-language-like syntax to

specify data structures ~axbe convenient, while using formal

routine semantic descriptions in, for example, VDM.

f. The computing industry in each country should set up (at least)

one Software Standards Laboratory (where insufficient already

exist), to provide the necessary independent conformance testing

for programs written in accordance with a standard.

The Path Ahead

Two groups of workers in US and in Europe have produced respectively IEEE

Trial Use Standard 2003 and the X/Open Portability Guide.

These large documents both address only a small part of a full standard -

in a very primitive non-formal pseudo-programming language way. While these

may be the result of many months of work - even years - they are notsuitable as a formal standard - nor even part of one.

Their major disadvantage is that they are expressed in terms of the C

programming language, which, besides not yet being given a standarddefinition of its own is totally unsuited to formal standard specification

as it has no data abstraction built into its semantics (just into "good

practice"!)

Vol 7 No 6 72 AUUGN

The path ahead therefore could well begin by completely rewriting them in

formal notation as one document, to which is attached an informal

descriptive explanation - rather in the way that the Ada language formal

syntax and semantics are expressed in that standard. This preliminary step

would also serve to separate the specific from the non-specific

functionality required.

ISO work is being undertaken to specify human user OSCRLs. The human

user interfaces for UNIX should take this work into consideration, as well

as the associated theoretical work which has been undertaken by IFIP WG2oTo

The specification of a "UNIX machine" is something which has not yet been

tackled in serious vein by any research or standards group. Specification

of such a low-level functional ~machine is therefore open to anyone

interested in starting such work.

Practical Steps

The preliminary informal specifications currently proposed should, it is

considered, be used solely as an ~½ter~ standard until formal

specifications can be produced as suggested above. Bringing this into force

will get the market accustomed to the benefits which even an interim

standard can provide.

In parallel with work to produce a formal UNIX Software Interface

Standard, work should be undertaken to produce a UNIX Human Interface

Standard, in association with ISO TC97/SC21/WG5 standardisation efforts.

Users of the existing UNIX interfaces should provide comment and suggestions

for alterations through the Standards Officer of their national UNiX User

Group. Particularly welcome will be comments from non-programmer users -

who form the vast majority although they seem to receive too little

attention!

It is hoped that implementers of UNIX kernels can join together, despite

the existence of commercial secrets to produce in the longer term a UNIX

Machine Standard, which will be of considerable use to hardware¯

Vol 7 No 6AUUGN 73

manufacturers as "special" soft machines come to be used more than they are

today.

Acknowledgements

Many thanks are due to my colleagues in the New Zealand UNIX Systems User

Group who have encouraged me to devote more time to technical matters and

less to administrivia. The poor current state of UNIX standardisation needs

a great deal of help to correct the existing direction of work.

Bibliograph¥

I EEE, Tribl-g£qe S~.arldard Por~.able O]gera~i’~g Sys~.em for C.ompt:~.er

Envi’ronmen~s, ( IEE~., New York, 1986).

X/OpenPor~bili’~yG~’de, (Elsevier, Amste~lam, 1985).

IFIP WG2.7, Reference /{odel for Oper~Y~g System Comm~nd end Responso

L~ng~/age.% (Springer, Heidelberg, 1986).

AUUGNVol 7 No 6 74

AT&T

AT&T Unix Pacific Co.,Ltd.No. 1 Nan-oh Bldg., 5th2-21-2, Nishi-ShinbashiMinato-ku, Tokyo 105 Japar~Tel : 03-431-3305Telefax : 03-431-3680Telex : J34936 ATTUP

February 20, 1987

Enclosed is a press release given out by AT&T and MicrosoftCorporation to introduce a new version of the UNIX~ System V operatingsystem for Intel Corporation’s 80386 microprocessor.

If you have any questions, please do not hesitate to contact us.

Sincerely,

Tokyo-Japan-RS-hy

warkAccount ExecutiveSoftware Licensing

Registered trademark of AT&T in the USA and other countries.

AUUGN 75 Vol 7 No 6

AT&T Unix Pacific Co., Ltd.No.1 Nan-oh Bldg., 5th F1.2-21-2, Nishi-ShinbashiMinato-ku, Tokyo 105Japan

For further information:

Ryerson SchwarkSoftware Licensing Account ExecutiveTel: 3-431-3305 (Japanese)

3-431-3670 (English)Fax: 3-431-3680Telex: J34936 ATTUPuucp :seismo!akgua!attunix!upshowa!schwark

PRESS RELEASE

AT&T and Microsoft Corporation today announced they will introduce a new version of the

UNIX* System V operating system for Intel Corporation’s 80386 microprocessor used in the

newest generation of microcomputers.

The new software product -- giving PC’s the power of a minicomputer -- will be developed by

Microsoft from AT&T specifications and will be distributed under AT&T’s trademarked name

"UNIX." The product is expected to be available in early 1988.

Vittorio Cassoni, Senior Vice President of AT&T’s Data Systems Division, said that "the use of

the trademark "UNIX" on operating system products will assure customers that their

applications will run unmodified on any computer based on the 80386 microprocessor, regardless

of the vendor."

The 80386 microprocessor (commonly referred to as the 386) is the basis for the newest

generation of 32-bit computers now being developed and marketed by many hardware

manufacturers. The combination of the 386 and the multi-tasking, multi-user features of UNIX

System V will be a powerful, cost-effective system for a wide variety of applications.

* Registered trademark of ATg~T in the USA and other countries.

Vol 7 No 6 76 AUUGN

"While much of the computer systems industry is experiencing minimal growth, the market

based on UNIX System V is accelerating," said Cassoni.

"We expect this version of UNIX System V, combined with the technological advances of the

Intel 386 microprocessor, to create tremendous growth opportunities for both computer

manufacturers and software vendors," he said.

He added that "the installed base of computers based on UNIX system software grew by about

75 percent in the past year," and that the current installed base is roughly 60 times larger than

when UNIX System V was first introduced in 1983.

AT&T will continue to market UNIX System V, and Microsoft will continue to market its

XENIX** operating system during the development of the new product. Applications written

for Microsoft ’s X:ENIX System V and for UNIX System V -- including applications for AT&T’s

PC 6300 PLUS -- will run on the new implementation of the UNIX system without modification.

When the new product becomes available, AT&T and Microsoft will market it as the sole UNIX

system product for the 386.

"Compatibility with existing applications for XENIX: System V and UNIX System V on the

80286 and the 80386 means that the new implementation of UNIX System V will be born with a

large existing base of application software," said Bill Gates, Chairman, Microsoft Corporation of

Bellview, Washington.

"Moreover, the establishment of a standard interface combined with the power of the 386 will

attract new application vendors," he said.

¯

"I am convinced that this announcement will clear the way for dramatic growth in the market

for computers based on UNIX System V," Gates said.

** XENIX is a registered trademark of Microsoft Corporation.

AUUGN 77 Vol 7 No 6

The new implementation will provide software developers with a standard application interface

while allowing them the option of using either AT&T or Microsoft software development tools.

Computer manufacturers and software vendors will be offered licenses to distribute products

based on the new implementation.

AT&T’s UNIX System V is a standard portable operating system, available on a wide variety of

machines from PC’s to mainframes. Microsoft is a licensee of UNIX system software and is one

of AT&T’s largest distributors of UNIX system-derived products under its XENIX operating

system.

Microsoft Corporation develops, markets, and supports a wide range of software for business

and professional use, including operating systems, languages, and application programs, as well

as books and hardware for the microcomputer marketplace.

Vol 7 No 6 78 AUUGN

AUUG

Membership Categories

Now that the Australian UNIX systems User’s Group has existed a while, its time thatall members reviewed their membership types, and even more, checked that they are infact still members!

There are 4 membership types, plus a newsletter subscription, any of which might bejust right for you.

The membership categories are:

Institutional MemberOrdinary MemberStudent MemberHonorary Life Member

Institutional memberships are primarily intended for university departments,companies, etc. This is a voting membership (one vote), which receives two copies ofthe newsletter. Institutional members can also delegate 2 representatives to attendAUUG meetings at members rates. AUUG is also keeping track of the licence statusof institutional members. If, at some future date, we are able to offer a software tapedistribution service, this would be available only to institutional members, whoserelevant licences can be verified.

If your institution is not an institutional member, isn’t it about time it became one?

Ordinary memberships are for individuals. This is also a voting membership (onevote), which receives a single copy of the newsletter. A primary difference fromInstitutional Membership is that the benefits of Ordinary Membership apply to thenamed member only. That is, only the member can obtain discounts on attendance atAUUG meetings, etc, sending a representative isn’t permitted.

Are you an AUUG member?

Student Memberships are for full time students at recognised academic institutions.This is a non voting membership which receives a single copy of the newsletter.Otherwise the benefits are as for Ordinary Members.

Honorary Life Memberships are a category that isn’t relevant yet. This membershipyou can’t apply for, you must be elected to it. What’s more, you must have been amember for at least 5 years before being elected. Since AUUG is only just over 2years old, there is no-one eligible for this membership category yet.

Its also possible to subscribe to the newsletter without being an AUUG member. Thissaves you nothing financially, that is, the subscription price is the same as themembership dues. However, it might be appropriate for libraries, etc, which simplywant copies of AUUGN to help fill their shelves, and have no actual interest in theAUUGN 79 Vol 7 No 6

contents, or the association.

Subscriptions are also available to members who have a need for more copies ofAUUGN than their membership provides.

To find out if you are currently really an AUUG member, examine the mailing labelof this AUUGN. In the lower right comer you will find information about yourcurrent membership status. The first letter is your membership type code, N forregular members, S for students, and I for institutions. Then follows your membershipexpiration date, in the format exp=MM/YY. The remaining information is for internaluse.

If your membership has already expired, or is about to expire (many expire in January)then now is the time to renew.

If you want to join AUUG, or renew your membership, you will find forms in thisissue of AUUGN. Send the appropriate form (with remittance) to the addressindicated on it, and your membership will (re-)commence.

Robert Elz

AUUG Secretary.

Vol 7 No 6 80 AUUGN

AApplication for Ordinary, or Student, Membership

Australian UNIX systems Users’ Group.*UNIX is a registered trademark of AT&T in the USA and other countries.

To apply for membership of the AUUG, complete this form, and return it with payment inAustralian Dollars to:

AUUG Membership SecretaryP O Box 366Kensington NSW 2033Australia

Please don’t send purchase orders -- perhaps your purchasing department will consider this form an invoice.Foreign applicants please send a bank draft drawn on an Australian bank, and remember to select eithersurface or air mail.

I, .................................................................................................do hereby apply for

r---I Renewal (indicate which membership type).

I---I Membership of the AUUG

I---] Student Membership of the AUUG

[~ International Surface Mail

I--I International Air Mail

Total remitted

$ 50.00

$ 3o.0o$10.00$ 50.00

(note certification on other side)

AUD$(cheque, money order)

I agree that this membership will be subject to the rules and by-laws of the AUUG as in force from time totime~ and that this membership will run for 12 consecutive months commencing on the first day of themonth following that during which this application is processed.I understand that membership includes a subscription to the AUUG newsletter, and that I will be entitled toattend AUUG sponsored functions at member rates for the duration of my membership.

Date: / / Signed"I---] Tick this box if you wish your name & address withheld from mailing lists made available to vendors.

For our mailing database - please type or print clearly:

Name: ................................................................ Phone: ...................................................(bh)

Address: ................................................................ ................................................... (ah)

Net Address: ...................................................

Write "Unchanged" if details have not

altered and this is a renewal.

AUUGN 81 Vol 7 No 6

Student Member Certification (to be completed by a member of the academic staff)

I, ...............................................................................................................................certify that

........................................................................................................................................... (name)

is a full time student at .............................................................................................(institution)

and is expected to graduate approximately _.._._J. _/. .

Title: ....................................................................Signature: ....................................

Office use only:

Chq: bank

Date: / /

Who:

bsb

$

- a/c #

Memb#

Vol 7 No 6 82 AUUGN

A GApplication for institutional MembershipAustralian UNIX systems Users’ Group.

*UNIX is a registered trademark of AT&T in the USA and other countries.

To apply for institutional membership of the AUUG, complete this form, and return itwith payment in Australian Dollars to:

AUUG Membership SecretaryP O Box 366Kensington NSW 2033Australia

Foreign applicants please send a bank draft drawn on an Australian bank, and remember to select eithersurface or air mail.

................................................................................................ does hereby apply forI--1 Renewal of existing Institutional Membership

I---I New Institutional Membership of the AUUG

[-] International Surface Mail

I---] International Air Mail

Total remitted

$250.00

$25o.o0$ 20.o0$1oo.oo

AUD$.(cheque, money order)

I agree that this membership will be subject to the rules and by-laws of the AUUG as in force from time totime, and that this membership will run for 12 consecutive months commencing on the first day of themonth following that during which this application is processed.I understand that I will receive two copies of the AUUG newsletter, and may send 2 representatives toAUUG sponsored events at member rates, though I will have only one vote in AUUG elections, and otherballots as required.

Date: / / Signed:

Title:I--i Tick this box if you wish your name & address withheld from mailing lists made available to vendors.

For our mailing database - please type or print clearly:

Administrative contact, and formal representative:

Name: ................................................................

Address: ................................................................

Phone: ...................................................(bh)

................................................... (ah)

Net Address: ...................................................

Write "Unchanged" if details have not

altered and this is a renewal.

Please complete the other side.

AUUGN 83 Vol 7 No 6

Please send newsletters to the following addresses:

Name: ......................................................................................................................................Address: ......................................................................................................................................

Name: ......................................................................................................................................Address: ......................................................................................................................................

¯,, ** **** ,***** ****** **** ** ,, ** ~*** ************************ **** ~, ,~** *** ~** ~, ** **** ** ******

¯**** ****** ****** ********** ** ******** ************ ** ** ** **** ** **** **** ************** ** **

Write "unchanged" if this is a renewal, and details are not to be altered.

Please indicate which Unix licences you hold, and include copies of the title and signature pages of each, ifthese have not been sent previously.

Note: Recent licences usally revoke earlier ones, please indicate only licences which are current, and indicateany which have been revoked since your last membership form was submitted.

Note: Most binary licensees will have a System III or System V (of one variant or another) binary licence,even if the system supplied by your vendor is based upon V7 or 4BSD. There is no such thing as a BSD

binary licence, and V7 binary licences were very rare, and expensive.

[’~ System V.3 source ~-] System V.3 binary

[---] System V.2 source ~ System V.2 binary

[--] System V source [-] System V binary

[--] System III source [--] System III binary

1--] 4.2 or 4.3 BSD source

[---] 4.1 BSD source

[-] V7 source

[--] Other (Indicate which) ...............................................................................................................................

Office use only:Chq: bank bsbDate: / / $Who:

- a/c #

Memb#

Vol 7 No 6 84 AUUGN

A UGApplication for Newsletter SubscriptionAustralian UNIX systems User Group.

UNIX Is a registered trademark of AT&T In the USA and other countries.

Non members who wish to apply for a subscription to the Australian UNIX systems UserGroup Newsletter, or members who desire additional subscriptions, should complete thisform and return it to:

AUUG Membership SecretaryP O Box 366Kensington NSW 2033Australia

Please don’t send purchase orders -- perhaps your purchasing department will consider this form an invoice.Foreign applicants please send a bank draft drawn on an Australian bank, and remember to select eithersurface or air mail.

Please enter / renew my subscription for the Australian UNIX systems User GroupNewsletter, as follows:

Name: .................................................... Phone: .......................................... (bh)

Address: .............................................................................................. (ah)

Net Address: ..........................................

Write "Unchanged" if address has

not altered and this is a renewal.

For each copy requested, I enclose:

[--] Subscription to AUUGN

International Surface Mail

International Air Mail

Copies requested

Total remitted

$ 50.00

$ ~o.oo

$ 5o.o0

AUD$(cheque, money order)

Tick this box if you wish your name & address withheld from mailing lists made available to vendors.

Office use only:

Chq: bank

Date: / /

Who:

bsb

$

a/c #

Subscr#

AUUGN 85 Vol 7 No 6

AUUGNotification of Change of Address

Australian UNIX systems Users’ Group.*UNIX is a registered trademark of AT&T In the USA and other countries.

If you have changed your mailing address, please complete this form, and return it to:

AUUG Membership SecretaryP O Box 366Kensington NSW 2033Australia

Please allow at least 4 weeks for the change of address to take effect.

Old address (or attach a mailing label)

Name: ........................................................................

Address: ........................................................................

Phone: .........................................................(bh)

......................................................... (a~)

Net Address: .........................................................

New address (leave unaltered details blank)

Name: ........................................................................

Address: ........................................................................

Phone: .........................................................(bh)

......................................................... (ah)

Net Address: .........................................................

Office use only:

Date: / /

Who: Memb#

Vol 7 No 6 86 AUUGN