Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/v21/081

Internet Message Format | 1990-12-05 | 8KB

From [e-mail]  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: [e-mail] (Jeffrey S. Haemer)
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.10 and 1003.15: Supercomputing and Batch
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
X-Submissions: [e-mail]
Date: 5 Sep 90 19:07:46 GMT
To: [e-mail]

From:  Jeffrey S. Haemer <[e-mail]>


           An Update on UNIX*-Related Standards Activities

                          September 4, 1990

                 USENIX Standards Watchdog Committee

          Jeffrey S. Haemer <[e-mail]>, 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