Usenet 1994 January

home *** CD-ROM | disk | FTP | other *** search

/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / reports / 1990.08 < prev next >

Wrap

Text File | 1990-10-26 | 135.2 KB | 3,184 lines

echo 1003.0 cat >1003.0 <<'shar.1003.0.23858' From std-unix-request@uunet.uu.net Wed Aug 22 12:18:26 1990 Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP id AA00636; Wed, 22 Aug 90 12:18:26 -0400 Posted-Date: 22 Aug 90 16:07:45 GMT Received: by cs.utexas.edu (5.64/1.71) id AA05386; Wed, 22 Aug 90 11:18:20 -0500 From: jsh@usenix.org (Jeffrey S. Haemer) Newsgroups: comp.std.unix Subject: Standards Update, IEEE 1003.0: POSIX Guide Message-Id: <447@usenix.ORG> Sender: std-unix@usenix.ORG Reply-To: std-unix@uunet.uu.net Organization: USENIX Standards Watchdog Committee X-Submissions: std-unix@uunet.uu.net Date: 22 Aug 90 16:07:45 GMT To: std-unix@uunet.uu.net From: Jeffrey S. Haemer <jsh@usenix.org> An Update on UNIX*-Related Standards Activities August, 1990 USENIX Standards Watchdog Committee Jeffrey S. Haemer <jsh@usenix.org>, Report Editor IEEE 1003.0: POSIX Guide Kevin Lewis <klewis@gucci.dco.dec.com> reports on the July 16-20 meeting in Danvers, Massachusetts: Dot Zero's rite of passage For the first time in plenary, the group walked through the entire guide (221 pages), fine-tuning verbiage. This walk-through takes Dot Zero across a threshold: instead of soliciting content to fill up empty sections, we are now filtering the text we have. I'm proud we've gotten this far. I remember when we started this journey, virtually from scratch. By the time we finished the walk-through, we had found that we needed more structure and parameters: rules to make our walk-throughs more productive. I ended my last report with the statement, ``let's see if we have the self-discipline to get there.'' Here is where some of that self-discipline comes in... we'll see at the next meeting who abides by the rules we have agreed upon. New Volunteers for OS and UI Sections Two other good things happened in Danvers. Tricia Oberndorf is now in charge of the operating system section of the guide. Tricia is project leader for the Navy's Next Generation Computer Resources Operating System Software Working Group (whew!), which has chosen POSIX as its base standard. Heretofore, Jim Isaak had been the section leader. Now that he has greater duties to fulfill, as part of the TCOS ruling class. Tricia has graciously stepped forward to fill his shoes. In addition to this noble deed, Martha (``Marti'') Sczcur (pronounced ``seezur''), from NASA, and Ruth Klein, from AT&T, have picked up the user interface section, which, up until the April, Utah meeting, had lain untouched for almost two years. These are welcome resources. Both of these welcome volunteers made significant contributions, to the user-interface section of the recently published draft 8 -- __________ * UNIXTM is a Registered Trademark of UNIX System Laboratories in the United States and other countries. August, 1990 Standards Update IEEE 1003.0: POSIX Guide - 2 - contributions woefully lacking in draft 7, What Will We Cut and What's a Profile? Toward the end of my last report, I stated that Dot Zero still faced hard decisions in two areas: guide content and profiles. I think guide content questions will resolve themselves as we move toward the mock ballot. Deadlines, like moving your household, have a tendency to make you throw away stuff that you otherwise might have kept. Given our goal of an early 1991 mock ballot, I think we will see a change in our ``pack rat'' mentality. You might be wondering what might find itself on the editing-room floor. I can offer two sections: Data Interchange and Graphics, whose demise might come about due to a lack of interest by anyone in the committee to contribute to them and move them along. There also seems to be a lot of redundancy. Good examples of this are the sections I am responsible for: Introduction and Scope. The guide seems to say the same thing in each of these sections but struggles to make it sound different. The fine tuning efforts will root this out. We're still debating profiles, but a consensus is forming around the term POSIX profile. Dot Zero agrees we must define such a profile, but its elements still elude us. (This gets into the debate about whether a ``true'' POSIX profile needs to include 1003.1. Right now, there is only one POSIX standard, and it would seem to make sense that a POSIX profile should include it. However, there are convincing arguments to the contrary, such as a profile that specifies 1003.2 (shell and tools) compliance on DOS machines, which cannot support 1003.1. I think POSIX profiles should include some POSIX standard, but not any specific one.)_ Also, should Dot Zero make mandatory rules for profile writers, or just offer basic guidelines? These two topics will serve as the focus for much of our discussion in the October, Seattle meeting. For uniform resolution of our debates about profiles, we will meet and coordinate with representatives of the other working groups, particularly the profile groups. (Right now, that's real-time, supercomputing, multiprocessing, and transaction processing.) This will also help ensure that we hear all issues and key points of view. The primary debate here focuses on whether Dot Zero should attempt to put ``teeth'' into the guide. Does Dot Zero, because of its goal in providing guidance to profile writers, have any say about the legitimacy of current or future profiling efforts? How extensive should this guidance be? How does Dot Zero provide guidance in an area where it lacks technical expertise? These kinds of questions frame the debate. [Editor: What do you think the answers are to these questions? Speak up. If you don't go, and don't have anyone else to tell, at least tell Kevin.] August, 1990 Standards Update IEEE 1003.0: POSIX Guide Volume-Number: Volume 21, Number 49 shar.1003.0.23858 echo 1003.10 cat >1003.10 <<'shar.1003.10.23858' From std-unix-request@uunet.uu.net Wed Sep 5 15:20:50 1990 Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP id AA19450; Wed, 5 Sep 90 15:20:50 -0400 Posted-Date: 5 Sep 90 19:07:46 GMT Received: by cs.utexas.edu (5.64/1.76) From: jsh@usenix.org (Jeffrey S. Haemer) Newsgroups: comp.std.unix Subject: Standards Update, IEEE 1003.10 and 1003.15: Supercomputing and Batch Message-Id: <485@usenix.ORG> Sender: std-unix@usenix.ORG Reply-To: std-unix@uunet.uu.net Organization: USENIX Standards Watchdog Committee X-Submissions: std-unix@uunet.uu.net Date: 5 Sep 90 19:07:46 GMT To: std-unix@uunet.uu.net From: Jeffrey S. Haemer <jsh@usenix.org> An Update on UNIX*-Related Standards Activities September 4, 1990 USENIX Standards Watchdog Committee Jeffrey S. Haemer <jsh@usenix.org>, Report Editor IEEE 1003.10 and 1003.15: Supercomputing and Batch An anonymous correspondent reports on the July 16-20 meeting in Danvers, Massachusetts: P1003.10 Supercomputing AEP Scope synopsis: write an Application Environment Profile (AEP) for supercomputing, and work with other POSIX groups to define additional interfaces where required. What an AEP is and what it must contain are still under development - - making it impossible to know when the work will go to ballot. POSIX.10 met two separate times in Danvers with POSIX.0 (which is writing a ``guide for profile writers'') and other profile groups. While we all agree that a profile is a list of standards, other aspects are unclear. For example, it was asserted previously that AEPs must be ISO Standardized Profiles (ISP), but it was suggested in July that there may be a POSIX Standardized Profile (PSP), or maybe a Preliminary PSP (PPSP). POSIX.0 is also undecided about whether an AEP should contain conformance testing information, or what might comprise such information. If extensive conformance testing is required for the 50-plus standards cited in the current POSIX.10 draft, the effort could take many years. Whatever the decisions, the progress POSIX.0 and ISO make in defining an AEP is the upper bound on the progress any profile group can achieve. In Danvers, POSIX.10 looked again at the numerical accuracy issues, including a proposal to ANSI X3T2 from DEC called a Language- Compatible Arithmetic Standard (LCAS), which may or may not be useful to supercomputing. POSIX.10 will request formal liaison with X3T2 to ensure that we keep current with developments in this area. The conflict between portability and performance improvements from __________ * UNIXTM is a Registered Trademark of UNIX System Laboratories in the United States and other countries. September 4, 1990 StIEEEr1003.10tand 1003.15: Supercomputing and Batch - 2 - proprietary formats is not easy to resolve, but is of paramount interest to numerical, supercomputing applications. This issue will not go away, though it may be impossible for the first release of this profile to make any meaningful statements about it. This working group also discussed Jim Isaak's article, ``Application Environment Profiles: a Significant Tool for Simplification and Coordination of the Standards Efforts'' (IEEE Computer, February 1990). Not only must profiles be complete, says Jim, they must be coherent. A profile may need to act like a glue, specifying not just lists of standards, but interactions of different standards on a single system. The working group will put all the standards it cites into a triangular matrix to identify potential interactions. As each interaction is identified, the group will examine the effects on coherence by looking more closely at parameters, options, and behaviors, to determine if additional interface standards are required. POSIX.10 must also pass proposals for standards extensions on to other working groups. A proposal for an Application Program Interface (API) for checkpoint and restart has been submitted to POSIX.1; they returned it with a request for substantial modification, but this writer understood them to agree that they will polish and ballot the interface. A proposal for a resource-limits API is also in preparation, and will be discussed further at the next meeting. Proposals for a resource reservation system, a removable/non-sharable media system (nine-track tape, cartridge tape, CD-ROM, etc.), and resource accounting also need to be done. These interfaces need to be done soon, because the batch group (POSIX.15) needs the underlying functionality to support batch processing. P1003.15 Supercomputing Batch Extensions Scope synopsis: define API, user commands and system administration commands for a networked batch queueing system; current draft is based on NQS sold by COSMIC at Univ. of Ga. POSIX.15 has the same chair as POSIX.10 (Karen Sheaffer from Sandia Livermore), but now has a separate vice chair and secretary. The group has grown to 15-20 regular participants in the batch discussions, and now includes active participation by more vendors. Their latest draft is very close to the page layout of the other POSIX documents, which is important for acceptance by the other groups. Jim Isaak spoke to the group in Danvers, and helped them to understand the balloting process and the relation of their Program Authorization Request (PAR) both to their own efforts and to the efforts of other September 4, 1990 StIEEEr1003.10tand 1003.15: Supercomputing and Batch - 3 - groups. A very important -- but very thorny -- issue for this group is the definition of a host-to-host request/reply protocol. In the first place, there are no other POSIX host-to-host protocols that this group can use as a model for how to write its spec. In the second place, numerous participants are dissatisfied with the NQS protocol: it simply doesn't carry enough information. HP, in particular, is working very hard to ensure that the load balancing aspects of their Task Broker system are not excluded by anything in the batch standard, and for that they need more information to be exchanged between hosts. Another problem facing this group is the lack of an API for resource limits, resource reservation, and resource accounting beyond basic UNIX accounting. Based on the balloting in POSIX.2, they can expect balloting objections against statements in their document which refer to these features until the interfaces are in place. Just before the close of the meeting, a representative of POSIX.7 presented some questions about the current direction of the batch effort and its relation to the Palladium print system (the Athena print system used at MIT). Many current NQS sites queue print requests with NQS, and there has been some interest in defining printing features. That function, however, is clearly within POSIX.7's scope. It is reasonable for POSIX.7 to question if and how Palladium and NQS are compatible. POSIX.15 meets eight times a year, with interim meetings about midway between the quarterly POSIX meetings. It would be in their interest to publicize these meetings, and to arrange them through the IEEE. (Following the October POSIX meeting, there will be one December 4-6 in Huntsville, AL hosted by Intergraph.) There is reason to be optimistic about the progress of this group. Although they've only been an official POSIX group for one meeting, they are showing an increased sensitivity to the political issues involved in getting their document through balloting. I think their biggest liability right now is their determination to go to ballot in January 1991. The date seems premature by a year or more; they need more meetings before balloting so more people can read and comment on their draft. September 4, 1990 StIEEEr1003.10tand 1003.15: Supercomputing and Batch Volume-Number: Volume 21, Number 81 shar.1003.10.23858 echo 1003.2 cat >1003.2 <<'shar.1003.2.23858' From std-unix-request@uunet.uu.net Thu Sep 20 14:21:46 1990 Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP id AA11139; Thu, 20 Sep 90 14:21:46 -0400 Posted-Date: 20 Sep 90 18:01:17 GMT Received: by cs.utexas.edu (5.64/1.76) From: jsh@usenix.org (Jeffrey S. Haemer) Newsgroups: comp.std.unix Subject: Standards Update, IEEE 1003.2: Shell and tools Message-Id: <530@usenix.ORG> Sender: jsq@usenix.ORG Reply-To: std-unix@uunet.uu.net Organization: USENIX Standards Watchdog Committee X-Submissions: std-unix@uunet.uu.net Date: 20 Sep 90 18:01:17 GMT To: std-unix@uunet.uu.net Submitted-by: jsh@usenix.org (Jeffrey S. Haemer) An Update on UNIX*-Related Standards Activities September 1990 USENIX Standards Watchdog Committee Jeffrey S. Haemer, Report Editor IEEE 1003.2: Shell and tools Randall Howard <rand@mks.com> reports on the July 16-20 meeting in Danvers, MA: Background on POSIX.2 The POSIX.2 standard deals with the shell programming language and utilities. Currently, it is divided into two components: + POSIX.2, the base standard, deals with the basic shell programming language and a set of utilities required for application portability. Application portability essentially means portability of shell scripts and thus excludes most features that might be considered interactive. In an analogy to the ANSI C standard, the POSIX.2 shell command language is the counterpart to the C programming language, while the utilities play, roughly, the role of the C library. In fact, because POSIX.2 provides an interface to most of the features (and possibly more) of POSIX.1, it might also be thought of as a particular language binding to the soon-to-be language independent version of that standard. POSIX.2 also standardizes command-line and function interfaces related to certain POSIX.2 utilities (e.g., popen(), regular expressions, etc.), as discussed in detail in the snitch report for the Snowbird meeting. This part of POSIX.2, which was developed first, is also known as ``Dot 2 Classic.'' + POSIX.2a, the User Portability Extension or UPE, is a supplement to the base POSIX.2 standard. Not a stand-alone document, it will eventually be an optional chapter and a small number of other revisions to a future draft of that base document. This approach allows the adoption of the UPE to trail Dot 2 Classic without delaying it. The UPE standardizes commands, such as vi, that might not appear in shell scripts but are important enough that users must learn them on any real system. It is essentially an interactive standard that attempts to reduce retraining costs caused by system-to-system variation. __________ * UNIXTM is a Registered Trademark of UNIX System Laboratories in the United States and other countries. September 1990 Standards Update IEEE 1003.2: Shell and tools - 2 - Some utilities have interactive as well as non-interactive features. In such cases, the UPE defines extensions from the base POSIX.2 utility. An example is the shell, for which the UPE defines job control, history, and aliases. Features used both interactively and in scripts tend to be defined in the base standard. Together, Dot 2 Classic and the UPE will make up the International Standards Organization's IS 9945/2 -- the second volume of the proposed ISO three-volume standard related to POSIX. Status of POSIX.2 Balloting Draft 10 of Dot 2 Classic was sent out during July in a recirculation ballot. Recirculation means that objections need only be considered if they are existing unresolved objections or are based on new material. Other objections will be considered at the whim of the Technical Editor. Draft 10 is an imposing, if not intimidating, 780 pages, made even denser by the decision to remove much white space in a (vain) attempt to save paper. Ballots are due by September 10. Unfortunately, the recirculation ballot materials arrived at my organization on August 17th, giving our group barely three weeks to review this massive document. The technical editors and others working behind the scenes (Hal Jespersen, Don Cragun, and others) have done an admirable job of diff-marking changes and producing personalized lists of unresolved objections for each balloter. In addition, all 96 pages of unresolved objections are provided. However, the amount of new material that has never been reviewed and the major reorganization means that Draft 10 bears much less resemblance to Draft 9 than one might hope. That, combined with balloting on the UPE, has put many balloters -- myself included -- in balloting overload. If a recirculation simply means forming opinions on my (and other) unresolved objections, then the time period is quite reasonable. However, as I shall describe below, Draft 10 is so changed from the previous drafts that it deserves to be read practically from cover to cover, and the recirculation deadline does not provide adequate time for that task. The changes fall into a number of categories: + New Utilities: For example, a superset of the traditional od replaced the Draft 9 hexdump which was xd in Draft 8. Pathchk and set -o noclobber have replaced create from Draft 9 and validfnam and mktemp from Draft 8. Such examples demonstrate that Draft 10 is not mature and needs more consideration to achieve consensus. September 1990 Standards Update IEEE 1003.2: Shell and tools - 3 - + Expanded Material: Previous descriptions of such utilities as awk, sh, bc, etc., were neither sufficiently comprehensive nor sufficiently complete to be of the quality demanded of a standard. In the latest draft, these descriptions have been fleshed out, and include much more detail on operator precedence, interactions, subtle semantics, and so on. This is clearly a step in the right direction, but adds to the job of reviewing Draft 10. + Internationalization: While the localedef and locale utilities remain, they have changed substantially. I personally support including these features, but am concerned that these are being designed during the balloting process which is, if anything, worse than design-by-committee. Overall, balloting-group reaction to these utilities ranges from impassioned pleas for their removal to requests for greater functionality (complexity) to handle ever more arcane aspects of the internationalization problem. + Chapter 2: Chapter 2's front matter is substantially reorganized and more voluminous. This chapter contains definitions, utility syntax information, requirements imported from POSIX.1, the definition of a locale, description of basic and extended regular expressions, etc.. Utility descriptions seem to be getting shorter, with more and more pointers to Chapter 2. This is a good trend, as long as balloters adequately consider the chapter's technical contents. Status of POSIX.2a Balloting The first formal ballot on POSIX.2a UPE Draft 5 was due in the IEEE offices by August 16th. Unfortunately, the UPE is laced with references to definitions and concepts largely defined in Chapter 2 of Draft 10. I did not receive my Draft 10 until after the UPE balloting was due to be returned. This hinders any attempt to review these two documents as a single entity -- which is what they will eventually become. The UPE is starting to mature: it's converging. The major controversy is scope -- as it has been throughout the UPE's entire life. This draft aligns itself more closely to Dot-2-Classic in many ways, which leads me to believe that combined review is essential to its understanding. A few utilities remain contentious: + nice, renice: These require underlying functionality absent from POSIX.1, although POSIX.4 has setscheduler(), which allows applications to set priority and scheduling algorithms. September 1990 Standards Update IEEE 1003.2: Shell and tools - 4 - Some working and balloting group members adamantly resist any attempt to add utilities that are not implementable on top of a bare POSIX.1. Others view the UPE as addressing what users type, regardless of underlying implementation. I am in the latter camp, not the least because other working groups, such as POSIX.4, have not yet standardized a utility interface, leaving a void which the much-maligned UPE group is most able to fill. (It is telling that implementing df and ps is impossible using only POSIX.1 functions, yet there is little opposition to including either utility. + ps: The description for this utility was an interesting amalgam of two incompatible visions of how ps output should be formatted -- that in Draft 4 and that in Draft 5. A correction should have been issued during balloting, so that balloters could concentrate on the real issues of what should be the scope of the ps utility. + patch: This utility differs from many others; its origins are in the public domain rather than in a traditional UNIX variants. As a result, many people feel that patch is worthwhile, but not mature enough to standardize. + lint89: This utility is optional, largely because it is controversial for a number of reasons. Obviously, the very name lint89 is painfully bureaucratic. Furthermore, many feel that ANSI C makes it unnecessary; moreover, any remaining required functionality rightfully belongs as an additional option in the c89 (cc) utility. Some point to existing practice. But what is existing practice when the utility's name is lint89? [Editor: On the other hand, it may prove indispensable in detecting portability problems in lex89- and yacc89-generated code. Parenthetically, Draft 10 calls these lex and yacc, but that must just be a temporary oversight; the utilities obligatorily have ANSI C input and output. (One assumes we'll escape c89tags because ctags can be made to work with both flavors.)] + compress: The inclusion of this utility remains controversial because of the Unisys patent on the particular variable of Lempel-Ziv compression used by traditional implementations of this utility. The working group appears to be divided on the subject of basing a standard on patented material -- no matter what the licensing fees are. There is, however, general agreement that it is preferrable to remove compress entirely rather than ``invent'' some new compression algorithm. Therefore, it appears that a pax-like compromise, of having a single interface to a number of competing formats or algorithms, is not widely supported. [Editor: see Andrew Hume's X3B11 report for another wrinkle on data compression.] Clearly, this issue will have to be resolved with further information from Unisys lawyers during the balloting process. September 1990 Standards Update IEEE 1003.2: Shell and tools - 5 - Status of the Danvers Meeting The Danvers working group dealt with neither Dot 2 Classic nor the UPE. Instead, at POSIX.3.2's request (that's the subgroup of Dot 3 producing test assertions for Dot 2), we met jointly to co-develop test assertions for Dot 2 Classic. This work is a consequence of the SEC's recent decision requiring each POSIX working group to develop its own test assertions and ballot them with the standard. It also stems from Dot 3's frustration over the (inadequate) way Dot 2 addressed testing. For example, automated testing of lp, is impossible; it can only be tested by a human test procedure. Our working group should have explored the implications of this before subjecting POSIX.3 to that task. (Some utilities can only be tested manually, but the working group defining that utility should likely put something to that effect in the Rationale or History of Decisions Made to confirm to the testing people that they knew this.) The three days of working with Dot 3 were a real learning experience for our working group. Nonetheless, many of us had our fill of test assertions that week. I'm also concerned that a three-day meeting cost my company nearly as much as a five day meeting would have. In the future, I would prefer to see schedules that make productive use of the entire working week. September 1990 Standards Update IEEE 1003.2: Shell and tools Volume-Number: Volume 21, Number 120 shar.1003.2.23858 echo 1003.3 cat >1003.3 <<'shar.1003.3.23858' From std-unix-request@uunet.uu.net Mon Oct 1 15:18:56 1990 Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP id AA19179; Mon, 1 Oct 90 15:18:56 -0400 Posted-Date: 1 Oct 90 18:42:48 GMT Received: by cs.utexas.edu (5.64/1.76) From: jsh@usenix.org (Jeffrey S. Haemer) Newsgroups: comp.std.unix Subject: Standards Update, IEEE 1003.3: Test Methods Message-Id: <568@usenix.ORG> Sender: jsq@usenix.ORG Reply-To: std-unix@uunet.uu.net Organization: USENIX Standards Watchdog Committee X-Submissions: std-unix@uunet.uu.net Date: 1 Oct 90 18:42:48 GMT To: std-unix@uunet.uu.net Submitted-by: jsh@usenix.org (Jeffrey S. Haemer) An Update on UNIX1-Related Standards Activities October 1, 1990 USENIX Standards Watchdog Committee Jeffrey S. Haemer, Report Editor IEEE 1003.3: Test Methods Doris Lebovits <lebovits@attunix.att.com> reports on the July 16-20 meeting in Danvers, MA: Overview Dot three's job is to do test methods for all of the other 1003 standards. The group's work, whose first parts are now in ballot, specifies the requirements for OS conformance testing for our industry and for NIST. This makes our balloting group, our technical reviewers, and our schedules worth watching. Pay attention, also, to what comes out of the Steering Committee on Conformance Testing (SCCT). Their projects and decisions will be interesting and important. This was the working group's seventeenth meeting. As usual, we reviewed the ballot status of P1003.1 test methods, worked on P1003.2 test methods and reviewed steering committee activities. Technical reviews were done on parts I and II and the group developed assertions for part III. Participants from the usual companies attended (AT&T, NIST, OSF, Mindcraft, IBM, DEC, HP, Data General, Cray Research, Unisys, Perennial, and Unisoft, Ltd.), as did an assortment of P1003.2 members (see below). Document structure Currently, our evolving document has three parts: Part I is generic test methods, Part II is test methods for measuring P1003.1 conformance, including test assertions, and Part III contains test methods and assertions for measuring P1003.2 conformance. After the ballot, each part will become a separate standard. Part I will be published as IEEE P1003.3, Part II as IEEE P1003.3.1, and Part III as IEEE P1003.3.2. __________ 1. UNIXTM is a Registered Trademark of UNIX System Laboratories in the United States and other countries. October 1, 1990 Standards Update IEEE 1003.3: Test Methods - 2 - Ballot status Draft 11 of the current ballot, which was recirculated to the (approximately) ninety-member balloting group late in February, closed balloting March 23. Of the respondents, 19 disapproved with substantive negative comments. This met the two-thirds response requirement, but falls short of the needed two-thirds approval. A recirculation ballot for P1003.3 Draft 12, which is the revision of Part I of Draft 11, began August 28 and is expected to close September 28, 1990. The recirculation of P1003.3.1 Draft 12 (Part II) will be conducted at a later date. On the first and last days, the technical reviewers worked on ballot objections to Part I and Part II. All Part I objections and most Part II objections were resolved. The definition of an untested assertion was reviewed and a permanent rationale will be included in Part I. P1003.2 verification This was our fifth meeting working on the verification standard for the P1003.2 standard. The assertion writing and review were done jointly with the P1003.2 working group. The whole P1003.3 and P1003.2 working groups worked jointly on defining test assertions based on P1003.2 Draft 10. They worked in three small breakout groups. The joint group (P1003.2 plus P1003.3) also met in plenary session several times to discuss progress and small-group issues. Progress was slow in the beginning, since most of the P1003.2 working group were not familiar with test assertions. but by the end of the week we had discussed and resolved several issues. Some examples: - Do we need to state assertions in P1003.3.2 explicitly that duplicate P1003.3.1? (Yes.) - Must we test locale variables for every locale-sensitive interface? (They should be tested when their behavior is clearly stated for a utility.) - Should assertions for multiple operands be consistent? (Yes.) Lowell Johnson (Unisys) is Secretary of the P1003.2 Test Methods activities, and Andrew Twigger (Unisoft Ltd) is Technical Editor. Ray Wilkes, the former Chair, has changed jobs and is no longer able to attend regularly, so Roger Martin is actively looking for a replacement. October 1, 1990 Standards Update IEEE 1003.3: Test Methods - 3 - Steering Committee on Conformance Testing (SCCT) The SCCT is supposed to alleviate the increasing dot-three work load that all the other proliferating groups are creating. Their job is coordinating the activities of all test-methods groups, monitoring their conformance to test methods, and writing Project Authorization Requests (PARs). Currently, its members are Roger Martin (NIST, Steering Committee Chair), Anita Mundkur (HP), Andrew Twigger (Unisoft Ltd), Bruce Weiner (Mindcraft), Lowell Johnson (Unisys) and the newest member, John Williams (GM). That there is a new member in the steering committee is very important, especially because John is from GM, the largest user voice other than the U.S. government. The steering committee did not have anything for the working group to review. It is still documenting procedures, and Roger is still clarifying which standards the working group will address. October 1, 1990 Standards Update IEEE 1003.3: Test Methods Volume-Number: Volume 21, Number 162 shar.1003.3.23858 echo 1003.4 cat >1003.4 <<'shar.1003.4.23858' From std-unix-request@uunet.uu.net Wed Aug 22 12:19:11 1990 Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP id AA00733; Wed, 22 Aug 90 12:19:11 -0400 Posted-Date: 22 Aug 90 16:09:13 GMT Received: by cs.utexas.edu (5.64/1.71) id AA05460; Wed, 22 Aug 90 11:19:05 -0500 From: jsh@usenix.org (Jeffrey S. Haemer) Newsgroups: comp.std.unix Subject: Standards Update, IEEE 1003.4: Real-time Extensions Message-Id: <448@usenix.ORG> Sender: std-unix@usenix.ORG Reply-To: std-unix@uunet.uu.net Organization: USENIX Standards Watchdog Committee X-Submissions: std-unix@uunet.uu.net Date: 22 Aug 90 16:09:13 GMT To: std-unix@uunet.uu.net From: Jeffrey S. Haemer <jsh@usenix.org> An Update on UNIX*-Related Standards Activities August, 1990 USENIX Standards Watchdog Committee Jeffrey S. Haemer <jsh@usenix.org>, Report Editor IEEE 1003.4: Real-time Extensions Rick Greer <rick@ism.isc.com> reports on the July 16-20 meeting in Danvers, Massachusetts: Most of the action in the July dot four meeting centered around -- you guessed it -- threads. The current threads draft (1003.4a) came very close to going to ballot. An overwhelming majority of those present voted to send the draft to ballot, but there were enough complaints from the dot fourteen people (that's multiprocessing -- MP) about the scheduling chapter to hold it back for another three months. Volunteers from dot fourteen have agreed to work on the scheduling sections so that the draft can go to ballot after the next meeting, in October. Actually, dot four voted to send the draft to ballot after that meeting in any case, and the resolution was worded in such a way that a consensus would be required to prevent the draft from going to ballot in October. Thus, the MP folks have this one final chance to clean up the stuff that's bothering them -- if it isn't fixed by October, it will have to be fixed in balloting. Some of us in dot fourteen felt the best way to fix the thread scheduling stuff was via ballot objection anyway. Unfortunately, the threads balloting group is now officially closed, and a number of MP people saw this as their last chance to make a contribution to the threads effort. The members of dot fourteen weren't the only ones to be taken by surprise by the closure of the threads balloting group. It seems that many felt that it would be a cold day in hell before threads made it to ballot and weren't following the progress of dot four all that closely. [Editor: I've bet John Gertwagen a beer that threads will finish balloting before the rest of dot four. The bet's a long way from being decided, but I still think I'll get my beer.] Meanwhile, the ballot resolution process continues for the rest of dot four, albeit rather slowly. There are a number of problems here, the biggest being lack of resources. In general, people would much rather argue about threads than deal with the day-to-day grunt work associated with the IEEE standards process. [Editor: The meeting will __________ * UNIXTM is a Registered Trademark of UNIX System Laboratories in the United States and other countries. August, 1990 Standards Update IEEE 1003.4: Real-time Extensions - 2 - be in Seattle, Washington. Go. Be a resource.] Many of the technical reviewers have yet to get started on their sections. Nevertheless, proposed resolutions to a number of objections were presented and accepted at the Danvers meeting. [Editor: Rick is temporarily unavailable, but Simon Patience of the OSF has kindly supplied these examples: The resolved objections were taken from the CRB: replacing the event mechanism by ``fixed'' signals, replacing the shared memory mechanism by mmap() and removing semaphore handles from the file system name space. Replacing events by signals was accepted; no problem here. Adopting mmap() got a mixed reception, partly because some people thought you had to take all of mmap(), where a subset might suffice. The final vote on this was not to ask the reviewer to adopt mmap(), which may not not satisfy the objectors. I'd guess the balloting group will eventually hold sway here! Finally, the group accepted abandoning the use of file descriptors for semaphore handles, but some participants wanted to keep semaphore names pathnames. The reviewer was sent off to rethink the implications of this suggestion. ] We should be seeing a lot more of this in Seattle. Similar comments apply to the real-time profile (AEP) work. The AEP group made more progress over the last three months than the technical reviewers did, although even that (the AEP progress) was less than I'd hoped. We're expecting our first official AEP draft in October. August, 1990 Standards Update IEEE 1003.4: Real-time Extensions Volume-Number: Volume 21, Number 50 shar.1003.4.23858 echo 1003.5 cat >1003.5 <<'shar.1003.5.23858' From std-unix-request@uunet.uu.net Mon Sep 17 14:32:11 1990 Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP id AA26270; Mon, 17 Sep 90 14:32:11 -0400 Posted-Date: 17 Sep 90 18:23:16 GMT Received: by cs.utexas.edu (5.64/1.76) From: jsh@usenix.org (Jeffrey S. Haemer) Newsgroups: comp.std.unix Subject: Standards Update, IEEE 1003.5: Ada bindings Message-Id: <521@usenix.ORG> Sender: jsq@usenix.ORG Reply-To: std-unix@uunet.uu.net Organization: USENIX Standards Watchdog Committee X-Submissions: std-unix@uunet.uu.net Date: 17 Sep 90 18:23:16 GMT To: std-unix@uunet.uu.net Submitted-by: jsh@usenix.org (Jeffrey S. Haemer) An Update on UNIX*-Related Standards Activities August, 1990 USENIX Standards Watchdog Committee Jeffrey S. Haemer <jsh@usenix.org>, Report Editor IEEE 1003.5: Ada bindings Jayne Baker <cgb@d74sun.mitre.org> reports on the July 16-20 meeting in Danvers, Massachusetts: Introduction and Overview P1003.5 completed the last touches on Draft 6 of the Ada Language Binding, before sending it to ballot, and considered our options for P1003.5 work beyond balloting. We also addressed the International Standards Organization's (ISO's) refusal to accept and register our draft and revised our balloting schedule. Final Document Modifications This meeting was our last chance to modify our document without a formal IEEE ballot to justify that change. We spent a large portion of the meeting editing Draft 5, chapter by chapter. Draft 6 will ballot in less than two months, so document stability was guarded, but we considered a few proposals for changes. 1. David Emery's Process Group ID as a Separate Type proposal addresses the P1003.1 intention and underlying semantics with respect to Process_Group_ID. Specifically, the proposal recommends that Process_Group_ID be a separate type, or a derived type at a minimum, rather than a part of Process_ID. Dave believes that P1003.1 intended Process_ID and Process_Group_ID to be treated as separate types. This perception is supported by a few operations, such as Wait_For_Process_Group, which suggest the two types are indeed separate. Representing the two types separately would help prevent confusing them. Making them separate would also allow function overloading. For the most part, the group agreed, but felt that the types really do behave more like derived types than separate types. There was some resistance to adopting this proposal because of the number of changes it would require in sections 3 and 4 __________ * UNIXTM is a Registered Trademark of UNIX System Laboratories in the United States and other countries. August, 1990 Standards Update IEEE 1003.5: Ada bindings - 2 - (Process Primitives and Process Environment), but there was also opposition to handing the problem off to the balloting group. We finally decided to consult with the Language Independence group. 2. A proposal submitted by Mars Gralia, of Applied Physics Laboratory, Clarify Functional Option `FIFO', addressed a topic presented in section 8 (Language-Specific Services for Ada), This proposal was accepted because it introduced flexibility that makes it easier for P1003.5 to support the P1003.4 work in the future. 3. Mars also offered a Simplify and Unify proposal, which provoked lengthy, somewhat heated discussion. Specifically, the section 8, Is_append, function returns yes/no, to support an existing application, but there is a naming convention P1003.5 supports that requires Is_Append to return a boolean; indeed, the append function in section 6 (Input and Output Primitives) already returns boolean. Our priorities are + Consistency with the Ada language. + Consistency between the Ada and POSIX portions of the document; + Consistency with existing implementations. Unfortunately, some of these conflict with others in this case. The good news is, we may not have to decide what to do: Ada Interpretation (AI) 544 addresses this issue, However, we did not know, and could not find out, the complete resolution of the AI in Danvers. Moreover, Dave Emery and Hal Jespersen, who are preparing the document for ballot, don't have time to make all the changes Mars's proposal would require between now and ballot circulation. Jim Lonjers suggested that Mars submit a negative ballot on this issue, which would let the ballot-resolution group construct a decision consistent with the AI during ballot resolution. Future Work When Draft 6 enters the IEEE ballot process, the ballot resolution group becomes responsible for ballot coordination and resolution, and the working group is freed to submit new Program Authorization Requests (PARs). IEEE policy only lets a group operate for six months without a PAR, so we have to do our job quickly. We listed possible new work areas, then ranked them based on our effectiveness in the area, the work's importance, and the effort August, 1990 Standards Update IEEE 1003.5: Ada bindings - 3 - required. Here is our list. 1. Test Assertions for P1003.5 A straw-man vote shows the test assertions work as the number one issue, though we suspect neither our corporations nor our individual bosses will be very interested in the work. However, test assertions are a National Institute of Standards and Technologies (NIST) requirement, which may increase corporate interest levels. We do have total control over the test assertions work, and have been directed by the SEC to address it prior to our first round of IEEE ballot. To prevent a delay to the first round of IEEE ballot, the SEC has allowed us to include a ``plan'' for identifying and accomplishing the test assertions portion of the document, rather than the actual test assertions. 2. Shells & Utilities (Ada binding to P1003.2) 3. Language Independence (Helping P1003.1 -- create a language- independent specification for 1003.1-1988, and 1003.1-1990.) The Shell and Tools work and language independence ran close seconds. The Shells & Tools work received a high ranking in the straw-man vote because we feel that the work is do-able and that our effectiveness in the area would be high; moreover, compared to other areas (e.g., the P1003.4 work), the level of P1003.5 effort required would be low. Language-independence ranked high as it is critical to both the current P1003.5 work (see ISO Acceptance and Registration, below) and the POSIX effort as a whole. The people working the language-independent issues are asking for our input now. Moreover, without our input the resulting language-independent work could adversely impact us, and P1003.5 might not have the voting clout during balloting to block anything particularly awful. Several members interested in these issues are already holding Birds-of-a-Feather meetings with the P1003.1 language-independent group. 4. Threads issues (Ada binding to P1003.4a) and Real-Time Extensions (Ada binding to P1003.4) This area generates the most interest among working group members, several of whom have been working with P1003.4 for some time. Ted Baker, former P1003.5 snitch, has written a document on the subject, Real-time Extension for Portable Operating System Ada Binding - Version 0.0 for the U.S. Army HQ CECOM Center for Software Engineering, and provided us with copies for review and consideration. Group consensus is that if we rush into this area, we are likely to stumble over language- independence issues, so we will work with the P1003.4 language- independence small group until their specification is well August, 1990 Standards Update IEEE 1003.5: Ada bindings - 4 - along, and then begin work on the Ada binding in parallel with its completion. ISO Acceptance and Registration Jim Isaak, Technical Committee on Operating Systems (TCOS) Chairman, reported to P1003.5 that ISO declined to accept and register P1003.5 at the recent Subcommittee 22 (SC22) Paris meeting. Their primary reason was the lack of a language-independent specification for P1003.1. How, they asked, can a language-dependent binding exist without a base, language-independent specification? We had also failed to use Working Group 11's procedure-calling mechanism to generate our language bindings. (The WG11 approach produces a direct, language-dependent binding to a language-independent specification.) P1003.9, FORTRAN binding to P1003.1, suffered the same fate for the same reasons. For now, we will provide a copy of P1003.5 Draft 5 to SC22 for their review and comments regarding potential registration problems in the future. To address WG11 concerns, Jim Isaak, POSIX Strategy Director -- note the different hat -- recommended we also forward a copy of Draft 5 to WG11 for review. David Emery and I, both of MITRE, will follow up with a white paper explaining, with examples, why a one-to-one, direct mapping of the functionality described in the language-independent specification to the language-dependent binding is not always optimal, and that a complete (i.e., thick) language- independent specification and a reference-type (i.e., thin) language- dependent binding is neither practical nor possible for some languages. Finally, we will formally submit Draft 7 (or later) to SC22, requesting they recommend it for ISO acceptance/registration as a Committee Document (CD). (CD has replaced ``Draft Proposal'' or DP.) The earliest this could happen is January 1991. Why not Drafts 5 or 6? A new policy, intended to promote document stability requires one IEEE ballot cycle before submitting a draft for ISO registration. IEEE Ballot Issues/Schedule We met with Jim Isaak and Lorraine Kevra, the new TCOS Balloting vice-chair, to discuss the IEEE balloting process and our balloting schedule. P1003.5 produced a schedule for achieving simultaneous IEEE and ISO ballot at the April/Salt Lake City meeting (see my report from last quarter), but because of the problems with ISO, described above, we have revised this schedule. August, 1990 Standards Update IEEE 1003.5: Ada bindings - 5 - Approximately 450 people joined the P1003.5 ballot group. Only 61 of those people are POSIX participants; that is, only one-sixth of all POSIX participants (from all working groups) signed up for our ballot group! The other 390-odd participants are SIGAda members. We are very pleased with this response. Ballot-group formation closed on August 6. Confirmation to applicants was originally scheduled for August 8. Because of the large number of non-POSIX balloters, this date was pushed back to about August 17, but anyone who signed up and has still not received confirmation should contact Bob Pritchard at the IEEE Standards Office, 445 Hoes Lane, Piscataway, NJ 08855, (908) 562-3811. Now that ballot group formation has closed, the group cannot expand. Only people who fail to respond to the initial ballot can be removed (``abstain'' is not a non-response); ballot group members are not required to respond to re-circulation ballots. Bob Pritchard will mail Draft 6 to the P1003.5 ballot group on September 10, 1990. The distribution takes a minimum of two weeks. The ballot period officially begins on September 24, 1990, and closes October 24, 1990. This allows the ballot group at least four weeks for review. Being realistic, we imagine that not everyone will complete their document review. To prevent the uneven coverage that would result from 450 reviewers reading the document from front to not-quite-back, our cover letter requests that reviewers begin their reviews at different spots, using a scheme based on the first letter of the reviewer's last name. If people do not return their ballots by October 24, the IEEE office may send a follow-up letter to the ballot group members requesting that they return their ballots. Steve Deller, of Verdix, will do all necessary coordination with organizations listed on our PAR. Jim Lonjers, of Unisys, with Lorraine Kevra's help, will coordinate ballot resolution, Each chapter will have someone responsible for its resolution, but alternates for each chapter are absolutely critical. Jim Isaak says that, based on his experience, we should assume 20% of the people who do ballot resolution will, for some reason, prove unable to complete their portion of the task. Jim Lonjers will provide the last ballot to the technical reviewers by December 5, 1990. The ballot resolution group will meet at the Tri- Ada meeting in early December to determine how close we are to achieving the 75% minimum acceptance. At that same meeting they will also coordinate ballot responses to objections which cover multiple chapters and objections which produce conflicting responses. We believe they will have resolved the last ballot by January 11, 1991, and a re-circulation ballot is tentatively scheduled for the April August, 1990 Standards Update IEEE 1003.5: Ada bindings - 6 - 1991 POSIX meeting time frame. In IEEE re-circulation ballot, two sets of material are returned to the balloting group: 1. the changes made to the document (either a set of changes, or a new document with change bars), and 2. the unresolved objections. IEEE policy does not allow the balloters' names, companies, or company locations to be returned with the unresolved objections packet; to maintain anonymity, ballot comments are numbered, and individual balloters notified of their own ballot comment numbers. (IEEE and ANSI do maintain balloters' names, companies, and company locations to detect corporate ballots, where and if they occur.) The balloting group gets at least ten days to review the re-circulation ballot, though they can be given more time if the size of the re-circulation material and the document being balloted warrant it. Miscellany Eight Next Generation Computer Resources (NGCR) representatives gave working-group participation quite a boost. Although NGCR people have the bond of all being NGCR representatives, they are not employed by a single employer, but are from all over the United States, and they possess individual interests and strengths. In the past, our core group has only been about a dozen people, so we are pleased by NGCR's interest and participation, and eager to work with them. In April 1990, David Emery went to Sweden, to meet with the Ada 9x committee group dealing with secondary standards and setting priorities of those standards. Secondary standards are those standards not contained within the language itself (i.e., not in the Ada Language Reference Manual). POSIX was a very high priority secondary standard. The next Ada 9x committee meeting will be at the SIGAda meeting in Los Angeles in August. Dave is heading a panel presentation on the P1003.5 Binding at this meeting. The chapter authors will also be a part of this panel. At July POSIX meeting, P1003.5 expressed its special thanks to Dave for his better-than-excellent job as our Technical Editor. He has contributed significant time (much of it his own) and effort to the P1003.5 work, and we appreciate it. August, 1990 Standards Update IEEE 1003.5: Ada bindings Volume-Number: Volume 21, Number 112 shar.1003.5.23858 echo bof cat >bof <<'shar.bof.23858' From uucp@tic.com Thu Aug 16 09:40:59 1990 Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP id AA26649; Thu, 16 Aug 90 09:40:59 -0400 Posted-Date: 16 Aug 90 01:36:42 GMT Received: by cs.utexas.edu (5.64/1.70) id AA09871; Thu, 16 Aug 90 08:40:51 -0500 Received: by longway.tic.com (4.22/tic.1.2) id AA05200; Thu, 16 Aug 90 08:35:40 cdt From: Jeffrey S. Haemer <jsh@usenix.org> Newsgroups: comp.std.unix Subject: Standards Update, USENIX Standards BOF Message-Id: <434@usenix.ORG> Sender: std-unix@usenix.ORG Reply-To: std-unix@uunet.uu.net Organization: USENIX Standards Watchdog Committee X-Submissions: std-unix@uunet.uu.net Date: 16 Aug 90 01:36:42 GMT Apparently-To: std-unix-archive@uunet.uu.net From: Jeffrey S. Haemer <jsh@usenix.org> An Update on UNIX*-Related Standards Activities August, 1990 USENIX Standards Watchdog Committee Jeffrey S. Haemer <jsh@usenix.org>, Report Editor USENIX Standards BOF An anonymous correspondent reports on the June 12 meeting in Anaheim, California: If they find out who I am... The snitch requests anonymity for several reasons, none of them related to his alcohol consumption during the bof. (No officer, I swear I wasn't going to log in and do system administration until I sobered up.) The request actually relates to the snitch's employer -- a standards organization. Because I am paid neither to file snitch reports nor to write opinions on standards, to submit this paper through normal channels for official, outside publication, even if it were entirely objective (or factual, for that matter), would require endless rounds of exhaustive, organizational review. On to the meeting. As usual, the meeting was held immediately after the official USENIX reception, which meant that the snitch continued to suck down his third or fifth beer as the meeting opened. John ``standards is politics'' Quarterman, of Texas Internet Consulting (TIC), and Susanne Smith, of Windsound, chaired the meeting, which was attended by about 40 people, including Larry Wall -- nearly a standards body by himself. [ Editor: Larry is the person responsible for such contributions to the community as rn, patch, and perl. ] Jeff Haemer was absent because ``his wife is having a baby any day and I just don't know where his priorities are!?'' [Editor: Zoe Elizabeth Haemer, 6lbs. 10oz., after a forty-five minute labor] John started out by covering the usual stuff -- who he is, how to reach him, what he does, [Editor: Sounds like it would have been valuable for me to attend.] and so on. You should already know all this since it is covered regularly in articles in the publication or newsgroup in which you reading this article. John gave some updates __________ * UNIXTM is a Registered Trademark of UNIX System Laboratories in the United States and other countries. August, 1990 Standards Update USENIX Standards BOF - 2 - for things that are probably already out-of-date, so I won't repeat them. Susanne pointed out that TIC and Windsound have collaborated on a calendar that includes all the latest dates of standards meetings, which they were giving away for free at the meeting. [Editor: You can request copies from tic@tic.com. They span July 1990-June 1991, and cost $5.00, plus shipping, handling, and (Texans only) tax.] John and Susanne briefly reviewed standards efforts of interest to USENIX members, including P1003 (POSIX) and P1201 (Windowing). John discussed whose standard (ISO? ANSI? FIPS? other?) was most important but I was unable to draw any conclusions or coherently summarize it, so I'll omit it here. Nonetheless he did get across two points: 1) there is a lot of coordination between groups and 2) he is very quotable. (``The IEEE standards board is baroque and byzantine.'') The crowd becomes surly After this basic informational introduction, the meeting was thrown open to the audience. The ensuing discussion was a mix of four things: 1. Humor A couple of examples will give the flavor. + An overheard conversation: ``Mach was the greatest intellectual fraud in the last ten years.'' ``What about X?'' ``I said intellectual.'' + The announcement of the new Weirdnix contest: a contest for a correct interpretation of P1003.1 or .2 furthest from the original intent. The state of Utah (I am not making this up) is offering a trip for two to Salt Lake City for the winner. 2. Opinion polling John tried to discern whether attendees thought they were being well-served by John, the USENIX Standards Watchdog Committee, and the USENIX position on standards: to attempt to prevent standards from prohibiting innovation. Indeed, at Snowbird, the site of the April POSIX meeting, John was told that smaller companies don't like our participation because of this position. Think about this a while. (For a more detailed discussion of the USENIX position on standards, see either ;login: 15(3):25 or August, 1990 Standards Update USENIX Standards BOF - 3 - the periodic overview posting in comp.std.unix about the USENIX Standards Watchdog Committee.) John explained how USENIX came to its current policies and why it does not endorse standards of its own. Some audience members were unhappy with extant standards bodies and said they wouldn't mind if USENIX played a more active role. Susanne reminded us that UniForum working groups, which she praised, play such a role. You are encouraged to tell John and the USENIX Board what you feel the USENIX position on standards should be, how much money USENIX should budget for standards activities, or anything else that's on your mind. (The current USENIX standards budget is $45K/yr.) On a related note, BOF attendees were quite eager to be kept informed on standards issues. In the snitch's opinion, this is probably the standards-related area in which USENIX most excels, and its contribution overshadows that of any other source that this snitch is aware of. The USENIX Standards Watchdog Committee publishes copiously in both ;login: and the usenet newsgroup comp.std.unix. (The level of detail can certainly not be said to be too high, but USENIX Board meetings continually propose reducing it.) While the newsgroups get the information more quickly, ;login:, in particular, remains the official voice of USENIX, and standards issues now fill 1/3 to 1/2 of each edition. Many non-UNIX aficionados who want to stay current on related standards join USENIX simply to get ;login:. Both John and the Board believe that although the newsgroup has been quite active this past year, hard copy still circulates more widely. Some attendees wanted increased coverage of standards currently outside of ;login:'s bailiwick, such as RS-232 and CD-ROM format. Unfortunately, following any and all computer-related standards would exceed USENIX's budget and resources. [Editor: The alert reader will have noticed Andrew Hume's fine report on WORM-based file system standards last quarter. Send me a report. I'll edit it. ] John raised the possibility of breaking out the standards information of ;login: into a separate publication. This was also discussed at the USENIX Board meeting during the week. Stay tuned. John and Susanne revealed that they are writing a book on UNIX- related standards (which will not be posted electronically). No suggestion was made for how it could possibly stay up to date. August, 1990 Standards Update USENIX Standards BOF - 4 - 3. Government-bashing (Who the hell is NIST and why are they so out of control?) As soon as we determined that NIST wasn't represented in the room and couldn't defend itself, it became fair game. (There were no OSF reps either -- their BOF ran concurrently with ours -- but no one knew what OSF was doing so we skipped insulting them.) John fanned the flames by giving an example where NIST had pushed too hard, in his opinion: System Administration. ``Dot seven shouldn't exist,'' he said, but NIST pushed for it. Because government agencies view FIPS so favorably that a system administration FIPS would quickly become a de facto standard for non-government users as well, the IEEE said ``ok, let's look at it.'' John said things didn't turn out as badly as they could have. Unfortunately there is little common practice or prior art in the area; fortunately, dot seven is coming along so slowly that there may be by the time it is ready to go to ballot. Moreover, dot seven's work has encouraged several companies and universities to work on the parallels between system administration and network management. Still, he reminded us that a standard should neither create nor innovate but only standardize, quoting Dennis Ritchie's compliment to X3J11 in his keynote address: ``The C committee took something that wasn't broken, and tidied it up without breaking it.'' The audience asked, ``How do we control the activities of NIST?'' NIST is a part of the government. If you are a U.S. citizen, your tax dollars fund it, so you can write your congressperson. While you can communicate directly with NIST's standards representatives, John asked that we not bug them in the name of USENIX, ``because I have to work with these guys.'' If you feel bold, you can actually talk to John Lyons, the director of NIST -- <lyons@micf.nist.gov> -- who lies midway between the scutpuppy standards reps and the demonically powerful congresscritters. He really does read and answer his email (and his signature does say that his opinions represent those of his organization). John ended by defending, or at least rationalizing, NIST's pro- active stance: ``The primary reason is money.'' A familiar example is the Air Force's AFCAC-251 RFP (Request For Purchase). This five-to-ten-billion-dollar request for SVR3-conforming systems created a heap of trouble by specifying a vendor brand name. After official protests, the procurement had to be reworded at great expense -- ultimately to you, the taxpayer. A vendor-independent, POSIX FIPS would have prevented this. August, 1990 Standards Update USENIX Standards BOF - 5 - One of the few questions John couldn't answer was, ``Why did NBS change its name anyway?'' This snitch scraped away at the dirt and uncovered the explanation: The U.S. Department of Commerce under which NBS resides had wanted to change the name for many years because NBS has long performed activities quite unrelated to standards. As usual, it was politically bobbled for quite some time until a sufficiently obvious expansion of responsibilities came up for funding at which time (1/89, Reagan) the following announcement was issued: the new name, ``National Institute of Standards and Technology,'' reflects the broadened role and new responsibilities assigned to the agency which will include the traditional functions of providing the measurements, calibrations, data, and quality assurance support to U.S. commerce and industry, together with several new programs to support the aggressive use of new technologies in American industry. NIST's new purpose is ``to assist industry in the development of technology and procedures needed to improve quality, to modernize manufacturing processes, to ensure product reliability, manufacturability, functionality, and cost-effectiveness, and to facilitate the more rapid commercialization ... of products based on new scientific discoveries.'' Several new programs have been created aimed at rapid transfer of technology to U.S. industry. They are: 1. Regional Centers for the Transfer of Manufacturing Technology; 2. assistance to state technology programs; 3. the Advanced Technology Program; and 4. the Clearinghouse for State Technology Programs. Call (301) 975-3058 (NIST Technical Information) if you would like more information on any of these programs or on NIST itself. 4. John's usual exhortation/guilt-trip: get involved in standards! This discussion went on for some time. UNIX is no longer guided by a few bright individuals; it is now in the hands of vested commercial interests, some of which don't give a damn about innovation or good design. August, 1990 Standards Update USENIX Standards BOF - 6 - For the most part, the committees themselves contain intelligent, well-meaning people who really want to create useful standards. But in a small committee, overlooked unintentional flaws can ruin otherwise good work. Snitches help forestall this by functioning as a community ear. If you don't have time to be on a committee, get on the mailing list and continue to read the newsgroups so you can comment on critical issues when they arise. If you don't, you have have only yourself to blame if the standards come out all wrong. August, 1990 Standards Update USENIX Standards BOF Volume-Number: Volume 21, Number 36 shar.bof.23858 echo intro cat >intro <<'shar.intro.23858' From std-unix-request@uunet.uu.net Thu Oct 11 22:31:14 1990 Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP id AA29774; Thu, 11 Oct 90 22:31:14 -0400 Posted-Date: 11 Oct 90 21:27:28 GMT Received: by cs.utexas.edu (5.64/1.78) From: jsh@usenix.org (Jeffrey S. Haemer,) Newsgroups: comp.std.unix Subject: Standards Update, USENIX Standards Watchdog Committee Message-Id: <13502@cs.utexas.edu> Sender: fletcher@cs.utexas.edu Reply-To: std-unix@uunet.uu.net Organization: USENIX Standards Watchdog Committee X-Submissions: std-unix@uunet.uu.net Date: 11 Oct 90 21:27:28 GMT To: std-unix@uunet.uu.net Submitted-by: jsh@usenix.org (Jeffrey S. Haemer,) An Update on UNIX1-Related Standards Activities October 11, 1990 USENIX Standards Watchdog Committee Jeffrey S. Haemer, jsh@ico.isc.com, Report Editor USENIX Standards Watchdog Committee Jeffrey S. Haemer <jsh@ico.isc.com> reports on summer-quarter stan- dards activities What_these_reports_are_about Reports are done quarterly, for the USENIX Association, by volunteers from the individual standards committees. The volunteers are fami- liarly known as snitches and the reports as snitch reports. The band of snitches, John Quarterman, and I make up the working committee of the USENIX Standards Watchdog Committee. Our job is to let you know about things going on in the standards arena that might affect your professional life -- either now or down the road a ways. We don't yet have active snitches for all the committees and sometimes have to beat the bushes for new snitches when old ones retire or can't make a meeting, but the number of groups with active snitches contin- ues to grow (as, unfortunately, does the number of groups). If you're active in any standards-related activity that you think you'd like to report on, please drop me a line. We know we currently need snitches in several 1003 groups, and nearly all of the 1200- series groups. We currently have snitches in X3J16 (C++) and X3B11 (WORM file systems), but there are probably X3 groups the USENIX members would like to know about that we don't even know to look for watchdogs in. I also take reports from other standards activities. This quarter, you've seen reports from the WG-15 TAG (the U.S.'s effort in the ISO POSIX arena), from the NIST Shell-and-Tools FIPS meeting, and from the USENIX Standards BOF. If you have comments or suggestions, or are interested in snitching for any group, please contact me (jsh@usenix.org) or John (jsq@usenix.org). If some of the reports make you interested enough or indignant enough to want to go to a POSIX meeting, or you just want to talk to me in person, join me at the next set, October 15-19 at the Westin Hotel in Seattle, Washington. __________ 1. UNIXTM is a Registered Trademark of UNIX System Laboratories in the United States and other countries. October 11, 1990 Standards Update USENIX Standards Watchdog Committee - 2 - The USENIX Standards Watchdog Committee also has both a financial committee -- Ellie Young, Alan G. Nemeth, and Kirk McKusick (chair); and a policy committee -- the financial committee plus John S. Quar- terman (chair). An official statement from John:2 The basic USENIX policy regarding standards is: to attempt to prevent standards from prohibiting innovation. To do that, we o Collect and publish contextual and technical information such as the snitch reports that otherwise would be lost in committee minutes or rationale appendices or would not be written down at all. o Encourage appropriate people to get involved in the stan- dards process. o Hold forums such as Birds of a Feather (BOF) meetings at conferences, and standards workshops. o Write and present proposals to standards bodies in specific areas. o Occasionally sponsor other standards-related activities, including as White Papers in particularly problematical areas, such as IEEE 1003.7, and contests, such as the current Weirdnix contest. o Very occasionally lobby organizations that oversee standards bodies regarding new committee, documents, or balloting pro- cedures. o Sponsor a representative to the ISO/IEC JTC1 SC22 WG15 (ISO POSIX) standards committee, jointly with EUUG (the European UNIX systems Users Group). There are some things we do not do: __________ 2. All that follows is currently true, but may change in the near future because of recent USENIX financial problems. See John's October 2, 1990, comp.std.unix posting on USENIX Standards Funding Decisions for details. October 11, 1990 Standards Update USENIX Standards Watchdog Committee - 3 - o Form standards committees. It's the USENIX Standards Watch- dog Committee, not the POSIX Watchdog Committee, not part of POSIX, and not limited to POSIX. o Promote standards. o Endorse standards. Occasionally we may ask snitches to present proposals or argue positions on behalf of USENIX. They are not required to do so and cannot do so unless asked by the USENIX Standards Watchdog Policy Committee. Snitches mostly report. We also encourage them to recommend actions for USENIX to take. John S. Quarterman, USENIX Standards Liaison October 11, 1990 Standards Update USENIX Standards Watchdog Committee Volume-Number: Volume 21, Number 199 shar.intro.23858 echo nist cat >nist <<'shar.nist.23858' From std-unix-request@uunet.uu.net Fri Sep 28 14:42:08 1990 Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP id AA21899; Fri, 28 Sep 90 14:42:08 -0400 Posted-Date: 28 Sep 90 18:23:58 GMT Received: by cs.utexas.edu (5.64/1.76) From: jsh@usenix.org (Jeffrey S. Haemer) Newsgroups: comp.std.unix Subject: Standards Update, NIST Shell-and-Tools FIPS Workshop Message-Id: <558@usenix.ORG> Sender: jsq@usenix.ORG Reply-To: std-unix@uunet.uu.net Organization: USENIX Standards Watchdog Committee X-Submissions: std-unix@uunet.uu.net Date: 28 Sep 90 18:23:58 GMT To: std-unix@uunet.uu.net Submitted-by: jsh@usenix.org (Jeffrey S. Haemer) An Update on UNIX1-Related Standards Activities September 1990 USENIX Standards Watchdog Committee Jeffrey S. Haemer, Report Editor NIST Shell-and-Tools FIPS Workshop Donald Lewine <lewine@cheshirecat.webo.dg.com> reports on the September 6, 1990 meeting in Gaithersburg, MD: The Federal Government publishes Federal Information Processing Standards (FIPS) for use in buying and using computers. One set of FIPS deal with systems with ``POSIX-like interfaces.'' The government will purchase about $17 Billion worth of POSIX systems in FY91. Standards let the government avoid vendor-specific requirements like UNIX or SVID. The theory is that the larger the number of vendors that can meet the specification the lower the cost to the taxpayer. Whether that's true or not, using standards makes it harder to protest a purchase decision. On September 6, the National Institute of Standards and Technology (NIST) held a workshop to gather input from industry and federal agencies on the wisdom of adopting Draft 9 of the IEEE Standard for POSIX Shell and Utility Application Interface (P1003.2) as a Federal Information Processing Standard (FIPS). The meeting was attended by about a dozen system vendors and about half that many Federal agencies. Roger Martin of NIST opened the meeting with what was to be a three- minute introduction. NIST's agenda was to collect specific comments on the FIPS as printed on Page 23959 of the Federal Register. The vendors' agenda was to get NIST to give up the idea of adopting a FIPS until after the IEEE standard is final. Not surprisingly, given this clash, Roger's opening remarks ran over by a factor of 20. Here is NIST's case for adopting a FIPS based on POSIX.2/D9: 1. The federal government is going to purchase about $17 billion worth of systems with ``POSIX-like interfaces.'' NIST wants to give the agencies as must help as possible. Draft 9 is a good enough standard to serve this purpose. __________ 1. UNIXTM is a Registered Trademark of UNIX System Laboratories in the United States and other countries. September 1990 Standards Update NIST Shell-and-Tools FIPS Workshop - 2 - 2. It takes about a year to get a FIPS adopted. If POSIX.2 is not approved until mid-1991, a FIPS based on draft 9 will have a significant lifespan.2 3. If NIST were to publish a FIPS, it would accelerate the production of the P1003.2 standard. (just as FIPS 151 accelerated IEEE 1003.1-1988). 4. No agency is going to be stupid enough to demand draft 9 if a vendor can supply a system conforming to a later draft or to the final standard, so the FIPS will do no harm. (This was hotly debated.) After that introduction, and before the next attack on Roger Martin, Sheila Frankel and Rick Kuhn described the technical content of the FIPS. Basically, the idea is to adopt draft 9 minus the parts that might change. There are about 25 items that may change. NIST is looking for specific technical comments by October 15. Send comments to <frankel@swe.ncsl.nist.gov>. Comments like, ``I don't know if _____ is technically correct but I like the general idea,'' are welcome for specific items. Comments from government users are especially welcome. Comments from industry on the general wisdom of adopting a FIPS prior to the final IEEE approval of a standard will not be very welcome. Roger Martin came back for another round of target practice. He went over the general policy of NIST, which is to adopt standards from outside and at the highest possible level. The levels are, highest to lowest: - International Standards - National Standards - Draft Standards - de facto Standards __________ 2. Just because the IEEE approves a standard does not make it a Federal Information Processing Standard. The feds still have to go through the entire legal process of publishing it in the Federal Register, collecting comments, writing responses to those comments, and getting it signed by the Secretary of Commerce. This process takes about a year even for a null standard. September 1990 Standards Update NIST Shell-and-Tools FIPS Workshop - 3 - NIST could be convinced to change from POSIX.2/D9 to POSIX.2/D10. Here are the factors it will consider: 1. How much delay is introduced (Three months may be OK. One year is unacceptable.) 2. Is Draft 10 that much better than Draft 9? Is this just a delaying action? Shane McCarron, former Watchdog Report Editor (now of UNIX International), made a great speech pointing out how much wasted effort would occur if every vendor had to rush out and implement POSIX.2/D9. The NIST people seemed shocked at how different POSIX.2/D9 is from existing practice. [Editor: See Randall Howard's POSIX.2 report for some examples of just how different Draft 9 is from Drafts 8 and 10.] Nevertheless, the argument seemed to fall on deaf ears, because NIST claimed that a promise to meet the FIPS should be good enough and everyone can still wait for AT&T USL to write the code. It was pointed out that Congress did not allocate enough funding for NIST to do much testing for POSIX.2 conformance. This means that vendors will have to ``self certify'' and coverage may vary. After some discussion this item was placed into the ``write your representative'' category, because only Congress can allocate the money. NIST pointed out that they are under a great deal of pressure to ``advise'' federal agencies who want to move to open systems. A large percentage of RFPs for POSIX-like systems will be coming from groups who know nothing about such systems. Vendors were worried that this ``advice'' would end up in court cases and be read by judges as ``regulations.'' In my opinion, NIST is going to go ahead and publish a flawed FIPS in the belief that it will drive the IEEE to pick up the pace of POSIX. The Government has a burning need for a standard, they find it politically unacceptable to use UNIX System V as that standard, and they strongly prefer action over waiting for the IEEE. September 1990 Standards Update NIST Shell-and-Tools FIPS Workshop Volume-Number: Volume 21, Number 146 shar.nist.23858 echo overview cat >overview <<'shar.overview.23858' From std-unix-request@uunet.uu.net Thu Oct 11 22:27:23 1990 Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP id AA28187; Thu, 11 Oct 90 22:27:23 -0400 Posted-Date: 11 Oct 90 21:26:10 GMT Received: by cs.utexas.edu (5.64/1.78) From: jsh@usenix.org (Jeffrey S. Haemer,) Newsgroups: comp.std.unix Subject: Standards Update, Recent Standards Activities Message-Id: <13501@cs.utexas.edu> Sender: fletcher@cs.utexas.edu Reply-To: std-unix@uunet.uu.net Organization: USENIX Standards Watchdog Committee X-Submissions: std-unix@uunet.uu.net Date: 11 Oct 90 21:26:10 GMT To: std-unix@uunet.uu.net Submitted-by: jsh@usenix.org (Jeffrey S. Haemer,) An Update on UNIX1-Related Standards Activities October 11, 1990 USENIX Standards Watchdog Committee Jeffrey S. Haemer, jsh@ico.isc.com, Report Editor Summer-Quarter Standards Activities This editorial addresses some of the summer-quarter standards activi- ties covered by the USENIX Standards Watchdog Committee.2 In it, I've emphasized non-technical issues, which are unlikely to appear in offi- cial minutes and mailings of the standards committees. Previously published watchdog reports give more detailed, more technical sum- maries of these and other standards activities. If my comments move you to read one of those earlier reports that you wouldn't have read otherwise, I've done what I set out to do. Of course, on reading that report you may discover the watchdog's opinions differ completely from the ones you see here. As watchdog editor I edit the reports, I don't determine their contents. The opinions that follow, in contrast, are mine. Profiles There's an explosion of activity in the profiles world, bringing with it an explosion of problems, and dot zero, the POSIX guide group, is at ground zero.3 The first problem is, ``What's a profile?'' Everyone has a rough idea: it's a document that specifies an application- specific set of standards (or pieces of standards). The best informal illustration I've heard is from Michele Aden, of Sun Microsystems. Imagine, she says, you have to write a guideline for buying lamps for Acme Motors. You might require that the lamps have ANSI-standard, three-prong plugs, accept standard one-way, hundred-watt bulbs, have cords no shorter than five feet, and stand either two- to three-feet tall (desk models) or five- to seven-feet tall (floor-standing models). This combination of pointers to standards, additional specifications, and detailed options, which gives purchasing agents __________ 1. UNIXTM is a Registered Trademark of UNIX System Laboratories in the United States and other countries. 2. A companion article provides a general overview of the committee itself. 3. I use ``dot zero'' to refer both to the P1003.0 working group and to the document it's producing. These are common conversational conventions among standards goers, and which of the two I mean is usually obvious from context. October 11, 1990 Standards Update Recent Standards Activities - 2 - guidelines to help them make choices without tying their hands to a specific vendor, is a profile - in this case, an Acme Motors lamp pro- file. Dot zero now sees itself as a group writing a guide to help profile writers pick their way through the Open-Systems'-standards maze. But that rough agreement is as far as things go. And the standards world is never informal. For ``profile'' to graduate from a hallway- conversation buzzword to an important organizing principle, it needs a precise definition. And since there are already four groups writing profiles - real-time, transaction processing, multiprocessing, and supercomputing - TCOS needs to figure out what a profile is pretty quickly. ISO already has IAPs, International Applications Profiles. The ISO document TR 10K describes these in detail. Unfortunately, TR 10K was developed for OSI-related profiles and shows it. Cut-down extracts of the standard appear in the document. Someone needs to define a PAP, a POSIX Application Profile. But that's just the first problem. Even thornier is the question ``What does it mean to say that something conforms to the POSIX transaction-processing profile?'' If I want to write assertions for a profile or tests to verify those assertions, how do I do it? Does it suffice to conform to the individual components? What about their interactions? The first principle of management is ``If it ain't somebody's job, it won't get done.'' Dot zero has done such a good job of promoting The Profile as an organizing principle for addressing standards issues that people are beginning to press dot zero for answers to questions like these. Unfortunately, that's a little like killing the messenger. It's just not dot zero's job. So the funda- mental profile question is ``Who's in charge?'' Right now, I think the question sits squarely, if uncomfortably, in the lap of the SEC - the Sponsors Executive Committee, which oversees the IEEE's operating-systems activities. In the meantime, the various working groups writing profiles are mak- ing headway by just trying to define profiles and seeing where they get stuck. Dot twelve, the real-time profile group, is busily making various sorts of tables, to try to find a reasonable way to specify the pieces that make up a profile, their options, and their interac- tions. Dot ten, the supercomputing profile group, is seeking an overall structure for a profile document that makes sense. Dot eleven, the transaction-processing profile group, is trying to steal from dots twelve and ten, an important test of the generality of the other two groups' solutions. Dot fourteen, the multiprocessing pro- file group, isn't far enough along to make theft worth their while, but will eventually provide a second generality test. Think of it as a problem in portable ideas. October 11, 1990 Standards Update Recent Standards Activities - 3 - Will_I_Win_My_Beer? In my last editorial, I announced a beer bet with John Gertwagen over whether threads will ballot and pass before the base dot-four (real- time) ballot objections are resolved. I'm still betting on threads, but it looks like the bet is still anyone's to win. Some folks assure me that I'll win my beer handily, others say I don't have a chance. At the summer POSIX meetings, in Danvers, Massachusetts, the dot-four chair, Bill Corwin, challenged the threads folks to come up with a ballotable draft by the end of the week, and they very nearly did. (I hear complaints from some quarters that the the vote to go to ballot was 31 to 7 in favor, and that attempts to move to balloting were only blocked because of filibusters from those opposed.) On the other hand, technical reviewers are now resolving ballot objections to the base with machetes. They've thrown away asynchronous events alto- gether and have discarded real-time files and adopted the mmap model that the balloting group suggested.4 Dot four has moved from ``design by working committee'' to ``design by balloting committee.'' Innovation C.A.R. Hoare once said, ``One thing [the language designer] should not do is to include untried ideas of his own.'' We have followed that precept closely. The control flow statements of Ratfor are shamelessly stolen from the language C, developed for the UNIX operating system by D. M. Ritchie. - Kernighan and Plauger5 Should standards groups just standardize existing practice, or should they be solving known problems? And if they solve known problems, how much innovation is allowed? Shane McCarron's September UNIX/Review article6 uses the real-time group, dot four, as a focus for an essay on this subject. His thesis is that standards bodies should only be allowed to standardize what's boring. I've already seen John Gertwagen's reply, which I assume will be printed in the next issue. __________ 4. Dot four's real-time files are currently a part of the supercomputing profile. If they disappear from dot four, they may reappear elsewhere. 5. Kernighan, Brian and Peter Plauger, Software Tools, Addison- Wesley, 1979, p. 318. 6. McCarron, Shane, ``Commodities, Standards, and Real-Time Extensions,'' UNIX Review, 8(9):16-19 (1990). October 11, 1990 Standards Update Recent Standards Activities - 4 - I find myself agreeing (and disagreeing) with both and recommend you read them. This battle will rage brighter in some of the groups less far along, but sporadic fighting still breaks out in the shell and tools group, dot two. Right now, collation and character classification are seeing a lot of skirmishing. Some want to stay relatively close to the existing practice, while others want to grow a mechanism to deal with the Pandora's box of internationalization. My favorite current exam- ple, though, is make. Bradford's augmented make is almost a decade old. Stu Feldman's original is a couple of years older than that. That decade has seen a number of good make replacements, some of them wildly successful: Glenn Fowler's nmake has virtually replaced make for large projects in parts of AT&T. Still, many of these upgrades maintain the original make model,7 just patching up some of make's more annoying craters and painting over its blemishes. At this point, there is real consensus among make augmentors about some patches. Most upgrades expand make's metarules. For example, .c.o: $(CC) $(CFLAGS) $< might become %.c : %.o $(CC) $(CFLAGS) $< Not much of a change, but it also gives us s.% : % $(GET) $(GFLAGS) -p $< > $> ... in place of the current, baroque __________ 7. Fowler, Glenn, ``A Case for make,'' Software-Practice and Experience, 20: S1/35-S1/46 (1990). October 11, 1990 Standards Update Recent Standards Activities - 5 - .c~.o: $(GET) $GFLAGS) -p $< > $> ... Make's successors don't agree on syntax, but they all agree agree that ``~'' rules are the wrong solution to a real problem. Should dot two standardize a newer solution? Existing-practice dogmatists would say, ``No. It's not make.'' Here's a place I say, ``Yes - if we can do it in a way that doesn't break too many makefiles.'' The prohibition should be against untried ideas, and I don't see those here. A year or so ago, Stu Feldman (make), Glenn Fowler (nmake), Andrew Hume (mk), and a handful of other make luminaries presented a proposal to add four extensions to dot two's make. Not one is yet in the draft. I hope that changes. SCCT_Faces_Serious_Problem At Danvers, the testing group, dot three, worked with dot two on test assertions to try to avoid the kinds of problems created by the P1003.1 test assertions, which dot one had no input into until the assertions were in ballot. A side effect of the collaboration, which is taking place before dot two is finished, is that it may reveal that parts of dot two are imprecise enough to require a rewrite. Dot two, draft eight had around four-hundred ballot objections, draft nine saw fewer than half that number. There was hope that draft ten would halve that again, bringing it within striking distance of being a standard8 The asser- tion work may point out and clear up rough spots that might otherwise have escaped the notice of battle-fatigued balloters. (Paradoxically, NIST, which is heavily represented in dot three and painfully familiar with dot two's status and problems, is currently pushing for a shell- and-tools FIPS based on the now-out-of-date draft nine.) The exercise of trying to construct assertions for dot two before it goes to ballot may bring some new testing problems into focus, too. Before I explain what I mean, I'll give you a little background. The POSIX effort has outgrown dot three, which did test assertions for dot one and is in the process of constructing test assertions for dot two. Dot three has, at most, a couple of dozen members, and the docu- ment for dot two alone may swell to one- or two-thousand pages.9 If __________ 8. It didn't reach that goal. Keith Bostic tells me he submitted 132 objections himself. October 11, 1990 Standards Update Recent Standards Activities - 6 - dot three were to continue to do all test assertion work, it would have to produce a similar document for at least a dozen other stan- dards. Reacting to this problem, the SEC created a steering committee, the SCCT, to oversee conformance testing. The committee's current plan is to help guide standards committees to write their own assertions, which will be part of the base document. Test assertions, like language independence, are about to become a standards requirement (a standards standard). With this change, the current process - write a base document, evolve the base document until it's done, write test assertions for the result, evolve the test assertions until they're done - would become: write a base document with test assertions, then evolve the base docu- ment modifying the test assertions as you go. A sensible-enough idea on the surface, but after the joint dot-two, dot-three meeting I have questions about how deep that sense runs. First, does it really make sense to write assertions early? Working- group members should be exposed to assertion writing early; when working-group members understand what a testable assertion is, it's easier to produce a testable document. Still, substantive, major draft revisions are normal, (see the real-time group's recent ballot, for example) and keeping test assertions up-to-date can be as much work as writing them from scratch. This meeting saw a lot of review of draft-nine-based assertions to see which ones had to change for draft ten. Second, if you make the assertions part of the standard, they're voted on in the same ballot. Are the same people who are qualified to vote on the technical contents qualified to vote on the test assertions? Third, writing good assertions is hard, and learning to write them takes time. How eager will people in working groups be to give up time they now spend writing and revising document content in order to do assertions? Fourth, is the time well-spent? Not everything merits the time and expense of a standard. If only a small number of organizations will ever develop test suites for a particular standard (with none being a ______________________________________________________________________ 9. Any imagined glamour of POSIX meetings fades rapidly when one is picking nits in a several-hundred-page standards document. When asked where the next meeting was, one attendee replied, ``some hotel with a bunch of meeting rooms with oversized chandeliers and little glasses full of hard candies on the tables.'' October 11, 1990 Standards Update Recent Standards Activities - 7 - special, but important case) does it make sense for folks to spend time developing standards for those test suites? Wouldn't it make more sense to develop it after there is a clear need? (This is a per- verse variant of the ``existing practice'' doctrine. Even if you don't think standards should confine themselves to existing practice, does it make sense to innovate if there's never going to be an exist- ing practice?) Stay_Tuned_for_This_Important_Message If you haven't yet had the pleasure of internationalizing applica- tions, chances are you will soon. When you do, you'll face messaging: modifying the application to extract all text strings from external data files. The sun is setting on main() { printf("hello, world\n"); } and we're entering a long night of debugging programs like this: #include <stdio.h> #include <nl_types.h> #include "msg.h" /* decls of catname(), etc. */ #define GRTNG "hello, world\n" nl_catd catd; main() { setlocale(LC_ALL, ""); catd = catopen(catname(argv[0]), 0); printf(catgets(catd, SETID, MSGID, GRTNG)); catclose(catd); exit(0); } This, um, advance stems from a desire to let the program print ch`o c'c ^ng instead of hello, world when LANG is set to ``Vietnamese.'' October 11, 1990 Standards Update Recent Standards Activities - 8 - Most programs use text strings, so the system services interface group, dot one, has been thinking about portable library calls to sup- ply such strings and portable formats for the files that contain them. Actually, ``re-thinking'' is probably more accurate than ``thinking about.'' 1003.1a Draft 9, specified a design by the UniForum Techni- cal Committee on Internationalization. At Danvers, X/Open counter- proposed a variant of its existing XPG3 specification, arguing that the X/Open scheme may have problems but it also has users, while the UniForum proposal is still in the laboratory. (It brings to mind the apocryphal story of Stu Feldman's wanting to improve the design of make, but feeling he couldn't because he already had seven users.) Someone from Unisys also brought a proposal, different from both UniForum's and X/Open's. That no one even showed up to defend the UniForum proposal shows that there is something wrong with standardizing messaging. One minute, there is enough support for a messaging scheme to get it into the draft standard; the next, there's none at all. In the end, the work- ing group agreed that a messaging standard was premature and that the free market should continue to operate in the area for a while. Given the relative sizes of the organizations concerned, this outcome probably sticks us with the X/Open scheme for a while, which I find the ugliest of the lot. Still, it's not a standard, and there's room for innovation and creativity if we're quick about it. The ``existing practice'' criterion is supposed to help avoid a requirement for mas- sive, murderous source code changes. We should be looking for the messaging scheme that doesn't require changes in the first place, not the one with the most existing victims. Language_Independence_Stalls_ISO_Progress Internationally, 1003.4 (real-time), 1003.5 (Ada bindings), and 1003.9 (FORTRAN bindings) are being held hostage by ISO, which refuses to loose them on the world until we come up with a language-independent binding for 1003.1. The question is, who will do the work? ``Not I,'' says dot four, whose travel vouchers are signed by companies caught up in the glamour of real-time and threads; ``Not I,'' say dot five and dot nine, who seldom have even ten working-group members apiece; ``Not I,'' say the tattered remnants of dot one, exhausted from struggling with 1003.1-1988, FIPS-151 and 151-1, and (almost) 1003.1-1990, before any other groups have even a first standard passed. Where is the Little Red Hen when we need her? Should_We_Ballot_POSIX_the_Way_We_Ballot_Three-Phase_Power? In the meantime, we progress inexorably toward balloting on several IEEE/ANSI standards. The sizes of the drafts (and several contribu- tors to comp.std.unix) raise real questions about whether the IEEE's balloting process make sense for the sort of standards work POSIX is October 11, 1990 Standards Update Recent Standards Activities - 9 - performing. A month or so might be enough to review a few-page hardware standard. But is it enough for the nearly 800 pages in the latest recirculation of dot two? Does it really make sense to review the standard for grep in hard copy? Many would like to see longer balloting times and on-line access to drafts. Some argue that the final standard should be available only from the IEEE, both to insure authenticity and to provide the IEEE with income from its standards efforts; even that argument seems weak. Checksums can guarantee authenticity, and AT&T's Toolchest proves that electronic distribution works: I'll bet ksh has paid for itself several times over. ``We_handed_1201.1_its_head_and_asked_it_to_comb_its_hair.'' Moving away from POSIX, we come upon 1201.1, still in search of an officially sanctioned mission that the group wants to take on. The group currently has a PAR (charter) to standardize various aspects of X-based windowing - principally the toolkit-level API - but any hope of compromise between the OPEN LOOK and OSF/Motif factions died at the winter-quarter Utah meetings. In a moment of responsible, adult behavior, the group recovered by switching to a dark horse: a window-system-independent API that could be implemented on top of either product. Marc Rochkind's XVT, which already allows users to write programs that are portable across several, unrelated window sys- tems including X, the Mac, and MS-Windows, was offered as a proof-of- concept. While the original charter could probably encompass the new XVT work, the group seemed to feel that this direction change, together with the fragmenting of the original group into separate toolkit, drivability, UIMS, and X intrinsics efforts, required that they ask the SEC for a new charter. (The drivability group has already had a separate PAR approved and is now 1201.2.) The group convened a pair of interim meetings in Milpitas, California, and Boulder, Colorado, to forge a PAR that would meet the SEC's new, stricter standards for PAR approval by the summer Danvers meeting. They didn't succeed. Most of the problems seem to have been administrative missteps. Some examples: - Working-group members complained that the Milpitas meeting took place without enough notice for everyone to attend, and issues that had been resolved at the interim meetings were re-opened in Danvers. - The PAR was so broadly written that at least one technology (Ser- pent) was advanced as a candidate that almost no one thought should even be considered. - Some working-group members hadn't even received copies of the XVT reference manual before they reached Danvers. October 11, 1990 Standards Update Recent Standards Activities - 10 - - Many SEC members appeared not to have seen a copy of the PAR until the afternoon before the SEC meeting, and some saw the final PAR for the first time at the SEC meeting itself. Many people who weren't familiar with the proposal ended up uneasy about it, not because they'd read it and didn't like it - they'd not been given much chance to read it - but because a lack of attention to administrative details in the proposal's presentation sapped their confidence in the group's ability to produce a sound standard. After all, standards work is detail work. In the end, the SEC tactfully thanked the group and asked them to try again. One SEC member said, ``We handed 1201.1 its head and asked it to comb its hair.'' I believe all of this is just inexperience, not a symptom of fundamen- tal flaws in the group or its approach. If 1201.1 can enlist a few standards lawyers - POSIX has no shortage of people who know how to dot all the i's and cross all the t's - and can muster the patience to try to move its PAR through methodically and carefully, I think the group will give us a standard that will advance our industry. If it doesn't do so soon, though, the SEC will stop giving it its head back. POSIX_Takes_to_the_Slopes Finally, I want to plug the Weirdnix contest. We currently have a great prize- including a ski trip to Utah - and only a few entries.10 The contest closes November 21, 1990. Send your entries to me, jsh@ico.isc.com. __________ 10. The occasionally heard suggestion that Brian Watkins was found clutching Mitch Wagner's entry is tasteless; it is almost - but, luckily, not quite - beneath me to repeat it. October 11, 1990 Standards Update Recent Standards Activities Volume-Number: Volume 21, Number 198 shar.overview.23858 echo tag cat >tag <<'shar.tag.23858' From std-unix-request@uunet.uu.net Fri Sep 28 15:37:12 1990 Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP id AA14219; Fri, 28 Sep 90 15:37:12 -0400 Posted-Date: 28 Sep 90 18:30:33 GMT Received: by cs.utexas.edu (5.64/1.76) From: jsh@usenix.org (Jeffrey S. Haemer) Newsgroups: comp.std.unix Subject: Standards Update, U.S. TAG to ISO/IEC/JTC1/SC22 WG15 Message-Id: <559@usenix.ORG> Sender: jsq@usenix.ORG Reply-To: std-unix@uunet.uu.net Organization: USENIX Standards Watchdog Committee X-Submissions: std-unix@uunet.uu.net Date: 28 Sep 90 18:30:33 GMT To: std-unix@uunet.uu.net Submitted-by: jsh@usenix.org (Jeffrey S. Haemer) An Update on UNIX*-Related Standards Activities September 27, 1990 USENIX Standards Watchdog Committee Jeffrey S. Haemer, Report Editor U.S. TAG to ISO/IEC/JTC1/SC22 WG15 Susanne Smith <sws@calvin.wa.com> reports on the July 19, 1990 meeting in Danvers, MA: 1. Overview Before you ask, ISO/IEC JTC1 SC22 WG15 is ISO POSIX. The U.S. TAG is the United States Technical Advisory Group, which formulates the U.S. position on WG15 issues, and chooses the members of the U.S. delegation to the international WG15 meetings. This meeting began at 8:00 A.M. and ended before noon. This must be a record -- not just for the TAG, but for any standards group meeting. There were three major business items: - language independence, - document circulation procedures (yawn), and - rapporteurs. This short agenda, coupled with a determination to avoid an extra meeting, like the Denver meeting we were forced into in June, kept the discussion on track all morning. ISO POSIX: Winners and Losers The vote for 9945-1.2 (1003.1a draft 5) was unanimously in favor without substantive comments. If all goes well there just may be an IEEE version of 9945-1 available in Seattle. Let's all cross our fingers. Now that it's September I think we need to cross our toes as well. My last report mentioned the formatting problems with the 9945-1 document. The TAG had decided to request the formation of an ad hoc committee in Paris to try to resolve these problems. WG15 resolved to __________ * UNIXTM is a Registered Trademark of UNIX System Laboratories in the United States and other countries. September 27, 1990 Standards Update U.S. TAG to ISO/IEC/JTC1/SC22 WG15 - 2 - instruct the WG15 convener, Jim Isaak, to request written editorial requirements from the ITTF (formerly the Central Secretariat) and IEEE, and forward these to SC22. The emphasis here should be on written requirements. WG15 refused to register 1003.4, real-time extensions, as a CD (committee document, formerly DP, draft proposal) because it is not a language-independent specification. They were also concerned that the standard might have to change once there is a language independent version of 1003.1. 1003.5, Ada binding, and 1003.9, FORTRAN binding, suffered a similar fate for different reasons. 1003.5 and 1003.9 were held off until at least the October WG15 meeting because G15 had not seen the 1003.5 and 1003.9 documents, and were reluctant to register something they hadn't seen before. And again, they were concerned that these standards might have to be re-written once there is a language independent version of 1003.1. Administrivia Skip to the next section if you're easily bored or just not interested in bureaucracy. Why, you ask, was WG15 being asked to register something they had not seen before? Here are the steps that have to complete before a document gets circulated: 1. The committee and SEC approve its release. 2. The TAG approves its circulation. 3. The committee chair delivers the document to the TAG chair, Donn Terry. 4. The TAG chair forwards the document to the WG15 convener, Jim Isaak. 5. The WG15 convener distributes the document. 1003.5 and 1003.9 were approved by the TAG for circulation to WG15 during the April meeting in Snowbird. This left six weeks for for the documents to be circulated and read. The problem was that the TAG chair did not receive the documents in time to have them circulated before the meeting. To avoid this problem in the future, the TAG is going to ask the SEC to assign an action item to the committee chair so that there is a method to track this task. In other news: September 27, 1990 Standards Update U.S. TAG to ISO/IEC/JTC1/SC22 WG15 - 3 - - The TAG procedures were entered and marked up, and will be included in the next mailing. - The meeting in Seattle will start our new meeting schedule of Sunday from 6 to 10 P.M., all Thursday, and again Friday if necessary. Are You Ready for UNIX in VDM? We cannot delay language independence for 1003.1 any longer. It's now really holding up international progress on important POSIX efforts. But what format or technique should we use? ISO rules seem to require an ISO-standard method, which could restrict us to VDM (Vienna Definition Method), but no one thinks VDM will work. Paul Rabin and Steve Walli have been working on a method, but the TAG worries that a non-standard method will create problems like those we've suffered through with document formats (see last TAG report). In order to avoid rejection later we will circulate the new method in SC22 and WG15 for review and comment. To make this circulation useful, Donn Terry is listing specific questions for SC22 and WG15 to answer. [Editor: I believe that ISO rules only restrict us to VDM if we produce a formal definition, i.e., something from which one could do correctness proofs. Of course, rules and politics are not always the same thing and using VDM might help grease the skids. Still, we should stop and ask if not using VDM would hold us up any more than using VDM.] The TAG will also ask the WG15 convener to schedule an ad hoc meeting on language independence, during the October WG15 meeting, to help move it along. ``Rap, a-rap, a-rap, they call me the rapporteur.'' Rapporteurs are technical experts on specialized aspects of a particular standards effort. Their scope is usually broader than an individual standard, and they usually coordinate efforts in several standards bodies. WG15 has three rapporteur groups, one each for conformance, internationalization, and security. We send a representative to each. The conformance-testing rapporteur group will be looking at 1003.3 draft 12 (conformance testing), and the OSF-UI-X/Open Phoenix project as potential base documents for the ISO 9945-series documents. The Phoenix project is developing a conformance-testing platform. We will not have to decide whether we want to submit 1003.3 as a new work item in this area until 1991. Ralph Barker asked that UniForum be allowed to send him and one UniForum Internationalization Technical Committee member to the next internationalization rapporteur group meeting. This person would be subject to subcommittee approval but selected by UniForum. Worry September 27, 1990 Standards Update U.S. TAG to ISO/IEC/JTC1/SC22 WG15 - 4 - about the fact that the TAG would not choose this person evaporated when it became clear that Donn Terry would continue as internationalization rapporteur and that the UniForum members would just be an addition. The TAG appointed Al Weaver security rapporteur to fill the vacancy Terry Dowling left when he resigned in January. Summary The most important development is that the synchronization proposal discussed in the last report is already dead. This proposal was to have fed balloting responses from IEEE into WG15, and vice-versa, allowing WG15 approval to follow on the heels of IEEE approval. Now, while the IEEE is advancing, everything in WG15 is blocked by 1003.1 language independence. September 27, 1990 Standards Update U.S. TAG to ISO/IEC/JTC1/SC22 WG15 Volume-Number: Volume 21, Number 147 shar.tag.23858 echo x3b11.1 cat >x3b11.1 <<'shar.x3b11.1.23858' From std-unix-request@uunet.uu.net Tue Sep 18 20:20:39 1990 Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP id AA14166; Tue, 18 Sep 90 20:20:39 -0400 Posted-Date: 18 Sep 90 23:37:37 GMT Received: by cs.utexas.edu (5.64/1.76) From: jsh@usenix.org (Jeffrey S. Haemer) Newsgroups: comp.std.unix Subject: Standards Update, ANSI X3B11.1: WORM File Systems Message-Id: <525@usenix.ORG> Sender: jsq@usenix.ORG Reply-To: std-unix@uunet.uu.net Organization: USENIX Standards Watchdog Committee X-Submissions: std-unix@uunet.uu.net Date: 18 Sep 90 23:37:37 GMT To: std-unix@uunet.uu.net Submitted-by: jsh@usenix.org (Jeffrey S. Haemer) An Update on UNIX*-Related Standards Activities September 1990 USENIX Standards Watchdog Committee Jeffrey S. Haemer <jsh@usenix.org>, Report Editor ANSI X3B11.1: WORM File Systems Andrew Hume <andrew@research.att.com> reports on the July 17-19, 1990. meeting in Murray Hill, NJ: Introduction X3B11.1 is working on a standard for file interchange on write-once media (both sequential and non-sequential (random access)): a portable file system for WORMs. The fifth meeting was held at Murray Hill, NJ on July 17-19, 1990. We adopted a working paper and set to work on a list of issues suggested by the chair. Data Compression Despite the huge capacities of WORM disks, people always want more. Data compression is an easy way to supply more, and on current machine architectures, probably can speed data access by trading CPU cycles for I/O bandwidth. Its main problem is that you need to support more than one algorithm and thus, you need some way to specify algorithms. This is a purely administrative issue, but luckily, it appears that X3 may soon act as a registry for compression algorithms (driven by the need to register compression algorithms for IBM 3840 cartridge tape work in X3B5). (How does this fit in with the rumblings about compress from POSIX.2? I'm not certain. I think part of becoming part of the register means giving up patent rights or allowing liberal licensing, but maybe not. After all, the CD formats are now an ISO standard, but I still think you have to be licensed to make them.) Path Tables and Extended Attributes Path tables were removed from the working paper. We agreed to support hard and symbolic links. The next question was how to handle ``secret'' files: files primarily intended for system use. Examples might include the file describing free space, associated files (like the resource fork of a Macintosh file), and extended attributes (of a Microsoft HPFS file). We agreed that the latter two cases should be handled by regular files that probably are not in the directory tree __________ * UNIXTM is a Registered Trademark of UNIX System Laboratories in the United States and other countries. September 1990 Standards Update ANSI X3B11.1: WORM File Systems - 2 - but are pointed to by the ``inode'' for a file. (Note that this implies there is a way to scan all the files in a volume set without traversing the directory tree(s), analogous to running down the inodes in UNIX.) Given this, we have decided to support extended attributes as a ``secret'' or system file (and probably include pointers to things like resource forks as those attributes). This also gives us an extensible way of handling non-standard or non-essential inode fields. One of the important tasks remaining is to decide which fields are more-or-less mandatory (such as modify time, owner) and which can safely be pushed off into the extended attributes (access control lists, file valid after date). Please send us your suggestions! Space Allocation and Management We agreed that we have to support preallocating space for files, freeing some or all of that space and then reusing that space for other files. After much discussion about extent lists and bit maps, we compromised on a scheme based on extent lists (the details to be worked by the working paper editor). The idea is that is that the free space is described by an extent list (of small but specifiable size) of the ``best'' (probably largest) free spaces, and if this overflows, ``worst'' free spaces are added to a system file representing all the free spaces not in the above extent list. Checksums It was decided that all system data structures would include a 16 bit checksum (CRC-16). We anticipate that most errors would be transient (cabling or memory) and not be media errors. Multi-Volume Sets I had thought the last meeting had settled just about all the questions about multi-volume sets; I was wrong. It took most of a day to agree on these. - You have to have the last volume in order to grok the whole volume set (access any/all of the directories and files). - You can extend volume sets at any time. This and the last item taken together imply the existence of ``terminal'' volumes (which can act as master volumes of a volume set) and ``nonterminal'' volumes (the rest). For example, if I extend a single-volume volume set by two volumes, then volumes 1 and 3 are terminal and volume 2 is not. - You can extract file data from any volume by itself. This is meant only for disaster recovery (I dropped the master volume down the stairwell) and doesn't imply any requirements on September 1990 Standards Update ANSI X3B11.1: WORM File Systems - 3 - directory tree information (much as fsck restores unattached inodes to /lost+found). - Volumes can refer to data (say, extents) on other volumes (both earlier and later volumes). Preallocated space on any volume in a volume set can be returned for future reuse. - The address space of logical blocks for the volume set will be 48 bits; 16 bits for the volume number and 32 bits for the logical block number within a volume. Media can be big (200GB helical scan media exist now) so 32 bits may seem barely big enough, but in such cases you can use a big logical block size. For example, a logical block size of 16KB implies a limit of 64 terabytes per volume; this should be ample for a few years. Defect Management We spent a lot of time on this and learned a lot, but basically put it off to the next meeting. What we mean by ``defect management'' is ``How do we deal with write errors from the file system's point of view?'' (We ignore the disk controller and the device driver, both of which do some unknown amount of more-or-less transparent error management.) We discussed the ``sane'' approach: insert a layer between the file system that handles errors, allowing the file-system code to assume an error-free interface. This apparently good idea is ruled out by slip-sectoring, a (to my mind bogus) technique, which says, ``if writing block n fails, then try subsequent blocks (n+1, n+2, ...) until we succeed.'' Slip-sectoring is mainly used to enhance performance (it does ensure that blocks are more-or-less contiguous), and some disk controllers use it as their error-management technique. (This really screws up your logical address space; it is legitimate for a SCSI disk, your typical error-free, logical-address-space disk interface, to write logical block 5 at physical block 5, then logical block 1 at physical block 4 (1-3 were write errors), then disallow I/O to logical blocks 2,3, and 4 because there is no place to put them - these blocks just vanish!) As preparation for the next meeting, Don Crouse, who deals mainly with high-end machines like Crays and large IBMs, is writing a position paper on performance, and members of the committee, many of whom are drive manufacturers or integrators, are collecting estimates of error rates we have to deal with. (This matters; I see one bad block out of 100,000, but some people have used drives with a bad block in every 100.) The problem is that WORMs have really slow seek times, and when you are pouring a 50MB/s Cray channel at a set of WORMs, you can't afford to spend 1-2 seconds seeking to the bad block area. I personally think we should just do regular bad-block mapping (like most SMD disk drivers) out of a special system file, and people with performance concerns should arrange to have this space spread over the disk. September 1990 Standards Update ANSI X3B11.1: WORM File Systems - 4 - Endian-ness A poll was taken of who really cared which way integer fields were stored; the results were LSB - 1, MSB - 1, Don't Care - 11. It is awkward to specify one of LSB and MSB; this puts half the systems out there at a competitive (performance) disadvantage (though I am skeptical of whether it's significant). Even though we're specifying an interchange standard, the group felt that most interchange would be between systems of the same endian-ness, so we should, somehow, allow native byte order. Accordingly, we agreed that endian-ness will be specified in the volume header (for the whole volume set). In retrospect, I think this was silly; we should have just picked one way. In order that everyone important be evenly disadvantaged, we could have used some byte order like 3-0-1-2 that no one uses. Finale The committee is trying to nail down a firm proposal for balloting. We anticipate a substantial amount of change at the next meeting (Oct 16-18 in Nashua, NH) and have reserved time (Dec 11-13, but no place) for an additional meeting so that we can ballot after the following meeting (Jan 29-31, Bay area). We now have a working paper (available by the end of September or so); I think it likely we can meet this schedule, but who knows. Anyone interested in attending any of the above meetings should contact either the chairman, Ed Beshore (edb@hpgrla.hp.com), or me (andrew@research.att.com, research!andrew, (908)582-6262). I am also soliciting your comments on necessary inode fields and defect management. I will present anything you give me at the next meeting. September 1990 Standards Update ANSI X3B11.1: WORM File Systems Volume-Number: Volume 21, Number 116 shar.x3b11.1.23858 echo x3j16 cat >x3j16 <<'shar.x3j16.23858' From std-unix-request@uunet.uu.net Wed Oct 3 11:21:46 1990 Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP id AA18463; Wed, 3 Oct 90 11:21:46 -0400 Posted-Date: 3 Oct 90 14:58:36 GMT Received: by cs.utexas.edu (5.64/1.76) From: jsh@usenix.org (Jeffrey S. Haemer) Newsgroups: comp.std.unix Subject: Standards Update, X3J16: C++ Message-Id: <571@usenix.ORG> Sender: jsq@usenix.ORG Reply-To: std-unix@uunet.uu.net Organization: USENIX Standards Watchdog Committee X-Submissions: std-unix@uunet.uu.net Date: 3 Oct 90 14:58:36 GMT To: std-unix@uunet.uu.net Submitted-by: jsh@usenix.org (Jeffrey S. Haemer) An Update on UNIX1-Related Standards Activities October 3, 1990 USENIX Standards Watchdog Committee Jeffrey S. Haemer <jsh@usenix.org>, Report Editor X3J16: C++ Mike Vilot <mjv@objects.mv.com> reports on the July meeting in Seattle, Washington: Standard C++? The C++ programming language has been gaining popularity at a remarkable rate (an informal estimate is that the C++ population doubles every nine months). One reaction to the growing popularity has been a call to stabilize the language's definition, and achieve some consistency across implementations. C++ is popular enough that larger corporations are considering adopting it as an officially endorsed development language -- but some cannot make such a move unless the language is defined by a standard. For these and other reasons, the ANSI secretariat agreed to establish the X3J16 committee to formulate a standard for C++. Dmitry Lenkov, of HP, made the official proposal, and serves as chairman of the committee. To date, X3J16 has met three times: an organizational meeting last December, the first technical meeting in March to get organized, and a meeting in July to really get started. The December meeting, in Washington D.C., was purely administrative: over 50 attendees received lectures and tons of paper on X3 rules and procedures. The highlight of the day was an invited presentation by Bjarne Stroustrup on ``the spirit of C++.'' The transcript is available as committee document X3J16/90-0022 or from Greg Comeau at Comeau Computing, 91-34 120th Street, Richmond Hill, NY 11418, (718) 849-2355. March meeting AT&T hosted the meeting in New Jersey. Most of the week was spent on administrative matters, while the group got organized and accustomed to The Bureaucratic Way. Since most of the members are engineers, the highlight of the week was the evening technical sessions on implementing exception handling for C++. (The week was sort of a __________ 1. UNIXTM is a Registered Trademark of UNIX System Laboratories in the United States and other countries. October 3, 1990 Standards Update X3J16: C++ - 2 - mini-Usenix conference, as most members had gone without a substantial C++ gathering since the October '88, Denver conference.) The week's major activities were discussing and preparing a goals document, describing the committee's activities and priorities. Goals Here is a brief outline of the goals document, which is available as X3J16/90-0023: 1. Base documents: C++ Reference Manual, ANSI C (ANS X3.159-1989), ISO C when available. 2. Standardize syntax and semantics of the language as a token sequence without the presence of preprocessing directives. 3. Define and standardize a minimum set of C++ libraries, their contents, and interfaces. 4. Standardize elements of a C++ environment. 5. Consider proposed major changes: parameterized types and exceptions. 6. Ensure that the standard is suitable for the international community. 7. Ensure a very high level of compatibility with ANSI C. 8. Establish coordinating liaisons with X3J11 (ANSI C) and Numerical C Extensions Group. 9. Produce two deliverables: draft proposed standard and rationale. 10. Priorities: - clear & unambiguous - C++ reference manual - other base documents - consistency - user/implementer experience - portability, efficiency, expressiveness - ease of implementation (including translation to C) October 3, 1990 Standards Update X3J16: C++ - 3 - There was some confusion over the multiple base documents. Most members had seen the AT&TT C++ version 2.0 reference manual, but in preparation for standardization, the language and its reference manual had suffered a number of subsequent, small changes. AT&T made the 2.1 reference manual available to X3J16; it was essentially the text of the book The Annotated C++ Reference Manual by Margaret Ellis and Bjarne Stroustrup published by Addison-Wesley (minus the annotations). My naive suggestion to remove the ANSI C standard as a base document in favor of a single base provoked the most intense and emotional discussion of the week. At stake was compatibility between C++ and C. While most members of X3J16 feel that the existence of a separate committee implies the standardization of a new language, some former members of X3J11, which just finished the C standard, want to eliminate any and all incompatibilities with C. (There was even a threat to sabotage the C++ standard in balloting if they are not removed.) This issue is obviously important and has two sides. Make your preferences known to the committee. For detailed reference material, both ``C++: As Close as Possible to C -- But No Closer,'' (Bjarne Stroustrup and Andy Koenig, The C++ Report, 1(7), 1989) and Chapter 18 of The Annotated C++ Reference Manual document and explain differences and incompatibilities between the languages as they stand today. Focusing on a language without preprocessing directives continues the de-emphasis of the C preprocessor. This is particularly favored by C++ vendors looking into more powerful development environments. [Editor: Admittedly, improper preprocessor use can sink us in deep and dirty bath water, but let's make sure to save the baby. When writing portable C, I personally find #ifdefs extremely valuable; I suspect they will remain valuable in C++, and I would hate to see the working group neglect this valuable porting tool.] The libraries effort includes asking what to do about the ANSI-C library, and investigating what can be standardized in a more C++-like approach. The environment work addresses the linking and executing of C++ code with non-C++ code (i.e., linkage and program execution models), rather than development environment tools. There are thousands of suggested ``improvements'' proposed as extensions to C++, but there is consensus on two named in the goals document: parameterized types and exception handling. Their proposals are detailed, and both have been implemented (in some form) in a few C++ implementations. The emphasis on international concerns reflects the lessons learned from the difficulties of C standardization. X3J16 has some fences to October 3, 1990 Standards Update X3J16: C++ - 4 - mend, particularly in the international community. Rather than waiting until the last minute to spring a standard on the ISO, the C++ committee is involving itself with the international community right from the start. July meeting Microsoft hosted the second, Seattle meeting. Sub-groups focused on the key topics listed in the goals statement began work at the March meeting, and reported their progress in Seattle. International Concerns Steve Carter, of Bellcore, presented the major International Concerns (particularly character sets and formal specification) and asked the other groups to work on these issues. He also suggested various sites overseas where future X3J16 meetings could help cooperation with international standardization efforts. Editorial Jonathan Shopirio, of AT&T, presented the Editorial group's proposal for organizing and formatting the standard. Jon is also working on an abstract machine model, and a way to define the semantics in the standard precisely and consistently. Formal Syntax James Roskind, an independent consultant, presented the work of the Formal Syntax group. He has developed (and published on the net) a yacc-able grammar for C++, and is concerned about ambiguities in the the language. Most of the discussion was spent trying to discover whether C++ can (or should) be made LALR(1). Core Language Andy Koenig, of AT&T, presented the Core Language group's work. Initially, they identified and classified difficulties in the working document. Environment John Vasta, of HP, presented the work of the Environment group. A key issue addressed by this group is the interaction of C++ with other programming languages. Among the important topics are linkage of C++ and non-C++ translation units, especially the construction and destruction of static C++ objects. Libraries I presented the Library group's work. There were many suggestions, from both inside and outside of the committee. (Interested outside suggesters were James Coggins, Keith Gorlen, and Doug Lea, who have each developed large C++ libraries.) A few people noted similarity with topics covered by other standards October 3, 1990 Standards Update X3J16: C++ - 5 - (notably POSIX). Initially, the library group will focus on a few commonly-used components. Parameterized types and exception handling will significantly effect the way we design libraries in C++. Language Extensions Bjarne Stroustrup, of AT&T, presented the work of the Extensions group, which was by far the most active. The technical sessions presented experience with implementation and use of the template facility. The most active and emotional debate of the week was on exception handling, discussing the proposal outlined by Andy Koenig and Bjarne Stroustrup in their paper ``Exception Handling for C++'' presented at the Usenix C++ conference in April. Martin O'Riordan, of Microsoft, and Mike Miller, of Glockenspiel, presented arguments in favor of extending the current proposal (which defines termination semantics for exceptions) to include resumption semantics. Andy and Bjarne explained their reasons for not including resumption -- the most important was the complexity and cost of implementation. To their credit, the group worked hard to find a proposal that provided both kinds of exceptions with acceptably small time/space overhead. However, at the end of the week, Bjarne declared the debate deadlocked, and refused to impose his proposal while substantial disagreement remained. This is another topic where you should make your opinions heard. C Compatibility Mike Miller presented the work of the C Compatibility group. Tom Plum, of Plum-Hall, produced a list of every section of the C++ reference manual that was not C. Much of the group's near-term activity will be devoted to explaining the many items on the list. The Seattle meeting produced tangible progress on the language standard. X3J16 voted to accept the proposed document outline and format. They also agreed to incorporate the template proposal (the text from Chapter 14 of The Annotated Reference Manual, minus the annotations -- it was literally a scissors-and-tape job). We hope C++ vendors will regard templates as now officially in the language, and provide users an opportunity to work with this feature. Next events A few substantial issues lie ahead. The next meeting should see some resolution on the exception proposal. We should see some progress on the review of language ambiguities and inconsistencies, and have some idea of how difficult it will be to ANSIfy the document. We should also see some specific proposals on library contents. The most October 3, 1990 Standards Update X3J16: C++ - 6 - substantial will be a simplified version of iostreams by Jerry Schwarz (now at Stardent, formerly at AT&T). Our target date for delivering a draft standard is the end of 1992. X3J16 meets three times per year. The next three meetings (and their hosts) will be: + November 12-26, Cupertino CA (Hewlett Packard) + March 11-15, Nashua NH (Digital) + June 17-21, Lund Sweden (Lund Institute of Technology) Membership on an X3 committee is open to any individual or organization with expertise and material interest in the topic addressed by the committee. The cost for membership is $250. Contact the chair or vice chair for details. Chair: Dmitry Lenkov HP California Language Lab 19447 Pruneridge Avenue MS 47 LE Cupertino, CA 95014 (408)447-5279 FAX (408)447-4924 email dmitry%hpda@hplabs.hp.com Vice Chair: William M. Miller Glockenspiel, Ltd P.O. Box 366 Sudbury, MA 01776-0003 (508)443-5779 email wmmiller@cup.portal.com October 3, 1990 Standards Update X3J16: C++ Volume-Number: Volume 21, Number 174 shar.x3j16.23858 exit