auug 1990 - preterhuman.net

ISSN 1035-7521

Australian UNIX systems UserGroupNewsletter

Volume 11, Number 4

December 1990

AUUG 1990AGM Reports

Registered by Australia Post, Publication Number NBG6524

The Australian UNIX* systems User Group Newsletter

Volume 11 Number 4

December 1990

CONTENTS

AUUG General Information ........................... 3

Editorial ................................. 4

AUUG Institutional Members ........................ 6

AUUG Incorporated1990 Annual General Meeting ................ : ..... 9

AUUG President’s Report ........................ 11

Secretary’s Report 1989/90 ........................ 12

Treasurer’s/Auditor’s Report 1990 ..................... 15

AUUG Election Report 1990 ....................... 24

From the ;login: Newsletter- Volume 15 Number 3 ..............25

Book Review: Life With UNIX - A Guide For Everyone ..........25

Report on ISOflEEE JTC1/SC22/WG15Rapporteur Group on Internationalization Meeting ..........26

International Standardization ..................... 30

An Update on UNIX and C Standards Activity ..............34

From the EUUG Newsletter- Volume 10 Number 2 ..............64

Call Doc Strange .......................... 64

AT&T Column ........................... 69 .

!%@:: A Directory to Electronic Mail Addressing and Networks,Second Edition, 1990 .................... 72

Puzzle Corner ......................... 73

A New Data Encoding Scheme .................. 75

Rules of AUUG Incorporated ....................... 77

AUUGN Back Issues ........................... 86

AUUG Membership Categories ...................... 88

AUUGN 1 Vol 11 No 4

AUUG Forms. ............................. 89

Copyright © 1990 AUUG Incorporated. All rights reserved.

AUUGN is the journal of the Australian UNIX* systems User Group (AUUG Incorporated).

Copying without fee is permitted provided that copies are made without modification, andare not made or distributed for commercial advantage. Credit to AUUGN and the authormust be given. Abstracting with credit is permitted. No other reproduction is permittedwithout proior written consent of AUUG Incorporated.

*UNIX is a trademark of AT&T in the USA and other counties.

Vol 11 No 4 2 AUUGN

AUUG General Information

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

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

The AUUG Membership Secretary Phone: (02) 361 5994P.O. Box 366 Fax: (02) 332 4066Kensington, N.S.W. 2033AUSTRALIA

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

The AUUG SecretaryP.O. Box 366Kensington, N.S.W. 2033AUSTRALIA

Phone: (02) 361 5994Fax: (02) 332 4066

¯ Email: [email protected]

AUUG Executive

President Greg Rose Vice President

gre g@ softway.sw.oz.auSoftway Pty LtdNew South Wales

Secretary Peter Barnes Treasurer

[email protected] ScienceUniversity of Queensland

Committee Frank Crawford

[email protected]. Tours Pry LtdNew South Wales

Chris [email protected] Pty LtdNew South Wales

Stephen [email protected] Lane Computer Services Pty LtdVictoria

Pat Duffy

[email protected] Australia Pry LtdNew South Wales

Michael [email protected] LimitedVictoria

Andrew Gollan

adj g @ softw ay.sw.o z.a uSoftway Pty LtdNew South Wales

Scott [email protected] Information TechnologyNew South Wales

Next AUUG MeetingThe AUUG’91 Conference and Exhibition will be held from the 24th to the 27th of September, 1991, at DarlingHarbour, Sydney. The AGM of AUUG Inc. will be held during the conference.

The AUUG’92 Conference and Exhibition will be held from the 8th to the llth of September, 1992, at theWorld Congress Centre, Melbourne.

AUUGN 3 Vol 11 No 4

Editorial

Due to the fact that I have been unable to devote as much time to the job of editing AUUG as I would haveliked, and also due to the fact that I have not received many articles, this will be the last issue of AUUGN for1990.

This is the administrative issue of the year. In this issue you will find the minutes of the AUUG IncorporatedAnnual General Meeting, as well as reports from the previous year’s office bearers that were presented at theAGM. These minutes will be confirmed at the next AGM, to be held during the AUUG’91 at Darling Harbour,Sydney, from September 24th to 27th, 1991.The AGM is the best opportunity there is for the membership to influence the course of the committee. Thecurrent committee is committed to improving the benefits of membership of AUUG, but it needs to know whatit is that the membership wants. The AGM gives you the chance to tell the committee directly, although thereare other means available: have you considered writing a letter to AUUGN?Also in this issue you will find the up-to-date Rules of AUUG Incorporated. These rules were changed by thereferendum held last May, and they are published here for the information of members.One final thing; I would like to extend thanks on behalf of myself and AUUG Incorporated to MichaelLawrence and Webster Computer Corporation. The previous editor of AUUGN, John Carey, was working atWebster, and after he left Webster and I took over editorship it has taken nearly two years to correct the addressof the AUUGN Editor in various international mailing lists. In this time Michael has forwarded.mail onto me,for which I thank him greatly.

AUUGN CorrespondenceAll correspondence regarding the AUUGN should be addressed to:-

David PurdueAUUGN EditorPO Box 366Kensington, NSW, 2033AUSTRALIA

Email:

Phone:

Fax~

[email protected]

+61 3 353 3913 (w)+61 3 813 1258 (h)+61 3 353 2987

ContributionsThis Newsletter is published approximately every two months. The deadline for contributions for the next issueis Friday the 1st of March 1991.

Contributions should be sent to the Editor at the above address.I prefer documents to be e-mailed to me, or mailed to me on a floppy disk (IBM-PC 5-1/4 inch or 720K 3-1/2inch; or Macintosh 3-1/2 inch), and in plain text format. Hardcopy submissions should be on A4 with 30 mmleft at the top and bottom so that the AUUGN footers can be pasted on to the page. Small page numbers printedin 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. Advertising rates are $300 for the first A4 page, $250 for a second page, and$750 for the back cover. There is a 20% discount for bulk ordering (i.e., when you pay for three issues or morein advance). Contact the editor for details.

Vol 11 No 4 4 AUUGN

Mailing ListsFor the purchase of the AUUG mailing list, please contact the AUUG secretariat, phone (02) 361 5994, fax (02)332 4066.

Back IssuesVarious back issues of the AUUGN are available, details are printed at the end of this issue.

AcknowledgementsThis Newsletter was produced with the kind assistance of and on equipment provided by the Advanced ImagingSystems department of Kodak (Australasia) Pty Ltd. I would also like to thank Labtam Australia for providingme with a network connection.

DisclaimerOpinions expressed by authors and reviewers are not necessarily those of AUUG Incorporated, its Newsletteror its editorial committee.

AUUGN 5 Vol 11 No 4

AUUG Institutional Members

Amdahl Corporation

Australian Nuclear Science andTechnology Organisation

Department of Industrial Relations &Employment

Department of Transport, Queensland

B.H.R Information TechnologyNewcastle Region

Department of Treasury and Finance,Tasmania

BHP Melbourne Research Labs

Basser Department of ComputerScience

Digital Equipment Corporation;(Australia) Pty. Limited

ERIN, Bureau of Flora and Fauna

Bureau of Meteorology Epson Australia Pty Ltd

Bureau of Vocational, FurtherEducation and Training

Bums Philp Plumbing Supplies Group

Centre for Information Tech & Comms

Classified Computers Pty Ltd

Co-Cam Computer Group

Commonwealth Department ofPrimary Industries andEnergy

Comperex (NSW) Pty Ltd

Computer Software Packages

Crane Enfield Metals Pty Ltd

Data General Australia Pty Ltd

Deakin University

Exicom Australia Pty Ltd

Fremantle Port Authority

Geelong and District Water Board

Genasys II Pty Ltd

Hamersley Iron Pty Ltd

Harris & Sutherland Pty Ltd

Honeywell Software Centre

IBM Australia Limited

IPS Radio and Space Services

Information Systems Branch

Kodak (Australasia) Pty Ltd

L. M. Ericsson Pty Ltd

Macquarie University

Vol 11 No 4 6 AUUGN

AUUG Institutional Members

OPSM Telecom Business Services

Pact International

Port of Melbourne Authority

Queensland Education Department

Telecom Information TechnologyGroup

The Far North Queensland ElectricityBoard

Queensland Justice Department

SEQEB

Shire of Eltham

Silicon Graphics Computer Systems

Softway Pty Ltd

South Australian Institute ofTechnology

Sphere Systems Pty Ltd

Stallion Technologies Pty Ltd

Stamp Duties Office Victoria

Steedman Science and Engineering

Sugar Research Institute

Tandem Computers Pty Ltd

Tasmania Bank

Tattersall Sweep Consultation

Tech Pacific

Technical Software Services P/L

The Logic Group

The Mathematics and ComputingDepartment- BCAE (KelvinGrove Campus)

The University of Melbourne(Information TechnologyServices)

The University of New South Wales

The University of Wollongong

Tusc Computer Systems

University College of CentralQueensland

University Computing Services

University of New England

Vicomp

Wacher Pty Ltd

WordPerfect Pacific P/L

Yartout Pty Ltd

AUUGN 7 Vol 11 No 4

NOW

dge S

SL-GMS...the complete tool for application graphics.The Graphical Modelling System from SL Corporation is the only complete application graphics tool for

UNIX and VMS workstations, including 386-based UNIX platforms.

Draw new graphical objects. Connect easily to data sourcesAnimate to visualise real-time data. Use to control the application

Standard widgets are not enough:With the rise of graphics workstations has come ademand for 1~6ols that speed the development ofgraphics screens for applications. A bewildering ar-ray of tools has appeared to aid developers with XWindows and primary GUI styles: MOTIF, OpenLook and DECwindows. Many of these tools areWYSIWYG editorslimit~l to the crea-tion of standard wid-gets such as menus,scroll boxes, slidersand buttons. Stan-dard widgets, how-ever, are not enoughfor application visu-alisation, inevitably,the need arises forcustom screen objects (graphs, maps, icons andother picture.s) which are beyond such tools, andwhich are too time-consuming to create with Xlib.Developers also need a way to visualise changingdata in real time.

A complete graphics toolmust provide:A Powerful Drawing Tool - The ability to createcustom screen objects. Not limited to cannedgraph types, this flexible tool withmany CAD features and an inter-face like familiar PC drawing toolsallows you to draw whatever youneed, attach dynamic behavioursand test those behaviours-ali withinthe drawing tool.

Dynamics - The ability of screenobjects to instantly reflect changesin data values, receive user input orexecute callback functions. Overforty attributes such as coiour ortext changes, visibility on/off, per-cent fill, line width, rotation,movement, scaling, font style or size, zooms andwindow creation can be triggered by changes indata values or user input.

Complete Xt Widget Integration - SL-GMSgraphics can fully incorporate Xt widgets. Screenobjects created with SL-GMS fully interact withMOTIF, Open Look, DECwindows or other toolkitwidgets, whether in the same or different windows.

GISMOs - Graphical Interactive Screen Manage-__, ment Objects are called GISMOs to distinguish

them from Xt widgets. Fully interactive with Xtwidgets, GISMOs can take any appearance youwish and trigger any user-defined function or ex-ternal program. Created with the drawing tool,GISMOs provide developers with tremendous de-sign flexibility.

HyperCard-like Screen Management - Afterscreens have been created, the user must be able tobutton from any screen to any other screen ira, theapplication. With the screen management System(SMS) included in SL-GMS, the developer cangive the user this ability without writing a line ofcode. SMS can bring up new screens with datasources attached and dynamics up and running.

Data Source Management - The ability to con-nect screen objects to data sources such as files,databases, expert systems and real-time feeds.Withthe Data Source Manager of SL-GMS, these con-nections are easily made.

Runtlme Editors and Con-figurators - The ability of theenduser to customise or recon-figure screens to match thecurrent environment.

Cross-Platform Portability -The ability to develop screenson any major workstation andrun them on any otherthrough simple ASCII filetransfer. SL-GMS also sup-ports PixWin, Iris GL, GKSand other non-X graphics

environments. Versions such as Iris GL take ad-vantage of special accelerator hardware and doublebuffering capability.

SL-GMS is widely used:For real-time or highly interactive applications infields such as manufacturing, process control, net-work management, cockpit display and financialtrading.

::: ::::o :...:...:.-...:.v.........:...: :..... ::" . ,::::::" ..." "" ::"’"":"’ "’"":" :’"::~i:i:i:

i~i ~i~::

