home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / v21 / 081 / text0000.txt < prev   
Encoding:
Internet Message Format  |  1990-12-05  |  7.1 KB
  1. From:  Jeffrey S. Haemer <jsh@usenix.org>
  2.  
  3.  
  4.            An Update on UNIX*-Related Standards Activities
  5.  
  6.                           September 4, 1990
  7.  
  8.                  USENIX Standards Watchdog Committee
  9.  
  10.           Jeffrey S. Haemer <jsh@usenix.org>, Report Editor
  11.  
  12. IEEE 1003.10 and 1003.15: Supercomputing and Batch
  13.  
  14. An anonymous correspondent reports on the July 16-20 meeting in
  15. Danvers, Massachusetts:
  16.  
  17. P1003.10 Supercomputing AEP
  18.  
  19. Scope synopsis: write an Application Environment Profile (AEP) for
  20. supercomputing, and work with other POSIX groups to define additional
  21. interfaces where required.
  22.  
  23. What an AEP is and what it must contain are still under development -
  24. - making it impossible to know when the work will go to ballot.
  25. POSIX.10 met two separate times in Danvers with POSIX.0 (which is
  26. writing a ``guide for profile writers'') and other profile groups.
  27.  
  28. While we all agree that a profile is a list of standards, other
  29. aspects are unclear.  For example, it was asserted previously that
  30. AEPs must be ISO Standardized Profiles (ISP), but it was suggested in
  31. July that there may be a POSIX Standardized Profile (PSP), or maybe a
  32. Preliminary PSP (PPSP).
  33.  
  34. POSIX.0 is also undecided about whether an AEP should contain
  35. conformance testing information, or what might comprise such
  36. information.  If extensive conformance testing is required for the
  37. 50-plus standards cited in the current POSIX.10 draft, the effort
  38. could take many years.
  39.  
  40. Whatever the decisions, the progress POSIX.0 and ISO make in defining
  41. an AEP is the upper bound on the progress any profile group can
  42. achieve.
  43.  
  44. In Danvers, POSIX.10 looked again at the numerical accuracy issues,
  45. including a proposal to ANSI X3T2 from DEC called a Language-
  46. Compatible Arithmetic Standard (LCAS), which may or may not be useful
  47. to supercomputing.  POSIX.10 will request formal liaison with X3T2 to
  48. ensure that we keep current with developments in this area.  The
  49. conflict between portability and performance improvements from
  50.  
  51. __________
  52.  
  53.   * UNIXTM is a Registered Trademark of UNIX System Laboratories in
  54.     the United States and other countries.
  55.  
  56. September 4, 1990 StIEEEr1003.10tand 1003.15: Supercomputing and Batch
  57.  
  58.  
  59.                 - 2 -
  60.  
  61. proprietary formats is not easy to resolve, but is of paramount
  62. interest to numerical, supercomputing applications.  This issue will
  63. not go away, though it may be impossible for the first release of this
  64. profile to make any meaningful statements about it.
  65.  
  66. This working group also discussed Jim Isaak's article, ``Application
  67. Environment Profiles: a Significant Tool for Simplification and
  68. Coordination of the Standards Efforts'' (IEEE Computer, February
  69. 1990).  Not only must profiles be complete, says Jim, they must be
  70. coherent.  A profile may need to act like a glue, specifying not just
  71. lists of standards, but interactions of different standards on a
  72. single system.
  73.  
  74. The working group will put all the standards it cites into a
  75. triangular matrix to identify potential interactions.  As each
  76. interaction is identified, the group will examine the effects on
  77. coherence by looking more closely at parameters, options, and
  78. behaviors, to determine if additional interface standards are
  79. required.
  80.  
  81. POSIX.10 must also pass proposals for standards extensions on to other
  82. working groups.  A proposal for an Application Program Interface (API)
  83. for checkpoint and restart has been submitted to POSIX.1; they
  84. returned it with a request for substantial modification, but this
  85. writer understood them to agree that they will polish and ballot the
  86. interface.  A proposal for a resource-limits API is also in
  87. preparation, and will be discussed further at the next meeting.
  88. Proposals for a resource reservation system, a removable/non-sharable
  89. media system (nine-track tape, cartridge tape, CD-ROM, etc.), and
  90. resource accounting also need to be done.
  91.  
  92. These interfaces need to be done soon, because the batch group
  93. (POSIX.15) needs the underlying functionality to support batch
  94. processing.
  95.  
  96. P1003.15 Supercomputing Batch Extensions
  97.  
  98. Scope synopsis: define API, user commands and system administration
  99. commands for a networked batch queueing system; current draft is based
  100. on NQS sold by COSMIC at Univ. of Ga.
  101.  
  102. POSIX.15 has the same chair as POSIX.10 (Karen Sheaffer from Sandia
  103. Livermore), but now has a separate vice chair and secretary.  The
  104. group has grown to 15-20 regular participants in the batch
  105. discussions, and now includes active participation by more vendors.
  106.  
  107. Their latest draft is very close to the page layout of the other POSIX
  108. documents, which is important for acceptance by the other groups.  Jim
  109. Isaak spoke to the group in Danvers, and helped them to understand the
  110. balloting process and the relation of their Program Authorization
  111. Request (PAR) both to their own efforts and to the efforts of other
  112.  
  113. September 4, 1990 StIEEEr1003.10tand 1003.15: Supercomputing and Batch
  114.  
  115.  
  116.                 - 3 -
  117.  
  118. groups.
  119.  
  120. A very important -- but very thorny -- issue for this group is the
  121. definition of a host-to-host request/reply protocol.  In the first
  122. place, there are no other POSIX host-to-host protocols that this group
  123. can use as a model for how to write its spec.  In the second place,
  124. numerous participants are dissatisfied with the NQS protocol: it
  125. simply doesn't carry enough information.  HP, in particular, is
  126. working very hard to ensure that the load balancing aspects of their
  127. Task Broker system are not excluded by anything in the batch standard,
  128. and for that they need more information to be exchanged between hosts.
  129.  
  130. Another problem facing this group is the lack of an API for resource
  131. limits, resource reservation, and resource accounting beyond basic
  132. UNIX accounting.  Based on the balloting in POSIX.2, they can expect
  133. balloting objections against statements in their document which refer
  134. to these features until the interfaces are in place.
  135.  
  136. Just before the close of the meeting, a representative of POSIX.7
  137. presented some questions about the current direction of the batch
  138. effort and its relation to the Palladium print system (the Athena
  139. print system used at MIT).  Many current NQS sites queue print
  140. requests with NQS, and there has been some interest in defining
  141. printing features.  That function, however, is clearly within
  142. POSIX.7's scope.  It is reasonable for POSIX.7 to question if and how
  143. Palladium and NQS are compatible.
  144.  
  145. POSIX.15 meets eight times a year, with interim meetings about midway
  146. between the quarterly POSIX meetings.  It would be in their interest
  147. to publicize these meetings, and to arrange them through the IEEE.
  148. (Following the October POSIX meeting, there will be one December 4-6
  149. in Huntsville, AL hosted by Intergraph.)
  150.  
  151. There is reason to be optimistic about the progress of this group.
  152. Although they've only been an official POSIX group for one meeting,
  153. they are showing an increased sensitivity to the political issues
  154. involved in getting their document through balloting.  I think their
  155. biggest liability right now is their determination to go to ballot in
  156. January 1991.  The date seems premature by a year or more; they need
  157. more meetings before balloting so more people can read and comment on
  158. their draft.
  159.  
  160. September 4, 1990 StIEEEr1003.10tand 1003.15: Supercomputing and Batch
  161.  
  162. Volume-Number: Volume 21, Number 81
  163.  
  164.