Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!ucsd!sdd.hp.com!samsung!uunet!usenix!std-unix 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> Date: 5 Sep 90 19:07:46 GMT Sender: std-unix@usenix.ORG Reply-To: std-unix@uunet.uu.net Organization: USENIX Standards Watchdog Committee Lines: 162 Approved: jsq@usenix.org (Moderator, John Quarterman) X-Submissions: std-unix@uunet.uu.net From: Jeffrey S. Haemer An Update on UNIX*-Related Standards Activities September 4, 1990 USENIX Standards Watchdog Committee Jeffrey S. Haemer , 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