~H~! ~.{.~P..:~ .~..~.t..~!~i~i~i!~i!ii~!i~i~!~i~i~i~iiiiiiiiii~i~i~!i~i.~iii~ :.H~I~I ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

:in:: ~6~ ~ h i i~ ~ii::::ii!::~!i::::::::!::i~::ii::i:~i::i!::::::::ii~i:.i!i~:::.!i::~:~i~::::::.i~:iii~

..................................................

Supported Workstations:Sun (PixWin or X), DEC (VMS or ULTRIX), Sili-con Graphics (X or OL), I-IF, Apollo, IBM, andMIFS as well as 386-based work.stations runningUNIX and the X windowing System.

Q.S.S. Pry. Ltd.40 Munibung Rd., Cardiff NSW 2285.PO Box 269, New Lambton 2305.Tel. (049) 546524 Fax. (049) 545132

AUUG ncorporated1990 Annual General Meeting

27th September 1990, World Congress Centre, Melbourne

These minutes are subject to amendment at the next General Meeting.

The meeting opened at 17:45 with the entire committee and a quorum of members present. The President (GregRose) took the Chair.

1 ApologiesNone.

2 Minutes of the last meeting (10th August, 1989)A copy of the minutes of the previous General Meeting, the 1989 AGM, was displayed for all members.

Moved Lawrie Brown, seconded Ken McDonell: That the minutes be accepted. Carded.

3 Business arising from the MinutesNone.

6 President’s ReportThe President, Greg Rose, presented the report as printed in AUUGN Vol 11 No 4. He thanked outgoingcommittee members Tim Roper and John Carey for their efforts. The meeting responded with acclamation.

Moved John Lions, seconded Ken McDonel|: That the President’s report be accepted. Carried.

7 Secretary’s ReportThe Secretary, Peter Barnes, presented the report as printed in AUUGN Vol 11 No 4.

Moved Lawrie Brown, seconded Robert E|z: That the Secretary’s report be accepted. Carried.

8 Treasurer’s ReportThe Treasurer, Michael Tuke, presented the report as printed in AUUGN Vol 11 No 4.

Ken McDonell asked that expenditure on the secretariat be estimated on an annual basis.

Moved David Purdue, seconded Ken McDonell: That the Treasurer’s report be accepted. Carded.

4 Returning Officer’s ReportThe Returning Officer, John O’Brien, presented the report as printed in AUUGN Vol 11 No 4.

Moved Ken McDonell, seconded Tim Segall: That the Returning Officer’s report be accepted. Carried.

AUUGN 9 Vol 11 No 4

5 Approvalof AppointmentsThe President explained that following the Constitutional amendments passed by the referendum, thecommittee had appointed Pat Duffy Vice-President (under Rule 23.(4)), Stephen Prince committee member(under Rule 23.(4)), and Scott Merrilees committee member (under Rule 23.(3)). These appointments now hadto be approved by the General Meeting (under Rule 23.(5)).

Moved Robert Elz, seconded John O’Brien: That the appointment of Pat Duffy as Vice-President beapproved. Carried.

Moved David Purdue, seconded Mark Andrews: That the appointment of Stephen Prince and ScottMerrilees as committee members be approved. Carried.

11 Other Business11.1 The President reported that there had been suggestions that AUUG change its name, and invited comment.All speakers spoke against the name change. Lawrie Brown suggested that we better publicise our charter.Andrew McCrae suggested that we raise our profile by making more press releases. Greg Kable suggested thatwe change our emphasis from UNIX to Open Systems. Tim Roper pointed out that several very successfulConferences and Exhibitions and associated press coverage had established the name AUUG, and that it wouldbe counter-productive to change it.A straw poll indicated overwhelming opposition to the change.

11.2 Scott Merrilees noted that ACSnet (or MHSnet) connection was a topic often raised by members. A surveyof the meeting revealed that about 15% of members were interested in gaining access to the network.

Robert Elz gave a brief history of the Usenix/uunet public access system, and pointed out that a Melbournecompany had already started a similar service.

Bob Kummerfeld noted that MHS was providing a similar service in Sydney for its customers.

A straw poll indicated general interest in the topic, and Scott Colwell and Greg Kable asked that the committeeinvestigate means of obtaining network access for members.

The President closed the meeting at approximately 18:55.

Vol 11 No 4 10 AUUGN

AUUG President’s Report

In the last year...AUUG has held another successful conference. The AUUG’90 Conference and Exhibition is the first that

we have held at the World Congress Centre, and I think that this is the best venue we have ever used. AUUG issure to be back here in two year’s time. AUUG’90 has also been the largest conference we have held to date,with 423 registrations and over 1100 people attending the exhibition.

1989/90 has been another year of growth for AUUG, especially in the area of institutional memberships,although we have not grown as much as figures suggest the UNIX market has grown.

In this year we established the AUUG Book CLub, a working relationship with Prentice-Hall Australia thatallows AUUG members to get a discount on Prentice-Hall books. PH also provide books for review inAUUGN.

In 1990 the Summer Technical Meeting program was finally got off the ground after false starts in previousyears. Meetings were held in Perth, Hobart, Adelaide, Canberra and Sydney. It was originally intended to bringin a visiting speaker from overseas, but when this could not be arranged the meetings went ahead anyway withsome local speakers bing interchanged with several of the meetings, and all were very successful.

The Management Committee has been working to establish closer connections between AUUG and otherinternational bodies with similar aims. In particular we have been seeking closer ties with Uniforum.

All this could not be achieved without the hard work, all volunteer labour, of many people. In particular Iwould like to thank two outgoing members of the Management Committee, Tim Roper and John Carey. Timhas been the AUUG Secretary for the past two years and has worked tirelessly to get the AUUG administrationin order, especially in the areas of getting AUUG incorporated and trying to get secretarial assistance for thecommittee. John was AUUGN Editor for a number of years before taking a seat on the committee, and has beenthe Programme Committee Chair for AUUG’90. His efforts are one of the main reasons this conference hasbeen so successful.

That was the good news.On the down side, I must admit that the administration of AUUG is still a mess, dewspite Tim Roper’s best

efforts. Also., we have failed to add significant new services for members, despite the best of intentions.

Hopefully getting better.After the recent amendments to the rules, AUUG has a larger Management Committee. This hopefully

means we have a larger pool of volunteer labour to draw upon.In the area of secretarial assistance, we are in the process of passing a lot of the day to day running of AUUG

over to ACMS, who already provide management and support services for the conferences. It is hoped thatAUUG can soon find a full-time employee to manage AUUG’s business.

In summary, AUUG is growing and improving, but to continue in this way we need more involvement fromthe rank and file members, whether it be serving on the Management Committee, helping to organise a SummerMeeting, volunteering to help provide a member benefit, or just writing articles for AUUGN.

Greg RoseAUUG President

AUUGN 11 Vol 11 No 4

Secretary’s Report 1989/90

Peter Barnes

Secretary

AUUG Incorporated

1. The Present

1.1. MembershipsMemberships continue to grow rapidly, even though times are austere throughout the Industry. When youconsider that each Institutional membership represents two members, we now have over 700 members.

As can be seen from the figures, Institutional members are growing faster than ordinary members, no doubtreflecting the continuing growth of the UNIX operating system as a commercial platform, and a greaterawareness of the importance of Open Systems (and independent representation) by industry.

Another pleasing change to our membership has been the election of our first Honorary Life Member, ProfessorJohn Lions, a fitting tribute which was bestowed as soon as it was constitutionally possible.

At 21/9/90, membership numbers and approximate growth rates since the last report are:

Class Number % Change

Student 13 +30%

Ordinary 442 +50%

Institutional 131 +87%

Honorary Life 1 + 100%

1.2. Conferences, Tutorials and Exhibition

1.2.1. AUUG ’89

Following the success of AUUG’88, we optimistically predicted a growth of over 30% for AUUG ’89. Growthwas in fact about 25%, with about 400 registrants in total. Nevertheless we are pleased with the result in leantimes. With a probable similar growth this year, we faced a watershed decision in our choice of venue - quitesimply, we have outgrown everything except purpose-built centres like this.

The AUUG ’89 pre-conference tutorials were very well attended, although our inexperience in running such anevent was evident in places. The tutorials seem certain to be a regular event, and we have aimed for muchgreater polish this year.

1.2.2. Summer meetings

Following an extended gestation, the first Summer meetings were held this year right across the country, inPerth, Melbourne, Hobart, Canberra and Sydney. These meetings fill two needs: one created when we movedfrom bi-annual to annual conferences, and the other as a forum for more informal, technical papers. We believethese meetings were successful on both counts, and hope to extend them next year.

1.3. AUUGNThe newsletter has had an uneven time recently, as the editor has struggled with job changes and lack of accessto tools. This highlights the difficulties we face attempting to service a rapidly growing membership with purelyvoluntary labour and loaned resources, and is a problem we must face squarely in the next year.


1.4. Membership benefits

AUUG is pleased to have been able to negotiate two discount schemes for its members: the first with Prentice-Hall, offering a 20% discount on selected titles, and the second with Addison-Wesley, offering a 20% discounton the O’Reilly’s Nutshell series.

Bulk purchases of Usenix Proceedings have continued, making these important documents available tomembers quickly and at low cost.

This year sees the Conference Proceedings published as a serial in their own right, reflecting their quality andimportance, and providing appropriate status for the papers presented.

For Institutional members, we have phased out subscriptions to Computing Systems, and instead are providingcopies of the UniForum Product Directory, easily the most comprehensive and up-to-date document of its kind.

Earlier this year AUUG joined forces with the DMR Group Australia to co-sponsor a comprehensive program,titled "Strategies for Open Systems in Australia". This program is exploring the Australian marketplace, andinvestigating issues related to markets and implementation strategies for Open System. Summaries of resultsfrom this program will be made available to AUUG members.

AUUG is also investigating cooperation with Spectrum ’90, and co-hosted an ACS Professional DevelopmentSeminar in Brisbane this year.

1.g. AUUG Chapters

We were pleased to see three local chapters created in the last year (WAUG, Sesspoole and SWIGS), althoughsome of these bodies had existed informally before then.

Overall, growth in the local chapters has been slower than in AUUG itself, although the success of the Summermeetings will perhaps spur the chapters on to greater activity.

1.6. Growing painsAs well as electing a new committee, the last elections also passed several amendments to our Constitution, allchanges which the Committee felt were necessary as AUUG grows and matures.

Other evidence of this growth is the upgrading of our office system with equipment kindly provided by FujitsuAustralia.

The last, and perhaps most important change is the establishment of a paid secretariat. This is currentlyunderway, and we apologize for the very slow processing of membership details as we attempt to coordinatebetween Brisbane, Melbourne and Sydney. We believe that this marks the start of a new era for AUUG, as ithad become obvious that a voluntary committee, no matter how enthusiastic, could not cope with some of thedaily chores of running a large national organization. The establishment of a secretariat should allow thecommittee much more time to improve and extend member services.

Our address now has a phone and fax number:

AUUG IncorporatedEO. Box 366Kensington NSW 2033Phone ÷61 2 361 5994Fax +61 2 332 4066

2. The FutureLast year my predecessor, Tim Roper, posed a number of questions, only some of which have been answered.Perhaps the most important, that of a paid secretariat,

has been, so now is the time for members to consider what directions AUUG should be taking, and whatservices it should provide.

The rapid growth of commercial UNIX has meant an equally rapid change in AUUG’s membership structure,and provides challenges to you and the committee.

Should we expand and improve the regional programme? How can we be both "Usenix" and "UniForum" inAustralia? Do you, the members, want a greater voice in the current standards processes, or more information


about them? What additional member services and benefits would you like? Should we sink our cash reservesinto a full-time secretariat?

These, and more, are issues on which we would welcome feedback and suggestions.

3. AcknowledgementsMost of the successes in this report are the result of much hard work by the previous Committee and othervolunteers. I would like in particular to thank Tim Roper, who served ably as Secretary during a period of veryrapid change, and whose place on the Committee will be greatly missed. I hope I can do the job half as well ashe.Another person we will miss is John Carey, whom I would like to thank for working hard and unselfishly forAUUG for more years than he probably cares to remember, both on the Committee and as AUUGN editor.

Thanks must also go to Glenn Huxtable, who masterminded the Summer meetings, a nightmare in tele-organization and long-distance cajolery.

Finally,

John Carey also deserves our thanks as Chair of the AUUG ’90 Programme Committee, to whom also ourcollective thanks for what promises to be an excellent conference and exhibition.

Peter BarnesAUUG Secretary


Treasurer’s/Auditor’s Report 1990

A.U.U.G INCORPORATION

PROFIT & LOSS STATEMENT

FOR THE PERIOD IST JUNE 1989

TO 31ST MAY 1990

CONFERENCE AUUG 1989

INCOME

LESS EXPENSESAdvertisingArt WorkBadgesBank ChargesInsuranceLecturer/Tutor FeesParkingPhotocopyingPostagePrinting & Stationery/ PhotocopyingPress ReleaseTravelling / Accomodation / Meals

NET PROFIT /(LOSS)

1990

46018.87

8805.48

3944.42

696.402924.90

8257.90

24629.10

21389.77

1989

12550.41

3579.44247.10

1320.0013.78

877.60

14 00177 6096 8249 00

475 005968 88

12819.22

(268.81)


A. U. U. G . INCORPORATION

PROFIT & LOSS STATEME/TT

FOR THE PERIOD ENDED IST JUNE, 1989 TO 31ST MAY 1990.

CONFERENCE A.U.U.G. 1990.

Income NIL

LESS EXPENSES

AdvertisingPhotocopying & Printing

737.92626.80

1364.72

$1364.72NET LOSS


A.U.U.G. INCORPORATED

PROFIT & LOSS STATEMENT

FOR THE PERIOD IST JUNE 1989 TO 31ST MAY 1990

INCOMEMembershipNutshell HandbooksOpen Look SpecificationUsenix Proceedings

- San Francisco- San Diego- Baltimore

AUUGN / Back IssuesSubscriptionsMailing ListInterest Received

SUMMER 90- Melbourne- Sydney- CanberraSecurity VideoSecurity Pacific National Bank

LESS EXPENSESBANK CHARGES- Credit Card- Government- General

199053190.6019930.15

492.00330.00

4147.111461.005959.505431.13

3873.003149.95

250.00360.00509.24

99083.68

440.76127.26

88.39

656.41

198941145.00

3907.22409.35

1288.00657.00

685.002776.004092.17

54959.74

291.5358.7296.54

446.79

Donations

MANAGEMENT COMMITTEE / MEETING EXPENSES-Airfares- Accomodation / Meals- Parking- Taxis etc.- Registration

4325.50485.70

28.00205.15

44.00

200.00

3331.00355.50

63.55203.10


- Editors Float 200.00

5288.35 3953.15

MEMBERSHIPFreight / PostagePhotocopyingPrintingProduct Directory

856.9616.80

2396.934117.34

7388.03

326.16104.22

430.38

NUTSHELLFreight / PostagePurchase Handbooks

2043.686903.18

8946.86

1502.715347.00

6849.71

USENIXBaltimore Conference 734.63

USENIX PROCEEDINGSSAN FRANCISCO- Postage- Purchase Proceedings

277.05956.32

1233.37

USENIX PROCEEDINGSSAN DIEGO

PostagePurchase Proceedings

192.491735.00

1927.49

OPEN LOOK EXPENSESPhotocopyingPostage / Freight

383.6041.15

424.75

A.U.U.G.N.Postage / FreightPrinting

34~4.8833348.88

36793.76

338.8529921.99

- - -

30260.84


SUMMER 90AdministrationMelbourneSydneyTasmania

2898.703576.623337.20358.00

10170.52

MAILING LISTPhotcopying / Printing,Postage / Freight

667.20

667.20

127.001382.57

1509.57

A.U.U.G. 89FreightPostage of CFP

OFFICEAccountingFreight / postagePetty CashPrinting / StationeryPurchases - Security VideoTrademark Registration

TOTAL OPERATING COSTS

GENERAL A/C NET PROFITA.U.U.G. 89 NET PROFIT / (LOSS)A.U.U.G. 90 (LOSS)

NET PROFIT

1850.001284.51

101.202379.92

468.0025.26

76754.65

22329.0321389.77(1364.72)

42354.08

73.21577.94

651.15

870.75

405.551644.46450.00

51257.96

3701.78(268.81)

3432.97


AUUG INCORPORATED

BALANCE SHEET

AS AT 31ST MAY, 1990.

NOTE 1990 1989

CURRENT ASSETS

CashReceivablesInvestments

(3)(2)(4)

25151.48 27000.406168.50. 1922.55

58552.93 28832.57

TOTAL CURRENT ASSETS 89872.91 57755.52

NON - CURRENT ASSETS

Intangibles 988.10 988.10

988.10 988.10TOTAL NON - CURRENT ASSETS

TOTAL ASSETS 90861.01 58743.62

CURRENT LIABILTIES

creditors and borrowings (5) 0.00 10236.69

TOTAL CURRENT LIABILITIES 0.00 10236.69

ASSOCIATION FUNDS

Accumulated profits 90861.01 48506.93

TOTAL LIABILITIES & CAPITAL 90861.01 58743.62


A.U.U.G. INCORPORATED

NOTES TO AND FORMING PART OF THE ACCOUNTS

FOR THE YEAR ENDED 31ST MAY, 1990.

1 ¯ ACCOUNTING POLICIES

The accounts are prepared in accordance with the historical costconvention. The Accounting policies adopted are consistant withthose of the previous year.

2 . INVESTMENTS

Investments are shown at cost. Capital Gains Tax is not taken intoaccount in determening the investments unless a definite decision tosell has been taken and the related Capital Gains Tax can be reliablyestimated.

Dividends and other distributions from investments are taken to incomeon a receivable basis.

3 o CURRENT DECEIVABLES 1990 1989

TRADE DEBTORS $ $

Membership 1328.00 1080.00Mailing List 1133.50 709.00Video 160.00 -Nut Shell Books 3547.00 -San Diego Proceedings - 90.00Openlook - 43.55

6168.50 1922.55


CURRENT INVESTMENTS

1990 1989

- at costChase AMPC.B.A.

31000.00 12000.0027552.93 16832.57

58552.93 28832.57

5. CURRENT CREDITORS & BORROWINGS

Bank OverdraftSundry Creditors

164.09 164.09- 10072.60

164.09 10236.69

6. MEMBERSHIP FEES

- Individual 27072.00- Institution 25619.60

52691.60 41145.00

No breakdown of figures were supplied for the year ended 31st May, 1989.


AUDITOR’S REPORT

MEMBERS OF A.U.U.G. INCOPORATED

We have audited the financial accounts, namely the Profit & Loss Statement,Balance Sheet and accompanying notes in accordance with Australian auditingstandards.

In our opinion :

(i) the financial statements present fairly the state of the associationsaffairs at 31st May 1990 and the result of its operation for the year thenended: and

(ii) the financial statements have been drawn up in accordance withAustralian accounting standards.

Date : 26th September 1990 Firm : Nicol & NicolCertified PractisingAccountants

Address : 230 York Street, South Melbourne.

STUART C. NICOLPARTNER


AUUG Election Report 1990

The annual election of office bearers was conducted in June. The Returning Officer was instructed by theSecretary, Mr. Tim Roper, that in the course of conducting the annual election several other ballots were to beconducted. These ballots concerned changes to the constitution rules and a nomination for Life Membership.There were 473 ballot papers mailed out including a report on suggested changes to the constitution.

Apart from a couple of spelling errors which slipped through, the election was carried out with little difficulty.The Assistant Returning Officer, Mr. David Purdue, came to Sydney the weekend following the closing ofballots and we counted all the formal votes.

There was an average of 87 formal votes for each ballot. I wonder why people insist on posting informal votes.Several people failed to turn the paper over and complete the reverse side.

The results for officer bears were as follows:

PresidentGreg Rose

Secretary

Peter Barnes

Treasurer

Michael Tuke

General CommitteeFrank Crawford

Pat Duffy

Andrew GollanChris Maltby

Returning Officer

John O’Brien

Assistant Returning Officer

David Purdue

The management committee proposed a number of changes to the rules of incorporation. These changes weregrouped according to their functionality. To assist with the description of the changes, a copy of the proposedrules were enclosed with the ballot paper. All the proposed changes were passed by more than the requiredmajority. The changes included: alteration to the AIMS, setting of fees, calling of meetings, expansion of theManagement Committee, the introduction of a new Off~ce Bearer and changes to the voting procedure.

This was the first time a member has been nominated for the position of Honorary Life Member. Dr. John Lions,who has been an ordinary member for more than five years, was nominated for the position of Honorary LifeMember following a petition to the management committee. Dr. Lions was elected as AUUG’s first HonoraryLife Member as a result of receiving the required majority of ballots cast.

John O’BrienReturning Officer


;login: 15:3

Book Review

Life with UNIX- A Guide ForEveryoneDon Libes & Sandy Ressler(Prentice-Hall, 1989, 346 pages,ISBN 0-13-536657-7)

Reviewed by Douglas A. [email protected]

This book should answer the vast majorityof questions that a thoughtful user of theUNIX operating system is bound to have con-cerning aspects of UNIX that are not addressedby reference manuals and "how to" tutorials.This is important information, since UNIX isnot only an operating system but also aphilosophy of computing, a set of traditions,an active subculture, and a major marketforce. Most of the material in Life with UNIXis not readily available from other sources,making this an essential reference volume for awell-rounded UNIX library.

Written in an informal style, Life withUNIX tells you everything you ever wanted toknow about UNIX and even things you didn’tknow you should ask about, among them:UNIX evolution and politics of its develop-ment; versions of UNIX and portability issues;UNIX licensing and the UNIX-based systemsmarket; standards, changing technologies, andthe future of UNIX; sources of printed infor-mation; tools and the use of the shell environ-ment; C, system programming, and program-ming support tools; system administration andsystem (in)security; Usenet, public-domainsoftware, and games; benchmarking, consult-ing, mailing lists, validation, and typesettingservices; UNIX applications; and databases,emulators, internationalization, networks,parallel processing, real-time processing, andworkstations. Also useful are the listings ofconferences, workshops, courses, and usergroups.

This guide includes a "Who’s Who" listingof significant names in the UNIX community,brief reviews of UNIX-related books andperiodicals, addresses for numerous organiza-tions, and an excellent comprehensive indexthat helps locate answers to such vexing ques-tions as "What is the NUXI problem, any-way?" There are also many items that readersmay find entertaining. These include quota-tions, anecdotes, and descriptions of some ofthe ways the UNIX community has fun, suchas the P1003 WeirdNIX competition and theannual International Obfuscated C CodeContest.

Life with UNIX is quite an accomplish-ment. I noticed only two nontrivial flaws: Itis riddled with minor inaccuracies, roughly oneper page. While these do not detract from itsuse as a significant source of informationabout the UNIX phenomenon, they do renderit unsuitable as a primary reference source andfor settling "bar bets." I also feel that itsattempts to foretell the future, especially itspronouncements about "the way things shouldbe," do not measure up to the quality of therest of the book. For instance, the authorsspeak approvingly of interfaces like the Macin-tosh Finder replacing the traditional UNIXshell, presumably as one step toward turningcomputers into appliances. Improved userinterfaces are undoubtedly possible, but theFinder is not sufficiently "programmerfriendly." What made UNIX great was that itwas designed by skilled programmers for useby them, e.g., enabling programs to supportfurther programs, thereby obtaining tremen-dous leverage.

This book should be a prerequisite forposting questions to the Usenet newsgroupcomp.unix.questions, because it answers nearlyall the obvious questions about UNIX.


;login: 15:3

Report on ISO/IEEE JTC1/SC22/WGI5Rapporteur Group on Internationalization Meeting

March 5-7, 1990, Copenhagen, DenmarkDominic Dunlop, The Standard Answer Ltd., [email protected]

Denmark. A small country which has taxrates so high that its five million inhabitantscomplain that, when they buy themselves acar, they have to buy one and a half cars t~orthe government. Some part of that tax goes tofund Dansk Standardiseringraad (DS), the na-tional standards body, which works hard to en-sure that the needs of Danes are not over-looked when larger nations get together towrite standards. DS has got its teeth intointernational standards for computers, andwith good reason: we’ve been doing thingswrong all along. We’ll have to mend our waysif we are to produce standards which really fillinternational needs, even if we don’t go as faras building in a framework which can easilyaccommodate Danish taxation.

Metropolitan Chicago today has a popula-tion larger than that of Denmark. Imaginethat you’ve just rebuilt the downtown areaafter the fire of 1871, only to have AlexanderGraham Bell come along with the telephone,Edison deciding to generate electricity, andrailroad companies starting to promote inter-urban lines. All these innovations need newinfrastructure - cables and conduits and tun-nels which you just hadn’t known you’d needwhen you laid the roads, put up the buildings,and connected them to gas, water anddrainage. As a result, competing telephoneand electric companies string a tangle of wiresfrom poles with little regard to safety and noregard for aesthetics or standardization, whileelevated railways appear above existing roads,cutting off light at street level and filling upperfloor rooms with smoke,l Only after many

1. In 1887, the West Chicago Protective League com-plained "... the proposed elevated road would materiallyand irreparably depreciate the value of real estate uponsaid streets.., and render the dwellinghouses thereon unfitfor private residences .... ,,t~l but amid the kind of politicalmaneuverings for which the city is justly famous, the "El"got built anyway.

years of disruption, digging up streets andmaking holes in the walls of existing buildingswould telephones, electricity and publictransportation be safely hi~den beneath theground,2 unseen, but playing an essential partin supporting the life of the city.

A descendant of Alexander Graham Bell’stelephone company now supports the UNIXoperating system out of Chicago. UNIX is alot like the Chicago of the last century. We’reat the stage of unifying the major variants inthe POSIX standards and the commercialSystem V, release 4, only to find that there isan increasing clamor for whole new infrastruc-tures to support international needs, to im-prove security, and to show that the system isperforming as billed. Suddenly, we’ve got toadd features to handle these requirements, andwe’ve got to try to do it while observing thethree conflicting maxims of standardization:do it once, do it right, and do it now. What’smore, we have to try to do it in a way whichremains hidden: existing programs should notbreak, nor should they get noticeably bigger orslower.

POSIX is not alone: those responsible forcomputer language standards face the sameproblems, and have also been the subject ~ofconstructive Danish criticism.[2’31 The Danes’long-standing interest makes it particularlyappropriate that the first meeting of the ISOPOSIX working group’s special interest groupon internationalization should be hosted by DSin Copenhagen. Internationalization is theprocess of removing cultural bias from asystem, and then providing tools to allowsystem administrators, to localize the system byadding a cultural bias of their own choosing.No wonder Dansk Standardiseringraad is in-terested in this technology: its employees

2. Well, in the case of Chicago, some of the publictransportation. You can still ride the El.


;login: 15:3

court a syntax error every time they type its....name at the UNIX shell.3 Internationalizationwill allow Danes to mold systems to their re-quirements, rather than having to rub alongwith implementation assumptions based onAmerican practice.

The Japanese are interested too: their cul-tural differences make Denmark look closeenough to the U.S.A. to be a fifty- first state!And the U.S.A. is interested because it hasbeen charged by ISO with the production ofANSI standards base documents for the inter-national POSIX standards, and wants them toreflect international needs. Denmark, Japan,and the U.S.A. sent representatives to theinternationalization meeting. There were alsoobservers from EUUG/USENIX (myself), theIEEE’s 1003.0 working group, and from an ISOstudy group which is grappling with the issuesof character set use in computer languages.

The official title of the POSIX internation-alization group is the ISO/IEEEJTC1/SC22/WG15 Rapporteur Group on Inter-nationalization. Just to explore some of thejargon, a rapporteur is a technical expertnominated by a member body - a nationalstandards organization such as ANSI or DS -to take an interest in a specialized aspect of aparticular standards effort. WG15, the ISOPOSIX working group, has rapporteur groupson security, conformance testing, and interna-tionalization. The security group met in Janu-ary, in conjunction with the New Orleansmeeting of the IEEE 1003.4 working group; theconformance test group, which corresponds tothe IEEE 1003.3 effort, met in Copenhagenalong with the internationalization group(although this report does not cover its meet-ing).

Internationalization is peculiar in that,although the IEEE’s POSIX standards aredrafted with international needs in mind, thereis no internationalization working groupwithin the POSIX project. There is a study

3. ISO 646,141 the earliest ISO standard for informationtechnology, is the international derivative of ASCII. ItsDanish variant replaces ASCII’s ) with aa. Around theworld,"#$~ [] "’(I)-, all of which have a special meaningto the shell, are replaced by other characters in standardsderived from ISO 646. See ts! for much more information.

group which, as part of the 1003.0 "POSIXGuide" work, is trying to decide how to bringinternationalization into the official structure,so that it can be given officers, schedules,terms of reference, and all those other goodthings which make us standards people feelsafer. It’s a big problem, because the issuereally affects every aspect of POSIX - it justtook a while to realize that it was an issue atall. Unlike realtime extensions, security exten-sions, or transparent remote file access forPOSIX, internationalization doesn’t reallymake sense as an add-on to a basic operatingsystem interface standard. Rather, the operat-ing system and all its extensions need to beinternationalized as a matter of course. Everyother working group in the IEEE POSIX ischarged with producing a distinct standard,but it is difficult to see how a new group deal-ing with internationalization could be givensuch a goal.

ISO has a similar problem, but it’s worsebecause the organization has so many. balls tokeep in the air. If it is to apply the "do itonce" and "do it right" maxims to internation-alization, it seems clear that the issue must behandled near the top of Joint Technical Com-mittee 1, the information technology standardsgroup. After all, as well as computer languagesand operating systems, internationalizationaffects communications, document standards,database, and much more. ISO recently bit asimilar bullet, establishing a new subcom-mittee (SC27) immediately below JTC1 to han-dle the security issues which are beginning toaffect so much of its work. It may yet do thesame with internationalization.

The "do it now" criterion, on the otherhand, argues in favor of addressing interna-tionalization at a lower level - doing the workin a new department, rather than going to thetrouble of establishing a whole new division.SC22, which is responsible for language andoperating system standards, is currently con-sidering the formation of a new working groupat the same level as WG15 (C language), WG15(POSIX), and the rest. This proposal has runinto opposition, both from those who say thatthe issue should be handled at a higher level,and from those who feel that there isn’t an


;login: 15:3

issue: after all, aren’t ISO’s standards sup-posed to be international anyway?

Meanwhile, WG15 has established asubordinate group to handle internationaliza-tion at the lowest level possible. As somebodysaid at the meeting, "You can’t get muchlower than us." We spent our time discussingwhat we. were supposed to be doing - and,equally important, what we could leave to oth-ers. In the end we came up with a little list:

Terms of Reference

The rapporteur group on internationalization (RIN)will study the aspects of internationalization relatedto POSIX and report its findings to SC22/WG15.

(Bland. imposing no needless restrictions on what wecan do.)

Program of Work

1. Carry out survey to capture most of the re-quirements relevant to internationalization.

(A job and a half We have to search out usersaround the world, and persuade them to tell us whatfeatures the.v really want, rather than what they canput up with, or program their way around.4)

2. Identify and forward requirements with recom-mendations to WG 15.

(So WGI5 gets to carry the can for us...)

3. Capture and collect national body profiles forreference.(Denmark and Japan have alread.v done some workon "profiles" that customize POSIX to suit localneeds. Their work suggests that current internation-alization features are inadequate.)

4. Perform investigations as needed to advancethe internationalization work of WG15.

(We can poke our noses into anything that takes ourfancy...)

5. Review, from an internationalization perspec-tive, documents submitted to WGI5 for review andcomment from an internationalization perspective.

(IJ’e de./initely get to poke our noses into anythingthat comes past ~’GI5...)

4. But we need to be a lot more diplomatic than asking"’Whal ticks you off most about these dumb Americanmachines’?" - although appeals to chauvinism have beenknown to achieve results...

6. Review, and evaluate impact on work of WGI5of, other documents relevant to internationalizationcirculated in JTC 1 or its subcommittees.(And we’ll try to get our hands on information fromfurther afield.)

That’s a lot of work. It defines the func-tion of our particular mill, but that mill stillneeds grist. That feedstock has to come fromoutside our group, and, because of our lowlyposition, we have to ask WG15 to ask others tosupply it. WG15, in turn, may have to refersome requests to higher authority: we want tobe aware of anything which happens in SC22which is relevant to POSIX internationalization- for example, what the C language people inWG14 are up to. That involves going upanother level in JTCI’s hierarchy. Getting intouch with other subcommittees, such as SC2,which looks after character sets, potentially in-volves going right to the top of the bureau-cracy. (Luckily, in this particular case, SC22’sstudy group on character sets can stand in forSC2.5) Consequently, when WG15 next meetsin Paris in June, it will have to deal withseveral resolutions concerned with turning onthe taps and starting the information flow tothe rapporteur group.

One of these taps is a little sticky: WG15doesn’t officially have a relationship with theIEEE’s 1003.0 group, although it can, via ANSI,talk to 1003.1, 1003.2, and 1003.4 through,1003.9. The problem is that 1003.0 deals withprofiles, baskets of standards which, whenbrought together, solve particular classes ofproblems - for example, those of transactionprocessing, realtime, or batch-orientedsystems. Profiles are outside the scope of theISO POSIX effort, so we can’t officially talk to1003.0, even though its study group iscurrently holding the baton on internationali-zation. Never mind. We’ll do thingsunofficially until some official pathway issorted out.

5. SC2’s answer to life, the universe and everything is DP(draft proposal) 10646, which defines a 32-bit wide charac-ter set with 8- and 16-bit wide canonical versions forstorage and transmission, and a 24-bit wide processingversion for those who can get by with only eight millioncharacters or so. As it’s still at the DP level, it’ll be a longtime before it hits the streets, and, even when it does,there’s the little matter of getting people to use it...


;login: 15:3

Apart from all this organizational stuff, wedid review some existing documents. For ex-ample, DTR (draft technical report) 10176, aproduct of SC14, discusses the treatment ofcharacters appearing in language constructs,variable names, literals, and comments, andturns out to have implications for sh, awk,yacc, and the other "little languages" definedin DP 9945-2, the forthcoming internationalstandard for the shell and tools. And a docu-ment from SC22’s study group on charactersets suggests that source files should have somemeans of announcing, the character set thatthey’re using. Could this mean typed files orresource forks for POSIX?6 How would wehide that?

The group next meets in Paris in June,just before the WG15 meeting. If you want tocome along, you have to persuade your na-tional standards body firstly that you’re a tech-nical expert on POSIX, and then that theyshould appoint you as internationalization rap-porteur. This may be surprisingly easy - con-siderably simpler, for example, than gettingsomebody to fund your trip. To quote from[81, "...standards committees would be hard-pressed to find people who participate on theirvoluntary committees with purely rational-economic expectations. Standards committeesseem bent on justifying their existences by us-ing hard data to prove that standards are good,yet they persist in using altruistic appeals toattract committee members." If you feel likeresponding to the altruistic appeal of this arti-cle, contact me by electronic mail.

Alternatively, if .you’re a European, youcan remain seated in front ’of your terminaland participate in a news forum on ISO 646and all that: Keld Simonsen of the DanishUNIX Users’ Group has volunteered to initiatea discussion of the European perspective oncharacter sets for POSIX. Denmark may besmall, but it’s certainly making its voice heardon this issue!

References1. Brian J. Cudhay, Destination Loop,

Stephen Green Press/Viking Penguin(1982).

2. P. J. Plauger, Quiet Changes., Part I, The CUsers Journal, vol. 8, no. 2 (February,1990), pp 9-16.

3. Keld Simonsen, A European Representa-tion for ISO C, European UNIX systemsUser Group Newsletter, vol. 9, no. 2(Summer 1989), pp 15-18.

4. ISO 646:1983, Information processing - ISO7-bit code character set for informationinterchange.

5. Keld Simonsen, An extension to the troffcharacter set for Europe, European UNIXsystems User Group Newsletter, vol. 9,no. 2 (Summer 1989), pp 2-14.

6. ANSI X3.159, 1989, ProgrammingLanguage C.

7. P. J. Plauger, Evolution of the C I/OModel, The C Users Journal, vol. 7, no. 6(August, 1989), pp 17-25.

8. Carl F. Cargill, Information TechnologyStandardization: Theory, Process and Or-ganizations, Digital Press (1989).

6. UNIX’s elegant and flavorless files have already taken abeating from X3.159, the ANSI C standard~6~, since otheroperating systems tend to support filing schemes which aremerely tastelessY1


;login: 15:3

International Standardization

An Informal View of the Formal Structuresas they Apply to POSIX InternationalizationDominic Dunlop, [email protected], 1990

This article provides an overview of theway in which the international standards com-munity works, insofar as it affects POSIX andthe incorporation into POSIX of internationali-zation features. I’m not going to describe thetechnology underlying internationalizationother than to say that its aim is to make theoperating system and applications software in-dependent of the user’s spoken language andits representation (character sets, collation, textdirection, and so on). This done, localizationsspecific to each group of users can tailorprograms to their requirements without theneed for expensive and legally-problematichacking of source code. (If you want to knowmore, let me know, and I’ll either expand onthe topic, or give a few pointers.)

Figure. 1 shows the relationship of stan-dards bodies as far as POSIX is concerned.(The picture may look very different for otherstandards efforts, such as Open Systems Inter-connection, but that need not concern ushere.)

All standards must originate somewhere,whether in industry, in a professional associa-tion, in a national standards body, or in aninternational standards body. In the case ofthe POSIX family of standards, the Institute(IEEE) has assumed responsibility for the ini-tial production of the documents. The IEEE isa professional association which is open toqualified engineers, no matter what theirnationality. It has been involved for manyyears in the production of consensus standardsthat is, standards arrived at through a formalprocess which gives ample opportunity for anyinterested party to comment and vote onproposals.

e.g. ECMA ISOflEC JTCl

dr~R in~ern~ion=l ~gh4 of nMion~l

ANSI DIN bodies...

TFormaletmndmrd in

beoorne~ m~ion~l Bt~nd~rd

Acc~edlted body

l IEEE

.~ D~ t~=~o ~nd ocher ,~’

1Figure

"i

According to the standards procedures ofthe IEEE, the main group of interested partiesis its membership, although non-members arealso allowed to participate. Unusually amongstandards bodies, voting on IEEE standards isnominally "one member, one vote." (Moretypical standards bodies vote by corporationor by country.) The exception to the IEEE’sindividual voting scheme is that institutionscan also participate, provided that theyrepresent a broad Constituency, rather than asingle narrow commercial interest. Currentlyrepresented on the POSIX effort are the OpenSoftware Foundation, UniForum, UNIX Inter-national, USENIX, and X/Open. None ofthese is an official standards body, although allare involved in the production of materials onwhich future standards may be based. In somecases, the organizations produce documentswhich look and smell like standards but which,because they are not produced by an open(and slow, and legalistic) consensus process,


;login: 15:3

may well~ show some bias towards the interestsof the originating organization. Knownbroadly as industry standards, these docu-ments appear before consensus standards, andmust subsequently be brought into line if aconsensus standard is to succeed.

As Figure 1 shows, in the hierarchy ofstandards organizations,~the IEE, E is near thebottom. Above it is firstly the national level,then the international. As the IEEE is based inthe U.S.A., it has gained accreditation fromthe U.S. national standards body, .ANSI (theAmerican National Standards Institute). Thismeans that ANSI considers the IEEE competentto produce national standards on behalf ofANSI. Of course, accreditation by ANSI givesrise to an anomaly: the IEEE, through ademocratic process potentially involving aninternational membership, is creating nationalstandards for the U.S.A. I shall return to thisissue later.

ANSI, in turn, is a "member body" ofJoint Technical Committee 1 (JTC1), an inter-national standards body formed jointly by theInternational Organization for Standardization(ISO) and the International ElectrotechnicalCommission (IEC) to handle the standardiza-tion of information technology. ANSI’s role inJTC1 is nominally to represent U.S. interestsin the "one nation, one vote" process by whichinternational standards are ratified. Othermember bodies such as DIN (West Germany),JISC (Japan), and IRISI (Iran), play a similarpart, making sure that no standard conflictswith their own national interests.

Member bodies may sponsor draft stan-dards at the JTC1 level. In the case of POSIX,ANSI is the sponsor. It is the expectation ofthe international standards community that adraft standard sponsored by a nationalmember body in this way is likely to show abias towards the needs and culture of thatmember body, and so may require amendmentand perhaps extension before it is suitable foradoption as an international standard. Cer-tainly, both POSIX and the C language havecome in for criticism at the international levelfor their lack of support for non-Roman al-phabets.

In order to root out and correct any biasor omission in a draft standard sponsored .by aparticular member body, other member bodiesare expected to pore over the proposal, andfeed in changes which reflect their nationalneeds. Obviously, this could take forever:approaching a hundred countries arerepresented on JTC1. Typically, the number ofmember bodies parti.cipating in a particularstandards effort is limited,, and of these fewplay a very active role. In the case of thePOSIX effort, around a dozen member bodiesare circulated with the working group’s paper-work, and of these, perhaps half are regularlyrepresented at its meetings. Even so, by thetime a national standard has progressed to thelevel of becoming a JTC1 draft, it is rather lateto begin making changes - particularly if, as isthe case for POSIX and C, there is a pressingneed for an international standard.

As presented so far, the standards worldis strictly hierarchical: a standard such asPOSIX progresses from an accredited specialinterest group within a country, firstly to na-tional level, and finally to international status.Officially, it is not until the final stage that in-terests outside the originating country get tocomment on it. The process could be mademore efficient if interest groups outside the ori-ginating country had a means of commentingat an earlier stage, but the hierarchy seems topreclude such comment.

Interestingly, there is a "side door" at theinternational level which can be used to short-circuit the normal time-consuming process.The top level of Figure 1 shows an organiza-.tion in liaison with JTC1, the European Com-puter Manufacturers’ Association (ECMA),which has gained the privilege of being al-lowed to propose and comment on standardsat the international level. The process of ob-taining liaison status is both difficult andlengthy, and is open only to international or-ganizations with a valid claim to representinga specific broad area of interest. (BesidesECMA, the World Health Organization andMastercard International are among the sixtyor so bodies in liaison with JTC1.) If themembers of a liaison body can formulate astandard which is useful to them, liaison statusallows that standard to be proposed for


;login: 15:3

adoption as a formal international standard.Since all bodies with such status are them-selves international (or at least regional), suchproposals are likely to satisfy internationalneeds without much need for amendment.(ECMA has sponsored several standards formagnetic media in JTC1; banking interestshave been active in the standardization ofcredit cards.) Indeed, JTC1 has developed a"fast track" approvals mechanism for usewhen member bodies agree that little review isnecessary - although it has to be said that notevery use of the fast track has resulted in astandard being approved.

The strict hierarchy imposed by ISOmakes for easy and obvious management con-trol, but is under some strain. Firstly, whereemerging standards seek to accommodateinternational needs from their first drafting,the late review by national member bodiesprovided by ISO makes for unnecessary delay- delay which could be avoided if nationalbodies had an official means of providing in-put at an earlier stage. Secondly, regionalstandards organizations - most notably CEN,the European Standards Centre - are growingin importance, and do not fit well into ascheme which is set up according to strictlynational guidelines.

These two problems combine to fosterprovincial attitudes on the part of standardsmakers - and politicians - involved withpOSIX both inside and outside the U.S.A.Those inside reason that, since they are creat-ing a U.S. national standard, internationalconsiderations are relatively unimportant, andcan be left for later. Outside the U.S., standar-dizers reckon that it will be so long before theycan mold a U.S.-produced standard to theirown requirements that they might as welldevelop their own, probably ~incompatible,standards to fill their immediate needs. InEurope, a proposal to adopt issue 3 ofX/Open’s Portability Guide (XPG3) as a stan-dard was strongly backed for a while, eventhough XPG3 is not wholly aligned withPOSIX. (On the reasonable grounds that the1003.1 standard had not been approved at thetime of publication. XPG4 will be aligned withPOSIX.) Interestingly, just as the IEEE is seenin Europe as representing U.S. interests,

X/Open is seen by many U.S.-based observersas a European outfit, despite its many U.S.members.

Provincial attitudes among technical peo-ple and their managers outside the U.S.A. ex-acerbate the problems. Although the IEEEmakes some effort to reach this constituencyby holding one of the quarterly working groupmeetings outside U.S. every couple of years,the majority of attendees are always Ameri-cans. Europeans in particular seem, even ifthey have the inclination to attend, to find itdifficult to justify the expense to their manage-ment. The interests of Arab countries and theIndian subcontinent are seldom represented atall. In contrast, delegates from Japan andother Pacific rim countries have been attend-ing meetings in increasing numbers, even whenlengthy and costly travel is involved.

Given the current structure of the inter-national standardization community, is it pos-sible to work within it and yet overcome thetwo problems which face the POSIX effort: thatof obtaining useful international input at anearly stage; and the parallel problem ofpreventing divergence between POSIX andemerging industry, national, and regional stan-dards? Can the current structure accommo-date formal mechanisms which provide forsolutions, or will the problems remain unlessthe structure itself is changed?

Until now, practical international inputto POSIX has come from two sources whichare not a part of the formal hierarchy of inter-national standardization: UniForum andX/Open. As I have already mentioned,X/Open is an international grouping seen bysome as primarily European; its activemembership has to date consisted of computersuppliers. UniForum, which was known as/usr/group until 1989, is a grouping ofhardware suppliers, software authors, value-added resellers, and users. As with X/Openand other groupings, it is the suppliers whichhave played the largest part in the organization- users have seldom made their voice heard.UniForum is U.S.-based, but has affiliatesaround the world. These affiliates are largelyautonomous, and, despite efforts to involvethem, have played almost no part inUniForum’s standards activities - even when


;login: 15:3

these are involved with internationalization.(While UniForum’s Technical Subcommitteeon Internationalization has active participationfrom outside the U.S.A., the people concernedbecame involved directly, rather than throughtheir local UniForum affiliates.) USENIX, theother user grouping with institutional represen-tation to the IEEE POSIX project, has a betterclaim to providing a forum for users, but is al-most exclusively North American, and, unlikeUniForum, has no internal structures con-cerned with standardization. The EuropeanUNIX systems User Group (EUUG) has a trulypan-European membership made up, like thatof USENIX, primarily of computer program-mers and technical users, but has not par-ticipated officially in any standards effort. Itsinvolvement to date has been confined to theco-sponsorship with USENIX of a standardsmonitor service, which provides members withinformation about progress on POSIX and inrelated areas.

It is my view that, if international in-terests are to play a greater part in the draftingof POSIX standards, they must be representedformally within the IEEE. This is not tominimize the importance of the work done byUniForum, but rather to say that an officialstamp of some sort is necessary in order thatits importance receives a wider recognitionboth inside and outside the IEEE. Unlikeother topics handled in the past by UniForum,real-time and transaction processing amongthem, internationalization has never officiallybeen incorporated into the POSIX effortbecause it cannot stand alone. There cannotusefully be such a thing as a standard for inter-nationalization; rather, internationalizationshould be a consideration in the drafting ofany standard for computer software.

The 1003.0 (POSIX Guide) working groupis currently wrestling with the problem of han-dling internationalization issues within POSIX.It may be possible to borrow a useful conceptfrom ISO: that of the rapporteur group. Rap-porteur groups cut across normal boundaries,bringing together those who are interested insome problem or activity which is common toa number of standards projects.

It is over-optimistic to hope that bringinginternationalization officially into the POSIXfold will result in immediate participation bythose who currently wait until documentsreach the ISO level before commenting throughtheir national member bodies. One way toreach this audience might be to convince itthat the IEEE is indeed an international, ratherthan strictly North American, grouping. Aradical way of achieving this would be for theIEEE to seek liaison status with JTC1, so ob-taining a means of submitting base documentsdirectly, instead of through ANSI. To do thiswould involve the IEEE in the considerable ex-pense and logistic complexity of sponsoringstandards - a task for which resources are notcurrently in place in an organization which sel-dom gives the appearance of being over-endowed with resources.

In any event, even if the IEEE were to ap-ply for liaison status tomorrow, it would be along time before it was granted. Unless or un-til this happens, it seems to me that it is theduty of user groups around the world to toencourage their members to play a part in theprocess through the IEEE. So that’s what I’vebeen doing in this article!


;login: 15:3

An Update on UNIX and C Standards Activity

Jeffrey S. HaemerReport Editor, USENIX Standards Watchdog Committee

What the reports are about

Reports are done quarterly, for the USENIX as-sociation, by volunteers from the individualstandards committees. The volunteers arefamiliarly known as "snitches" and the reportsas "snitch reports." The band of snitches andI make up the working committee of theUSENIX Standards Watchdog Committee.The group also has both a financial com-mittee: Alan G. Nemeth, Ellie Young, andKirk McKusick (chair); and a policy com-mittee: the financial committee plus John S.Quarterman (chair). Our job is to let youknow about things going on in the standardsarena that might affect your professional life --either now or down the road a ways.

An official statement from John:

The basic USENIX policy regarding standards is:to attempt to prevent standards

from prohibiting innovation.

To do that, we

¯ Collect and publish contextual and technicalinformation such as the snitch reports that other-wise would be lost in committee minutes or ra-tionale appendices or would not be written down atall.

¯ Encourage appropriate people to get involvedin the standards process.

¯ Hold forums such as Birds of a Feather (BOF)sessions at conferences. We sponsored oneworkshop on standards.

¯ Write and present proposals to standards,bodies in specific areas.

¯ Occasionally sponsor White Papers in particu-larly problematical areas, such as IEEE 1003.7 (in1989).

¯ Very occasionally lobby organizations thatoversee standards bodies regarding new committee,documents, or balloting procedures.

¯ Starting in mid-1989, USENIX and EUUG (theEuropean UNIX systems Users Group) began spon-soring a joint representative to the ISO/IEC JTC1SC22 WG15 (ISO POSIX) standards committee.

There are some things we do not do:

° Form standards committees. It’s the USENIXStandards Watchdog Committee, not the POSIXWatchdog Committee, not part of POSIX, and notlimited to POSIX.

Promote standards.

¯ Endorse standards.

Occasionally we may ask snitches to presentproposals or argue positions on behalf of USENIX.They are not required to do so and cannot do sounless asked by the USENIX Standards WatchdogPolicy Committee.

Snitches mostly report. We also encourage them torecommend actions for USENIX to take.

We don’t yet have active snitches for allthe committees and sometimes have to beatthe bushes for new snitches when old onesretire or can’t make a meeting, but the numberof groups with active snitches continues togrow (as, unfortunately, does the number ofgroups). This quarter, you’ve seen reportsfrom .0, .1, .2, .3, .4, .7, .8, .11, and .12, aswell as reports from 1201 and from X3Jll(not really a New Orleans report, but usefulnone the less).

If you have comments or suggestions, orare interested in snitching for any group,please contact me ([email protected]) or JohnQuarterman ([email protected]). If you want tomake suggestions in person, both of us attendthe POSIX meetings.


;login: 15:3

Reports on the October 1989Meeting in Brussels(continued from ;[ogin." vol. 15, no. 2)

Report on IEEE 1003.2:Shell and tools

Randall Howard <[email protected]> reports onthe October 16-20, 1989 meeting in Brussels,Belgium:

Background on POSIX.2

The POSIX.2 standard deals with the shellprogramming language and utilities.Currently, it is divided into two pieces:

¯ POSIX.2, the base standard, deals with thebasic shell programming language and a set ofutilities requiredfor application portability.Application portability essentially means por-tability of shell scripts and thus excludes mostfeatures that might be considered interactive.In an analogy to the ANSI C standard, thePOSIX.2 shell command language is the coun-terpart of the C programming language, whilethe utilities play, roughly, the role of the Clibrary. POSIX.2 also standardizes command-line and function interfaces related to certainPOSIX.2 utilities (e.g., popen, regular expres-sions, etc.). [Editor’s note -- This document isalso known as "Dot 2 Classic."]

¯ POSIX.2a, the User Portability Extensionor UPE, is a supplement to the base POSIX.2standard; it will eventually be an optionalchapter of a future draft of the base document.The UPE standardizes commands, such asscreen editors, that might not appear in shellscripts but are important enough that usersmust learn them on any real system. It isessentially an interactive standard thatattempts to reduce retraining costs incurred bysystem-to-system variation.

Some utilities have interactive as well as non-interactive features. In such cases, the UPEdefines extensions from the base POSIX.2 com-mand. An example is the shell, for which theUPE defines job control, history, and aliases.

Features used both interactively and in scriptstend to be defined in the base standard.

In my opinion, the biggest currentproblem with the UPE is that it lacks acoherent view: it’s becoming a repository forfeatures that didn’t make it into the base stan-dard. For example, compress is in the currentUPE draft. It’s hard to rationalize classifyingfile formats as an "interactive" or "user porta-bility" issue, yet the one used by compress isspecified in the UPE. It certainly doesn’t fit inwith a view of the UPE as a standard thatmerely adds utility syntax information (e.g.,information that would allow users to type thesame command line to compress a file on anysystem). This highlights the schizophrenic na-ture of the UPE: it addresses a range ofdifferent needs that, taken together, do not ap-pear to define a whole. Dot 2 Classic, to mytaste, appears to have far more unified scopeand execution.

A second, related, problem with the UPEis that there appears to be less enthusiasm forit than for the base standard. A number ofpeople, including me, understand the need forit, but it doesn’t appear to have the strategicimportance of the base. [Editor’s note -- TheUPE is, frankly, controversial. Like 1201, thecommittee undertook the UPE out of a fearthat if they didn’t, NIST would do the jobwithout them. Supporters note that althoughits utilities are probably not necessary for por-tability of most software, it would be un-pleasant for programmers to do the portingwork without them. Detractors counter thatPOSIX was never intended to cover softwaredevelopment and that the group is exceedingnot only its charter, but that of the entire 1003committee.]

Status of POSIX.2 Balloting

POSIX.2 is in its second round of balloting.The first ballot, on Draft 8, produced manyobjections that are only partially resolved byDraft 9. Although there were only fifty-fourpages of unresolved objections remaining afterDraft 9 was produced, the current ballotinground is not restricted to existing objections,and there will almost certainly be many new


;login: 15:3

ones. Remaining objections range from theperennial war between David Korn and theUNIX Support Group over what featuresshould be required in the POSIX shell, throughthe resolution of the-incompatible versions(Berkeley and USG) of echo, to the treatmentof octal and symbolic modes in umask.

A digression to illustrate the kind of issuesbeing addressed:

In March of 1989, a study group from 1003.2met at AT&T to resolve major objections tothe shell specified in Draft 8 by the two war-ring parties. This was a good place to hold themeeting, since both parties are from AT&T:one led by David Korn of Bell Labs, theauthor of the popular Korn Shell (KSH) theother, a group led by Rob Pike of Bell LabsResearch and the UNIX Support Organization,advocating more traditional shells, like theSystem V Bourne Shell and the Version 9Research Shell. Kom’s group contends thatthe shell should be augmented to make it pos-sible to etficiently implement large scripts to-tally within the shell language. For example,while the more traditional camp views shellfunctions as little more than command-levelmacros and uses multiple scripts to modularizelarge shell applications, the Korn shell viewsfunctions as a tool for modularizing applica-tions, and provides scoping rules to encouragethis practice.

The two philosophies engender different opin-ions on issues such as the scoping of trapswithin functions and the use of local variables.Other contentious issues were the reservationof the brace ({)) characters as operators(rather than as the more tricky "reservedwords"), the promotion of tilde expansion to aruntime expansion (like parameter expansion),and the issue of escape sequences within echo,print, and printf.

The meeting produced a false truce. I at-tended, and believe that both parties haddifferent views of the agreement that came outof the meeting. As a result, Draft 9 producedballoting objections from both parties and thedispute continues unabated. Shades ofPOSIX.1 Tar Wars...

I suspect the next draft (Draft 10) will failto achieve the consensus required for a full-usestandard. This is a good thing. Usefulfeatures are still finding their way into thedocument. (Draft 9 introduces hexdump,locale, localedef, and more.) Also, the sheersize (almost 800 pages) of Draft 9 hasprevented many balloters from thoroughlyreviewing the entire document. Still, there is astable core of utilities that is unlikely tochange much more than editorially; I predictthe standard will become final around Draft12.

A mock ballot on Draft 4 of the UPE willprobably start after the New Orleans meetingin January, and the resulting Draft 5 will prob-ably go to a real ballot somewhere in summerto early fall of 1990. Although many sectionsremain unwritten or unreviewed, the UPE is amuch smaller standard than POSIX.2 andshould achieve consensus more quickly.

Status of the Brussels Meeting

The Brussels meeting focused on the UPE, withonly a summary report on the status of ballot-ing for the base standard. For most of themeeting, small groups reviewed and composedUPE utility descriptions. The changesgenerated at the meeting will appear inDraft 3.

The groups reviewed many utilities. Thechapter on modifications to the shell language(for interactive features) is now filled in, andsuch utilities as lint89 (the recently renamedversion of lint), more, etc. are approachingcompletion. Still, much work remains.

[Editor’s complaint -- We think renamingcommon commands like lint ("lint89") and cc("c89") is both cruel and unusual. We are noteager to re-write every makefile and shell scriptthat refers to cc or lint, nor to retrain ourfingers to find new keys each time the C com-piler changes. The name seems to have beencoined by either a hunt-and-peck typist, orsomeone who has longer and more accuratefingers than we do. (Was it, perhaps, the workof Stu Feldman, author of f77?) Moreover,replacing commands with newer versions is


;login: 15:3

commonplace and traditional in UNIX. Exam-ples like make, troff, and awkspring to mind.If an older version is kept on for die-hards, it’srenamed (e.g., otroff, oawk).

One Dot-Two member rebuffed our objec-"B ~tions with the reply, ut, you see, this isn’t

UNIX: it’s POSIX."]

Because the meeting was in Europe, atten-dance at the working group meetings waslower than normal (20-25 rather than the nor-mal 35-40 in POSIX.2). Nevertheless, thechoice of location served a purpose. Themeeting was held in Brussels to garner interna-tional support and participation, particularlyfrom the European Economic Community.There were many EEC representatives at thebackground sessions on POSIX and two orthree European working group members in thePOSIX.2 meetings who wouldn’t normally haveattended. Though it remains to be seen whatwill come out of having met in Brussels, I amconvinced that the extra effort will prove tohave been justified.

Report on IEEE 1003.5:Ada-language Binding

Ted Baker <[email protected]> reportson the October 16-20, 1989 meeting inBrussels, Belgium:

The P1003.5 group is producing an Ada-language binding for 1003.1. The Brusselsmeeting had two objectives: to reach con-sensus on a draft document to be distributedfor mock ballot, and to solicit input from theEuropean community. We achieved the firstbut not the second; only one of the ten atten-dees was European (Olle Wikstrom, fromEricsson).

The technical editor (David Emery) andthe chapter authors had worked very hardbetween meetings to produce version 3.2 ofthe document, and Dave brought copies to themeeting. The working group reviewed it to tryto correct any serious errors or omissions be-fore mock ballot.

There was a lengthy discussion aboutschedule and logistics for the mock ballot.The present plan is to send out copies of thenext draft, in ISO format, to both the ISO andthe entire 1003.5 mock ballot mailing list.[Editor’.s note: All committees are re-formatting their documents in ISO format tosmooth the way for ISO acceptance (see Do-minic Dunlop’s report on WG15 for moredetails), and an IEEE copy editor appeared, onthe scene in Brussels to give P1003.5 guidanceand help in this.] Since there is no way thatenough input can be received before the nextPOSIX meeting, in January, the group hasscheduled a special meeting for mock ballotresolution, between the January and AprilPOSIX meetings, to be held in Tallahassee.The objective will be to produce a proposedstandard to be reviewed at the April meeting.

Most technical issues discussed wereminor, compared with previous meetings. Themost significant, and complicated, was thetreatment of system configuration limits. Hereare three problem areas:

1. Tri-state configuration parameters (true,false, undefined) in the POSIX C binding needto be treated differently in the Ada binding,because Ada prohibits references to undefinedsymbols (i.e., Ada lacks an #±~dof facility).

2. For the same reason, it isn’t clear how anAda binding can accommodate future POSIXextensions. Suppose, for example, a future ex-tension adds a new configuration constant.How does one write an Ada program thattakes advantage of the new feature on imple-mentations where it’s available withoutpreventing the same program from compilingon older implementations, where it’s not?

3. Because Ada compilers can do optimiza-tions, such as dead code elimination, based onstatic expressions (the nearest analog to someC preprocessor capabilities), it is important toprovide compile-time constants, where safe.At the same time, to support "bubble pack"software that is usable on different systemconfigurations, programs should also be able todefer binding such values until run time.


;login: 15:3

The group did achieve consensus on atreatment of configuration limits for the mockballot. It includes a combination of functions,to allow software to defer resolution of systemlimits and characteristics until runtime, andimplementation-defined constants and numericranges, to allow optimizers to take advantageof information available at compile time. Thisdoes not fully solve all the problems men-tioned above. Perhaps the mock ballot processwill turn up some suggestions for improve-ments.

The treatment of process arguments andenvironment variables, which must be pro-vided as parameters when starting a new pro-cess or calling Exec produced another con-troversy.

Unlike C, Ada does not allow pointers to.stack or statically allocated objects. An AdaPOSIX interface implemented over a C-language binding must bridge this gapsomehow. For example, an implementationmight use a C-compatible data structure andhide the non-Ada details, or use an Ada datastructure and translate between the two forms.Everyone agreed that the interface shouldavoid constraining the implementation, but thefirst interface solutions appeared to rule outdesirable implementations. The present solu-tion permits an application to ensure that ifthe Ada POSIX interface machinery allocatesany "heap" storage this storage is berecovered, while allowing an implementationto impose restrictions that would permit stackallocation. A price paid for this compromiseis that writing portable applications takes morecare: an application that works OK with oneimplementation may lose storage or exceedsize limits with another.

At the previous two meetings, we hadsubstantial interaction both with other groupsworking on language-independence and withP1003.4 (real-time). There was much less thistime, partly because the group was concentrat-ing so hard on getting ready for mock ballot,partly because meetings were spread overseveral buildings, and partly because P1003.4mostly skipped Brussels.

On the administrative side, Steve Dellerwas promoted from Vice Chairman to Chair-man (in charge of external affairs and runningmeetings) and Jim Lonjers was chosen as ViceChairman (in charge of administering ballotresolution). This change was required becausethe ex-Chairman (Maj. Terry Fong) has beenunable to participate regularly in the workinggroup recently, owing to conflicts with hisprofessional duties.

Another issue that came up was whetherworking group members are at liberty to pub-lish papers or present talks on the 1003.5work. The answer is, "Yes." Until now, somemembers have been exercising self-censorship,based on an earlier agreement designed todiscourage anyone (e.g., defense departmentpersonnel) from making commitments (e.g., re-quiting use of the POSIX Ada binding in con-tracts) based on erroneous (e.g., overly op-timistic) progress reports. It did not takemuch discussion to agree that such censorshipis now counterproductive, and may never havebeen wise. At this point, P1003.5 certainlywants public exposure of its draft document,and hopes that such exposure will generatemore reviewers and active working groupmembers.

Report on IEEE 1003.7:System Administration

Steven J. McDowall <[email protected]>reports on the October 16-20, 1989 meeting inBrussels, Belgium:

Background

Now, almost everyone agrees that 1003.7should deal with networks, not just isolatedsystems. To wit, it would be nice if I couldadminister all the machines in a network froma single machine with simple commands. Forexample, to add a user to all machines in thedomain mn.org, all I should need to do is issuea command like adduser -d mn.org -op-tions -parameters username. The questionis, without any de facto standard already inplace to adopt, how can we achieve this?


;login: 15:3

The Approach

This is important, so pay attention. Becausethe major goal of 1003.7 is to create a stan-dard way to manage a set of objects, the grouphas .decided to take an object-orientedapproach. Our idea is to begin by creating alist of objects to manage, then to follow thatby defining the set of commands to manageeach object. This approach is novel for bothsystem administration and POSIX. It willprobably require more work on the front endto define the objects, their attributes, and theirrelationships, than to define the actual com-mand structure to support and manipulatethem. Whether this approach will workremains to be seen.

The Meeting

The meeting was boring. To put it bluntly, theweek was simply a work week. Objects (andsub-objects) were defined and discussed indetail, then put in the draft. Little got doneon the first and last days, due to EEC formali-ties, which left us with three working days in-stead of the normal four and a half. Atten-dance was pretty dramatically reduced, too.About half the normal North Americansshowed up, probably because of the location,and only one (yes one...) new European cameeven though we were meeting in Europe. Ohwell, except for my having had my passportstolen, it was a good chance to see Belgium.

Concerns

1. The process is taking a long time to moveahead, both because of the difficulty involvedand because we seem to attract less manpowerthan many other groups. Moreover, sincewe’re taking a radical approach, it takes extratime to teach the ideas to anyone new thatdoes come.

2. SYstem administration doesn’t have theglamour of some of the other areas beingstandardized. As the Rodney Dangerfield ofPOSIX, 1003.7 gets no respect.

3. The notation we’re using to define our ob-jects is ASN.1. "Why ASN.I?" you ask.

Simply because it’s a standardized meta-language to describe abstract data types. The ¯feeling was that this would help make thewhole package more suitable for interoperabil-ity. I bring this up because there’s somemovement throughout 1003 to redo all datastructures in a new meta-language created bysome of the people working on language-independence. Not only would this requirethat we go back and redo our definitions, but Ialso think ISO will only allow the use of stand-ardized data-languages in their standards.Does anyone out there know if there is such anISO restriction? If so, it’s important for 1003as a whole, not just for dot seven.

4. Currently, almost all working-committeemembers are from vendors. IBM, DEC, HP,AT&T, and others are well-represented. A fewinterested parties, like OSF and/sys/admin arethere as well, but as far as I can tell, there isn’tone real user. By "real user" I mean someonewho does nothing but administer a system. Allof us are connected somehow with creating anadministrable system or getting paid to do so.Of course, I should make clear that we all haveto administer systems of our own, so we’re notsimply an ivory tower group with no real ex-perience, but representation is still grossly un-balanced.

5. Finally, there’s been a loss of focus on in-teroperability directly attributable to the lossof our X/Open representative, Jim Oldroyd.Jim was well respected and made many valu-able contributions, but can no longer attendour meetings. As the X/Open representative,he was very concerned with multi-vendor en- ’vironments, and was a major force in helpingus focus on and ensure interoperability. I amnot saying that no one else on the committeecares about the issue, but it does seem to bebeing pushed aside in a spirit of, "I think weshouldn’t have any interoperability problems ifwe do this, so let’s do it and worry about itlater on." Jim had helped provide a morepositive, direct approach of determining upfront what would be needed for true in-teroperability. If X/Open is still interested inSystem Administration, and in making sure


;login: 15:3

the 1003.7 standard includes provisions for in-teroperability, we could still use their help.

Report on IEEE 1003.8/2:Networking (IPC)

Steve Head <[email protected]> reports onthe October 16-20, 1989 meeting in Brussels,Belgium:

Overview

P1003.8 is the IEEE POSIX networking stan-dards committee, working on network stan-dard interface definitions for POSIX. Thecommittee is currently divided into six sub-committees: transparent file access, networkIPC, remote procedure call, OSI/MAP services,X.400 mail gateway, and directory services.

This report is a summary of the activity inthe network IPC subcommittee, which iscurrently working on two potential interfaces,a "detailed" interface (DNI) and a "simple" in-terface (SNI). DNI is roughly (though not ex-clusively) at the transport level. SNI is in-tended to be somewhat simpler to use thanDNI. but at roughly the same level.

At this meeting, presentations of DNI andSNI were made at the EEC (Common Market)headquarters in Brussels. Discussions on DNI(definitions) and SNI (routines) continued.The main topics of discussion were:

1. DNI, SNI presentation to EEC2. DNI definitions3. SNI routines4. Schedule5. Security6. P1003.8/2 --~ full POSIX committee

Detail

1. DNI, SNI presentation to EEC

Keith Sklower and Steve Head gave presenta-tions on DNI and SNI respectively to POSIXattendees at EEC (Common Market) headquar-ters. This meeting was scheduled in Brusselsprimarily to obtain European input. The

presentations went well, and attendees in-cluded X/Open and EEC representatives.

No significant differences of opinion ordirection were noted between the committeeand other attendees. This indicates somedegree of success (?). (Other networkinggroups, such as directory services, were not sofortunate.)

This meeting "broke the ice" with interna-tional organizations in the area of networking,and we now expect increased interaction withthose organizations.

2. DNI definitions

The committee discussed DNI definitions.Steve Head presented a paper on the subject.Suggestions made at the meeting will be incor-porated into a future version of the paper,which will be circulated via electronic mail. Ifno further significant issues are raised, it willbe incorporated into the next DNI draft.

3. SNI routines

The committee discussed SNI routines, basedon a paper from Keith Sklower. No conclu-sions were reached, however, this particulardiscussion was very useful since it brought anumber of goals and requirements for SNI intoclear focus.

SNI is adopting some characteristics ofISODE (the ISO Development Environment).This is probably beneficial since it means thatSNI will be partially based on a working imple-mentation instead of being entirely new. Assuch, it may gain importance as a migrationstrategy for transferring applications fromTCP/IP to ISO. (ISODE stands for the ISODevelopment Environment, a publicly avail-able collection of networking software thatruns over either TCP/IP or ISO transport andallows higher level applications to be obliviousto the type of transport a given system pro-vides.)

4. Schedule

The working schedule has been delayed by theneed to make presentations at Brussels, insteadof doing "real work." Originally, we hadscheduled the topics of connection setup,


;login: 15:3

connection tear-down, and name resolution forthis meeting. These topics were not discussed,and our schedule has been shifted back a quar-ter to reflect this. These topics will bediscussed at the next meeting.

5. Security

We held another joint meeting with the POSIXsecurity group, P1003.6. An electronic mailinglist was created for the topic of networksecurity. For more info or to be put on thelist, please contact Mike Ressler (bellcore!mpror [email protected]). A list of topics on net-working security to begin discussions on wasinitiated.

6. P1003.8/2 -~ full POSIX committee

The decision to make P1003.8/2 a full POSIXcommittee was postponed by the POSIX execu-tive committee (SEC). This subject will be re-addressed at the next POSIX meeting in Janu-

Reports on the January 1990Meeting in New Orleans

Report on IEEE 1003.0: POSIX Guide

Charles Severance <[email protected]>reports on the January 8-12, 1990 meeting inNew Orleans, LA:

Dot zero is producing a guide to thePOSIX Open System Environment (OSE). Theguide will bring existing and evolving stan-dards together to provide specifications for allaspects of an OSE - everything from applica-tion programming interfaces to user interfacesand system management. It will give users anoverview of the 1003, and other related stan-dards, describe their interrelationships, andhelp them select the subset of available stan-dards necessary for any particular application.

Draft Six Review

The group reviewed draft six, and points ofspecial interest were:

the formal definition of "open system"

¯ internationalization

¯ an editorial review of the entire documentto ensure a consistent style

¯ a review of some high-level architecturediagrams, proposed to make Chapter 3("Overall Architecture") easier to understand

The only one of these discussed by the en-tire group was the definition of "OpenSystem." To simplify the definition we createda definition for "Open Standard" which wasused in the Open System definition. Here isthe definition we finally agreed on:

Open System." A system that implementssufficient Open Specifications for interfaces,services, and supporting formats which enableproperly engineered applications software: a)to be ported across a wide range of systemswith minimal changes, b) to interoperate withother applications on local and remotesystems, and c) to interact with users in a stylewhich facilitates user portability.

Open Specification: A public specificationwhich is maintained by an open, public, con-sensus process to accommodate new technolo-gies over time and consistent with interna-tional standards.

The group won’t define "user portability"until next meeting, but the idea is that usersshould see a consistent interface from applica-tion to application, both within and acrosssystems. Public user-interface standardsshould simplify both user training and vendordocumentation.

The other issues were handled in smallworking groups.

1. Internationalization. This group identifiedparts of the document affected by internation-alization and other "cross-component" issues,such as system management and security.They promise to present new draft text for the


;login: 15:3

internationalization sections by the next meet-ing.

2. Editorial review. This group tackled theno-fun jobs of reviewing the entire draft forstyle and identifying areas that had too much,or too little, detail. Along the way, theyproposed a style guide and template for sec-tions of Chapter 4.

3. Architectural overview. This group con-tinued work on Chapter 3 to complete the textof the chapter, and worked to simplify it, andmake it easier to understand. The CCTA (UK)presented a high-level classification schemecalled "MUSIC" (Management, User Interface,System Interface, Information Interchange,and Communication) as a potential contribu-tion to chapter 3. The chapter will have exten-sive modifications and additions for the nextmeeting.

Application profiles

Next meeting we’ll discuss exactly what mustbe in a POSIX Application EnvironmentProfile (AEP). Profiles will affect and generateprocurement issues, so this will be a keydiscussion~

Profiles specify a set of standards forspecific computing areas, such as supercomput-ing. Not all standards will be required for allareas; a profile lists the subset of the standardsnecessary for a particular area.

The biggest point of contention in thisdiscussion will probably be whether 1003.1[Editor: the system interfaces set out in theUgly Green Book] will be required for allprofiles. Should vendors be allowed to adver-tise compliance to, say, 1003.11 (transactionprocessing), if they’ve implemented that stan-dard on an underlying system that doesn’t sup-port lower-level POSIX calls like fopenO?(There isn’t a standard for 1003.11 yet, butyou get the idea.)

One argument advanced for requiring1003.1 is that it will force vendors to adopt itmore quickly. I don’t think that 1003.1 needsany help in that area. Another is that requir-ing compliance will ensure that vendors who

want to advertise POSIX-compliant systems arefollowing the general POSIX direction and notjust implementing the simplest standard sothey can claim that their system implements"some POSIX."

An argument made against the require-ment is that it may damage implementations.For example, real-time systems may lack evena file system, and may want a very limitedsubset of the POSIX interface to keep the im-plementation as small as possible. If all of1003.1 is required, vendors may have to addcostly and unnecessary features just to claimPOSIX compatibility.

When the dust settles, I think 1003.1 willbe strongly suggested but not required, because1003.1 is a pretty arbitrary subset of any list of"required system interfaces."

[Editor: We disagree. 1003.1 is a set of appli-cations programming interfaces carefullychosen to be necessary, and sufficient to makean operating system UNIX-like for the Cprogrammer. Providing standards for aUNIX-like operating system should be the goalof the POSIX standards, and attempts by ven-dors uncomfortable with UNIX to dilute theeffort should be cut off at the pass.]

[Author: POSIX must evolve a set of indepen-dent standards that have UNIX as their heri-tage. POSIX standards are all evolving asUNIX-like standards. Why discourage a ven-dor from implementing some subset of UNIX-like standards just because the vendor is notready to provide a complete 1003.1 implemen-tation?]

Want to go to a POSIX meeting?

This was my first POSIX meeting. In case youhaven’t been and are thinking of going, hereare a couple of things you’ll want to know.

New people are welcomed. As a practicalmatter, it helps to stick with a group for theentire week. It’s tough to understand much ifyou come into an advanced discussion cold. Itwould help if each group summarized its pur-pose and listed the big issues at the beginningof each meeting, to get everyone in the proper


;login: 15:3

frame of mind. Still, you’ll be granted a sort offirst-time armor to protect you when you asknaive questions or need clarification. For ex-tra insurance, use the phrase "I will take an ac-tion item..." often.

Report on IEEE 1003.1:System services interface

Mark Doran <[email protected]> reports on theJanuary 8-12, 1990 meeting in New Orleans,LA:

Most published standards inevitably re-quire updating through corrective supple-ments. P1003.1 has now reached that stage.The first supplement, P1003.1a, is at an ad-vanced stage and was the central issue at theNew Orleans meeting.

Also on the agenda were:

¯ further talks with the group working ontransparent file access;

¯ more language-independent-specificationwork; and

run-through of the material in the em-bryonic second corrective supplement,P1003.1b.

P1003.1a Ballot Resolution

The first corrective supplement to IEEE1003.1-1988 (POSIX.1) is intended to correcterrors and oversights in the first publicationwith a view to clarifying the intent. It isdefinitely not meant to introduce newfunctionality or behavior into the standard.

This work received its second recircula-tion ballot during the week preceding the NewOrleans meeting. Donn Terry, chair ofP I003.1, hopes that one, or at most two, morerecirculations will bring the document to apublishable state. Accomplishing this willsend it off to ISO, who will ballot it for sixmonths. (That’s right, six months; an IEEE re-circulation ballot lasts ten days - does thisseem a little lopsided to you?)

The details of the content of P1003.1a andits ballot resolution are long and complex, so Iwon’t repeat them here. However, there is oneissue worth raising which the ballot brought tolight. On the subject of changes relating to thesupport of split baud rates, one balloter com-mented:

While we do not agree with the direction this issueis obviously taking, we will abide with the decisionof POSIX insofar as split baud rates are concerned.

But we would be remiss in our responsibilities if wedid not express our complete outrage with the pro-vincial attitudes expressed by a number of the bal-lot comments we have had the pleasure to reviewduring this recirculation period.

Split baud rates ARE NOT uncommon with a greatnumber of the community of users of these stan-dards. Obviously, many of those submitting ballotshave not had the opportunity to consider the needsor requirements of users outside their own im-mediate view. We abhor such a limited, irresponsi-ble scope, especially considering the nature of thetasks we are charged with resolving. It is our hopethat we shall do better in the future.

Only rarely are standards meetings gracedwith such florid language, and the balloterclearly has at least the tip of his tongue in hischeek. However, there is, underneath thisbonhomie, a serious point being made.

The IEEE is an ANSI-accreditedstandards-developing body, responsible formaking standards pronouncements for use inthe USA. All POSIX standards are beingpassed to ISO for potential adoption as inter-national standards. The POSIX steering com-mittee (SEC) has declared that POSIX wouldlike to think of itself as an internationally ac-cessible organization. If POSIX is indeed to beinternationally accessible then the attitudes ofsome of those who attend will have to change.Take for instance, the split baud rate issuementioned above.

Working group discussions revealed thatsplit baud rate support, though a non-issue inthe USA, is important in Europe. (The reasonsfor this stem from the way the PTTs in Europestructure their charges for communicationslines - PTTs are Europe’s little AT&T


;login: 15:3

at any problem. Delve deeply into POSIX andANSI C internationalization issues, and you’llalways discover topics that the committeeshave not yet dealt with. This is not a criticismof the internationalization standardizationgroups; much work is still needed and solu-tions to many problems remain elusive. In theuuencode example, we felt the output ofuuencode should be code set invariant (i.e.,uuencode on an EBCDIC system should pro-duce the same results as uuencode on an ASCIIor ISO 646 character system). To achieve this,¯ " through "__" must be expressed as 0x20through 0xsF and "begin" must be expressedas 0x62 0x65 0x67 0x69 0x6E (the hexequivalents of ’b’ ’e’ ’g’ ’i’ ’n’ in ASCII).POSIX appears to offer no standard way toconvert a file from one code set to another.

Attendance at the UPE working group was,again, relatively small - around a dozen peo-ple. One reason is PAR proliferation. Mostcompanies cannot afford to send one com-mittee member to each working group. (I, forexample, also had to cover TFA, POSIX.lb, andthe internationalization efforts.) [Editor:Readers should note that that being spreadthin didn’t stop Randall from turning out aclear, thoughtful report. Thanks, Randall.]Another reason is that there is less enthusiasmfor the UPE than for Dot 2 Classic. Even HalJespersen has said that "...basically the NISTput our feet to the fire to do the UPE."

Some people want the UPE to include anEMACS editor description as well as one for vi.Unfortunately, although there was talk of anEMIN proposal, none was submitted to theworking group. If you EMACS fans want it in-cluded in the ever-expanding UPE, then submita proposal. [Editor: Listen up, folks. He’sserious.] (Of course, some devotees feel thatstandardization would be inappropriate for anextensible environment like EMACS.)

"Revision/Source Code Control Software"is a much-shuffled area of future standardiza-tion within the overall POSIX.2 PAR. Fearinganother Tar Wars-like clash between fanaticsupporters of of SCCS and RCS, the topic wasremoved from Dot 2 Classic and deferred tothe UPE. The Source Code Control System

(SCCS) is the original UNIX source code con-trol system which was implemented in the mid1970’s, modeled after mainframe systems ofthe time. The more modern (no bias here...)Revision Control System (RCS), by WalterTichy of Purdue University, claims to haveimproved on SCCS. Each has its proponents;SCCS appears to have a stronger followingbecause of commercial support by vendors,but RCS appears to have a more devoted un-derground following. The working group is di-vided between those who want either SCCS orRCS and those who want neither, arguing thatsource control is a vendor-specific application.Unfortunately, the UPE working group has hadproblems resolving the controversy and HalJespersen has proposed that POSIX.2c (yes, youheard it right, .2c) be assigned as a PAR forworking on this topic. (What happened to.2b? POSIX.2b is the working group that willprepare revisions and clarifications of Dot 2Classic - which isn’t even finished balloting.)

Report on IEEE 1003.3: Test Methods

Doris Lebovits <[email protected]>reports on the January 8-12, 1990 meeting inNew Orleans, LA:

Dot three’s job is to do test methods forall of the other 1003 standards. This was theworking group’s fifteenth meeting. Wereviewed the ballot status of P1003.1 testmethods, worked on P1003.2 test methods, andcreated a steering committee.

Review of ballot status and Dot two verification

The PI003.3 standard will consist of severalparts: Part I is generic test methods, and partII is test methods for measuring P1003.1 con-formance, including test assertions. Part III ofP1003.3 will contain test methods and asser-tions for measuring P1003.2 conformance. Asother P1003 standards evolve, they will becovered as separate parts in the P1003.3 stan-dard.

Each day was divided into two sessions:mornings, we did technical review of parts I


;login: 15:3

and II, afternoons were spent writing asser-tions for part III. AT&T, NIST, OSF, Mind-craft, IBM, DEC, HP, Data General, CrayResearch, Unisys, Perennial, and Unisoft Ltd.were represented. [Editor’s complaint: I seeno user representation at all.]

It took twelve meetings of the previousP1003.3 working group to prepare the draftthat is now balloting. The technical review forthe Draft 10 ballot was completed. Draft 11was re-circulated late February 1990 andclosed March 23, 1990. The balloting group isapproximately ninety members. X/Open sub-mitted a list of assertions for P1003.1a. Thislist was included as an appendix to Draft 11.Balloters were expected to review this appen-dix as part of their ballot. We anticipate anapproved P1003.3 standard in the third quarterof 1990.

This is the third meeting for developing averification standard against the P1003.2 stan-dard. The P1003.2 assertion writing andreview were done in small groups. Some ofthe assertions were based upon P1003.2Draft 9.

A steering committee and some new officers.

The chair, Roger Martin, instigated the crea-tion of a test-methods steering committee tohelp alleviate the increasing dot-three workload all the other proliferating groups arecreating. The committee will coordinate theactivities of all test-methods groups, monitorthe groups’ conformance to test methods, andwrite and approve Project Authorization Re-quests (PARs). Membership will be dynamic,limited to four to six, and new members willbe chosen based on long term commitment,new ideas, and technical/managerial skills.Roger suggested an initial makeup - RogerMartin (NIST, Steering Committee Chair), An-ita Mundkur (tlP), Andrew Twigger (Unisoft),Bruce Weiner (Mindcraft), and Lowell Johnson(Unisys) - and the working group approved.It’s a non-controversial mix of establishedP 1003.3 members.

The Standards Executive Committee (SEC)has approved both the committee and its

membership. Their first assignment is todocument procedures.

In addition, new officers were chosen forthe P1003.2 Test Methods activities. RayWilkes,of Unisys, is Chair, Jim Moe of CrayResearch, is Co-chair, Lowell Johnson ofUnisys is Secretary, and Andrew Twigger ofUnisoft Ltd is Technical Editor.

Report on IEEE 1003.4:Real-time Extensions

Rick Greer <[email protected]> reports onthe January 8-12, 1990 meeting in New Orle-ans, LA:

1003.4 goes to ballot

The big news in 1003.4 is that some of it isready for balloting. The current draft is a330-page, eclectic collection of real-timefeatures. Some (e.g., asynchronous eventnotification) address significant deficiencies inthe dot-I base, but others (e.g., IPC messagepassing) seem to be of limited value. Itremains to be seen whether the limited appli-cability of some of the proposed features isenough to shoot down the entire ballot.

One area that may cause trouble is theshared-memory model in the Language-Specific Requirements section. While thislanguage-independent model addresses a realneed - serialization of reads and writes in thepresence of simultaneous updates to a com-mon store - it does so rather formally; peopleuncomfortable with formal mathematicalmodels may be put off by it. The fact remains,however, that both dot 1 and the ANSI C stan-dard failed to address this problem, which iscritically important in shared-memory mul-tiprocessor architectures.

Threads

The threads proposal is only an appendix inthe current draft, and won’t be subject to for-mal ballot. Though there were too many looseends in the threads proposal to send it to


:login: 15:3

ballot in this round, most of them were tied upin New Orleans. We should have a ballotabledraft ready after the April meeting.

Meanwhile, the active membership in thethreads "small group" is changing. Represen-tation from the Ada community has grownfrom two to six; almost a quarter of the activemembership is now familiar with Ada and itsmultitasking model. Most threads people, in-cluding me, are also becoming active in thenew multiprocessor study group.

Discussion within the multiprocessorgroup promises to be quite lively, since thethreads group’s more contentious issues (e.g.,signals) were skirted by defining high-level in-terfaces, leaving details of low-level behaviorunspecified. The multiprocessor group, on theother hand, must deal with the low-levelbehavior of multiprocessor configurations, andmany of the old arguments have already resur-faced (e.g., should signal state be maintainedper-process or per-thread?). Using high-levelinterface specifications to dodge low-level im-plementation issues does have its problems,though. People unaware of more subtle imple-mentation issues tend to view new high-levelinterlaces as unnecessary complications. It’sdifficult to convince them that, even if con-sensus could be reached regarding the behaviorof primitive functions, we would still needhigh-level interfaces (or rigid coding discip-lines) to guarantee that independentlydeveloped routines use primitives consistentlywhen addressing common problems. The realsticker here has been how to asynchronouslyterminate a thread and cause it to executecleanup code. Everyone agrees that this isnecessary. Some members, particularly thosefrom AT&T/USO, feel that the best way to pro-vide this facility is by minor enhancements totraditional UNIX signals, but most of thegroup feels that the best way to deal with no-torious signal races in a uniform, language-independent manner, is to adopt a high-levelinterface, modeled after one used by DEC/SRC.

1003.4 turns into .4, .4A, .4B, .4C, and .14

There are three other major, ongoing efforts indot 4: language-independent specification ofthe real-time extensions, identification andspecification of other important non-threads,real-time extensions that didn’t make it intothe current ballot, and specification of a real-time application profile. The first is farthestalong, but none is anywhere near completion.Recognizing that these efforts were separatefrom the current proposal, and from oneanother, the working group submitted fournew Program Action Requests (PARs). TheSponsor Executive Committee (SEC) approvedall four, and decided that the application-profile effort was so distinct that it needed anew number. The working group’s five PARsare now:

the current ballot 1003.4threads 1003.4Alanguage independence 1003.4Bfurther real-time extensions 1003.4Creal-time application profile 1003.14

Report on IEEE 1003.7:System Administration

Martin Kirk <[email protected]> reportson the January 8-12, 1990 meeting in New Or-leans, LA:

The System Administration working groupis developing portable interfaces for adminis-tering computer systems, which will providetraditional systems-administration functionssuch as managing users, file systems, anddevices.

The working group began with a basedocument similar to the draft System Ad-ministration FIPS produced by NIST in Sep-tember 1988, containing a set of commandsbased on existing functionality. It addressedonly the single machine case, and the groupquickly saw that it formed an inadequate basisfor extension to networked systems.


;login: 15:3

Three competing models were advanced tocope with heterogeneous networks. All threeassumed that there would be a standard inter-face, but differed in the scope of the underly-ing administrative database and the degree ofinteroperability. To update a network of 100systems, supplied by five different vendors, thethree models had:

1. one database per system, requiring anyoperation to be performed 100 times

2. one database per vendor, requiring eachoperation to be performed five times

3. one database for the entire network re-quiring each operation to be performed onlyonce.

The working group chose Model 3, whichoffered the greatest interoperability, the mostbenefit, and the biggest technical challenge.The working group also chose an object-oriented approach. [Editor: USENIX can takesome credit for this, having prepared a white-paper that recommended precisely thisapproach.]

Because system administration is closelyrelated to network administration, in that bothare concerned with managing objects distri-buted across a heterogeneous network, thegroup adopted an object template based on thework of the OSI Network Management Forum.The template uses Abstract Syntax NotationOne (ASN-1), to specify the attributes andcharacteristics of objects.

Currently, the group’s major task is todevelop object class definitions. Some of theobject classes, such as the user object class,seem relatively s.traightforward, with attributessuch as login-name, numeric-uid, group-id,home directory, and login shell. Others, suchas the device object class, introduce majorquestions: How far is it appropriate to go indefining sub-classes such as disk-devices andtape-devices?

The standard will not specify implementa-tions. Information about a user can be storedin whatever fashion seems appropriate: in atraditional place, such as /etc/passwd, or in adatabase.

When the object-class definitions are com-plete, the next task will be to specify both acommand-line interface and a programmaticinterface to manipulate the objects. The latterwill have both a language-independentspecification and a C-language binding. Allobjects will support a core set of four opera-tions - create, delete, set-attribute, and get-attribute - and probably a fifth to check con-sistency. In addition, there will be operationsspecific to particular object classes, such as amount operation for file systems.

I am happy with the general approach, butthere may be trouble ahead on the commandinterface front. At present, this is the canoni-cal form:

<object> -o <operation> <attributes>

such as

user -o add name =j sh,uid = 423,group = editors

or something of that general style. I expectthat there will be complaints once it sinkshome that this removes old favorites such as"mount" from the system administrationcanon.

Though the standard is designed forheterogeneous network administration, theworking group has not really tackled in-teroperability. Someone must address thiscritical area, but it may ultimately be the IEEETCOS networking groups.

Dot seven is currently aiming at a mockballot in 1991, and a full ballot in either 1992or 1993.

Disclaimer: The views contained hereinare my personal opinions and do notnecessarily have any relation to those of myemployer.

Report on IEEE 1003.8:Transparent File Access

Jason Zions <[email protected]> reports onthe January 8-12, 1990 meeting in New Orle-ans, LA:


;login: 15:3

1003.8 breaks up

The networking work has been reorganized;what was one committee is now five. At thismeeting, the Sponsors’ Executive Committee(SEC) approved all the networking ProjectAuthorization Requests (PARs) and forwardedthem to the IEEE Standards Board for finalapproval. In the past, 1003.8 was responsiblefor half-a-dozen types of networking issues.From now on, 1003.8 will restrict itself totransparent file access (TFA); the other workwill be distributed t6 four new groups. Thenew structure is:

1003.8 TFATransparent File Access

1003.12 PII or P2PProtocol Independent Interfaces, or Process toProcess

1003.13 RPCRemote Procedure Call

12xx PDIProtocol Dependent Interfaces, a.k.a, s-lOSIFTAM and ACSE

12yy NS/DSName Spaces and Directory Services, maybeX.500

The SEC tentatively assigned 1200-seriesnumbers to NS/DS and PDI, because they in-tend these standards to apply to any operatingsystem, not just one that’s UNIX-like. (There’sone exception: NS/DS must identify the namespaces required by the 1003 standards anddetermine some means of managing them.)

TFA decides what to do about NFS

The meeting was a landmark for TFA. Untilnow, no consensus on overall direction hadbeen achieved. We spent a great deal of timediscussing the philosophy and goals for a FullTFA and Subset TFA, but no common under-standing had been reached in the minds of allmembers; we wandered between extremes of,"Full means 1003.1!" and, "But NFS sureseems to be good enough for users; after all,they’re still buying it."

It became clear that some agreement hadto be reached for progress to be made. ManyTFA attendees had never worked on a POSIXcommittee before and didn’t quite understandthe POSIX consensus process, but after a jointmeeting of 1003.1 and TFA, the exact scopeand structure of work were finally hashed out.The group’s work items are described below.

1. Full TFA

This piece will contain minor additions andchanges to 1003.1-1988 to specify its behaviorwhen operating on remote files. Work will in-clude extending already-defined interfaces (e.g.,new statO information), defining new errors,defining failure and recovery semantics, and soon.

Semantically, a remote file accessed under FullTFA will be indistinguishable from a local file.A strictly conforming POSIX application willrun completely unaltered in a Full TFA en-vironment.

2. Subset TFA

This piece will define both a core subset of1003.1-1988 that can work correctly over avariety of remote-file-access protocols ("theCore") and a number of additional optionalfeature sets. The specification will form addi-tional text for IS 9945-1 (ISO’s version of1003.1).

The intent is to have Subset TFA work on thewidest variety of protocols consistent with auseful Core; if a remote-file-access protocol isso constraining that any Core based on itwould be too small to support useful applica-tions, it will be excluded.

FTAM, the International Standard FileTransfer and Access Method (IS 8571), willshape decisions about what will go into theCore, for a variety of reasons.

¯ It is the weakest common mechanism forremote file access.

¯ The standard has little chance of successat the ISO level unless it is clearly cognizant ofFTAM.


;login: 15:3

¯ Nothing weaker than FTAM is likely toprove useful to application writers.

o People are clamoring for a simple inter-face to FTAM; the open/read/write/close styleof Subset TFA meets that need.

The difference in functionality between theCore and Full interfaces will be divided intoblocks of capabilities (the "feature sets" men-tioned above), which might be provided byother commonly used file-sharing mechanisms.A Core-conforming application will be able toinquire (via pathconfO) what functionality,over and above the Core, is available on aper-file basis, and alter its behavior accord-ingly.

The Core will meet an expressed need to know"what doesn’t work right" over common filesharing protocols. For example, Sun mightdefine NFS’s functionality in terms like, "NFSprovides Core Subset functionality, plus the_PC_LOCKING, _PC_DIRECTORIES, and_PC_TIMES capability sets." An applicationprogrammer could use such a specification todetermine exactly what features of 1003.1-1988 were safe to use in an NFS environment.This scheme also permits continued develop-ment of remote-file-access protocols. Anymechanism that supports at least the Core willconform to the standard. This encouragesvendors and researchers to developmechanisms that combine the Core and its op-tions with other advantages (very high perfor-mance, very high robustness, good behaviorover WANs, etc.), while giving users a well-defined interface for applications that willwork in all such environments.

3. A Data-Stream Encoding (DSE) supportingthe Full TFA Interface

This will provide the mechanism necessary forinteroperation of client and server systems.1003.8 will only develop the encoding; nobinding to any particular protocol stack orsuite is planned. (Such bindings will be doneby working groups chartered to developprofiles to satisfy particular needs.)

Work on the DSE will probably not begin forat least another six months. There are now

two existing proprietary mechanisms that pro-vide the appropriate functionality: SVR4 RFSand the Andrew File System (AFS v.3 fromTransarc). The committee hopes at least one(if not both) of these products’ DSEs will bereleased to POSIX for standardization. If bothare, there will probably be a gun-battle overwhich to base the standard on.

There was good progress on the first twowork items. The group hopes to have a mean-ingful draft available by April, and would liketo go to ballot by the end of the year. Thisquick ballot will help compensate for the smallworking group by bringing major ballot objec-tions to the surface early. (Much coordinationwith other 1003 working groups, especially1003.1, will also help.) The balloting processwill probably be quite lengthy: on the order of12-15 months.

Report on IEEE 1003.11:Transaction Processing

Bob Snead <[email protected]> reports on theJanuary 8-12, 1990 meeting in New Orleans,LA:

Context

Our charter is to develop an application profilefor POSIX Transaction Processing (TP). We’rewrestling with both the content of our profileand the idea of a profile, since profiles are newto POSIX. [Editor: Jim Isaak reviewed appli-cation profiles in the February issue of IEEEComputer.]

The content is influenced by two other TPefforts: OSI’s DTP and X/Open’s XTP. Wemust handle OSI DTP, just to gain ISO accep-tance - a goal of all the 1003 efforts. Intheory, XTP is just another proprietary con-cern. In fact, XTP’s ongoing deliberations arecurrently confidential. Moreover, X/Openisn’t an official standards body so we can’tofficially reference XTP in our profile.Nevertheless, XTP will carry considerableweight, since it will be a multi-vendor con-sensus on how to do UNIX TP.


;login: 15:3

Models

As at previous meetings, we spent much timediscussing TP models. For the most part thesediscussions were based on a snapshot of XTP’smodel released to non-X/Open members sometime ago. Each model we discussed consistedof three or four of the following elements: Ap-plication Programs (APs), Resource Managers(RMs, like database managers), Communica-tions Managers (CMs, like TCP/IP), and Tran-saction Managers (TMs, which enforce thetransaction protocol among APs, CMs andRMs). Here, in chronological order, were themajor topics of discussion.

We discussed whether a CM might just bean instance of an RM (viewing an instance of acommunications protocol or link as aresource), but concluded that attributes of CMsmake them fundamentally different beasts(though, to be honest, it’s still not clear to mewhy).

We considered several models based onXTP, but differing from one another in theroles of the CM and the interfaces between theAP and CM. We concluded that each com-munications protocol would have to have itsown CM, and that our model must supportmultiple concurrently active CMs. A CM,though, is more than just its protocol support.It has to include support for additionalfunctionality required for DTP. We never con-cluded whether or not an AP should talkdirectly to a CM, or to a CM via the TM.

Requirements

In the course of the model discussions, itbecame clear that many of us had different re-quirements in mind, so we shifted our focus torequirements to try to reach some consensus.Ultimately, we decided that POSIX TP must:

1. be mappable onto OSI DTP,

2. support global (distributed) transactions,

3. support chained and unchained transac-tions,

4. support a conversational mode,

5. provide data conversion (e.g., ASN. 1),

6. ensure that POSIX RPC supports DTP se-mantics,

7. ensure that DTP can be accomplishedthrough RPC,

8. provide for location independence viadirectory services, and

9. provide for security of data.

Exercises

We decided to break the modeling deadlock byfocusing on the AP/TM interface and ignoringcommunication. We worked several examples,following ISO DTP services but using an RPCparadigm, and concluded that an API based inRPCs would need at least four services:

¯one for a caller to start a transaction,

° one for a callee to find out if it is par-ticipating in a transaction,

° one for a callee to abort a transaction,

¯ one for a caller to commit or abort a tran-saction.

We also identified the following assump-tions for TP via RPC:

° A thread of control (TOC) can be in atmost one transaction at any given time.

° If one TOC communicates with another,the latter joins the former’s transaction bydefault.

¯ No nested transactions are permitted.

° A GTRID (Global TRansaction ID) can beassociated with multiple TOCs and multipleRMs.

¯ A transaction has only one initiator andonly the initiator can issue commit. Any TOCmay abort.


;login: 15:3

Report on IEEE 1003.12:Inter-Process Communication

Steve Head <smh@hpda,HP.COM> reportson the January 8-12, 1990 meeting in New Or-leans, LA:

Overview

P1003.12 is the IEEE POSIX Network Inter-Process Communication (IPC) committee(formerly P 1003.8/2). The committee iscurrently working on two potential interfaces:a detailed interface (DNI) and a simple inter-face (SNI).

At this meeting, the group arrived at ahigh-level description of a name-to-addresstranslation facility, and decided the questionof XTI versus sockets versus "something else"in favor of "something else." The group begandiscussing connection setup, and continueddiscussing SNI. Finally, the POSIX steeringcommittee (SEC) changed the group’s name toP1003.12.

There were about twelve attendees.

Detail

1. SNI reviewed

A UC Berkeley SNI proposal is gradually takingshape. The proposal describes both objectsand functions that act on them. Some of theseobjects and functions have analogues in thesocket world, while most of the others arecomposites.

The most recent additions are sni_saveO andsni_restoreO, sni_saveO takes a snapshot of anendpoint and saves it in a string, suitable forpassing to a child process through an argumentor the environment, sni_restoreO restores thelibrary state of an endpoint from that string.

The committee has had two goals for SNI. Fornaive users, it should simplify the networkinginterface. For vendors, it should allow imple-mentation of interfaces over complex protocolstacks (such as ACSE - or something aboveACSE - over OSI-7).

One issue that came up was what the applica-tion programmer would target for. If DNI andSNI retain distinct differences, SNI-based appli-cations risk outgrowing SNI’s capabilities. Onealternative would be to combine DNI and (thecurrent) SNI to allow seamless expansion intoprotocol-specific hooks, without recoding ofapplications.

Next meeting, UNISYS is expected to presentan alternative SNI proposal.

2. Naming

The group discussed name-to-address transla-tion for DNI in detail, specified an interface ata high level, and intends to pass it to the nam-ing group. The specification is:

given:hostname/"entity"service/"facility"type/"context"protocol or protocol family

return:set of (

addressany input parameters that were

completely or partially wild-carded)

SNI might need something similar, but withoutthe protocol / protocol-family / address-familyparameter. (SNI is protocol-independent.)

The interface lets applications defer decidingwhich protocol- or address-family to use untilafter the query. It will also permit load-balancing, a technique to optimize data-transfer performance over slower interfaces(such as multiple serial point-to-point links).

The group deferred discussing both perfor-mance (time and memory) and which inputparameters could be wild-carded.

3. XTI versus sockets

The XTI versus sockets issue came up brieflywhile discussing passive-endpoint functions.The group resolved to incorporate the best ofXTI, sockets, and possibly other extensions,into DNI.


;login: 15:3

The group decided not to require full XTI-typefunctionality, and accepts the risk that portingXTI-based applications to DNI may requiresource code changes. A potential advantage ofthis decision is that the standard can leave outthe mistakes of XTI and sockets. Also, ven-dors remain free to supply the older interfaceson the side.

A UCB representative will prepare a new DNIproposal between now and the next meeting..

4. P1003.8/2 --~ P1003.12

The SEC gave network IPC its own separatenumber: P1003.12. This change will be for-mally approved at the IEEE standards boardmeeting, a couple of months from now.

5. Potential overlaps with P1003.4

For several meetings, both P1003.12 andP1003.4 have been aware of their potentiallyoverlapping coverage of process-to-processcommunication on a single, local system.Since there should be only one interface forcommon functions, and any characteristicspeculiar to local IPC can be supported byprotocol-specific options under DNI, P 1003.12’sposition is tha~ it should handle all IPC. Thegroup has asked the networking steering com-mittee chair, Tim Baker, to relay this positionto the SEC.

Future Meetings and Significant Dates:

The Spring 1990 meeting will address SNI/DNIconnection setup/tear-down and SNI/DNI datatransfer.

Report on IEEE 1201: User Interface

Peter H. Salus <[email protected]> reportson the January 8-12, 1990 meeting in New Or-leans, LA:

What’s happening?

P1201 purports to concern itself with the userinterface. As of the New Orleans meeting,P 1201 comprised . 1 (Applications Program-ming Interface), .2 (Graphical User Interface),

.3 (Human-Computer Interaction), and .4(XLib) subgroups.

Working backwards through these, 1201has recommended that XLib go to ballotdirectly, a proposal which seems to have soshocked the SEC that they put off deciding onballoting till April. Steve Jobs told theUSENIX audience in Phoenix, in June 1987,that X was "brain-damaged." Whether that’strue or not, X has won, and just’ putting XLibto a vote makes good sense.

1201.3, under the chairmanship ofRichard Seacord, has had a number of in-teresting discussions and presentations (ofwhich I attended several, though not all). Themajor problem here is that we are nowherenear knowing what the "standard" for an in-terface might really require. However, the ex-plorations are valuable, and a forum like thiscan be informative.

This leaves me with the GUI and the API.Both in Brussels and in New Orleans wereskirmishes in the GUI wars: battalions of em-ployees of OSF and its member companiesarrayed in opposition to those of UI or USOand theirs, with a pair of observers fromNeXT and Apple taking and placing bets onthe sidelines.

I assure readers that have never attendedthese meetings that acrimonious backbitingand vituperation are the order of the day inboth camps. Though a former employee ofOSF, I wouldn’t hesitate to condemn thebehavior of both sides, but the blame rests.elsewhere. Where? In the tourists. See below,but for my money, too many folks like totravel and too many people have caught the"open systems/open standards" bug.

So long as the market remains unsettledabout Motif, NeXTStep, OPEN LOOK, andPresentation Manager (to say nothing ofApple’s Macintosh interface and IBM’s CUA)[Editor: That’s "Common User Application",a part of SAA], the meetings of 1201.1 and1201.2 will serve as tilting grounds, not occa-sions for useful discussion.


;login: 15:3

From my point of view, until the market(which means the big boys and the users) has ashake-out, .1 and .2 can only serve as debateplatforms or end up recommending standardsthat are either the intersection of OPEN LOOKand Motif or their union. It might be that .2can come to some sort of conclusion on thevarious style guides without . 1, but I see theproducts being waved, not the functionbanners.

Why is it turning out this way?

All of this is prologue ("The past is prologue,"writes Shakespeare in The Tempest) to a com-mentary on the TCOS-standards industry. [Ed-itor: TCOS, the Technical Committee onOperating Systems, is the IEEE organizationunder which both 1201 and 1003 fall.]

Over the past 40 years, ISO has approvedor accepted over 20,000 standards, which con-cern almost everything imaginable fromhockey masks to medical prostheses to thehinging of radar masts on inland-waterwayvessels. The standards have arisen in a varietyof ways, most emanating from one of the re-gional or 70-odd national standards bodies.Typically, it has taken from four to ten yearsto progress from raising a committee toapproving a standard. The result of this hasbeen genbral agreement within the concernedindustry prior to the issuance of an interna-tional standard. Wall plugs are an excellentexample of what happens when the engineersand bureaucrats issue a standard without in-dustry consensus.

I am far from convinced that the ever-increasing number of 1003 and 1201(sub)committees is productive or useful, andembarrassed and appalled at their continuingproliferation. There are currently at least sixor seven standards for diskettes. Do we reallyneed that many for graphical user interfaces? Ithink not. Might we get what happened in therecord industry (i.e., 45s for short cuts; 33s forlong works and anthologies) if we wait? Ithink so.

Moreover, does the standards processreally require more than two or three folks per

company? There were 38 in attendance at theISO/IEC Joint Technical Committee on Appli-cation Portability meeting in September (in-cluding the secretariat); there were nearly 300in New Orleans. My perception is that goingto a POSIX meeting is a perk. Holding themeetings in Hawaii, New Orleans, andSnowbird does little to dissuade me. The NewOrleans host was OSF; the Snowbird host isUnisys. Though the new Unisys is a big en-tity, I didn’t realize they had a site inSnowbird; nor OSF one in New Orleans.

C’mon,. lets get back to work, not meetingsfor the holiday or for the sake of meetings.1003.1 did good, solid work. Some of theother groups are doing work, too. Partyingain’t part of it. Bah!

Report on ANSI X3Jll:C Programming Language

Doug Gwyn <[email protected]> reports on thestate of ANSI C:

There is now a C standard

After the one appeal of CBEMA X3’s approvalof the proposed ANSI C standard was eventu-ally voluntarily withdrawn by the appellant,the ANSI Board of Standards Review approvedthe proposed standard on December 14, 1989.(CBEMA is the Computer and Business Equip-ment Manufacturers’ Association, the organi-zation that sponsors X3.)

No appeals were received by ANSI withinthe time allotted, so there is now an officialAmerican National Standard for ProgrammingLanguage C: ANS X3A59-1989. The technicalcontent of the ANS is identical to that of theDecember 1988 X3Jll draft.

The X3Jl 1 technical committee will enteran "interpretations" mode at the March 1990meeting in New York City. During this phase,the committee will be considering requests forclarification and interpretation of the standard.It is anticipated that Technical InformationBulletins will be issued from time to timewhen it is felt that clarification of the intent of


;login: 15:3

the standard needs to be published. Suchbulletins would not technically be consideredpart of the official standard; however, theyshould provide valuable guidance to both Cimplementors and C programmers.

USENIX Standards WatchdogCommittee UpdateJeffrey S. Haemer <[email protected]> reportson. winter-quarter activites of the watchdogcommittee:

1003.0: A Guide toPOSIX-Based Open Systems

Dot zero, the POSIX guide group, continues tosuffer from bureaucratic inertia. It complainsthat its forty or so attendees are insufficient toallow rapid progress, yet in a year-and-a-halfthey’ve just created a table of contents. Somepeople think this reflects badly on the group. Ithink this is completely wrong.

Admittedly, the economics of .producingthe POSIX guide itself are unfavorable. Alarge fraction of the attendees are highly-placed or key employees of large corporationsand influential organizations. A back-of-the-envelope calculation puts salary expendituresalone, for each one week dot zero meeting,close to six figures. Had the committeedelegated the entire task to one or two full-time people, it would be done. The fine over-views UniForum occasionally publishes areproofs by example.

How, then, does dot zero benefit the usercommunity? The meetings give influentialpeople from the most important corporationsin the commercial UNIX arena a way to gettogether in the same room (or after hours inthe same city) and discuss the direction ofUNIX without risking an anti-trust suit.

USENIX meetings serve a similar purposefor more technical segments of the UNIX com-munity. To some degree, UniForum meetingsserve an analogous purpose for other segmentsof the industry. But where else is there such a

concentration of high-level, UNIX vendormanagement except, perhaps, at meetings ofthe Hamilton or Archer groups, or of theboard of directors of X/Open? Attendees sup-port POSIX, and influence their companies tobecome involved. Because POSIX is a goodthing, so are dot zero meetings.

1003.1: System Services andC Language Binding

Dot one is well ahead of the rest of 1003; lookhere to see the future. The initial standard isdone, published, and government-approved asFIPS 151-1. The group is now working on sup-plements, which come in two flavors: nit-picksand corrections (1003.1a) and real additions(1003.1 b). But to speak of "the group" ismisleading; these two working groups have astrikingly different makeup from the groupthat created dot one. Many who werepassionately and intimately involved in theproduction of the Ugly Green Book havemoved on, either to other committees or outof the standards game. The working groupsare now small numbers of hard-core, dot-onedevotees. For. 1 a, this isn’t a problem - that’sexactly the kind of person needed for nit-picking.

Watch . l b like a hawk, though. Any newfunctionality, slipped into supplements and ap-pendices, carries the same risks as riders oncongressional bills; if it can be slipped inunobtrusively enough, or with the right timing,it can be awful and still ride on the coattails ofthe main body. Bad deeds done here will bothinflict irresistible harm, and diminish the cred-ibility of dot 1.

I recommend resisting any effort to addfunctionality for which there aren’t existingimplementations in wide use, and about whichthere isn’t already general consensus. Design-by-standards-committee efforts should bedeferred to other more ignorable standards.


;login: 15:3

1003.2: Shell and Utilities

Dot 2 is still firmly in the dot one mold. Dot2 Classic is balloting away, and should soon beboth done, government approved and FIPS-ified, with a set of test assertions that com-panies like Mindcraft can sell test suites for.When this is done, a large number of systemswill advertise compliance with 1003.1, 1003.2,and X3.159 and provide, for most users, astandard "UNIX."

Even the controversial UPE is mostlycodifying existing practice. Arguments areover places where more than one practice iswidespread, for example, source-code control,where partisans of SCCS struggle with parti-sans of RCS. (Actually, that’s not true.What’s really happening is that the group’sshying away from this area because they’reworried about a struggle. "Tar wars" seems tohave spoiled the industry’s appetite for makingdifficult decisions about contentious topics.)

Parenthetically, I’ll admit to beingmystified by the dim view some folks take ofthe UPE. I actually put programmer portabil-ity above program portability, since, when I golooking for new jobs I can’t take my softwarewith me, but do want to be sure that I can stilluse vi. (Of course, most members of workinggroups are sponsored by vendors.)

The equivalent of. 1 a already has a name:.2b. Even the bad of dot one is mirrored here.Truly controversial proposals are being pushedoff to the as-yet unborn .2c, which should pro-duce a deja vu feeling in those already watch-ing . lb. ("But," you remark, "you always saythat.") And, just as . 1 sometimes shied awayfrom real decisions, in order to avoid upsettinganyone, .2 occasionally reacts to vendor incon-sistency by proposing solutions that avoidupsetting any vendor by penalizing all users.As an example, the committee proposes requir-ing a C compiler (good), and naming it c89(bad, but I complained about this loud andlong last time). An important motivation forthe new name is that cc already invokes theK&R C compiler on many vendors’ platforms,and specifying a flag to choose one behavior orthe other would conflict with someone’s

existing implementation; any given letter isalready preempted by some vendor.

I’m not convinced by this argument. Ihave consulted the Ouija® board in my office,normally used only for project scheduling, andwill now predict the effects of this sidestep, ifapproved:

¯ In two years, everyone will have a c89compiler, to comply with a government FIPS.Shell scripts and makefiles will continue to in-voke cc, but be less portable than they arenow.

¯ On a few conformant machines, there willbe no cc command. This will break an enor-mous number of programs, and solutions willvary from user to user, project to project, andinstallation to installation.

¯ On other machines, cc will produce oneflavor or the other. Most, but not all,machines will link cc to c89. This will break avariety of things, but not consistently enoughto allow a portable solution.

~ On some of these machines, flags willmake c89 compile K&R C. The flag will varyfrom vendor to vendor.

In short, we who do ports will have tokeep track of how to invoke the C compiler oneach of our target machines; .2 will not haveenhanced portability in this area of our work.

Finally, like .1, my unease over a smallnumber of problems stands in stark relief tothe generally high opinion I have of the workdone by this group.

1003.3: Test Methods

Dot three, a tiny mirror of the overall POSIXeffort, is proliferating because it has no choice.It will now have a subcommittee to developtest assertions for each of the other POSIXefforts, and has acquired a steering committeeto oversee the subgroups. Whether this is abetter choice than having each POSIX com-mittee develop its own test assertions isn’tclear - I see plusses and minuses for eachapproach. Still, all in all, the group seems toknow what it’s doing, and is willing to do it.


;login: 15:3

Dot three isn’t always popular; one hears com-plaints that they come up with interpretationsthat seem contrary to the intention of the ori-ginal standards committees. On the otherhand, that seems as good a reason as any fortheir existence. They form a combinationsystem-test and quality assurance group for theother committees, generating all the frictionone expects from any such organization.

A dot three member did take the time todivulge an unexpected answer to a question Iraised in my last report - what motivatessomeone to be in dot three? For a few folks,it’s obvious: MindCraft employees attendbecause their company develops and sells testsuites. Others are also there because they’rereally interested in testing. But think: if youwant an overview of all of POSIX, what groupshould you attend? There are three candi-dates: dot zero, but then you’d have to buy anexpensive wardrobe; the SEC, but that group ismostly institutional representatives, officers,and overworked committee chairs; or dotthree, which examines each standard in detailas it nears completion. If you’re thinking ofjoining a working group, and want this sort ofvantage point, I’m certain the group has plentyof work to hand out.

1003.4: Real-Time Extensions

The real-time group now has five PARs: .4,.4a,, .4b, .4c, and .14. The first of these wentto ballot after the New Orleans meeting.Threads, controversial enough to be omittedfrom .4, has been pushed into .4a. (Things toocontroversial to go into threads will be pushedinto the multiprocessor group, which should bea lot of fun.)

(The remarks below in brackets and with-SP are taken from a response posted tocomp.std.unix by Simon Patience of the OpenSoftware Foundation; see also the article ofcomment by John S. Quarterman that follows.-Ed.)

[This is not actually true. Pthreads wasnever in the draft of 1003.4 proper but was anappendix. After New Orleans when .4 wasready to ballot, pthreads was not and so could

not become a real chapter of its own within .4and so got its own PAR. It had nothing to dowith being controversial. Your parentheticalcomment is pure fantasy also. -SP].

The threads subgroup (1003.4A) hasattempted to kill the .4 ballot by a block votefor rejection. One correspondent says they aredoing this because .4 is no good withoutthreads. (I’m told that two "large, non-vendororganizations" are part of the coalition againstthe 1003.4 ballot. There is rumored to be aspecial, invitation-only, threads-strategy meet-ing by these two groups immediately precedingthe Utah meeting. Can anyone confirm thisand supply more details?)

[More misinformation here. The CommonReference Ballot was written by a number ofpeople from different organisations some ofwhom attended the threads group and somedidn’t. The endorsements for it came from asignificantly wider audience than the threadsgroup, some of whom I believe have not beento a .4 meeting either, or at least regularly.The objections were not related to threads ex-cept where an interface was impossible to beused in a multi-threaded environment.

The rumor of a pre-Utah meeting is com-pletely overblown. OSF and UI regularly meet,with representatives of our respective memberorganizations, to discuss technical matters totry and maximize commonality between ourtwo systems, especially at the interface level.The subjects include threads as this is anemerging technology area, but it is certainlynot restricted to threads. As the people in-volved in this also attend POSIX meetings, it isnatural to take advantage of the fact that weare all going to be in the same place. Themeetings take place regularly and more fre-quently than POSIX meetings. We think thislevel of cooperation is the sort of thing the in-dustry would expect us to do, especially theend user community, rather than indulge inthe UNIX wars that are restricted to the TradePress. -SP]

University of California’s Computer Sci-ence Research Group (the folks who bring usBerkley UNIX) is also voting against the .4


;login: 15:3

ballot as a block. This stand has nothing to dowith the lack of a threads proposal; the voteobjects to the working group’s addition ofcompletely new and (their words) "lame"features to UNIX. An amusing twist, this. Toa traditional standards activity, one vendorblock voting against another; POSIX adds oneresearch group (CSRG) voting against another(.4).

[I believe that this was just an endorse-ment of the Common Reference Ballot men-tioned above, which was submitted by some-one at Berkeley. -SP]

The threads group itself is divided overwhether-they are doing an interface to OS-kernel services or an applications library.They are also divided about whether they aredoing an interface to language-independent,concurrent programming services, or just a C-language extension.

In general, .4A seems to be a small core ofactivists pushing ahead with a clear agenda,with an opposition that complains but appearsincapable of putting together a detailed unifiedcounter-proposal. Both the rush to go to bal-lot, and the move to tie success of the rest of1003.4 to threads, should be causes for scru-tiny.

[I can’t think where you get this ideafrom. There is no desire that I know of to tiethreads to the rest of .4. The people involvedare highly motivated and think that the time isright to standardize on a thread interface be-fore the industry become too divergent. It isfelt be many people that there is enough ex-perience in the industry and academia to writea good usable standard and are trying to do so.-sP]

Interestingly, if threads are forced backinto the base .4 standard, it may end up caus-ing another problem. The ACM’s ARTEWG(the special interest group on Ada’s runtimeenvironment working group) is likely to votein a block against 1003.4 if it contains athreads proposal that does not support Ada ina natural way.

[This is not likely to happen as I saidabove. The threads group are talking to theAda people (constantly it feels like :-) and it ishoped that when the draft is ready for ballot-ing most of the Ada folks will be happy. Thereis a problem with scope which has never reallybeen properly defined with respect to Ada,especially Ada runtime.

Your overall tone was one of suspicionthat there is a subversive plot going on andthat half of POSIX is being taken over by asmall number of people in the threads group.This is deafly ridiculous as it could never hap-pen; the consensus process prohibits it. -SP]

The Ada folks are concerned that there bean underlying, OS-level model of concurrencyconsistent with both the C-threads and Adatasking models. This seems especially impor-tant to them if Ada applications want to usestandard services written using C librarieswhich are implemented using C-threads (e.g.,windowing and database access). Such amodel would also be important for support ofAda compilation systems, which are typicallyproduced by independent software houses tooperate on a variety of operating systems andmachine architectures.

Dot 4b is a language-independence effort.What’s interesting here is that real-time wasone of the groups that the SEC grandfatheredout of the requirement that POSIX standardsbe language-independent. (Other exemptionsincluded other standards well along, like .1,and standards that were intrinsically language-dependent, like .9, FORTRAN bindings).Despite that exemption, real-time may be thefirst group to write a language-independentbinding.

Real-time also has PARs for .4C, a placeto put stuff that didn’t make it into .4 (i.e., .4is to .4C as. 1 is to. I B), and. 14, the real-timeprofile.

Language-independence Study Group

I want to straighten out something I was con-fused about in the last summary report.(Thanks to Jeff Kimmel, of the language-independence study group, for taking the time


;login: 15:3

to explain this.) Language-independence is asop to ISO. Two prices we pay to gain rapidinternational approval of the POSIX standardsare an agreement to hand ISO standards for-matted in their preferred style, to which endthe IEEE is providing editorial assistance, anda commitment to a direction ISO intends totake for all its standards: language indepen-dence.

And, to clear up another misconception,Steve McDowell worried, in his last .7 snitchreport, that ISO requires language-independentspecification languages to themselves be stand-ardized. This would force POSIX to use some-thing frightening like VDL. Fortunately, thatturns out only to be true for formalspecification languages: languages from whichone can derive correctness proofs. ISO isn’tinterested in proofs, only in divorcingspecifications from specific programminglanguages. They don’t want to give an unfairadvantage to languages in which the things be-ing standardized are likely to be initially im-plemented, like C or FORTRAN, over moreinternational languages, like ALGOL-66. Inother words, POSIX will probably producespecs in ASN.1 or even English.(That’s"language independent." Get it?.)

1003.5: Ada Bindings

Dot five didn’t officially meet in New Orleans,partly to give .5 members more time to attendother groups. Dot five members kept sayingthings to puzzled members of other com-mittees like, "We’re not really meeting," "I’mnot really here," and "Well, I am here, butdon’t tell our chair, Steve Deller." Onemember graciously volunteers this short, buttimely, update:

"The Ada binding group (P1003.5) justfinished an intensive working meeting atFlorida State, in Tallahassee. The meetingwent very smoothly. We resolved all theissues brought up by the recent mock ballot,and expect to have a revised draft ready forthe April POSIX meeting. That draft is sup-posed to be given some finishing touches at themeeting, and then sent out for formal ballot."

1003.8: Transparent File Access

As expected, what used to be dot 8 has splitinto several groups. There was a meeting onthe last day, in which chairs of each of thenewly-formed POSIX networking-relatedgroups gave status reports. At that meeting,one attendee objected that the models andAPIs that come out of these groups increaseportability, but do little or nothing to ensureinteroperability. Surely, networking standardsshould have interoperability as a primary goal,he complained. While the current groupsdon’t have solving this problem as part of theircharter, many attendees agreed that the com-plaint is valid, and something should be doneon this front. Keep your eye on this problem.

While the other subgroups have newnumbers, the group standardizing transparentfile access (TFA) retains the dot 8 name.

Six months ago, TFA was torn between afaction wanting to canonize NFS, and anotherinsisting on something that supports full dot 1semantics. Now, the group has achieved con-sensus. They’ll provide several standards: acore subset with which FTAM will comply, aset of extensions to the core with which vari-ous versions of NFS will comply to variousdegrees, and a full standard that will supportfull dot 1 semantics. This compromise recog-nizes the de facto international standardwithout sacrificing a commitment to dot 1.

1003.9: FORTRAN Bindings

Dot 9 is in the middle of editorial cleanup inpreparation for balloting. Emphasis until nowhas been on content, so the draft developedwith many styles and formats. Much of thelast meeting was spent trying to even thingsUp.

Since things are drawing to a close, youmight expect meetings to be sedate. If youread the .9 postings in comp.std.unix, you’llknow that’s not true. When I walked in on the.9 meeting the group was in the middle of aheated discussion. Someone had proposed ad-ding several functions to increase portability ofFORTRAN programs. One specific example


;login: 15:3

was a function that would return the max-imum REAL for the implementation. Whilethere is little question of the utility of such afunction, there were two sorts of illuminatingobjections:

1. Some members of the group objected thatthe standard was not intended to increase por-tability of FORTRAN programs, only to pro-vide FORTRAN bindings to the .1 standard.(Indeed, unlike .5, .9 makes no attempt to be astand-alone document. It freely uses pointersinto .1.) Others countered that the section be-ing discussed corresponds to section 8,Language-Specific Service for the C Program-ming Language, of the Ugly Green Book; thatthe group’s goal is improving application por-tability; and that additions that further thatgoal are completely within the group’s charter.

2. One member objected strenuously thatmany of these additions required REAL sup-port. I was utterly mystified by this objection,until the group patiently explained that,though .9 is an F77 binding, it won’t requireF77 compliance, and won’t use all the featuresof F77. For example, these new functionswere .9’s first use of REALs. What the memberwas objecting to was that without the addedfunctions, a vendor could advertise .9 compli-ance with an integer-only FORTRAN compiler.Adding these new functions would require thatthe vendor’s FORTRAN compiler actually han-dle REALs. Think about that.

The ultimate (and, in my opinion, correct)decision was to add the functions, but you cansee that there are interesting philosophicaldivisions in this group. Similar divisions actu-ally exist in all the groups, but the discussionsin .9 seem to be more direct and get resolvedmore quickly. Chalk it up to more program-mers, fewer politicians.

1003.10: Study Group on Supercomputing

Dot ten has two subgroups, Profile and Batch,each working on a document.

The Supercomputing Application Environ-ment Profile specifies a set of standards, alongwith options and parameters needed for super-computing application environments. The

current draft, 1.0, is still rough, but specifiesmost of the required standards. At the Aprilmeeting, the Profile subgroup will hold a jointsession with dot 0 and the other profile work-ing groups (. 11, . 14, and the multiprocessingstudy group) to discuss profiles.

Batch Extensions for Portable OperatingSystems describes a standard batch manage-ment system based on NQS (the NetworkQueuing System, available from NASA Ames).The batch subgroup began its work within/usr/group’s supercomputing working group,has been meeting eight times a year, and isnow on draft 1.2. When complete, the docu-ment will specify required extensions toPOSIX, including interfaces forcheckpoint/restart and resource control, utili-ties for job submission/management and batchsystem administration, and a networkapplication-level protocol. The subgroup hassubmitted a PAR for the batch work, which theSEC will consider at their April meeting.

1003.11: Transaction Processing Study Group

Good news in transaction processing. Dot 11has been trying to work out what model oftransaction processing to adopt. Becausemany committee members are also active inother committees specifying other TP models,the committee had a running start, butprogress has been slowed somewhat becausethere are at least three camps: those whofavor the ISO model, those who favor theX/Open model, and those who believe thatdiscussion of concrete models is premature.

Part way through the New Orleans meet-ing the committee took a break from modelingto explore what an API to a transaction pro-cessing system might look like. This, finally,provided a fairly uncontentious topic on whichall members could collaborate, and the com-mittee seems to have been able to generate realagreement rather quickly. Success breeds suc-cess, and this may smooth the way to findother areas that the committee can makeprogress.

One warning: working out a sample APImay serve only to clarify the committee’s


;login: 15:3

thinking about the requirements of their appli-cation profile, but I wouldn’t be shocked to seethe committee eventually submit a PAR for thework. If that happens, ask yourself whetherthe committee should be designing APIs for anarea where there isn’t yet industry consensus.

1003.12: Protocol IndependentApplication Interfaces

Dot 12, process to process communication, isone of the groups derived from the division ofthe old dot 8 group. The big news from thisgroup is that they’ve made a real decision inthe struggle between XTI and sockets. Thegroup has decided to invent a new interface,which they hope will combine the best of bothand avoid the mistakes of each. This is im-portant. It is the first time since the beginningof the committee (several years ago, countingits origins in /usr/group) that it has actuallytaken a stand on the question. The issue hascome up often in past meetings, but until nowbeen deferred by the group.

On other fronts, the group is still trying toproduce two APIs: a detailed network inter-face and a simple network interface. I worry abit about having two disjoint interface stan-dards in the same area. Are two standardsbetter than none? (On the other hand, havingtwo raises the possibility of splitting the groupinto two separate, numbered groups at somelater date, a popular POSIX pastime.) Recog-nizing the danger in this split approach, somemembers of the group are considering whetherit might be possible to specify a single expand-able interface.

12xx: Protocol Dependent Interfaces for OSI

This new dot 8 spin-off, chaired by KesterFong, is looking at protocol-dependent net-working interfaces. They’ll begin by concen-trating on FTAM. I predict this group willmake rapid progress, because its compositionis dominated by users.

To help prevent its work from being anAristotelian exercise in abstract design, thegroup has begun to collect all the examples itcan find of applications based on FTAM. If

you have, or know of, any such examples,please pass them on. Kester’s e-mail addressis FONG%[email protected].

1201: User Interface

1201 is growing to four groups: . 1 (Applica-tions Programming Interface), .2 (GraphicalUser Interface), .3 (Human-Computer Interac-tion), and .4 (XLib). This serves as a focus foran interesting philosophical issue.

As many readers realize, there iswidespread sentiment outside of these groupsthat 1201 should, instead, shrink to zerogroups - that standards in this area are prema-ture. Even more interesting is that the samesentiment is widespread inside the groups.The level of dissatisfaction does vary fromgroup to group. Out of curiosity, I requested avote for dissolution at the first New Orleansmeeting of 1201.3. Fewer than one-third ofthe attendees voted to dissolve. This contrastswith a similar vote in Brussels in 1201.2,where nearly half of the attendees voted todissolve. With this much anti- 1201 sentiment,isn’t there a way to get the IEEE to reconsiderthe activity? Apparently not.

At the last USENIX, in Washington D.C.,Jim Isaak, the SEC chair, explained to thewell-attended standards BOF that there isreally no easy way to dissolve a committee. Ifvolunteers show up to staff the working group,follow the IEEE rules, and eventually circulatea ballot that passes, they’ve created an IEEEstandard. This means, if you don’t like theidea, you currently have only three options.

1. Join the balloting group and vote anyproposal down. Not easy; you have to have agood reason for voting no. Of course, "Thisstandard is premature; the direction of in-dustry is too unclear" may be good enough.

2. Join the working group and filibuster untilthe direction the standard should take does be-come clear. (Of course, that would be expen-sive, and lose you popularity points.)

3. Let the group declare a standard and hopeeveryone ignores it. This one’s dangerousbecause NIST won’t, which means the vendors


;login: 15:3

can’t, which means users probably won’t bepermitted to, and will, at least, have to carrythe code around as excess baggage.

So, I’m curious. If you don’t like what’sgoing on here, which do you intend to do?(Okay, I’m not that picky. If you like what1201’s doing but object to some other portionof what Doug Gwyn calls "the standards jug-gernaut," what are you doing about it?)

X3Jll: C Language Standard

Closing on an upbeat note, we have a C stan-dard. What more newsworthy item could youask for?

From: John S. Quarterman, USENIX Stan-dards Liaison, <[email protected]>.

The summary report from Jeff Haemer,the USENIX Standards Watchdog CommitteeReport Editor, is in general just the kind ofthing we try to publish. However, there were afew problems with it. In particular, the com-ments about a supposed block vote against

1003.4 originated by a threads subgroup wereinaccurate. There was in fact a common refer-ence ballot that originated with UCB CSRG.It addressed many points throughout the1003.4 draft document. It was referenced innumerous negative ballots, including severalfrom Institutional Representatives. (USENIXdid not reference it in a ballot, but only due totime pressure: USENIX supports it in prin-cipal.)

These errors in Jeff’s report were due toinadequate review before publication, whichoccured because I was out of the country as hefinished the report. It was important to get thesummary posted on the networks before theUtah standards committee meeting, and tur-naround time to substitute reviewers turnedout to be greater than anticipated. My apolo-gies for this coordination problem. We willattempt to prevent this kind of situation in thefuture by more thorough review, includinghaving each section about a specific committeereviewed by the corresponding WatchdogCommittee volunteer in addition to beingreviewed by me.


CALL DOC STRANGE ~ COLSTON SANGER

Managing Users

Call Doc Strange

Colston Sangerdoc.stran ge@ gid.co.uk

GiD Ltd

with a little help from ’Cheery Bye’ Neil Todd

Colston Sanger has left the Olivetti International Education Centre. He isnow a sort of senior consultant/tea boy with GiD Ltd and a visiting lecturer inthe Faculty of Engineering, Science and Mathematics at MiddlesexPolytechnic.

This issue’s topic is managing users -- you know,dtem, the ones who cause all the trouble, but whoMso pay the bills. More precisely, the topic ishow to assign login names and how to nudge themgently into groups, particularly across distributedfilesystems.

Assigning gids and uidsWhile it is somethnes sorely tempting to regard allyour users as simply them, on closer inspectionIhey will often seem to fall fairly naturally intocl,xsses or groups. There’s the "I’m aprogranuner, I’ve got magic fingers" group, the"I’m too important or too busy to read that"group, the "Oh, is that what it does" group...

Seriously, why not group them by function or byIhe need to share information? In a mfiversity, theobvious groups are likely to be staff, research orpostgraduate studenls, and undergraduates. Youmight want to divide these further by department.You might have psych_staff, sot_staff

alld comp_s ci_st a f f, for example, forpsychology, sociology and computer science staffrespectively. Shnilarly, you might want to divide

the postgraduate and undergraduate students bydepartment, by course or by year. In acommercial organisation, the groups might bewordpro, accounts, personnel andsales, where sales might again be furtherdivided by region.

When assigning numeric gids, it makes sense toincrement by more than simply the next availablenumber. For example, you might assign thenumeric gid 100 to the wordpro group, 200 toaccounts, 300 to personnel and so on.Then, when you come to assigning numeric uids,sharon and tracy in the word-processingdepartment can be numeric uids 101 and 102,kevin in accounts can be 201 and scan inpersonnel can be 301. The advantage of thisscheme is the extra level of redundm~cy itprovides: if your /etc/passwd lile should oneday ’accident~dly disappear" withou! Irate orbackup, then you have a better chance of sortingout what belongs to whom from the numeric gidsand uids stored in the i-nodes (as shown by anls -1) than if you had just assigned gids anduids randomly.

In System V, users are only ever a member of onegroup -- the group to which you as system


CALL DOC STRANGE ~ COLSTON SANCtER

manager assign them when you add them as auser. If they need to share information with themembers of another group, probably the easiestand most secure way to do it is to use thenewgrp shell built-in command to temporarilychange group to the other group.

For this to work, however, you have to set thingsup properly. If you look up the manual page for/etc/group you will see that it says that thefou~1h field in each line is ’a comma-separated listof all users ,allowed in the group’. It’s not actually

-- or else the wording has always beenambiguous and confusing (to me). What thefourth fieM really is, is a list of users who areauthofised to use the newgrp command tochange to that group.

Let me demonstrate. Assume you are a memberof the staff group, but that sometimes (forwhatever reason) you want temporarily to becomea member of the student group. Here are therelevant entries in /etc/passwd and/etc/group:

you:x:204:200:Member of staff:/u/staff/you:

(This machine has a shadow password file.)

staff::200:student::300:

You trya newgrp command:

$ iduid=204 (you) gid=200 (staff)$$ newgrp studentnewgrp: Sorry

D~sn’two~. N0wadd yourselfasa memberoffile student group in /etc/group:

staff::200:student::300:you

$ iduid=204 (you) gid=200 (staff)$$ newgrp student$$ iduid=204 (you) gid=300 (student)$$ newgrp$$ iduid=204 (you) gid=200 (staff)

And back again.

1 suppose I ought to mention that Berkeley UNIXhas the concept of a group of groups. If you usePC-NFS, however, don’t be caught by the ’gotcha’that you are only ever a member of your basegroup (the one defined in /etc/passwd)

regardless of whether or not you are filesharingwith a BSD machine.

Naming schemesThere is, of course, a step previous to all this:what if you have more than one clever trevor

in your organisation? In any organisation of morethan half a dozen people it’s a virtual certaintythat there will be some who share the same firstname. In recognition of this potential problem,some system managers use the initial letters ofusers’ first, middle and last names for loginnames, perhaps with a common or group prefix.Others don’t use personal login names at all:instead, they use logins by job function mwordprol, wordpro2, for example. To mymind, though, that’s a bit impersonal. If you’retrying to encourage people to give up their fearand loathing of computers, it’s not exactly helpful.It could also make it more difficult to spotunauthorised use of a login. Certainly in an officeenvironment, there’s a lot to be said for usinglogin names that correspond to the names orinitials that are used on existing distribution orcirculation lists. Whatever you decide, the pointis it’s worth thinking about a login namingscheme from the outset.

Where to put themOnce you have sorted out the groups, the next stepis to decide where to put them. Again, it makessense to create separate disk partitions for eachgroup, mounting one as /u/wordpro), forexample, another as /u/accounts.

What do you gain by this? Well, you now havethe potential to spread your users’ files across a


COLSTON SANGER ~ CALL DOC STRANGE

number of disk partitions. It means you canensure that greedy users in one group cannot hoglarge anaounts of disk space to the detriment ofother groups (the downside is that you have tomake a reasonable guess as to how large thatgroup’s partition needs to be, and you lose theautomatic and dynamic allocation of spacebetween groups as users create and delete files).You also have the possibility of load balancingacross disks and disk controllers, and can dump orbackup the different groups at differentfrequencies from each other.

Moreover, if you use a distributed filesystem suchas NFS, you can restrict the files you wish toexport much more easily (remember that exportrestrictions in NFS are on a per partition basis),thus your fileserver can, for example, exportundergraduates’ login directories to thosemachines on which undergraduate logins arepermitted, while at the same dme denyingundergraduate access to staff or postgraduatelogin directories (which are presumably exportedto other machines).

Sharing files between machinesDistributed filesystems are all the rage these days.There are two that are generally available: NFSand RFS. NFS works in a UNIX or heterogeneousenviromnent, whereas RFS is for UNIX only.Since they are both available in System V Release4.0 (implemented under the Virtual File Systemn VFS), it’s maybe worth discussing how they

deal with with user and group ids mapped acrossthe entire distributed filesystem.

NFS assumes that you have a flat namespace(strictly, uid space) across all machines. That’s tosay, the assumption is that files with a uid of n onmy machine are owned by the same person as fileswith a uid of n on your machine -- or, to put itanother way, if I can become the user with uid non my machine and I can access your machine viaNFS, then I own all files with uid n on yourmachine. The only mapping that NFS will do foryou is to map requests that come with a uid ofroot (0) into requests coming from the usernobody (typically -2 or 32767), thus ensuringthat root: on one machine cannot operate withsuperuser privileges on another machine, rllaat’sit,

RFS, on the other hand, provides you with theability to lnap users and groups globally or on aper machine basis. Under RFS, if you never set up

mapping, all remote users will be mapped to aspecial guest id, represented by an id number thatis one higher than the maximum allowed on yoursystem. By default, the maximum number ofusers and groups on a system is 60000, so thespecial guest id number is 60001. When a remoteuser does an ls -1 of your files, they willappear to be owned by uid 60001 or 60002. The60001 means the file was created by a remoteuser, whereas the 60002 means the file wascreated by one of your local users and, therefore,remote users can only access the file if they haveot he r permissions.

User mapping increases the power and flexibilityof RFS. For example, you may want to map someor all remote users into particular local users’permissions. If you are the administrator ofseveral machines, you may want to map all root:logins together across the machines so that youwill be able to modify any remote resourcesmounted on any machine you are working from.

Alternatively, you may want to set up a group ofmachines to have the same /etc/pas~wd and/et:c/c_rroup files so that when a user creates afile he or she maintains sole ownership of it,regardless of where die file actually resides. Withthis transparent mapping, you could shareresources that require a consistent view of userownership. For example, you could share your/usr/mail directory, mount it on/usr/mail on other machines and have onemail directory for the entire set of machines.

Or you may want to map users from one machinein a different way than users from anothermachine. For example, you may want to map allusers from one machine into uid 600, fromanother machine into 700 and from another into800 so that you can monitor which remotemachine’s users are creating files within yourresources.

How to set up user mapping in RFS

You ~vill need to create a set of ’mapph, gtranslation tables’. These tables will be used byyour machine to process requests from remoteusers for access to resources belonging to you thatare mounted on their machines.

The command to create translation tables isidload. When you mn idload without anyoptions it does the following:


CALL DOC STRANGE ~ COLSTON SANGER

¯reads the rules Ides to detemfine how youwant to set up mapping

reads the /etc/passwd and/etc/group files on your machine andcopies those from other machines as required

° creates translation tables.

idload has two options: -n lets you do a trialmn without actually changing the mapping; and-k lets you see the mapping that is currently ineffect.

You will need three sets of files, as follows. First,you need rules files, i.e., the files uid. rulesand gid. rules located in the/usr/nserve/auth. info directory.Theinformation you, add to these files tellstheidload command how to create the translationtables. Second, you need the /etc/passwdmid /etc/group files on your machine.Although you don’t modify these files, you willneed the information in them. For example, if youmap by local name, these files are read to translatethe names to numeric ids. Third, you need remotepasswd and group files. Because mappingtranslation tables ,-ire sets of numbers, if you wantto map a remote user by name, you must have acopy of the passwd and group files from theretnote user’s machine. These files should beplaced in the/ us r/nserve / auth. info/domain/nodenamedirectories, where domain and nodename arereplaced by the remote machine’s RFS domainand nodenames respectively.

To make the discussion more concrete, here is anexample uid. rules file:

globaldefault transparent

host rfsdemo.sixnineexclude 0map all

Essentially, uid.rules contains two ’blocks’of rules: the global block, which defines thepermissions that will apply to the users on allmachines for which there is no specific mapping;and one or more host blocks, one for eachremote machine you want to map specifically.Both blocks are optional.

Within a global block, the default line canbe either omitted, in which case the default 60001is assumed, or transparent, which means

that each user will have the permissions of theuser with the same uid on your machine (mostuseful when the /etc/passwd files areidentical on all machines) or you can usedefault local, where local is any local uid orname, meaning that any users who are notspecifically mapped will have the permissions ofthe particular local user on your machine.

If you want to exclude certain users from havingthe permissions defined in the default line,you can add exclude lines. For example, ifyou use default transparent, you maywant to exclude 0 to make sure that remoteroot users don’t have permission to modify filesowned by the local root on your resources.You can either exclude remote-M or a range ofremote-ids, as in exclude 0 or exclude0-99. In either case, the excluded remote userwould then only have the permissions of the guestid (60001).

You can also add map lines to map specificremote uids to local uids or names. You caneither map remote-id:local-id or name orsimply map remote-id. For example, if you usethe second form, map 0 would give a remoteroot the same permissions as the local root.

The format of host blocks ishost RFS domain.nodename as in:--

host rfsdemo.sixnine

host blocks can also include default,exclude and map lines. In a host block,map can be followed by the additional keywordall, meaning that all remote user names shouldbe mapped to the permissions of those users withthe same names on your machine.

The gid.rules file has the same generalformat as the uid. rules file, except that nowyou are mapping groups rather than users.

If, when you created the uid.rules andgid.rules files, you referenced any remoteusers or groups by name, you will need t.’opie.~ ofthe remote /etc/passwd andfiles to put in/usr/nserve/aut h. info/d0mai~t/.ode.amedirectories on your machine (note that map allmaps by name). You’ll need to obtain copies ofthese files by any suitable file transfer method(such as uucp), create directories as requiredand install them on your machine.


COLSTON SANGER ~ CALL DOC STRANGE

You ,are now ready to mn idload with the-n option. This will print a listing of the mappingrules without creating the translation tables:

## idload-nTYPE MACHINE REM ID

USRUSRUSRUSRUSRUSRUSRUSRUSRUSRUSRUSRUSRUSR

GLOBALrfsdemo.slxn±nerfsdemo.slxn±nerfsdemo.sxxnxnerfsdemo.sxxnmnerfsdemo.smxnmnerfsdemo.smxnmnerfsdemo.slxn±nerfsdemo.smxnlnerfsdemo.s±xn±nerfsdemo.sixnmnerfsdemo.sixnmnerfsdemo.sixnxnerfsdemo.sixnlne

DEFAULTDEFAULT012345i0377O71124525

REM NAME--

n/an/an/adaemonbinsysadmuucpnuucplistentroubleipcolstondemo

GRPGRPGRPGRPGKPGRPGRPGRPGRPGRPGRPGRP

GLOBALrfsdemoosmxnlnerfsdemo.slxn±nerfsdemo.smxnmnerfsdemo.sxxnmnerfsdemo.smxn±nerfsdemo.smxnmnerfsdemo.sLxnlnerfsdemo.smxnmnerfsdemo.sixnmnerfsdemo.sixnmnerfsdemo.sixnmne

DEFAULTDEFAULT01234612i003o05o0

n/an/an/aotherbinsysadmmaildaemonstaffvisitordemo

If these mapping rules are acceptable, you can runidload without ,any options. This will create thetranslation tables. Finally, run idload -k toprint the mapping rules that are now in effect.

lln the next issue

the next issue, maybe an article on yp.1

LOC ID

transparent600016000112345i0377071294693

transparent60001600011234612200400600

LOC NAME

n/aguest_idgue st_iddaemonbinsysadmuucpnuucplistentroubleipcolstondemo

n/aguest idguest_idotherbinsysadmmaildaemonstaffvisitordemo

I. Yellow Pages is a registered trademark of British Telecomin the UK.


AT&T COLUMN GILL MOGG

AT&T Column

Gill [email protected]

Unix Europe Limited (UEL)blternational House

Ealing BroadwayLondon W5 5DB

Gill Mogg is in Market Communications at Unix Europe Limited.

The guest writer this issue is:

Vijayakumar Vijayaratnam Senior Consultant - AT&T UNIX SoftwareOperation, Europe

Mr Vijayaratnam has been involved with the Information Technologyindustry for the past 10 years. He has developed and provided consultancy inthe area of application/system software, on hardware ranging from PCs tomainframes, running a variety of operating systems. He is currently workingwith Databases and Transaction Processing systems in a UNIX environment.

Transaction Processing - into the Open Systems Environmentby Vijayakumar Vijayaratnam, AT&T UNIX Software Operation, Europe

IntroductionMainframe envirorm~ents have always beenconsidered the appropriate medium for theprocessing of high volume transactions. OpenSystems, specifically the UNIX operating system,have achieved limited penetration in thisparticular field.

Changes in the status quo are, however, underway. Increasingly users have recognised that thecharacteristics of the UNIX System - freedom ofchoice in hardware, freedom of choice of databasesoftware, compliance with industry networkingstandards - are equally essential and benefici~ inbuilding a transaction processing system.

The wider use of the UNIX operating system,coupled with the technological advancements ofUNIX-based data management applications, meansthai it is becoming common for institutions to lookfor UNIX based TP systems to address the needsof their data management environments, with

special emphasis on systems that can provide suchfunctionalities as concurrency controls, resourcemanagement, scheduling and the prioritisation oftasks, normally found on large proprietarymainframe systems.

What is Transaction Processing?Transaction Processing (TP) involves computerapplications which affect us directly in our dailylives. The classic TP example is a hotel or airlinereservation system, in which a person at aterminal talks directly to a computcr databaseabout the actual, up-to-the-minulc r~,om or seatawtilability position while you, the cuslomcr, waitto see if the reservation (ie transaction) isconfirmed. Other applications arc in the financi~and manufacturing areas.

In computer terms, TP systems are designed toprovide the highest throughput in the shortestpossible time to a large user base. The basiccharacteristic of the TP enviroimaent is that users


AT&T COLUMN ~ GH.L MOGG

are often perfomfing si~nilar or identical tasks. Forexample, in a transaction system, many users maybe completing the same order entry screen prior toa customer order being entered in the system. Intiffs instance, the different characteristics of thetraditional UNIX environment ,are immediatelyobvious. Under UNIX, users are performing verydifferent kinds of functions - one may beperforming a compile while another is editing adocument etc.

A second major characteristic of the TPenviromnent is the predictable nature of the input.A TP system is built on a limited number of inputtypes - add, update, query, delete etc. All suchinteraction with the system is performed usingelectronic fomm or screens. In a typicalenvironment there may be between one and ahundred such forms. The duration of interactionbetween the form and the transaction system isvery short, often involving a short program inwhich the input is verified and a response relayedto the user.

TP systems rely to a large degree on a mechanismwhich prioritises the running of the tasks. Oneexample of this is a customer service application,in which the transaction dealing with retrievingthe customer details must have precedence over,say, a task which is performing a managementreport.

The components of TP system include atransaction manager, a database managementsystem and the business application itself. Thetransaction manager provides communicationsand co-ordination in a TP system, the applicationprovides the forms processing and business logic,and the database management system manages thestorage and retrieval of data.

Today, there is a tendency towards distributed TPenvironments, in which users access a number ofdatabases scattered over a wide geographical area.In an environment of tiffs type, there is a need fora system capable of managing tasks in a timelyand efficient manner, as well ,as providing thebasic functionalities such as robustness andconcurrency controls. The system which handlesthis function, the TP MONITOR, is thus an integralpart of the daily activities of all types oforganisations concerned with providing access toa large user base reliant on instantaneous access tostored information.

What is a Transaction?A transaction is a set of operations (a unit ofwork) that results in the transformation of thedatabase from one consistent state to another.This, however, is not how the end user sees it. Inhis terms, the transaction begins with the entry ofdata on a screen or a form, continues with thescheduling of the transaction type through a TPMONITOR which provides the services to therequest, and concludes with a response to the user,often in the form of a report. In a distributedenvironment, the term transaction describes a unitof work that may be composed .of informationgathered from a number of physical locations, butrepresented to the user as a logical unit.

Taking TP into the Open SystemsArenaScepticism about the capabilities of Open Systemsfor TP remains strong. Some organisations arevehement in theft claims that such processing canbe expedited successfully only on proprietarysystems with proven track records. On the otherhand, moves towards a genuine open systemsbased TP platform are already well established.Meeting such a challenge depends on twooperations which are key to open systems ingeneral - the definition of standards, and thedevelopment of products which conform to them.

Standards

In the database realm there is an existing standard- SQL - which defines the interface to thedatabase and allows multiple applications to workon a single database.

TP has been the subject of standards activity forsome time. X/Open’s first group on the matter wasformed as long ago as 1987, and produced aWhite Paper that Summer. The XTP Group, itssuccessor, has continued with the work sinceMarch 1988, with the intention of defining astandard for On-Line, Transaction Processing(OLTP). A second X/Open working group, theData Management Working Group (I)MWG),concentrates on the specification of standards fordatabase enviromnents. The goal of the twogroups is to define a TP model and a common setof interfaces that will enable providers of TP andDB systems to achieve the objectives of opensystems, by providing applications that conform tothese interface standards.


AT&T COLUMN ~ GILL MOGG

Three axioms represent the basis of the TPstandards work undertaken by the X/Opencommittees: interoperability, portability andinterchangeability. Interoperability is the capacityto write transaction programs that draw on theresources of several different Resource Manager(RMS), perhaps at different sites, and perhapsproduced by different vendors. Customers will beable to perform multi-site update to heterogeneousRMS. The portability of applications is designed toensure that customers can move their X/Opencompliant code to different systems withoutchanges. Interchangeability is the facility toexchange RMS without having to rewritetransaction programs, to support standards thatX/Open has previously endorsed (such as SQL andIndexed Sequential Access Method, ISAM), and topermit a compliant system to operate in theframework of other standards, such as the ISO/TPprotocols. As a result, tile current workundertaken by the committees will preserve, as faras possible, existing RM interfaces.

The work of the XTP committee has so far yieldeda model for distributed transaction processing(DTP), which will work well even in a non-distributed environment, and a set of routines,collectively known as the XA interfaces, that willenable RMS to communicate with TMS effectivelyin a heterogeneous environment.

The DTP model has three functional components:

The Application Program (AP), defmestransaclions and supervises the actions thatconstitute a transaction

The Transaction Manager (TM) assigns a globaltransaction identifier to transactions, monitors theprogress of transactions, decides whether atransaction can be committed, and performsfidlure recovery.

The Resource Manager (RM), such as databasesor l’de systems, uses shared resources as directedby the AP. This service interface may be SQL orISAM. The TM also calls the RM to declare start,end and disposition of transactions.

For an Open System policy to operatesuccessfully, all the above components must beable to communicate with one other. Theapplication to RM interface is provided bystandard SQL, while a vital element of thestandard model is the XA Interface, responsiblefor the TM to RM interface. This incorporates thetechnically important two phased commit protocol

while retaining the SQL interface to the underlyingdatabases. Two phased commit is the key protocolto allow distributed access to a database to makechanges (for example a new flight reservation)while guaranteeing data integrity in casesomething goes wrong in the middle (for example,a tunnel project cuts the phone line). The XAInterfaces have been adopted as the standard forAP to RM interfaces, and are to be published inthe X/Open Portability Guide.

AT&T has proposed an extension to the standardmodel called the Application TransactionManagement Interface (ATMI), which gives theprogrammer transparent access to networkcommunications primitives, automatic dataconversion and transaction control operations.This covers the interface between the AP and TM.

All of this activity demonstrates that the movetowards an Open Systems TP standard is by nomeans a recent undertaking. Instead, as a result ofthe work of X/Open, a superstructure is in place towhich products under development at the presenttime can meaningfully conform.

ProductsAs we saw, the successful implementation of anopen OLTP system depends on the availability ofcompatible products in three areas: the database,the application and the transaction manager. Withthe expansion of the UNIX system as a viableoperating system for database and busihesstechnology applications, state of the art productsare appearing, all of which conform to recognisedstandards. One example of this is the largenumber of database products from the majorindependent software vendors, such as ORACLE,INFORMIX and EMPRESS, which alreadyincorporate the SQL standard.

Unlike SQL, an OLTP standard is a newphenomenon, and products are just starting to beannounced in the marketplace. There is everyreason for confidence that as these products maketheir impact on the market, the long standing mythof UN1X’s weakness as a TP environmcu! will

tvamsh from memory!

TUXEDO - The Transaction ProcessingManager for UNIX System V

The TUXEDO (TM) system recently announced byAT&T’s UNIX Software Operation meets theX/Open standard and provides an open,distributed TP monitor available to computer


GILL MOGGAT&T COLUMN

manufacturers and applications vendors. TUXEDOhas been designed to exploit the strengths of UNIXSystem V in networking to allow the distributionof OLTP applications across networks and acrossmultiple servers in multiprocessor systems. Thesemultiprocessors, exploiting RISC chip technology,will provide the high capacity databases servingover a thousand simultaneous users which have upto now required the expensive mainframes fortheir solutions.

TUXEDO System V Release 4.0 incorporates two

components that can be licensed and deployedseparately: the System/r Transaction Managerand the System/D DBMS. Both componentsincorporate the XTP transaction model, includingthe XA interface which allows TUXEDO System/Tto control transactions for compliant vendordatabases while retaining their native SQLinterface. It also incorporates the ATMI interface,which. AT&T has proposed as a standardapplication interface for transaction processing.

Article republished courtesy of SystemsIntemational magazine.

! % @:: A Directory to Electronic Mail Addressing and Networks Second Edition, 1990The new 1990 edition of !%A:: A Directory of Electronic Mail Addressing and Networks, by DonnalynFrey and Rick Adams will be available in June, 1990. This new edition provides readers with a directoryand usage guide to over 130 of the world’s research and educational networks, as well as commercialnetworks. The network information has been updated for 1990, with many new networks added. Thedirectory makes it easy for readers to find networks they can use to reach other people around the worldand guides readers in how to use them. It also assists readers in finding someone’s email address andsending mail. The book is in an easy-to-use short reference format.

The directory is of use to system administrators who field electronic mail questions, network adininistratorswho work with networks in other countries, researchers who want to get in touch with other researchers,conference attendees with many contacts, and others who routinely send email. Each network sectioncontains general information about the network, as well as address structure and format, connections toother sites or networks, facilities available to users, contact name and address, cross references to othernetworks, network architecture, future plans, date of the last update, and a map showing the networklocation. Also included is a three-way index to network name, network type, and country, as well as a listof many of the word’s second and third level domains.

This new edition contains:

information on new networks such as AlterNet, CANET, CA*net, EASInet, InterEUnet, IX!,MFENET-II, TUVAKA, XL1NK, and YNET

updated information on networks that are reorganizing or have reorganized, such as BIONET, ESNET,MFENET, NYSERnet, and OnTyme

information on networks in the Soviet Union, Eastern European countries, and the People’s Republic ofChina

networks not in the first edition, such as ATT Mail, K_REOnet, and SCIENCEnet

updates of most of the existing networks described in the first edition which was published in 1989.

This new edition is the most up-to-date guide for directing your electronic mail; it is a real lime saver. Thebook will continue to be updated every ten to twelve months. Readers who fill out the response card in thebook have the option of either receiving notification of updates or receiving the updated editionautomatically at a 25% discount.


PUZZLE CORNER ~ MICK FARMER

Puzzle Corner

Mick [email protected]

Birkbeck CollegeMalet St

London WC1England

Mick is a lecturer at Birkbeck College (University of London) and theSecretary of the UKUUG. His interest is in all aspects of Distance Learningand he is the Senior Consultant (Software) for LIVE-NET, an interactivevideo network connecting London’s colleges. He is also a metnber of theUniversity’s VLSI Consortium, mainly because the design tools draw suchpretty pictures.

Hello peeps,

Solution to Puzzle Number 10

If two thirds (40/60) failed on Compilers and threequarters (45/60) failed on Graphics then theminimum number failing both is 25/60 of the class(the maximum number may be much higher). Inaddition, if four fifths (48/60) failed on Networksthen the smallest number now failing is 13/60 ofthe class. This fraction equals 26 students, whichmeans 120 students failed.

Solution to Puzzle Number 11This is ,another simple problem solvable on paper,or using something like Prolog. There are threepossibilities given the basic facts. The uniquesolution gives Ms Portuguese offering French ,andHungarian.

A complete solution is available to anyoneinterested.

l’uzzle Number 12

A flat roof tile 10" × 4" x 3/16" weighing two lbs.re.sls, with ils long dimension along along theslopc, on a smooth wooden roof having an angle

of 20 degrees to the horizontal as illustrated inFigure 1.

Figure 1 The Creeping Roof Tile

The tile is not attached to the roof, but is keptfrom sliding down by its friction, the coefficientbeing 0.5. In the morning of a winter day the tileis at a temperature of 0°F. During the day it iswanned by the sun to 50°F, and at nightfall it isagain chilled to 0°F. After such a cycle of" heatingand cooling, will the tile have moved from itsmorning position by the end of thc day, and if so,how much mid in what direction? Assume the tilehas a them~al coefficient of expansion of 6 × 10-6

inches per inch per degree and no expansion ofthe roof.


PUZZLE CORNER ~ MICK FARMER

Puzzle Number 13

I recently came across an old-fashioned toasterthat had two heating elements, one on each side,with a door on each side to hold the toast. Thusonly one side of the bread could be toasted at atime, but two pieces could be toastedsimultaneously. It takes two hands to insert orremove each slice. To tum the slice over it ismerely necessary to push the toaster door all theway down, and allow the spring to bring it back.Thus two slices can be turned at the same time;but only one can be inserted or removed. The

time to toast a side is exactly 0.50 minutes. Timeto turn over is 0.02 minutes. Time to removetoasted slice and place on plate is 0.05 minutes,and the time to take a slice of bread from the plateand put it in the toaster is 0.05 minutes. Theproblem is to find the shortest possible timerequired to toast three slices of bread on bothsides, starting with bread on plate, and retumingtoast to plate. Assume the toaster is warmed andready to go.

Loads-a-puzzles,

Mick


A NEW DATA ENCODING SCHEME ~ CHEESE AND ONIONS

A New Data Encoding Scheme

Andrew B [email protected] P Onions

[email protected]

Computer Science DepartmentNottingham University

Nottingham.

IntroductionThe computer industry from its very inception hasused the binary systetn to represent all types ofinformation. This system has much to recommendit’s use. It is simple to construct hardware basedupon this system and all the normal arithmetic andlogical operations can be performed upon it.

However, it is the authors opinions that thissystetn is not as optimal as it could be and thatsome rather simple changes to the method ofencoding data can bring about large increases instorage, communications and reliability.

The IdeaThe basic ideas stem from the seemingly simpleidea of replacing the binary method of encodingby a different scheme. In essence, all that isrequired is to take the value normally representedby a 1 or true state, and replace this with two O’sor false states, e.g.

decimal binary new scheme9 1 00 1 000 00013 1 1 0 1 0000000

At first sight there doesn’t seem to be ~nuch of anadvantage in this scheme of encoding but as therest of this paper will attempt to prove, thebenefits are enormous when applied in the properway.

This method, whilst not bin,try is also not strictlyunary. It has therefore been christened sesquinary(from sesqui - one and a half).

ApplicationsFile Storage

An intelligent operating system can make greatuse of the encoding. As an example, a file neednot be stored as the complete set of bits. All that isrequired is for the operating system to keep countof the "number" of zero’s in the file. In the caseof the UNIX System this would mean that theentire disc would consist of inodes. Each inode,instead of referencing blocks would keep a countof the number of zeros. For large files, double andtriple indirection could be applied - see thesection below on compression. Obviously,’ forsmall files, the single indirection is more cost-effective but with larger files it would pay tomove towards more indirection as a saving ofspace. A flag in the inode could keep count of thenumber of indirections currently performed.

This scheme does have some overhead in theupdating of random access files, in that theoperating system must first "unpack" the file,perform the update, and then repack the file. Thiscould probably be done in virtual memory formost operations though.

Networking

In networking, this method reMly comes inlo it’sown. To begin with, there are practically nobandwidth limitations. The problems inherent innormal communication over serial and phone linesstems from the ability to detect the transitionsbetween two states. Once this transition isremoved, and the data is in effect transitionless,the bandwidth of the circuit is only reliant on thespeed with which zeros can be pumped down the


A NEW DATA ENCODING SCHEME ~ CHEESE AND ONIONS

fine by the hardware (and the rate at wtfich theycan be received of course).

Another advantage comes in the standard ethemetenvironment. Normally an ethemet transceivermust wait for a clear slot to arrive, transmit thepacket and detect if a collision occurred, if so itmust retry. With the all zero encoding methodtransmission can take place at any point, there isin effect nothing on the ethemet that can scramblethe signal as all hosts are transmitting zeros.

Compression

As hinted at above the possibilities forcompression are fantastic. You can forgetHuffman encoding and Lempel-Ziv can take aw,’dk! The compression techniques can reduceany amount of data to 1 number, although thatnumber may be larger than the convenient wordsize of a given architecture. The basic algorithm isoutlined below.

while (length (data) > i) {

data = count zeros (data) ;

iteration ++;

)return iteration;

This can be also be changed to do essentially theabove but in N steps for large files.

Hardware

It is expected that there may be someimplementation problems associated with thehardware of this device. However, the benefitsappear to outweigh the drawbacks in many ways.To begin with, the memory using this techniqueshould be simple. There is no need to invert bits orto even sense the bits - they should all be zero,anyway. Memory failure can be detected veryeasily, no need for complex CRC checks - any 1bits are obviously due to failing memory.

Another advantage is that all memory iseffectively permanent, as there is no state to besaved. This means computers built using thismodel should be unaffected by power-outs and beimpervious to crashes.

Encryption

This scheme also seems to lend itself to dataencryption. The details have not been fullyworked out and may appear in a second paperonce the decrypfion algorithms have beenstraightened out.

Parallelism and Data-flow

Again, this method has more advantages forparallel hardware. Shared memory is particularlyeasy to implement for the same reasons that theethemet is easy - effectively there are no changesin memory state so collisions can’t happen (unlessdefective memory is present).

ImplementationThere have been some doubts raised about thehardware realisation of this technique, but ingeneral this can probably be attributed either tothe resistance to change generally found, or bymanufacturers protecting their own interests. Thevast benefits that this method seems to havethough should mean that once it is taken up it willclean up in the computer industry.


Rules of AUUG Incorporated

NAMEThe incorporated association shall be known as the AUUG Incorporated,abbreviated hereinafter to AUUG.

,(1)

(2)

(3)

(4)

DEFINITIONSIn these rules, unless otherwise stated:"he", "him" and "his" shall also be construed to mean "she", "her" and "her"respectively;"The Act" means the Associations Incorporation Act 1981 (Vic);"Financial year" means the period from 1 June to 31 May;"General Committee Member" shall mean a general member of the ManagementCommittee;"mail" shall imply the transmission of information in written or printed form,first-class pre-paid, via the general post or public or private courier service;"unfinancial member" shall mean any member whose most recent term ofmembership has expired and who has not yet paid the subscription for the nexttwelve month period;"voting member" shall mean any member entitled to cast a vote.

In these Rules, a reference to the secretary of the AUUG is a reference:(d) where a person holds office under these Rules as Secretary of the AUUG, tothat person; and(e) in any other case to the Public Officer of the AUUG.Words or expressions in these rules shall be interpreted in accordance with, andsubject to, the Act as in force from time to time.If any doubt arises as to the proper construction or meaning of any clauses inthese Rules, the decision of the Management Committee thereon shall be finaland conclusive provided such decision be reduced to writing and recorded in theminutes of a meeting of the Management Committee.

,

AIMS

The aims for which the AUUG is established are to promote knowledge andunderstanding of Open Systems including but not restricted to the UNIX system,networking, graphics, user interfaces and programming and developmentenvironments, and related standardsFor the furtherance of these aims and to achieve its purposes, the AUUG maycarry out any or all of the following activities: conduct technical meetings,conferences, discussion groups, panels, lectures and other types of meeting;prepare and distribute a newsletter and other publications; collect software anddistribute said software to its members for their use; verify licences of membersfor the purposes of administering the services of the AUUG; subscribe to orcooperate with or affiliate with or amalgamate with other associations formedelsewhere with similar aims; accumulate assets; and establish and promote otheractivities not included in the above list consistent with its aims for the benefit ofits members.


.

.

.

,

(1)

(2)

(1)

(2)

(3)

(4)

(5)

(6)

ELIGIBILITY FOR MEMBERSHIP

Any individual or organisation who subscribes to the aims of the association, andwho agrees to be bound by its rules and regulations and who has not beenpreviously expelled from the association shall be eligible to join the AUUG.

An application for membership shall be in writing on the form approved by theManagement Committee and shall provide such information as shall from timeto time be prescribed by the Management Committee.

Membership shall become current on the first day of the month following thedate on which a valid membership application accompanied by payment of theappropriate entrance fee plus annual membership subscription is received by theSecretary, and shall continue for twelve months from that date.

Upon completion of the initial membership period and any subsequent periods,membership may be renewed for a further period of twelve months by paymentof an additional annual membership subscription.

There shall be four classes of members: Ordinary members, Institutionalmembers, Student members and Honorary Life Members.Any natural person who is eligible to be a member may become an OrdinaryMember.Any person or organisation who is eligible to be a member may become anInstitutional Member.Any full-time student who is eligible to be a member may become a StudentMember.Any person who is an Ordinary Member of at least five years standing and whohas rendered special services to the AUUG may be elected via a ballot of themembers as an Honorary Life member.If before the first day of May the Secretary receives a petition from at leasttwenty voting members requesting the election of a member of the AUUG to theposition of Honorary Life Member, then he shall arrange a ballot of themembership on this question to be conducted in conjunction with the annualelection of Officers and General Committee Members.

All Ordinary, Institutional and Honorary Life Members whose membership iscurrent shall be entitled to cast a vote.

,

10. (1)

(2)

MEMBERSHIP SUBSCRIPTIONS AND FEESThe Management Committee shall determine before the commencement of eachfinancial year a scale of fees for entrance to the AUUG, and for annualsubscriptions for each class of members to be applied during that financial year.

REGISTER OF MEMBERS

The Secretary shall keep and maintain a register of members in which shall beentered the full name and address of each member and the register shall beavailable for inspection by members at the address of the Public Officer.Nothing in the previous subsection shall entitle any member to make a copy ofthe register of members, except with the permission of the ManagementCommittee, and on such terms and conditions as the Management Committeeshall from time to time determine.


11. (1)

(2)

(3)

TERMINATION OF MEMBERSHIPA member may resign his membership at any time by giving notice in writing tothe Secretary. No member who resigns shall have any claim for a refund ofsubscriptions paid.A member who has been unfinancial for more than two calendar months shall bedeemed to have resigned his membership, and shall no longer be entitled to anyprivileges enjoyed by members.Former members who have resigned will be entitled to rejoin the AUUG on thesame basis as new members joining the AUUG.

12.EXPULSION OF MEMBERS

Upon receipt of a petition so requesting from twenty or more members, or halfthe membership, whichever is less, the Management Committee shall call uponany member to explain any alleged misconduct, and the Management Committeeshall have power to suspend or expel any member who in its opinion has eitherbeen guilty of misconduct or has acted prejudicially to the interests of the AUUGor who has wilfully infringed any of the Rules of the AUUG.

13.

14.

15. (1)

(2)

(3)(4)

16. (1)

GENERAL MEETINGSThe Annual General Meeting shall be held within the second half of eachcalendar year. The date and general location of each Annual General Meetingshall be determined at the preceding Annual General Meeting but either the dateor location or both may be changed by the Management Committee if it provesimpossible or highly inconvenient to meet at the location previously selected oron the date previously selected.

An ordinary general meeting of the AUUG shall be called by the ManagementCommittee in conjunction with any technical meeting or conference or otherfunction where attendance by a quarter or more of the voting members isexpected by the Management Committee.

Written notice of the time and place for each meeting and its agenda shall bemailed to each voting member of the AUUG at least four weeks before the dateof the meeting.Business conducted at such meetings shall be confined to matters included in thewritten agenda, reports from Officers, and resolutions instructing theManagement Committee to conduct a formal ballot of the membership onmatters of substance. Such resolutions shall not be binding on the ManagementCommittee unless the meeting was attended by at least twenty voting members,or half the membership, whichever is less, and the resolution was supported byat least three-quarters of the members voting.All voting members shall be entitled to cast one vote.Any voting member may award his proxy to another voting member for theperiod of a single General meeting providing he so notifies the Secretary inwriting at least 24 hours before the appointed time of commencement of themeeting.

Upon receipt of a petition so requesting from twenty or more members, or halfthe membership, whichever is less, the Secretary shall call an Extraordinary


(2)

(3)

(4)

17. (1)

(2)

(3)

18.

General meeting of the AUUG for a date no later than two calendar months afterreceipt of the petition.The business of the meeting shall be confined to matters described in the petitionand to other matters specifically provided for in these rules and recorded in thewritten agenda sent to all members by mail at least four weeks before the date setfor the meeting.If the Management Committee does not cause a a special general meeting to beheld within two months after the date on which the petition is sent to the addressof the Secretary, the members presenting the petition or any of them, mayconvene a special general meeting to be held not later than four months after thedate of that petition.A special general meeting convened by members in pursuance of these rulesshall be convened in the same manner as nearly as possible as that in which thosemeetings are convened by the Management Committee and all reasonableexpenses incurred in convening the meeting shall be refunded by the AUUG tothe persons incurring the expenses.

For each general meeting, the quorum shall be fifty members personally presentand entitled to vote.If within an hour after the appointed time for the commencement of a generalmeeting, a quorum is not present, the meeting if convened upon the requisitionof members shall be dissolved.In other cases the meeting shall be deferred to a place and time determined bythe Management Committee. If that meeting is to be at the same location on thefollowing day then notice of the meeting may be given by posting a notice at thelocation specifying the time of the meeting and the business to be conducted noless than four hours before the time of the meeting. In any other case notice shallbe given as for any other General Meeting.

At all general meetings of the AUUG the Chair shall be taken by the President,or in his absence, the Vice-President, or in his absence by a member elected bythe meeting.

19.OFFICERS

The Officers of the AUUG shall be: the President; the Vice-President; theSecretary; the Treasurer; the Returning Officer; and the Assistant ReturningOfficer.

20.

MANAGEMENT COMMITTEE

The management and control of the business and general affairs of the AUUGshall be vested in a Management Committee of nine members, namely: thePresident; the Vice-President; the Secretary; the Treasurer; and five GeneralCommittee Members.

21. (1)

(2)

ELECTIONSThe election of Officers and General Committee Members shall be by a postalballot held annually.Nominations for each position shall be received by the Secretary up until thefourteenth day of April each year. Each nomination must be in writing, mustname the position or positions sought, must be signed by at least three voting


22.

(3)

(4)

(5)

(6)

(7)

members, and must be countersigned by the nominated member who must be afinancial voting member of the AUUG.Where only one valid nomination is received for a particular position by the closeof nominations, the nominee shall be declared elected forthwith, and no ballot forthat position shall be held.

Any position for which no nomination is received, or which remains unfilledafter the election has been conducted, shall be considered as a vacancy on theManagement Committee, and handled as specified in these rules.On or before the first day of May, the Secretary shah advise the Returning Officerof all valid nominations received, and if a ballot is required shall advise him of adate no later than the fifteenth day of May for the ballot for all contestedpositions, and shall provide him with a list of voting members.While any Ordinary Member may be nominated to more than one office orposition, no person shall be elected to more than one position. Ballots shall bedetermined in the following order: for President, for Vice-President, forSecretary, for Treasurer, for General Committee Members, for Returning Officer,and lastly for Assistant Returning Officer.All voting members shall be entitled to cast one vote.

The term of office for all Officers and General Committee Members shall be forone year, from July 1 to June 30.

23. (1)

(2)

(3)

(4)

VACANCIES ON THE MANAGEMENT COMMITTEEThe position of any General Committee Member shall be vacated if the memberfails to attend any Management Committee meeting without furnishing asatisfactory explanation as to the cause of his absence, and if the ManagementCommittee resolves that his office be vacated, or if the member ceases to be amember of the AUUGShould the office of President be vacant, the Vice-President shall becomePresident, and the office of Vice-president shall become vacant instead. If for thisreason, or for any other, at any time any of the other principal Officers (Vice-President, Secretary or Treasurer) be unable to continue in office for any reason,then the Management Committee shall appoint one of their number to the vacantoffice.Should a vacancy occur among the other Officers, or among the Generalmembers of the Management Committee, then the Management Committee shallappoint an Ordinary Member of the AUUG to fill the vacancy.Should a vacancy occur as the result of the creation of a new position, thevacancy shall be filled as specified in these rules.The Management Committee shall make the approval of such appointments anorder of business for the next General Meeting of the AUUG if any such meetingwill be held before the next election of Officers and General CommitteeMembers.

24. (1)(2)

MANAGEMENT COMMITTEE MEETINGSThe Management Committee shall meet formally at least twice per year.Notification of time, place and agenda for each meeting shall be made in writingto each member of the Committee by the Secretary at least four weeks inadvance.


25.

26.

27.

28.

29.

30.

(3) All members of the AUUG are entitled to be present at such meetings, and mayspeak when invited by the Chairman, but only members of the ManagementCommittee may vote.

At meetings of the Management Committee the President shall take the chair, orin his absence, the Vice-President, or in his absence a member of theManagement Committee elected by the meeting.

The quorum for such meeting shall be five. If a quorum is not present at thenominated time for the start of the meeting, the commencement of the meetingmay be delayed for up to one hour, and if at that time a quorum is still not presentthe meeting shall be dissolved.

Resolutions of the committee shall require a simple majority of the memberspresent and voting. The chairman shall have a casting vote in the event of a tie.

DISTRIBUTION OF INCOME

The income and property of the AUUG however derived shall be applied solelytowards the aims and purposes of the AUUG as set out in these Rules, and noportion thereof shall be paid or transferred directly or indirectly by way ofdividend to any member of the AUUG at any time.

The AUUG shall not appoint a person who is a member of the ManagementCommittee to any office in the gift of the association to the holder of which thereis payable any remuneration by way of salary, fees or allowances.

Notwithstanding the previous section the AUUG may compensate the reasonableexpenses actually incurred by any member in the conduct of the business of theAUUG under the direction of the Management Committee.

31. (1)

(2)

(3)

(4)

CHAFFERS

Ten or more members of the AUUG may petition the Management Committeeto form a chapter of the AUUG.General rules for the organisation, operation, obligations and privileges ofchapters shall be as resolved by the Management Committee or the membershipas a whole from time to time.Each chapter shall appoint a chapter committee consisting of at least a ChapterChairman and a Secretary/Treasurer.The chapter committee may convene meetings consistent with the aims of theAUUG, but may not enter into any financial commitments on behalf of or in thename of the AUUG except with the written approval of the ManagementCommittee.

32.AFFILIATION OR AMALGAMATION WITH OTHER ORGANISATIONS

The Management Committee may at any time seek or discuss the possibility ofaffiliation or amalgamation with any other organisation whose aims are similarto or compatible with those of the AUUG. No agreement for affiliation oramalgamation may be finalised until the matter has received the assent of three-quarters of the members voting in a postal ballot.


33. (1)

(2)

(3)

34.

DISSOLUTION OF THE AUUGUpon receipt of a petition requesting the dissolution of the AUUG from twentyor more members, or half the membership, whichever is less, the Secretary shallarrange for the question to be put to the membership by ballot no later than onemonth after the date that he receives the petition.If three-quarters of the members voting agree, the AUUG shall be dissolved.If upon the dissolution of the AUUG there remains after satisfaction of all itsdebts and liabilities any property whatsoever, the same shall not be paid to ordistributed among the members or Chapters if any, but shall be given ortransferred to some public educational institution, or other institution to bedetermined at or before the time of dissolution by resolution of the membership.

CHANGES TO THE RULESChanges to these Rules may be initiated at the request of a General meeting, orby the Management Committee. All proposed changes must be approved by athree-quarters majority of the votes received in a postal ballot of the membersbefore having effect.

35. (1)

(2)(3)

36. (1)

(2)

(3)(4)

37. (1)

(2)

(3)

(4)

RIGHTS OF MEMBERSEach member shall be entitled to attend all meetings of the AUUG, includingmeetings of the Management Committee, provided any prescribed attendancefee is paid.Each member shall be sent a copy of the association’s newsletter.Each member entitled to vote in a ballot shall be sent notice in writing of allballots and copies in writing of the annual reports of the Secretary and Treasurer.

THE SECRETARYThe Secretary shall furnish to the Returning Officer a complete list of all votingmembers whenever this is required for the conduct of a ballot.The Secretary shall keep or cause to be kept full and correct minutes of allresolutions and proceedings at General meetings and Management Committeemeetings of the AUUG.The Secretary shall conduct correspondence on behalf of the AUUG.The Secretary shall, during his last month of office, prepare a written report onthe state of the affairs of the AUUG for distribution to the membership.

THE TREASURERThe Treasurer shall keep or cause to be kept correct accounts and books andrecords showing the financial affairs of the AUUG.The Treasurer shall notify the President and Secretary in writing of the usuallocation of said accounts, books and records whenever this location is changed.The Treasurer shall receive all fees and subscriptions and all other monies onaccount of the AUUG and provide receipts for the same. The Treasurer shalldeposit all monies received into a bank account maintained by the AUUG.The Treasurer shall receive accounts for payment for services rendered to theAUUG, and as directed by the Management Committee arrange for paymentfrom the AUUG’s account.


(5)

(6)

The Treasurer shall, during his last month of office, prepare or cause to beprepared a written report on the financial affairs of the AUUG for distribution tothe membership.The accounts and books referred to in sub-clause (1) shall be available forinspection by members.

38.

39. (1)

(2)

(3)

FUNDS

The funds of the AUUG shall be derived from entrance fees, annualsubscriptions, donations and such other sources as the Management Committeedetermines.

Signing Officers for the AUUG’s accounts shall be the President, the Vice-President, the Secretary, the Treasurer and one other General CommitteeMember chosen by the Management Committee.All cheques, drafts, and other orders for payment of money out of the funds ofthe AUUG, if for less than a limit established by the Management Committee,may be signed by only one Signing Officer.For other amounts, each such instrument must be signed by at least two SigningOfficers.

40. (1)(2)

SEAL

The Common Seal of the AUUG shall be kept in the custody of the Secretary.The Common Seal shah not be affixed to any instrument except by authority ofthe Management Committee and the affixing of the Common Seal shall beattested by the signatures either of two members of the Management Committeeor of one member of the Management Committee and the Public Officer of theAUUG.

41.

EXECUTION OF CONTRACTS

The Management Committee, except as otherwise provided in these Rules, mayprospectively or retroactively authorise any Officer or member of the AUUG toenter into any contract or execute and satisfy any instrument, and any suchauthority may be general or confined to specific instances, except that anycontract whose dollar value exceeds an amount predetermined by theManagement Committee must be specifically authorised in advance by theManagement Committee.

42. (1)

(2)

(3)

(4)

VOTING

All voting by the members with respect to the election of Officers and GeneralCommittee Members, with respect to the election of Honorary Life Members,with respect to changes to these Rules, and all other substantive matters shall beconducted by postal ballot.Every voting member of record as of the date of entry of a ballot into the mailsshall be entitled to vote in the ballot.On all questions to be put to a ballot, the Secretary shall designate a date for theballot to be placed in the mails, and the due date shall be four weeks after thatdate.The Returning Officer shall nominate the address to which voters shall returncompleted ballot papers by mail.


(6)

(7)

(8)

A ballot will not be counted if it is received after the due date or if the ballot paperdoes not comply with the instructions printed on it.The ballots will be received by the Returning Officer, and counted by him andthe Assistant Returning Officer.The Returning Officer shall report the result of the ballot in writing to theSecretary no later than two weeks after the due date.The formal procedures of voting shall be determined from time to time by theManagement Committee.


AUUGN Back Issues

Here are the details of back issues of which we still hold copies. All prices are in Australiandollars and include surface mail within Australia. For overseas surface mail add $2 per copy andfor overseas airmail add $10 per copy.

pre 1984 Vol 1-4 various $10 per copy

1984 Vol 5 Nos. 2, 3, 5, 6 $10 per copyNos. 1,4 unavailable

1985 Vol 6 Nos. 2, 3, 4, 5, 6 $10 per copyNo. 1 unavailable

1986 Vol 7 Nos. 1, 4-5, 6 $10 per copyNos. 2-3 unavailable(Note 2-3 and 4-5 are combined issues)

1987 Vol 8 Nos. 1-4 unavailableNos. 5, 6 $10 per copy

1988 Vol 9 Nos. 1, 2, 3 $10 per copyNos. 4, 5, 6 $15 per copy

1989 Vol 10 Nos. 1-6 $15 per copy

1990 Vol 11 Nos. 1-4 $15 per copy

Please note that we do not accept purchase orders for back issues except from Institutionalmembers. Orders enclosing payment in Australian dollars should be sent to:

AUUG Inc.Back Issues DepartmentPO Box 366Kensington NSWAustralia 2033


SESSPOOLE is the South Eastern Suburbs Society for Programmers Or Other LocalEnthusiasts. That’s the South Eastern Suburbs of Melbourne, by the way.

SESSPOOLE is a group of programmers and friends who meet every six weeks or so for thepurpose of discussing UNIX and open systems, drinking wines and ales (or fruit juices if alcoholis not their thing), and generally relaxing and socialising over dinner.

Anyone who subscribes to the aims of SESSPOOLE is welcome to attend SESSPOOLEmeetings, even if they don’t live or work in the South Eastern Suburbs. The aims ofSESSPOOLE are:

To promote knowledge and understanding of Open Systems; and topromote knowledge and understanding of Open Bottles.

(Note that these aims have been updated in line with recent changes to the aims of AUUG Inc.)

SESSPOOLE was the first Chapter of AUUG Inc to be formed, and members of SESSPOOLEwere involved in the staging of the AUUG Summer’90 and Summer’91 meetings.

SESSPOOLE meetings are held in the Bistro of the Oakleigh Hotel, 1555 Dandenong Road,Oakleigh, starting at 6:30pm. Dates for the next few meetings are:

Wednesday, 27th February, 1991Thursday, 18th April, 1991Tuesday, 28th May, 1991

Wednesday, 17th July, 1991Thursday, 29th August, 1991

Hope we’ll see you there!

For more information on SESSPOOLE and SESSPOOLE activities (including a description ofhow much fun it is to book a table in a restaurant under the name "SESSPOOLE"), contacteither David Purdue (ph. (03) 353 3913, e-mail: [email protected]) or John Carey(ph. (03) 587 1444, e-mail: [email protected]), or keep a lookout for announcementsin aus.auug.


AUUG Membership Categories

Once again a reminder for all "members" ofAUUG to check that you are, in fact, a member, and thatyou still will be for the next two months.

There are 4 membership types, plus a newslettersubscription, any of which might be just right for you.

The membership categories are:

Institutional MemberOrdinary MemberStudent Member,

Honorary Life Member

Institutional memberships are primarily intendedfor university departments, companies, etc. This is avoting membership (one vote), which receives twocopies of the newsletter. Institutional members can alsodelegate 2 representatives to attend AUUG meetings atmembers rates. AUUG is also keeping track of thelicence status of institutional members. If, at somefuture date, we are able to offer a software tapedistribution service, this would be available only toinstitutional members, whose relevant licences can beverified.

If your institution is not an institutional member,isn’t it about time it became one? Ordinarymemberships are for individuals. This is also a votingmembership (one vote), which receives a single copy ofthe newsletter. A primary difference from InstitutionalMembership is that the benefits of OrdinaryMembership apply to the named member only. That is,only the member can obtain discounts an attendance atAUUG meetings, etc. Sending a representative isn’tpermitted.

Are you an AUUG member?

Student Memberships are for full time students atrecognised academic institutions. This is a non votingmembership which receives a single copy of thenewsletter. Otherwise the benefits are as for OrdinaryMembers.

Honorary Life Membership is not a membershipyou can apply for, you must be elected to it. What’smore, you must have been a member for at least 5 yearsbefore being elected.

It’s also possible to subscribe to the newsletterwithout being an AUUG member. This saves younothing financially, that is, the subscription price isgreater than the membership dues. However, it might beappropriate for libraries, etc, which simply want copiesof AUUGN to help fill their shelves, and have no actualinterest in the contents, or the association.

Subscriptions are also available to members whohave a need for more copies of AUUGN than theirmembership provides.

To find out if you are currently really an AUUGmember, examine the mailing label of this AUUGN. Inthe lower right comer you will find information aboutyour current membership status. The first letter is yourmembership type code, N for regular members, S forstudents, and I for institutions. Then follows yourmembership expiration date, in the format exp=MM/YY. The remaining information is for internal use.

Check that your membership isn’t about to expire(or worse, hasn’t expired already). Ask your colleaguesif they received this issue of AUUGN, tell them that ifnot, it probably means that their membership haslapsed, or perhaps, riley were never a member at all!Feel free to copy the membership forms, give one toeveryone that you know.

If you want to join AUUG, or renew yourmembership, you will find forms in this issue ofAUUGN. Send the appropriate form (with remittance)to the address indicated on it, and your membership will(re-)commence.

As a service to members, AUUG has arranged toaccept payments via credit card. You can use yourBankcard (within Australia only), or your Visa orMastercard by simply completing the authorisation onthe application form.


AUUG incorporated

A s ralian UNIX* systems Users’ Group.*UNIX is a register~ 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, or credit card authorisation, to:

AUUG Membership SecretaryP O Box 366Kensington NSW 2033Australia

¯ Foreign applicants please send a bank draft drawnon an Australian bank, or credit card authorisation,and remember to select either surface or air mail.

This form is valid only until 31st May, 1991

................................................................................................ does hereby apply forNew/Renewal Institutional Membership of AUUG $325.00

International Surface Mail $ 40.00

[] International Air Mail $120.00

Total remitted

Delete one.

AUD$(cheque, money order, credit card)

I/We agree that this membership will be subject to the rules and by-laws of the AUUG as in force from timeto time, 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/We understand that I/we will receive two copies of the AUUG newsletter, and may send tworepresentatives to AUUG sponsored events at member rates, though I/we will have only one vote in AUUGelections, and other ballots as required.

Date: / / Signed:

Title:[] 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 charge $ to my/our [] Bankcard [-] Visa IS] Mastercard.Account number:_ . Expiry date: /

Name on card:

Office use only:Chq: bankDate: / /Who:

bsb - a/c #$ CC type __

Signed:

Please complete the other side.

Member#


Please send newsletters to the following addresses"

Name" Phone" ¯ .... (bh)Address: .......................................... (ah)

Net Address"

Name"Address"

Phone" .. (bh).......................................... (ah)

Net 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.

[] System V.3 source

[] System V.2 source

[] System V source

[] System III source

[] 4.2 or 4.3 BSD source

[] 4.1 BSD source

[] V7 source

Note: Recent licences usally revoke earlier ones, please indicate only licences which are current, and indicate

any 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 binary

[] System V.2 binary

[] System V binary

[] System III binary

[] Other (Indicate which) .................................................................................................................................


Application Ordinary, or S uden , MembershipAustralian UNIX* systems Users’ Group.

UNIX is a r~istered trademark of AT&T in the USA and other ~untries

To apply for membership of the AUUG, complete this form, and return it with payment inAustralian Dollars, or credit card authorisation, to:


¯ Please don’t send purchase orders -- perhaps yourpurchasing department will consider this form to be aninvoice.¯ Foreign applicants please send a bank draft drawn on anAustralian bank, or credit card authorisation, and rememberto select either surface or air mail.


I, ................................................................................................. do hereby apply for

I-I Renewal/New* Membership of the AUUG $78.00

I-I Renewal/New Student Membership $45.00 (note certification on other side)

E] International Surface Mail $20.00

[] International Air Mail $60.00 (note local zone rate available)

Total remitted

Delete one.


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 the monthfollowing that during which this application is processed.

Date: / / Signed:[] 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.

Please charge $

Account number:

Name on card:

Office use only:Chq: bank

Date: / /

Who:

to my [] Bankcard [--1 Visa Mastercard.

¯

Signed:

Expiry date: /

bsb a/c

CC type __

Member#


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 / / .

Title: Signature:


AUUG incorporatedApplication Newsletter SubscriptionAustralian UNIX* systems Users’ 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:


¯ Please don’t send purchase orders -- perhaps yourpurchasing department will consider this form to be aninvoice.¯ Foreign applicants please send a bank draft drawn on anAustralian bank, or credit card authorisation, and rememberto select either surface or air mail.¯ Use multiple copies of this form if copies of AUUGN areto be dispatched to differing addresses.


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"

CI Subscription to AUUGN

[] International Surface Mail

[] International Air Mail

Copies requested (to above address)

Total remitted

$ 90.00

$ 20.00

$ 60.00


[] Tick this box if you wish your name & address withheld from mailing lists made available to vendors.

I--1 Visa [--] Mastercard.

¯

Signed:

Expiry date: /

CC type __

Subscr#

Please charge $ to my V1 BankcardAccount number:

Name on card:Office use only:

Chq: bank bsb a/c

Date: / / $

Who:


ANotification 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:


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)

......................................................... (ah)

Net Address: .........................................................

New address (leave unaltered details blank)

Name: ........................................................................

Address: ........................................................................

Phone: .........................................................(bh)

......................................................... (ah)

Net Address: .........................................................

Office use only:

Date: / /

Who: Memb#


auug 1990 - preterhuman.net

Documents