🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

4 total messages Started by Stephen R. Walli Tue, 29 Dec 1992 22:26
Standards Update, POSIX.7b: Software Administration
#885
Author: Stephen R. Walli
Date: Tue, 29 Dec 1992 22:26
79 lines
4645 bytes
Submitted-by: stephe@usenix.org (Stephen R. Walli)

Esti Koen <emk@cray.com> reports on the October 19-23, 1992 meeting in
Utrecht, NL:

I attended the POSIX.7b meeting in Utrecht, never having been
previously exposed to POSIX.  Lacking the historical perspective, it
was difficult for me to identify when the discussion was a
clarification of an already agreed upon point verses a major shift in
emphasis or direction.  If this report seems somewhat lacking in
detail or introductory, it reflects my own level of involvement to
date.

For the purpose of this report, I assume readers are mainly interested
in broad decisions concerning the content of the standard or a shift
in direction and expected balloting dates.

Early attempts to standardize the nonexistant ``common practice'' of
software administration seemed doomed to failure. (I don't envy those
early pioneers.) POSIX.7 finally adopted the network view of a managed
system.  Forging ahead in areas where they feel they can make
consensus based progress, POSIX.7 is now split into two documents
called POSIX.7a (print queue administration) and POSIX.7b (software
administration).

Recognizing the need for information describing existing practice in
the area of network wide system management, the Open Software
Foundation (OSF) solicited technologies from industry that could be
integrated to simplify system management in heterogeneous computing
environments.  In October, 1991, OSF announced that they had chosen
Hewlett Packard's Software Distribution Utilities to provide the basis
for the OSF Distributed Management Environment (DME).  The current
draft of POSIX.7b is a roughly one year old descendant of the External
Specification that describes the HP Software Distribution Utilities.

The original HP implementation suggested an object orientation but it
was not developed using a rigorous object oriented specification
language.  In one year of POSIX meetings the group has made
significant progress in further defining the attributes of the managed
objects, but the specification is still incomplete and at times
ambiguous.  There is much discussion concerning object behavior.

Open issues include the question of allowing multiple Management
Information Bases (MIB), and which attributes of a software object can
be used, and how they are used as a selection mechanism.

Although invention by a standards committee is not advisable, it seems
unavoidable when the base design is incomplete for the purposes of the
standard.

Several decisions regarding general content were finalized.  There
will be no API included in the standard.  An informative annex which
provides information on how one implementation communicates between
the manager, source and target roles will be included.  A rationale
section which informs the reader as to the intent and history of the
standard will also be included.

The serial media format was previously specified as tar, but will now
be specified as being readable and writable by pax (POSIX.2-1992).
Locking mechanisms are considered to be an implementation detail and
outside the scope of the standard.  A command line option will be
provided to permit interaction sufficient to handle multi-volume media.

The group discussed rewriting part of the document using the ISO
Guidelines for the Definition of Managed Objects (GDMO).  The process
of rewriting using GDMO would have the beneficial side effect of
highlighting inconsistencies, omissions, and redundancies.  In fact,
it was advised that the draft would not be adopted by ISO unless GDMO
was used.

The active participants did not embrace the idea whole heartedly
because a drastic structure change could further delay the balloting
schedule.  Mock ballot is planned to occur after the January meeting.
Budget constraints may impose a time limit on the standards activity,
and active participants fear having the POSIX.7b standards activity
permanently interrupted before going to ballot.  Refinement of the
existing object definitions and behaviors continues at a fast pace.

Volume-Number: Volume 30, Number 12
Re: Standards Update, POSIX.7b: Software Administration
#970
Author: peter da silva
Date: Tue, 05 Jan 1993 00:27
26 lines
1628 bytes
Submitted-by: peter@ferranti.com (peter da silva)

In article <1hqj9sINN9mu@ftp.UU.NET> std-unix@uunet.uu.net writes:
> Forging ahead in areas where they feel they can make
> consensus based progress, POSIX.7 is now split into two documents
> called POSIX.7a (print queue administration) and POSIX.7b (software
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^
> administration).

Isn't this a rather narrow subject for a POSIX standard... not to mention
being pretty much covered by two completely irreconcilable models (BSD
and System V).

You're going to have to dump BSD spooling, dump System V spooling, or
dump both and create something out of whole cloth. If it's the latter,
why not create a generalised batch queueing and scheduling system that
just happens to include printing?

I assume 7b is where all the interesting stuff is going to be.
-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
Sugar Land, TX  77487-5012 USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"

Volume-Number: Volume 30, Number 16
Re: Standards Update, POSIX.7b: Software Administration
#973
Author: Duke Robillard
Date: Sun, 10 Jan 1993 11:46
37 lines
2070 bytes
Submitted-by: duke@portal.paperboy.osf.org (Duke Robillard)

In article <1iakluINNblv@ftp.UU.NET> peter@ferranti.com (peter da silva) writes:

>>consensus based progress, POSIX.7 is now split into two documents
>>called POSIX.7a (print queue administration) and POSIX.7b (software
>                  ^^^^^^^^^^^^^^^^^^^^^^^^^^
>administration).
>Isn't this a rather narrow subject for a POSIX standard... 
>I assume 7b is where all the interesting stuff is going to be.

Actually, POSIX.7 is being split into n documents, one for each area
of system administration.  1003.7.1 (what Esti called .7a) is about
print systems, 1003.7.2 (formally known as .7b) is about software
package installation, 1003.7.3 will be about user management, etc.

>You're going to have to dump BSD spooling, dump System V spooling, or
>dump both and create something out of whole cloth. 

Well, some people claim we've done the later, although that a little 
extreme.  We've adopted Palladium, the print system developed at MIT's 
Project Athena.  It's an implementation of the ISO Print Standard.

>If it's the latter, why not create a generalised batch queueing and 
>scheduling system that just happens to include printing?

We thought about that, but couldn't find any software like that to base
the standard on.

--
  Bob Robillard    Technical Editor, 1003.7.1   duke@osf.org 

Duke Robillard, DoD #0130, duke@osf.org
angst.motorcycles: "We may be doomed, but at least the adrenaline
keeps us awake"

Volume-Number: Volume 30, Number 19
Re: Standards Update, POSIX.7b: Software Administration
#977
Author: Ran Atkinson
Date: Sun, 10 Jan 1993 12:32
20 lines
1378 bytes
Submitted-by: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson)

  Doug Gwyn <gwyn@smoke.brl.mil> has been using such generalised batch
software on UNIX systems.  I think his stuff might even be freely
distributable.

  I find it absolutely fascinating that you continue to claim that MIT
developed Palladium and yet the vast majority of MIT won't have
anything to do with it -- including large portions of Project Athena.
(We sent someone from NRL up to MIT to survey the Palladium situation :-)

  To me that is a clear sign that there are problems with Palladium.
Also, existing practice at one site out of hundreds of thousands is
not anything resembling generalised existing practice (which both BSD
and System V do strongly resemble).

Ran
atkinson@itd.nrl.navy.mil

Volume-Number: Volume 30, Number 23
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads