jsh@usenix.org (Jeffrey S. Haemer) (09/06/90)
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
emv@math.lsa.umich.edu (Edward Vielmetti) (09/07/90)
From: emv@math.lsa.umich.edu (Edward Vielmetti)
In article <485@usenix.ORG> jsh@usenix.org (Jeffrey S. Haemer) writes:
[ Well, actually, an anonymous person wrote it; Jeff edited it. -jsq ]
IEEE 1003.10 and 1003.15: Supercomputing and Batch
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.
For the record, there's an Internet Engineering Task Force group doing
work on defining a Network Printing Protocol. I enclose the charter
of the group as I find it on nnsc.nsf.net:/ietf/npp-charter.txt.
--Ed
Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu>
Network Printing Protocol (npp)
Charter_
Chairperson:
Leo McLaughlin, ljm@twg.com
Mailing Lists:
General Discussion: print-wg@pluto.dss.com
To Subscribe: print-wg-request@pluto.dss.com
Description of Working Group:
The Network Printing Working Group has the goal of pursuing
those issues which will facilitate the use of printers in an
internetworking environment. In pursuit of this goal it is
expected that we will present one or more printing protocols to
be considered as standards in the Internet community.
This working group has a number of specific objectives. To
provide a draft RFC which will describe the LPR protocol. To
describe printing specific issues on topics currently under
discussion within other working groups (e.g., security and
dynamic host configuration), to present our concerns to those
working groups, and to examine printing protocols which exist
or are currently under development and assess their
applicability to Internet-wide use, suggesting changes if
necessary.
Goals and Milestones:
Done Review and approve the charter, making any changes deemed
necessary. Review the problems of printing in the
Internet.
Apr 1990 Write draft LPR specification.
May 1990 Discuss and review the draft LPR specification. Discuss
long-range printing issues in the Internet. Review
status of Palladium print system at Project Athena.
May 1990 Submit final LPR specification including changes
suggested at the May IETF. Discuss document on mailing
list.
Jun 1990 Submit LPR specification as an RFC and standard.
Jul 1990 Write description of the Palladium printing protocol
(2.0) in RFC format.
Aug 1990 Discuss and review the draft Palladium RFC.
Volume-Number: Volume 21, Number 86