>I'd like to remind the readers of this group and teh distinguished authors
>of the CRB that 1003.4B is an an extension to a real-time standard (please
>read the scope statement of 1003.4) and its purpose *is* to provide
>real-time functionality. Unlike the endless debate about 1003.4a
>(pthreads), I don't think there is any question here.
The entire real-time standard is folded into the .1 standard.
The whole thing together is a single standard, with a lot of options.
As far as I can tell, some of the things like spawn() being put in .4a
should really be in base .1, and are placed here only because this is a
quicker method to get into .1. Some of these these are going to be quoted
in non-realtime systems -- contracts will read: I need .1, with the
spawn option, and the contiguous file option... And who knows what the
FIPS will mandate next time around?
So, anything that goes in under the realtime banner, had better be
full and complete in the full, generic operating system sense.
I, by the way, had 6 objections on spawn, mainly because I believe spawn
has nothing to do with realtime, and I have several clients right now
for non-realtime purposes that want to implement it. They want to do
it for simple performance reasons. I want to make darn sure that it
actually accomplishes its goals (50% of forks in the shell).
Right now it doesn't. I can say that, as perhaps the only one to date
who has actually converted a shell over to try to use spawn...
Again, nothing to do with realtime.
Alex White.
Volume-Number: Volume 33, Number 28
From std-unix-request@uunet.UU.NET Tue Dec 7 00:46:41 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA27735; Tue, 7 Dec 93 00:46:41 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA19579; Tue, 7 Dec 93 00:46:39 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA15932; Mon, 6 Dec 93 21:46:38 PST
Xref: majipoor.cygnus.com comp.std.unix:191
From: mib@geech.gnu.ai.mit.edu (Michael I Bushnell)
Newsgroups: comp.std.unix
Subject: Interpretation of O_ACCMODE
Organization: FOO
Sender: sef@uunet.uu.net
Message-Id: <2e1556INNr17@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 6 Dec 1993 21:43:02 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: mib@geech.gnu.ai.mit.edu (Michael I Bushnell)
In our system we have three bits for access modes:
#define O_READ 0x0001
#define O_WRITE 0x0002
#define O_EXEC 0x0004
#define O_RDONLY O_READ
#define O_WRONLY O_WRITE
#define O_RDWR (O_RDONLY | O_WRONLY)
We have a call `fexecve' (and associated stuff) which permits one to
execute a file which has been opened with O_EXEC set.
Should O_ACCMODE be defined as (O_RDWR) or as (O_READ|O_WRITE|O_EXEC)?
The purist claim is clearly that it should be the latter.
But the practical claim is for the former, on the grounds that any
real uses of O_ACCMODE will be like the following:
switch (mode & O_ACCMODE)
{
case O_RDONLY:
...
case O_WRONLY:
...
case O_RDWR:
...
}
So, which is it? The actual standard doesn't really deal with it at
all. Has anybody ever actually used O_ACCMODE?
--
+1 617 623 3248 (H) | The soul of Jonathan was bound to the soul of David,
+1 617 253 8568 (W) -+- and Jonathan loved him as his own soul.
1105 Broadway | Then Jonathan made a covenant with David
Somerville, MA 02144 | because he loved him as his own soul.
Volume-Number: Volume 33, Number 29
From std-unix-request@uunet.UU.NET Mon Dec 13 02:32:23 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA00798; Mon, 13 Dec 93 02:32:23 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA23598; Mon, 13 Dec 93 02:32:21 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA20551; Sun, 12 Dec 93 23:32:20 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id XAA05295 for std-unix-archive@uunet.uu.net; Sun, 12 Dec 1993 23:32:13 -0800
Xref: majipoor.cygnus.com comp.std.unix:193
From: mfeustel@ccd.harris.com (McFuzz)
Newsgroups: comp.std.unix
Subject: Re: Not true! This is .1
Organization: Harris Controls Division
Sender: sef@uunet.uu.net
Message-Id: <2eh3q4INNpri@rodan.UU.NET>
References: <2dvurlINN4nb@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 12 Dec 1993 22:58:12 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: mfeustel@ccd.harris.com (McFuzz)
Alex White (alex@mks.com) wrote:
>The entire real-time standard is folded into the .1 standard.
>The whole thing together is a single standard, with a lot of options.
@@->> A point of clarification - all of the dots (.) working
groups are intended to be incorporated into the base standard.
The POSIX standard is really not .1 but 1003 appended with the
year of the update. For example the 1003-1990 standard will be
replaced with the 1003-1993 which will include all the realtime
options included in P1003.4d14...which will be submitted to ISO
for inclusion in the international std. 9945..
mcfuzz
Volume-Number: Volume 33, Number 31
From std-unix-request@uunet.UU.NET Mon Dec 13 02:32:20 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA00791; Mon, 13 Dec 93 02:32:20 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA23584; Mon, 13 Dec 93 02:32:18 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA20545; Sun, 12 Dec 93 23:32:16 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id XAA05283 for std-unix-archive@uunet.uu.net; Sun, 12 Dec 1993 23:32:10 -0800
Xref: majipoor.cygnus.com comp.std.unix:192
From: fred@mindcraft.com (Fred Zlotnick)
Newsgroups: comp.std.unix
Subject: Re: Interpretation of O_ACCMODE
Organization: Kithrup Enterprises, Ltd.
Sender: sef@uunet.uu.net
Message-Id: <2eh3npINNpph@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 12 Dec 1993 22:56:57 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: fred@mindcraft.com (Fred Zlotnick)
Michael Bushnell writes:
>We have a call `fexecve' (and associated stuff) which permits one to
>execute a file which has been opened with O_EXEC set.
>
>Should O_ACCMODE be defined as (O_RDWR) or as (O_READ|O_WRITE|O_EXEC)?
>
>The purist claim is clearly that it should be the latter.
The purists are incorrect. See below.
>So, which is it? The actual standard doesn't really deal with it at
>all. Has anybody ever actually used O_ACCMODE?
Yes. The reason O_ACCMODE exists is that historically, O_RDONLY is not
a bit mask; it's 0. (That was a mistake, IMHO.) This means that if you
want to determine whether a particular file descriptor is open for
reading, for example, the following intuitively obvious code WILL NOT
work:
if ( fcntl(fd, F_GETFL) & O_RDONLY )
... /* Condition is always zero */
So instead, you write something like the switch statement above, or:
From std-unix-request@uunet.UU.NET Mon Dec 13 02:32:27 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA00811; Mon, 13 Dec 93 02:32:27 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AB23609; Mon, 13 Dec 93 02:32:24 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA20557; Sun, 12 Dec 93 23:32:23 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id XAA05307 for std-unix-archive@uunet.uu.net; Sun, 12 Dec 1993 23:32:16 -0800
RS/Magazine mentioned something called Spec 1170, "a UNIX specification
announced by 75 vendors .. that specifies 1,170 application programming
interfaces. It sounded like X/Open will/does own this spec.
What exactly is this and how does it relate to POSIX, COSE?
Where can one obtain this Spec? I would really like to see a TOC to see
what is included.
Is this only a draft proposal today? If so, what is the time frame for
it to become a standard?
--
Steve Zanoni
GE Medical Systems
stevez@med.ge.com
Volume-Number: Volume 33, Number 32
From std-unix-request@uunet.UU.NET Mon Dec 13 02:32:28 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA00816; Mon, 13 Dec 93 02:32:28 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA23619; Mon, 13 Dec 93 02:32:26 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA20563; Sun, 12 Dec 93 23:32:25 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id XAA05319 for std-unix-archive@uunet.uu.net; Sun, 12 Dec 1993 23:32:18 -0800
Xref: majipoor.cygnus.com comp.std.unix:195
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: Not true! This is .1
Organization: U.S. Army Ballistic Research Lab, APG MD.
In article <2dvurlINN4nb@rodan.UU.NET> alex@mks.com (Alex White) writes:
>As far as I can tell, some of the things like spawn() being put in .4a
>should really be in base .1, and are placed here only because this is a
>quicker method to get into .1.
IEEE working group P1003 considered spawn(), but decided that it did
*not* belong in the POSIX.1 standard. (Ditto for vfork().)
Volume-Number: Volume 33, Number 33
From std-unix-request@uunet.UU.NET Mon Dec 13 14:24:40 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA04438; Mon, 13 Dec 93 14:24:40 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA21156; Mon, 13 Dec 93 14:24:38 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA10336; Mon, 13 Dec 93 11:24:36 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id LAA19481 for std-unix-archive@uunet.uu.net; Mon, 13 Dec 1993 11:24:29 -0800
Xref: majipoor.cygnus.com comp.std.unix:196
From: hlj@posix.COM (Hal Jespersen)
Newsgroups: comp.std.unix
Subject: Re: Not true! This is .1
Organization: POSIX Software Group, Redwood City, CA
Sender: sef@uunet.uu.net
Message-Id: <2eif7pINN3o6@rodan.UU.NET>
References: <2eh3q4INNpri@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 13 Dec 1993 11:19:21 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: hlj@posix.COM (Hal Jespersen)
mfeustel@ccd.harris.com (McFuzz) writes:
>@@->> A point of clarification - all of the dots (.) working
>groups are intended to be incorporated into the base standard.
A point of reclarification: Many of the API-related working groups
are building amendments to 1003.1-199x (aka ISO/IEC 9945-1: 199x).
The ".1" is not being dropped because there are still other dot
groups with their own identities. 1003.2 (9945-2) and related
amendments, 1003.5 (Ada binding), 1003.9 (FORTRAN-77), and various
profile standards in the 1003 group are all examples.
Hal
Volume-Number: Volume 33, Number 34
From std-unix-request@uunet.UU.NET Mon Dec 13 19:23:32 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA10462; Mon, 13 Dec 93 19:23:32 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA12731; Mon, 13 Dec 93 19:23:30 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA24640; Mon, 13 Dec 93 16:23:28 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id QAA27242 for std-unix-archive@uunet.uu.net; Mon, 13 Dec 1993 16:23:20 -0800
Xref: majipoor.cygnus.com comp.std.unix:197
From: rgallen@muug.mb.ca (Rennie Allen)
Newsgroups: comp.std.unix
Subject: Re: Spec 1170: What is this???
Organization: Manitoba Unix User Group, Winnipeg, Manitoba, Canada
Sender: sef@uunet.uu.net
Message-Id: <2ej0nqINN9vf@rodan.UU.NET>
References: <2eh3s2INNpt6@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 13 Dec 1993 16:18:02 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: rgallen@muug.mb.ca (Rennie Allen)
In <2eh3s2INNpt6@rodan.UU.NET> stevez@outboard.med.ge.com (Steve Zanoni 5-4325) writes:
>What exactly is [1170] and how does it relate to POSIX, COSE?
Next year, any vendor who markets an OS which complies with spec 1170 will be
allowed to call their OS Unix. X/Open will own the spec (and the Unix trade
mark), and "give" the Unix trademark to spec 1170 compliant vendors...
gallen@muug.mb.ca
(204) 339-8005
Fax: (204) 488-5943
Volume-Number: Volume 33, Number 35
From std-unix-request@uunet.UU.NET Tue Dec 14 20:42:03 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA24788; Tue, 14 Dec 93 20:42:03 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA13416; Tue, 14 Dec 93 20:41:53 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA15507; Tue, 14 Dec 93 17:41:50 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id RAA27093 for std-unix-archive@uunet.uu.net; Tue, 14 Dec 1993 17:41:40 -0800
Submitted-by: preece@urbana.mcd.mot.com (Scott E. Preece)
In article <2ej0nqINN9vf@rodan.UU.NET> rgallen@muug.mb.ca (Rennie Allen) writes:
>Next year, any vendor who markets an OS which complies with spec 1170 will be
>allowed to call their OS Unix. X/Open will own the spec (and the Unix trade
>mark), and "give" the Unix trademark to spec 1170 compliant vendors...
Just to clarify the answer to the explicit question -- spec 1170 is a
product of the COSE effort, written by a COSE working group and endorsed
by a large number of UNIX vendors. It includes the XPG4 interfaces plus
some additional interfaces from SVID3, the OSF AES, the BSD
distribution, and (I believe) some non-base X/Open specs. The goal was
to include all the interfaces commonly used by ISV applications, and the
research included having some ISVs run surveying tools over their
applications to determine what interfaces they use.
--
scott preece
motorola/mcg urbana design center 1101 e. university, urbana, il 61801
phone: 217-384-8589 fax: 217-384-8550
internet mail: preece@urbana.mcd.mot.com
Volume-Number: Volume 33, Number 36
From std-unix-request@uunet.UU.NET Tue Dec 14 20:42:05 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA24796; Tue, 14 Dec 93 20:42:05 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA13453; Tue, 14 Dec 93 20:41:59 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA15515; Tue, 14 Dec 93 17:41:52 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id RAA27105 for std-unix-archive@uunet.uu.net; Tue, 14 Dec 1993 17:41:43 -0800
>Next year, any vendor who markets an OS which complies with spec 1170 will be
>allowed to call their OS Unix. X/Open will own the spec (and the Unix trade
>mark), and "give" the Unix trademark to spec 1170 compliant vendors...
Well, "spec 1170" is the COSE API document, which is a blending/superset
of XPG4 and SVID3 with things like sockets and curses added. the 1170 is
for the 1170-odd interfaces and headers listed in it.
Rennie's reply is correct excepting for the timetable, which is still
fluid.
--
Mark S. Brown IBM Austin, TX| Call for the police.
mbrown@austin.ibm.com RS/6000| Call for an ambulance.
VNET: MBROWN@AUSVM6 512-838-3926| Call for a pizza.
MS 9582 11400 Burnet Rd. 78758| See who shows up, and in what order.
Volume-Number: Volume 33, Number 37
From std-unix-request@uunet.UU.NET Thu Dec 16 22:46:59 1993
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA19465; Thu, 16 Dec 93 22:46:59 -0500
Received: from cygnus.com by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA21966; Thu, 16 Dec 93 22:46:58 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA27567; Thu, 16 Dec 93 19:46:56 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id TAA03673 for std-unix-archive@uunet.uu.net; Thu, 16 Dec 1993 19:46:55 -0800
Xref: majipoor.cygnus.com comp.std.unix:200
From: cameron@cse.unsw.edu.au (Cameron Simpson)
Newsgroups: comp.std.unix
Subject: Re: Spec 1170: What is this???
Organization: CS&E Computing Facility, Uni Of NSW, Oz
>Next year, any vendor who markets an OS which complies with spec 1170 will be
>allowed to call their OS Unix. X/Open will own the spec (and the Unix trade
>mark), and "give" the Unix trademark to spec 1170 compliant vendors...
So, how synonymous is 1170 with what defining _XOPEN_SOURCE is supposed to do?
And is 1170 online anywhere?
--
Cameron Simpson, who's intuiting what XOPEN is from the Sun
include headers...
cameron@cse.unsw.edu.au, DoD#743
Volume-Number: Volume 33, Number 38
From std-unix-request@uunet.UU.NET Thu Dec 16 22:47:08 1993
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA19496; Thu, 16 Dec 93 22:47:08 -0500
Received: from cygnus.com by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA22034; Thu, 16 Dec 93 22:47:03 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA27579; Thu, 16 Dec 93 19:47:01 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id TAA03685 for std-unix-archive@uunet.uu.net; Thu, 16 Dec 1993 19:47:00 -0800
Xref: majipoor.cygnus.com comp.std.unix:201
From: nick@usenix.org (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.7: System Administration
Organization: USENIX Standards Report Editor
Sender: sef@uunet.uu.net
Message-Id: <2er9urINNimh@rodan.UU.NET>
Reply-To: std-unix@uunet.uu.net
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 16 Dec 1993 19:44:27 -0800
To: std-unix@uunet.UU.NET
Submitted-by: nick@usenix.org (Nicholas M. Stoughton)
USENIX Standards Report Editor
Nicholas M. Stoughton <nick@usenix.org>, Report Editor
POSIX.7: System Administration
Matt Wicks <wicks@fnal.gov> and Keith Duval
<duval.vnet.ibm.com> report on the October 18-22, 1993
meeting in Bethesda, MD.:
Introduction
POSIX.7 is divided into three separate groups, each
producing their own standard:
- POSIX.7.1 - Printing Administration
- POSIX.7.2 - Software Installation and Management
- POSIX.7.3 - User and Group Administration
Print Administration
Of all the work of POSIX.7, the work of the printing group
is most advanced, with the initial formal ballot conducted
in June-July, 1993. The print standard is based on MIT's
Palladium, which is a distributed print management system
and also the base technology for OSF's offering in the Print
Management arena.
The working group explicitly decided to reject using lpr or
lp as the basis of the standard believing that neither
really addressed all of the issues of a distributed printing
system.
The ballot was generally positive, so there seems to be some
willingness within the standards community to approve System
Administration based standards. It remains to be seen if
both vendors and users are ready and willing to migrate to a
totally new printing system.
Commencing the week of October 18th, the POSIX.7.1 Printing
standards group met in Bethesda. A great deal of progress
was made toward producing a final document which satisfies
the overwhelming majority of interested parties, and while
resolving the objections and comments is a daunting task,
the committee was formed, and objectives and means for
achievement of the goals at hand were delineated.
Moreover, there were a number of excellent suggestions from
the balloters which will improve the overall standard and
implementations derived from same. Further, it was readily
- 2 -
recognized by all who participated in the arduous task of
interpretation and response to the objections and comments
in Bethesda, and by all who are credible in the field, that
this represents a significant enhancement of the art with
respect to distributed systems technology. Finally, it was
generally agreed that `times have changed' and, if we allow
ourselves the intellectual stimulation, change is good for
us. In the print technology area, it was increasingly
obvious during the week that the `old' is just a bit too old
to be relevant any longer, other than as grist for whimsey
and fond recollection of much simpler systems challenges and
times.
Software Installation and Management
The Software Management standard is based on Hewlett
Packard's software installation package, with some
contributions from the SVr4 software installation package.
(The HP system is also the base technology for the software
management portion of OSF's Distributed Management
Environment.)
There are two primary goals of the standard. One goal is to
provide a standardized command line interface for all of the
typical software management tasks. These include commands to
install and remove software, configure software, list and
verify software. This goal allows administrator portability
since the software management process will work the same on
different machine types.
The second goal is to define a standard software package
layout. This goal allows media portability. Software
packaged in the standard layout would be able to be managed
by any POSIX conformant implementation.
For a good explanation of additional details of the
standard, I recommend obtaining a copy of the proceedings of
the most recent USENIX LISA conference. Barrie Archer
provided a very good paper that not only explains the
standard, but also some of the reasons why certain decisions
were made.
I have been involved in the Software Group since its
formation over 2 years ago. This meeting has a significantly
different flavor as the group is nearing completion of its
initial work, planning to go to ballot after the April, 1994
meeting. Although there were several heated discussions on
several technical issues over the course of the week, in
general the work was focussed on "fine tuning" the document.
- 3 -
The next two meetings will be dedicated almost exclusively
to editorial issues and attempting to resolve any
discrepancies between different sections in the document.
User and Group Administration
A separate snitch report is being written by a member of
this working group. However, I did want to use this
opportunity to encourage other people to get involved.
The User and Group Administration work is in its early
stages and is being done primarily by two individuals (a
third person joined them this week) both of whom are vendor
representatives. Here is an opportunity to get involved and
make a difference in the standards arena. Otherwise, you
will have to accept what is produced by a very small group
of people.
Participation in POSIX does take time, but it is well worth
it. Send me mail if you would like more information on how
to get involved.
Volume-Number: Volume 33, Number 39
From std-unix-request@uunet.UU.NET Thu Dec 16 22:47:12 1993
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA19510; Thu, 16 Dec 93 22:47:12 -0500
Received: from cygnus.com by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA22122; Thu, 16 Dec 93 22:47:10 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA27591; Thu, 16 Dec 93 19:47:08 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id TAA03709 for std-unix-archive@uunet.uu.net; Thu, 16 Dec 1993 19:47:07 -0800
Xref: majipoor.cygnus.com comp.std.unix:203
From: nick@usenix.org (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, Fault Management Study Group
Organization: USENIX Standards Report Editor
Sender: sef@uunet.uu.net
Message-Id: <2era0kINNir3@rodan.UU.NET>
Reply-To: std-unix@uunet.uu.net
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 16 Dec 1993 19:45:24 -0800
To: std-unix@uunet.UU.NET
Submitted-by: nick@usenix.org (Nicholas M. Stoughton)
USENIX Standards Report Editor
Nicholas M. Stoughton <nick@usenix.org>, Report Editor
Fault Management Study Group
Stephen Hinde <S.Hinde@frec.bull.fr> reports on the October
18-22, 1993 meeting in Bethesda, MD.:
Do you know the difference between Fault Tolerance, High
Availability, a fault, a failure and an error? If so you
could consider joining the ``Fault Management Study Group''
at the next POSIX meeting at Irvine.
October was the first meeting of this group, following BOF
sessions at the two previous POSIX meetings. The status of
the group is a ``Study Group'' preparing a Project
Authorization Request (PAR). The healthy participation
would indicate that Fault Management is something
organizations are interested in sending people to work on.
Which is one of the basic criteria for success in these hard
times.
A number of existing documents are being studied as base
documents, including the ``UNIX International High
Availability Working Group report'', which was contributed
by UI at the previous BOF, and a draft of the ``ANSI X3.T8-
1993 Fault Isolation Information Characterization for
Information Technology''.
The group found itself with an awesome ``laundry list'' from
the submitted requirements. The requirements ranged from a
framework to improve application availability to a framework
to improve platform availability. The required system scope
is not limited including single CPU systems, to Symmetric
Multiprocessor systems and clustered systems.
The group debated whether it was to be a new PAR, or a sub-
PAR of an existing group. The word ``Management'' had led
some to ask whether the group would end up as a sub-PAR of
POSIX.7, the System Management group. However some of the
objectives of the group were clearly outside the area of
System Management, and a number of alternative titles for
the group were being considered, for which the current
favorite was ``Services for Dependable Systems''. The PAR
sub-PAR debate will be easily settled when the PAR
submission and scope documents are complete.
The work of fleshing out a Fault Management Process Model
largely dominated the meeting, this is a model that would
allow the decomposition of the error detection and error
treatment steps, and allow the identification of the APIs
- 2 -
involved. The model was mapped against several
implementations as a sanity check. The behavior and
definition of the building blocks of the process were
examined including Error Detection, Sympton Encoding, Error
Logging, Diagnosis, Notification, Reconfiguration and
Recovery. Possible areas for standardization could include
APIs for Error Logging, Error Reporting, APIs for recovery
modules and a "finger printing" technique for uniquely
identifying faults.
Bradford Glad of ISIS gave a presentation of HORUS a
Distributed Toolkit layer designed to build distributed
fault tolerant systems. The key ideas include virtual
synchrony, a fault tolerant membership service, process
groups and a reliable broadcast protocol. New work includes
a high level abstraction called the Uniform Group interface.
This working group spent an intensive week, looking at a
wide range of topics in the fault tolerant arena. The acid
test is going to be selecting a hit list of topics for
standardization, ready for the PAR submission at Tahoe.
If you are interested in more information on the group why
not contact the group chair Helmut Roth,
hroth@relay.nswc.navy.mil.
Volume-Number: Volume 33, Number 41
From std-unix-request@uunet.UU.NET Thu Dec 16 22:47:16 1993
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA19519; Thu, 16 Dec 93 22:47:16 -0500
Received: from cygnus.com by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA22167; Thu, 16 Dec 93 22:47:13 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA27598; Thu, 16 Dec 93 19:47:12 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id TAA03721 for std-unix-archive@uunet.uu.net; Thu, 16 Dec 1993 19:47:11 -0800
Xref: majipoor.cygnus.com comp.std.unix:204
From: nick@usenix.org (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, Automated Testing BOF
Organization: USENIX Standards Report Editor
Sender: sef@uunet.uu.net
Message-Id: <2era1dINNisp@rodan.UU.NET>
Reply-To: std-unix@uunet.uu.net
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 16 Dec 1993 19:45:49 -0800
To: std-unix@uunet.UU.NET
Submitted-by: nick@usenix.org (Nicholas M. Stoughton)
USENIX Standards Report Editor
Nicholas M. Stoughton <nick@usenix.org>, Report Editor
Automated Testing BOF
Kathleen Liburdy <liburdy@hubcap.clemson.edu> reports on the
October 18-22, 1993 meeting in Bethesda, MD.:
The fourth Automated Testing BOF met on Wednesday afternoon
during the week of POSIX in Bethesda, MD. This group
provides a forum for the discussion of alternative and
progressive approaches to conformance testing.
Announcements and discussion related to the group are posted
to the mailing list oats@stdsbbs.ieee.org.
In the opening remarks, a Project Authorization Request (PAR
was announced for POSIX.5 (Ada) test methods. This project
will explore the potential application of formal
specifications and automated testing in POSIX test methods.
In particular, the assertions will be developed using the
Clemson Automated Testing System (CATS) assertion language.
These assertions are English-like in nature and can be
automatically translated into an executable test suite. The
decision to apply formal specifications in test methods
development was strongly supported by the POSIX.5 working
group. The PAR was approved by the Sponsor Executive
Committee (SEC), and the first meeting for this effort is
scheduled for January 1994 at the POSIX/Irvine meeting.
The first presentation was an update on the ADL Project by
Shane McCarron. The ADL Project is a four year project
sponsored by the Japanese Minsitry of International Trade
and Industry. The project is being managed by X/Open and
the primary research is being conducted by Sun Microsystems
Laboratories. The mission of this project is to improve the
test suite creation process through automation.
Each version of each deliverable is being reviewed by a
public review group (XoPubADL@xopen.co.uk). Several sets of
draft documents have been submitted for public review,
including version 0.5 of the ADL Language Reference Manual
and ADL Translator Design Specification. The ADL Project
Quality Plan has also been delivered, and is now complete at
version 1.0. The next deliverable of the ADL Project is
November 1, which includes ADLT Design Spec 1.0 Alpha, ADL
Language Reference Manual 1.0 Alpha, and other related
documents. All these documents will be placed on the uunet
ftp site ftp.uu.net under the directory /vendor/adl.
A technical briefing by Alberto Savoia of Sun Microsystems
on the ADL Project was announced for the following morning,
- 2 -
and all AT BOF participants were invited to attend. Alberto
agreed to present a technical upate on the ADL Project and
discuss related issues at the next AT BOF in Irvine, CA.
The next presentation was ``Automated Testing of POSIX
Subsets'' by Jim Leathrum. As part of the continuing
development of CATS, experiments have been undertaken to
investigate the issues associated with specification and
execution of tests for subsets of standard interfaces. As
part of this work, the CATS test harness has been enhanced
to allow the test developer to create subsets of both the
specification and the implementation of the system under
test. A version of the CATS facility with the subsetting
capabilities and the corresponding user manual are scheduled
for release in January.
The ability to subset specifications and implementations in
the CATS environment has led to many new issues which could
not be addressed before. Jim discussed issues such as
subset integrity, testability and granularity which are
currently being investigated with the CATS facility. Many
of these issues were also raised by the POSIX Subset Ad Hoc
group. At the conclusion of the presentation, Lowell
Johnson asked about the possibility of applying CATS to the
POSIX subset dilemma by implementing and experimenting with
some of the proposed POSIX subsets. Jim agreed that this
would be an interesting application for CATS and indicated
that this idea would be considered in future work.
Roger Martin, chair of the Steering Committee for
Conformance Testing (SCCT), expressed an interest in being
responsive to issues raised in the AT BOF. He stated that
the decision in April 1993 to rescind testing requirements
should be viewed as an opportunity to explore new approaches
to testing. He also announced an invitational workshop on
alternative testing methodologies to be hosted by NIST. The
precise date for this workshop has not been determined, but
the general time frame is spring 1994. The purpose of the
workshop is to bring together major players in the field of
conformance testing and collectively identify ways to
cooperate in the pursuit of improved testing capabilities.
The fourth issue of the OATS newsletter was distributed. In
addition to articles related to the AT BOF presentations,
the newsletter includes ``CATS in the Classroom'',
``Software through Pictures: The T Tool'', and ``DejaGnu
Product Description''. Submissions for future issues are
invited and should be sent to liburdy@hubcap.clemson.edu.
Requests for issues of the newsletter may also be sent to
this email address.
Volume-Number: Volume 33, Number 42
From std-unix-request@uunet.UU.NET Thu Dec 16 22:47:11 1993
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA19508; Thu, 16 Dec 93 22:47:11 -0500
Received: from cygnus.com by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA22065; Thu, 16 Dec 93 22:47:05 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA27585; Thu, 16 Dec 93 19:47:03 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id TAA03697 for std-unix-archive@uunet.uu.net; Thu, 16 Dec 1993 19:47:02 -0800
It is over a year since the first round of balloting
on the '.13 profiles closed. Ballot resolution has
been slow because of three gating issues:
a. The '.13 Profiles reference the POSIX.4 and
POSIX.4a Draft Standards and would, in any
event, have to wait for both of these Standards
to be approved.
b. The POSIX.13 Draft contained four (4) profiles
in a single document. An earlier draft of the
ISO document that defines profiles (TR 10,)
apparently forbade multiple profiles in a
document.
c. Three of the four POSIX.13 Profiles restrict an
application to a subset of the interfaces in
POSIX.1. PASC Profile Steering Committee (PSC)
rules for profiles - non-existent when POSIX.13
first went to ballot - forbids a profile to
specify a subset of a base standard.
The first roadblock is in the process of resolving
itself. POSIX.4 is a done deed, and Pthreads should
be approved by mid-'94. A later draft of TR10, now
allows multiple profiles in a ``Standard Profile'', if
a number of conditions regarding cohesiveness, etc.
are satisfied.
The final issue is one which has consumed vast amounts
of PASC meeting time, in Working Groups, PSC meetings,
SEC (Sponsor Executive Committee) meetings, and in
hallway/bar room conversations. An intensive effort
during the week of meetings by an Ad Hoc of the SEC
has resulted in a compromise, of which more later.
5. LIS - RIP Or "What ever happened to '.4c?" POSIX.4c
was to be the Language Independent Specification (LIS
)of POSIX.4. But, when in July the SEC rescinded the
requirement for Working Groups to produce LIS for all
PASC Standards, the '.4 Working Group immediately
voted to stop work on their LIS. That decision was
confirmed again at this meeting.
- 4 -
Thanks to the efforts of Michael Gonzalez, the Working
Group has a nearly complete first draft of the LIS.
Michael said that he wanted to complete the remaining
couple of sections, and would like to see the results
be made available to anyone interested. The WG has
been assured that it will be no problem to arrange to
have the completed, unreviewed, draft available for
ftp from both the IEEE's emerging SPA (Standard's
Process Automation) system, or from Michael Gonzalez's
University system at University of Cantabria,
Santander, Spain.
Working Group Actions and Plans
With all of its documents, except for POSIX.13, done or out
for ballot, one might well wonder what the POSIX.4 working
group is doing meeting in exotic places like Bethesda, MD.
Two things: planning for additional drafts to standardize
additional interfaces, and '.13 ballot resolution.
First, '.13 ballot resolution: The Profiles ballot
resolution effort had degenerated to getting the issue of
specifying subsets of POSIX.1 resolved. Because this issue
is one of inter-Working Group coordination, it required a
lot of interaction with members of the ad hoc committee
established to report back to the SEC. Several members of
the Working Group, who are also '.13 technical reviewers, -
Andy Wheeler, Joe Gwinn, and others - spent a couple of
hours every day, Monday through Thurdsay, in the ad hoc;
reporting back to the Working Group daily on progress or the
lack thereof.
The ad hoc made a fairly thorough review of the issues,
noting that the primary objection to the subsetting was more
religious and political than technical - that is, the
``dilution'' of the POSIX name if it were associated with
anything less that full POSIX.1-1990 as we know and love it.
In truth, though, a number of technical issues did surface
concerning testing of subsets, the effort of respecifying
the semantics of POSIX.1 with formal subsets, the
integration of Standards that later modify the full POSIX.1,
such as Pthreads, POSIX.8, etc., with a subsetted POSIX.1,
...
Ultimately, the ad hoc placed a resolution before the SEC to
suspend the PSC rules for the ``special case'' of real time
subsets for POSIX.13, and allow POSIX.13 to specify the
subsets in the profiles. After an hour and a half of debate
in the SEC, the motion passed, with an amendment requiring
that the POSIX.13 balloting group be reopened for a minimum
period of 30 days. The primary objections to the motion
- 5 -
were not in objection to allowing POSIX.13 to subset '.1; so
much as to having the subsetting done in '.13. The view was
that if subsetting were to be done, do it once and for all
in POSIX.1. This would probably hold up not only the
POSIX.13 profiles for a couple of more years; but any
extension standards that happened to coincide with the
subsetting revision. The resulting resolution will provide
the embedded real time systems community - users and vendors
alike - with a standard profile that describes the runtime
environment that the target applications can depend on, and
that conforming implementations must, as a minimum, support.
The Chair of the SEC pointed out that later, when extensions
to POSIX.1 settle down, and the real time (subset) profiles
have had some use, might be an appropriate time to formalize
the subsets in the POSIX.1 standard itself.
The SEC resolution now clears the way to complete the
POSIX.13 first round ballot resolutions. But, a fair amount
of work now falls on the Technical Reviewers to add the
normative text that effects the subsetting to the next
Draft. A not so small group of volunteers signed up to work
on and review drafts of the subsetting text. The approach
discussed in the Working Group is to prescribe what
functions are available to Strictly Conforming Applications
for each profile. Where some subset of behavior of a
required function is not required, it will be explicitly
unspecified. For example, _o_p_e_n() of a non-existent file in
a profile with no requirement for a file system will be
unspecified; rather than, say, return a specific error.
Initial drafts should be available for the January meeting.
The other new work item was additional interfaces for - call
it POSIX.4d. The Working Group has had a running list of
features and functions of real time systems that are
potential candidates for future Real Time extensions of '.1.
But, the Chair has instructed the Working Group that we
won't generate another PAR unless concrete proposals,
including base documents, are presented, backed by a strong
commitment to see them through to standardization. The
Working Group reviewed several proposals, a couple of which
had fallen out of earlier work such as POSIX.4b because of
lack of consensus at the time that '.4b was otherwise ready
for ballot. The new proposals include:
o+ Typed Memory: This is essentially an additional type of
memory object, like /dev/mem, that represents different
views of special physical memories, such as external
memory modules visible on multiple busses. Extensions
to mmap() to support additional flags for
dynamic/contiguous allocation by the object and
functions to obtain an offset within the object from
- 6 -
the address returned by mmap(), needed with dynamic
allocation.
o+ absolute nanosleep(): This is an extension to the
POSIX.4 nanosleep() function - a new function, actually
- to wait until a specified time using the POSIX.4 high
resolution timespec.
o+ Barrier Synchronization objects: Independently of these
being proposed for POSIX.4, they were also spec'ed by
POSIX.14 - the Multiprocessing Working Group. Because
'.14 is a Profiles Working Group, they need to have any
new interfaces that they propose put into one of the
System Interfaces Working Groups' drafts. The '.14
group had already made tentative arrangements for a
number of new synchronization primitives to go into
POSIX.1a, so the '.4 Working Group may drop this.
o+ Enhancements to POSIX.4: Yes, the ink is barely dry on
the official standard approval, and we're thinking
about ``enhancing'' POSIX.4. That's because some
people have implemented, or are in the process of
actually implementing it. The one extension presented
was to POSIX.4 message queues to make registration for
notification of message arrival, via _m_q__n_o_t_i_f_y(),
optionally persistent.
Other ``housekeeping'' items, such as resolution of
conflicts or unintended ambiguities between POSIX.4 and
Pthreads may come up in time for a '.4d effort.
The January working group is expected to me more of the
same: POSIX.13 ballot resolution, and new proposals. There
are also coordination issues between the '.4 and '.20 - Ada
binding to '.4 - Working Groups, and with the Distributed
Realtime group, .21 to be addressed as they arise.
Volume-Number: Volume 33, Number 40
From std-unix-request@uunet.UU.NET Thu Dec 16 22:47:19 1993
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA19530; Thu, 16 Dec 93 22:47:19 -0500
Received: from cygnus.com by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA22201; Thu, 16 Dec 93 22:47:16 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA27604; Thu, 16 Dec 93 19:47:14 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id TAA03733 for std-unix-archive@uunet.uu.net; Thu, 16 Dec 1993 19:47:13 -0800
Xref: majipoor.cygnus.com comp.std.unix:205
From: robinson@mdd.comm.mot.com (Jim Robinson)
Newsgroups: comp.std.unix
Subject: Re: Spec 1170: What is this???
Organization: Motorola - Wireless Data Group; Richmond, BC
>Well, "spec 1170" is the COSE API document, which is a blending/superset
>of XPG4 and SVID3 with things like sockets and curses added. the 1170 is
>for the 1170-odd interfaces and headers listed in it.
The *draft* document I saw contained the socket API, but not the TLI/XTI
API. Is this correct, or did I see something that was incomplete? I was
under the impression that XTI was X/Open's baby, and thus would be found
in XPG4 and thus also found in "spec 1170".
--
Jim Robinson
robinson@mdd.comm.mot.com
{ubc-cs!van-bc,uunet}!mdivax1!robinson
Volume-Number: Volume 33, Number 43
From std-unix-request@uunet.UU.NET Thu Dec 16 22:53:23 1993
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA19695; Thu, 16 Dec 93 22:53:23 -0500
Received: from cygnus.com by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA24102; Thu, 16 Dec 93 22:53:22 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA27671; Thu, 16 Dec 93 19:53:20 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id TAA03791 for std-unix-archive@uunet.uu.net; Thu, 16 Dec 1993 19:53:19 -0800
In article <2elpqlINNo29@rodan.UU.NET> Scott E. Preece,
preece@urbana.mcd.mot.com writes:
>Just to clarify the answer to the explicit question -- spec 1170 is a
>product of the COSE effort, written by a COSE working group and endorsed
>by a large number of UNIX vendors.
Just to clarify the clarification -- it wasn!t really a COSE work group
-- it was a group with longstanding common issues with UN*X
specifications which produced the initial draft. (OSF participated in
drafting the spec -- and we!re not a COSE partner.) Copies of the
initial draft were available from UNIX International and OSF for review
and comment.
--
John S. Morris
jsm@osf.org
Volume-Number: Volume 33, Number 44
From std-unix-request@uunet.UU.NET Fri Dec 17 15:56:57 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA11873; Fri, 17 Dec 93 15:56:57 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA14913; Fri, 17 Dec 93 15:56:54 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA15385; Fri, 17 Dec 93 12:56:52 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id MAA21929 for std-unix-archive@uunet.uu.net; Fri, 17 Dec 1993 12:56:51 -0800
Taligent, The Research Libraries Group, Symantec, Unisys, Wordperfect, and
Xerox.
The Unicode Consortium is accessible at:
1965 Charleston Road, Mountain View, CA 94043, USA, phone + 415 966 1637
Systems Administration
There was some discussion as to exactly where POSIX.7 (Systems
Administration) would fit in with the remaining POSIX documents.
Hal Jespersen, the Project Editor for Working Group 15, has
announced that WG15 has agreed with his document plans that have changed
set of committees. The POSIX Systems Administration work, which
consists of a number
of subdot groups, will be in a multipart international standard
numbered differently than 9945. The number will not be assigned
until the first CD is registered, but assume it's 12345. Then,
the POSIX.7 documentss will be:
POSIX.7.1 --> ISO/IEC 12345-1
POSIX.7.2 --> ISO/IEC 12345-2
This also assumes the POSIX.7 WG doesn't rearrange their work further.
===========================
Flames to /dev/null, please. P
Volume-Number: Volume 33, Number 45
From std-unix-request@uunet.UU.NET Sun Dec 19 21:46:40 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA10240; Sun, 19 Dec 93 21:46:40 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA24173; Sun, 19 Dec 93 21:46:38 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA18374; Sun, 19 Dec 93 18:46:36 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id SAA05931 for std-unix-archive@uunet.uu.net; Sun, 19 Dec 1993 18:46:36 -0800
Xref: majipoor.cygnus.com comp.std.unix:208
From: jazz@hal.com (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.7: System Administration
Organization: Kithrup Enterprises, Ltd.
Sender: sef@uunet.uu.net
Message-Id: <2f33b1INN9pp@rodan.UU.NET>
References: <2er9urINNimh@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 19 Dec 1993 18:40:33 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: jazz@hal.com (Jason Zions)
>Further, it was readily recognized by all who participated in the arduous
>task of interpretation and response to the objections and comments in
>Bethesda, and by all who are credible in the field, that this represents
>a significant enhancement of the art with respect to distributed systems
>technology. Finally, it was generally agreed that `times have changed'
>and, if we allow ourselves the intellectual stimulation, change is good
>for us. In the print technology area, it was increasingly obvious during
>the week that the `old' is just a bit too old to be relevant any longer,
>other than as grist for whimsey and fond recollection of much simpler
>systems challenges and times.
This continues to make me nervous. If the Print Management specification is
really a significant enhancement of the art, how smart is it to standardize
it immediately? How much implementation with this "significant enhancement
to the art" do we, as a community, possess? Is there yet another significant
enhancement around the corner that will render this as obsolete as lp and
lpr, and if we waited another year could have?
I do not claim the answer to these questions force one to conclude that
print management, as a standard, is ill-timed. But I would like to be
convinced that there *is* sufficient experience with what lies in the draft
that we won't get caught having to revise in two years to fix fatal flaws;
convinced that this is a good "advance", rather than the advance to the art
of prenatal care that thalidomide turned out to be. (Yes, I know I risk
being accused of excessive hyperbole with that last, but I couldn't find a
milder and less-painful metaphor with 60 seconds thought; I apologize, but
the intent remains.)
>The User and Group Administration work is in its early
>stages and is being done primarily by two individuals (a
>third person joined them this week) both of whom are vendor
>representatives. Here is an opportunity to get involved and
>make a difference in the standards arena. Otherwise, you
>will have to accept what is produced by a very small group
>of people.
If all they have is two or three people, I plan on moving to withdraw
sponsorship. I don't care if they're the smartest people in the world; three
people is too small to develop a balanced draft, too small to ensure the
work gets done, too small to give me any confidence that enough people care
about this standard. After all, if people really cared, they'd be working on
it; that's the only relevant measure at this phase of development.
These are, of course, my personal opinions, and are not official opinions of
any part of IEEE-CS PASC of which I am a member.
Jason Zions
jazz@hal.com
Volume-Number: Volume 33, Number 46
From std-unix-request@uunet.UU.NET Sun Dec 19 21:46:49 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA10248; Sun, 19 Dec 93 21:46:49 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA24195; Sun, 19 Dec 93 21:46:48 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA18380; Sun, 19 Dec 93 18:46:47 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id SAA05943 for std-unix-archive@uunet.uu.net; Sun, 19 Dec 1993 18:46:46 -0800
>2. POSIX.4a aka Pthreads aka POSIX.4c: Draft 8 of
^^^^^^^^ POSIX.1c
>Pthreads is being recirculated for a 10 day ballot
>period from 1 - 12 Nov 1993.
[...]
>Note that POSIX.8, Transparent File Access (TFA), is
( now known as POSIX.1f - it wasn't just the 1003.4 family that got shuffled
by the wise folks at the IEEE )
>also expected to be approved at close to the same
>time. The System Interfaces Coordinating Committee
>(SICC) has noted this and has determined that Pthreads
>will be merged with the then merged POSIX.1/1b
>standard before TFA. It remains to be seen when, and
>in how many volumes, the results will be distributed.
The relevant issue is just how often the IEEE is interested in publishing
merged 1003.1-1990-plus-amendments. As far as SICC can see, we expect to see
one amendment to 1003.1-1990 approved every quarter beginning in April 1994
and continuing through mid-95. Will the roll-in the amendments every three
months and kill another forest? Roll them in every other amendment? Stop
killing trees and start putting the standard out on CD-ROM and electronic
form only? And what about... Naomi? (Sorry; it's Friday at 6 PM and I'm
punchy.)
Concerning the "slice-and-dice" ad hoc resolution, i.e. Subsetting of
1003.1-1990:
>The resulting resolution will provide the embedded real time systems
>community - users and vendors alike - with a standard profile that
>describes the runtime environment that the target applications can depend
>on, and that conforming implementations must, as a minimum, support. The
>Chair of the SEC pointed out that later, when extensions to POSIX.1
>settle down, and the real time (subset) profiles have had some use, might
>be an appropriate time to formalize the subsets in the POSIX.1 standard
>itself.
At the risk of breaking something in the subsets originally created by '.13.
I admit to being on the side of "let .1 do it, not .13"; I do recognize that
the base system API working group (i.e. the "dot 1 gang") still has a bunch
of work on its plate, but the integration headache that SICC is beginning to
address at the amendment-granularity level will get worse with slicing
occurring in profiles rather than in the base standard. Frankly, the level
of complexity in just deciding how to order the approval of standards so one
can read and understand what one is balloting on scares me.
#include <std-standard-disclaimer.h>
Jason
Volume-Number: Volume 33, Number 47
From std-unix-request@uunet.UU.NET Sun Dec 19 21:46:57 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA10258; Sun, 19 Dec 93 21:46:57 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA24225; Sun, 19 Dec 93 21:46:56 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA18387; Sun, 19 Dec 93 18:46:54 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id SAA05955 for std-unix-archive@uunet.uu.net; Sun, 19 Dec 1993 18:46:54 -0800
Xref: majipoor.cygnus.com comp.std.unix:210
From: hlj@posix.COM (Hal Jespersen)
Newsgroups: comp.std.unix
Subject: Re: unpublished SunExpert column
Organization: POSIX Software Group, Redwood City, CA
Sender: sef@uunet.uu.net
Message-Id: <2f33juINN9vc@rodan.UU.NET>
References: <2et69rINNbdg@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 19 Dec 1993 18:45:18 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: hlj@posix.COM (Hal Jespersen)
phs@netcom.com (Peter H. Salus) writes:
>The POSIX Systems Administration work, which consists of a number of
>subdot groups, will be in a multipart international standard
>numbered differently than 9945. The number will not be assigned
>until the first CD is registered, but assume it's 12345. Then,
>the POSIX.7 documentss will be:
>
> POSIX.7.1 --> ISO/IEC 12345-1
> POSIX.7.2 --> ISO/IEC 12345-2
>
>This also assumes the POSIX.7 WG doesn't rearrange their work further.
Two updates on this. I have retired from my PE position and Jon Spencer
now has the reins. This POSIX.7 info is now rather old. Although it
is still true that the POSIX sysadmin standards will target another
number in ISO, the underlying POSIX numbers have changed. For you
afficionados of POSIX numbering, they seem to be (currently):
Previous New Subject
-------- --- -------
none P1387.1 Framework for system administration
P1003.7.1 P1387.4 Print administration
P1003.7.2 P1387.2 Software management
P1003.7.3 P1387.3 User management
So each IEEE Std 1387.n will have an ISO/IEC "12345"-n counterpart.
Hal
Volume-Number: Volume 33, Number 48
From std-unix-request@uunet.UU.NET Tue Dec 21 13:44:13 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA15321; Tue, 21 Dec 93 13:44:13 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA19490; Tue, 21 Dec 93 13:44:10 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA19237; Tue, 21 Dec 93 10:44:06 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id KAA19690 for std-unix-archive@uunet.uu.net; Tue, 21 Dec 1993 10:44:05 -0800
Xref: majipoor.cygnus.com comp.std.unix:211
From: rsalz@osf.org (Rich Salz)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.7: System Administration
Organization: Open Software Foundation
Sender: sef@uunet.uu.net
Message-Id: <2f7ftpINNe8r@rodan.UU.NET>
References: <2er9urINNimh@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 21 Dec 1993 10:39:53 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: rsalz@osf.org (Rich Salz)
In <2er9urINNimh@rodan.UU.NET> std-unix@uunet.uu.net writes:
>The print standard is based on MIT's
>Palladium, which is a distributed print management system
>and also the base technology for OSF's offering in the Print
>Management arena.
The OSF print services were, indeed, based on Palladium. Note the
past tense. :-) OSF has announced it had cancelled the print services.
I believe the announcement was made last month and has since showed up
in a few trade rags who cover DME.
/r$
Volume-Number: Volume 33, Number 49
From std-unix-request@uunet.UU.NET Tue Dec 21 13:44:25 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA15392; Tue, 21 Dec 93 13:44:25 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA19614; Tue, 21 Dec 93 13:44:20 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA19266; Tue, 21 Dec 93 10:44:18 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id KAA19702 for std-unix-archive@uunet.uu.net; Tue, 21 Dec 1993 10:44:18 -0800
Xref: majipoor.cygnus.com comp.std.unix:212
From: preece@urbana.mcd.mot.com (Scott E. Preece)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.7: System Administration
Submitted-by: preece@urbana.mcd.mot.com (Scott E. Preece)
In article <2f33b1INN9pp@rodan.UU.NET> jazz@hal.com (Jason Zions) writes:
>This continues to make me nervous. If the Print Management specification is
>really a significant enhancement of the art, how smart is it to standardize
>it immediately? How much implementation with this "significant enhancement
>to the art" do we, as a community, possess? Is there yet another significant
>enhancement around the corner that will render this as obsolete as lp and
>lpr, and if we waited another year could have?
Are your reservations based on having actually been at the meeting and
not hearing enough detail there to make you comfortable, or are you
saying that a posted summary of the group's activities didn't provide
you with enough information to feel comfortable? Isn't the general
principle that since we can't all be at the meetings, we assume the
people who do attend are a cross section of vendors and users who *do*
know what is common today, what is obsolescent, and what is likely to be
around the corner, and that they are authorized to make a recommendation
to the rest of us that we then review and vote on? It hasn't been a
secret what they were working on or what direction they were going; if
the industry was seriously disturbed by their direction, it certainly
had lots of time to enter the discussion.
>If all they have is two or three people, I plan on moving to withdraw
>sponsorship. I don't care if they're the smartest people in the world; three
>people is too small to develop a balanced draft, too small to ensure the
>work gets done, too small to give me any confidence that enough people care
>about this standard. After all, if people really cared, they'd be working on
>it; that's the only relevant measure at this phase of development.
Is that the whole count for their meetings, or is that the number of
people actively writing text? How big is the document expected to be?
I can imagine two people being the primary authors of the text, if they
have a reasonable group of people bounding and reviewing the text.
If they're the only people actually thinking about the subject matter,
I'd agree it's not enough...
scott
--
preece@urbana.mcd.mot.com
Volume-Number: Volume 33, Number 50
From std-unix-request@uunet.UU.NET Tue Dec 21 13:45:15 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA15546; Tue, 21 Dec 93 13:45:15 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA19783; Tue, 21 Dec 93 13:44:40 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA19278; Tue, 21 Dec 93 10:44:37 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id KAA19714 for std-unix-archive@uunet.uu.net; Tue, 21 Dec 1993 10:44:36 -0800
Xref: majipoor.cygnus.com comp.std.unix:213
From: john@iastate.edu (John Hascall)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.7: System Administration
Organization: Iowa State University, Ames, IA
Sender: sef@uunet.uu.net
Message-Id: <2f7g3nINNeoj@rodan.UU.NET>
References: <2er9urINNimh@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 21 Dec 1993 10:43:03 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: john@iastate.edu (John Hascall)
>Submitted-by: nick@usenix.org (Nicholas M. Stoughton)
>Of all the work of POSIX.7, the work of the printing group
>is most advanced, with the initial formal ballot conducted
>in June-July, 1993. The print standard is based on MIT's
>Palladium, which is a distributed print management system
>and also the base technology for OSF's offering in the Print
>Management arena.
>The working group explicitly decided to reject using lpr or
>lp as the basis of the standard believing that neither
>really addressed all of the issues of a distributed printing
>system.
How interesting. We (Iowa State U) investigated using all of
MIT's Athena technology and the *1* piece we completely
rejected was Palladium.
Some how we managed to implement a large (~1000 clients, ~15,000 users,
~250 printers) system using lpr as a baseline. Mind you it works
nothing like lpr/lpd internally, but at least it looks like them
to the users. It supports:
* non-1-to-1 mappings between queues and devices
* output routing (i.e. "bins")
* real-time accounting
* forms
* remote-lpd to other devices
I am not promoting *it* as a standard either (esp. since I can't make
the source available), but I would like to hold it up as
proof-by-counter-example that you needn't dismiss lpr/lpd summarily.
Job 914 queued via lps20-1.durham to du95_lps20@fs-2.iastate.edu
(a DEC LPS20 in 139 Durham (output bins))
% lpq -Plps20
du95_lps20 is ready and printing via network
Rank Owner Submitted At Job Files Total Size
active jaburns Dec 21 09:06 913 stdin 5124
1st john Dec 21 09:06 914 .login 72
John Hascall ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center + Ames, IA 50011 + 515/294-9551
Volume-Number: Volume 33, Number 51
From std-unix-request@uunet.UU.NET Tue Dec 21 13:47:27 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA15783; Tue, 21 Dec 93 13:47:27 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA21179; Tue, 21 Dec 93 13:47:24 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA19351; Tue, 21 Dec 93 10:47:21 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id KAA19843 for std-unix-archive@uunet.uu.net; Tue, 21 Dec 1993 10:47:21 -0800
>The *draft* document I saw contained the socket API, but not the TLI/XTI
>API. Is this correct, or did I see something that was incomplete? I was
>under the impression that XTI was X/Open's baby, and thus would be found
>in XPG4 and thus also found in "spec 1170".
XTI is a part of "spec 1170" (gawd I hate that name for it), but TLI
isn't. X/OPEN is the reference. There are some things going on to make
everything fit smoothly together (as possible), as well.
--
Mark S. Brown IBM Austin, TX
mbrown@austin.ibm.com RS/6000
VNET: MBROWN@AUSVM6 512-838-3926
MS 9582 11400 Burnet Rd. 78758
Volume-Number: Volume 33, Number 52
From std-unix-request@uunet.UU.NET Tue Dec 21 13:47:32 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA15793; Tue, 21 Dec 93 13:47:32 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA21225; Tue, 21 Dec 93 13:47:30 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA19360; Tue, 21 Dec 93 10:47:26 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id KAA19855 for std-unix-archive@uunet.uu.net; Tue, 21 Dec 1993 10:47:26 -0800
>So, how synonymous is 1170 with what defining _XOPEN_SOURCE is supposed to do?
>And is 1170 online anywhere?
Well, 1170 is supposed to be a superset of XPG4, and as such, there will
probably be a new feature test macro (_XOPEN_1170_SOURCE ?, I hope not!)
to go with the expanded namespace. I doubt the X/OPEN will mess with
XPG4 itself....
cheers,
mark
--
Mark S. Brown IBM Austin, TX
mbrown@austin.ibm.com RS/6000
VNET: MBROWN@AUSVM6 512-838-3926
MS 9582 11400 Burnet Rd. 78758
Volume-Number: Volume 33, Number 53
From std-unix-request@uunet.UU.NET Tue Dec 21 21:54:41 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA14440; Tue, 21 Dec 93 21:54:41 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA28700; Tue, 21 Dec 93 21:54:40 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA21880; Tue, 21 Dec 93 18:54:38 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id SAA29483 for std-unix-archive@uunet.uu.net; Tue, 21 Dec 1993 18:54:37 -0800
Xref: majipoor.cygnus.com comp.std.unix:216
From: jazz@hal.com (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.7: System Administration
Organization: Kithrup Enterprises, Ltd.
Sender: sef@uunet.uu.net
Message-Id: <2f8cg5INNdv3@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 21 Dec 1993 18:47:33 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: jazz@hal.com (Jason Zions)
>Are your reservations based on having actually been at the meeting and
>not hearing enough detail there to make you comfortable, or are you
>saying that a posted summary of the group's activities didn't provide
>you with enough information to feel comfortable?
I attend POSIX meetings regularly (since I chair 1003.8 it's considered
_de_rigeur_... :-)) and was the SEC PMC project mentor for the 1003.7 family
of standards. I'm quite familiar with their work.
My reservations are tied to their characterization of their work as a
significant departure from the current state of the art, i.e. invention.
The snitch called it that, anyway, and the drafts I've seen lead me to the
same conclusion. It may be that there are no answers to the questions I
raised that would make me comfortable with a Print Management standard based
on their current draft, but I can imagine some answers that would increase
my discomfort.
>It hasn't been a secret what they were working on or what direction they
>were going; if the industry was seriously disturbed by their direction,
>it certainly had lots of time to enter the discussion.
Yep. Every three or six months a discussion ensues here about whether
Palladium 2 is a good direction; every time it comes up significant flamage
erupts, mostly yelling that Palladium 2 is in fact invention. Each time we
are reassured that the .7 Print Management draft is based on existing
practice, that there are implementations of something very similar. If that
were true, characterizing the work as a significant enhancement of the state
of the art is inappropriate, and I would hope participants in the working
group would know that. Seeing it characterized that way makes me wonder if
the flamers were in fact correct all along.
>Is that the whole count for their meetings, or is that the number of
>people actively writing text? How big is the document expected to be?
>I can imagine two people being the primary authors of the text, if they
>have a reasonable group of people bounding and reviewing the text.
>If they're the only people actually thinking about the subject matter,
>I'd agree it's not enough...
At its height I remember seeing as many as ten people working on the
document. Once its in ballot I have no trouble with there being only two or
three people managing it and responding to ballots. But the phase just
before ballot entry still requires bodies; it strikes me as important to get
concensus before wasting a ballot group's time and the IEEE's money on a
half-baked draft. (See also my comment about voting with ones money
indicating interest.)
Jason Zions
Speaking as an individual, not as chair of 1003.8, chair of PASC SEC PMC, or
chair of PASC SEC SICC. Or any other part of PASC, for that matter.
Volume-Number: Volume 33, Number 54
From std-unix-request@uunet.UU.NET Wed Dec 22 13:56:22 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA16706; Wed, 22 Dec 93 13:56:22 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA15063; Wed, 22 Dec 93 13:56:19 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA16676; Wed, 22 Dec 93 10:56:17 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id KAA14753 for std-unix-archive@uunet.uu.net; Wed, 22 Dec 1993 10:56:16 -0800
In article <2f7ftpINNe8r@rodan.UU.NET> rsalz@osf.org (Rich Salz) writes:
>The OSF print services were, indeed, based on Palladium. Note the
>past tense. :-) OSF has announced it had cancelled the print services.
>I believe the announcement was made last month and has since showed up
>in a few trade rags who cover DME.
I didn't know this, although I'm not really surprised.
Could you (or anybody else) tell us what OSF's reasons for cancelling
the print services were? Or, alternatively, provide a pointer to the
announcement?
Bjorn
Volume-Number: Volume 33, Number 55
From std-unix-request@uunet.UU.NET Fri Dec 24 17:23:25 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA25263; Fri, 24 Dec 93 17:23:25 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA11101; Fri, 24 Dec 93 17:23:24 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA05082; Fri, 24 Dec 93 14:23:22 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id OAA00103 for std-unix-archive@uunet.uu.net; Fri, 24 Dec 1993 14:23:22 -0800
Xref: majipoor.cygnus.com comp.std.unix:218
From: andyfe@ost.com (Andy Feibus)
Newsgroups: comp.std.unix
Subject: Re: POSIX.7.1 (now P1387.4) Print Admin
Organization: Kithrup Enterprises, Ltd.
Sender: sef@uunet.uu.net
Message-Id: <2ffpvcINNoka@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 24 Dec 1993 14:20:28 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: andyfe@ost.com (Andy Feibus)
nick@usenix.org (Nicholas M. Stoughton) writes:
>The working group explicitly decided to reject using lpr or
>lp as the basis of the standard believing that neither
>really addressed all of the issues of a distributed printing
>system.
I just read the D7 draft and didn't see anywhere how they plan to
reconcile the use of pdpr (the Palladium command for submitting
a print job) with lp (the POSIX.2-1992 way of printing something).
lp has already been approved, so will we end up with two commands
for printing?
Anyone know?
--
Andy Feibus.
AMF Enterprises; Process Systems & Integration, Inc.; Open Systems Today
andyfe@ost.com
or: amf@amfent.gwinnett.com
Volume-Number: Volume 33, Number 56
From std-unix-request@uunet.UU.NET Mon Dec 27 13:58:27 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA13549; Mon, 27 Dec 93 13:58:27 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA27650; Mon, 27 Dec 93 13:58:25 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA13791; Mon, 27 Dec 93 10:58:24 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id KAA20532 for std-unix-archive@uunet.uu.net; Mon, 27 Dec 1993 10:58:24 -0800
Xref: majipoor.cygnus.com comp.std.unix:219
From: rsalz@osf.org (Rich Salz)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.7: System Administration
In <2fa520INNg10@rodan.UU.NET> bjla@statoil.no writes:
>Could you (or anybody else) tell us what OSF's reasons for cancelling
>the print services were? Or, alternatively, provide a pointer to the
>announcement?
I believe that the following text was made available at the OSF Management
SIG. (An OSF SIG is a set of OSF members who are interested in a
particular part of OSF technology.) This is a canned answer to "why
was PRS cancelled?":
The goal of DME is to provide the foundation for interoperable systems
and network management applications. Since interoperable print
solutions based on the Palladium technology, the ISO DPA standard, and
DCE are currently available, OSF is no longer adding value in this
space and has stopped work on this component.
For more details, contact Lance Travis <cmt@osf.org>, the DME Business
Area Manager.
Disclaimer: Not an official OSF spokesman.
/r$
Volume-Number: Volume 33, Number 57
From std-unix-request@uunet.UU.NET Fri Jan 7 13:56:19 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA11610; Fri, 7 Jan 94 13:56:19 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA22184; Fri, 7 Jan 94 13:56:13 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA12690; Fri, 7 Jan 94 10:56:12 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id KAA25994 for std-unix-archive@uunet.uu.net; Fri, 7 Jan 1994 10:56:10 -0800
My 1988 copy of P1003.1 says in section 6.4.2 (page 113) for write:
"If nbyte is zero, the write() fucntion shall return zero and have no
other results if the file is a regular file;..."
And three paragraps beyond that it says:
"If the O_APPEND flag of the file status flags is set, the file offset
shall be set to the end of the file prior to each write"
^^^^^
This seems to be conflicting. Where is the file offset supposed to be
after a write of 0 bytes to a file opened with the O_APPEND flag.
Is the offset unchanged, or at the end??
I'm inclined to pick the former alternative, but what does the standard
intends to say??
Frans
PS: I have this checked in P1003.1/1990 and there the ambiguity is not
resolved.
--
Frans Meulenbroeks (meulenbr@prl.philips.nl)
Philips Research Laboratories
Volume-Number: Volume 33, Number 57
From std-unix-request@uunet.UU.NET Fri Jan 7 15:27:07 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA26405; Fri, 7 Jan 94 15:27:07 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA06236; Fri, 7 Jan 94 15:27:03 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA16598; Fri, 7 Jan 94 12:27:01 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id MAA27960 for std-unix-archive@uunet.uu.net; Fri, 7 Jan 1994 12:27:00 -0800
Xref: majipoor.cygnus.com comp.std.unix:221
From: mib@geech.gnu.ai.mit.edu (Michael I Bushnell)
Newsgroups: comp.std.unix
Subject: Re: POSIX write() ambiguity
Organization: FOO
Sender: sef@uunet.uu.net
Message-Id: <2gkg9iINNort@rodan.UU.NET>
References: <2gkb4vINNb0b@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 7 Jan 1994 12:22:10 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: mib@geech.gnu.ai.mit.edu (Michael I Bushnell)
In article <2gkb4vINNb0b@rodan.UU.NET> meulenbr@prl.philips.nl (Frans Meulenbroeks) writes:
>Where is the file offset supposed to be
>after a write of 0 bytes to a file opened with the O_APPEND flag.
>Is the offset unchanged, or at the end??
In my Unix, the offset gets changed. I suspect this is the most
common behavior.
Volume-Number: Volume 33, Number 58
From std-unix-request@uunet.UU.NET Mon Jan 10 01:24:07 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA20823; Mon, 10 Jan 94 01:24:07 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA08718; Mon, 10 Jan 94 01:24:01 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA01428; Sun, 9 Jan 94 22:24:00 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id WAA18728 for std-unix-archive@uunet.uu.net; Sun, 9 Jan 1994 22:23:59 -0800
Xref: majipoor.cygnus.com comp.std.unix:222
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: POSIX write() ambiguity
Organization: U.S. Army Ballistic Research Lab, APG MD.
Sender: sef@uunet.uu.net
Message-Id: <2gqs7kINNk8r@rodan.UU.NET>
References: <2gkb4vINNb0b@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 9 Jan 1994 22:22:44 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
In article <2gkb4vINNb0b@rodan.UU.NET> meulenbr@prl.philips.nl (Frans Meulenbroeks) writes:
>This seems to be conflicting. Where is the file offset supposed to be
>after a write of 0 bytes to a file opened with the O_APPEND flag.
>Is the offset unchanged, or at the end??
Our intention was for the offset to be reset to EOF, just as the
standard says. The "no other results" clause was inserted after
much argument; it simply legitimatized a bug in existing UNIX
implementations. Clearly, writing a file *should* update its
mod time regardless of the amount of data written; however, that
is not what POSIX.1 specified.
There seems to be a lot of misunderstanding when it comes to
manipulation of 0-length data objects. Both the POSIX and C
standards committees decided to make special rules for the 0-
length cases even though they were unnecessary. I don't think
most of the people involved felt very comfortable with the
concept of 0-sized objects, and therefore tried to constrain
them unduly.
Volume-Number: Volume 33, Number 59
From std-unix-request@uunet.UU.NET Mon Jan 10 01:24:14 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA20830; Mon, 10 Jan 94 01:24:14 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA08853; Mon, 10 Jan 94 01:24:11 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA01435; Sun, 9 Jan 94 22:24:10 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id WAA18740 for std-unix-archive@uunet.uu.net; Sun, 9 Jan 1994 22:24:09 -0800
Xref: majipoor.cygnus.com comp.std.unix:223
From: louisi@sco.com (Louis Imershein)
Newsgroups: comp.std.unix
Subject: POSIX7.3 Clarification
Organization: The Santa Cruz Operation, Inc.
Sender: sef@uunet.uu.net
Message-Id: <2gqs94INNka9@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 9 Jan 1994 22:23:32 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: louisi@sco.com (Louis Imershein)
This is to clarify some information about involvement in the
POSIX7.3: Systems Management: User/Group Account Management
group. I know this has all been said before, but perhaps
it bears repeating:
The POSIX7.3 working group has been around a long time.
At its height, it consisted of 10 people actively attending
meetings.
At the Irvine POSIX meeting in 1991, the PAR for this group
was sent back to the drawing board by the PMC. At this
point, many people stopped attending meetings.
A small group of people, who believed that the widespread
existing practice of command line user administration should
be codefied, stayed on and worked toward producing a new PAR
and selecting a base document on which to base that PAR.
The group has now had only one meeting with a PAR. That
meeting was attended full-time by 3 people, two from
commercial companies and one from NIST, all worked on actively
producing a POSIX draft at the meeting in Fall POSIX meeting
in Washington DC. The meeting was also attended part-time
by two others, one from Fermi Labs, and one from X/Open LTD.
I'm now at the POSIX meeting in Irvine California and know of
at least four people who have confirmed they will be attending
this meeting and three who plan to attend part-time.
This group is working on nine very similar utilities for
the management of user accounts and group accounts. We've
made very good progress and our drafts have received good
reviews from system administrators which I would be more
than happy to post here. We are not trying to invent
new technology. We are meerly attempting to take existing
interfaces (from SVID3) and extend them to manage existing
functionality.
As a side note, many of the utilities we chose to base the
draft on are already available as part of the "shadow" passwd
suite available from comp.sources.misc
Feel free to mail me any questions or comments.
--
Louis Imershein
Distriubuted Objects & Systems Management Engineering
SCO Product Development
Chair, IEEE POSIX 1003.7.3: Systems Management: User/Group Account Management
Volume-Number: Volume 33, Number 60
From std-unix-request@uunet.UU.NET Tue Jan 11 15:33:33 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA29502; Tue, 11 Jan 94 15:33:33 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA03269; Tue, 11 Jan 94 15:32:26 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA27909; Tue, 11 Jan 94 12:32:18 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id MAA02638 for std-unix-archive@uunet.uu.net; Tue, 11 Jan 1994 12:32:17 -0800
Xref: majipoor.cygnus.com comp.std.unix:224
From: willcox@urbana.mcd.mot.com (David A Willcox)
Newsgroups: comp.std.unix
Subject: Ballotting group for 1003.1a open for one more week
Organization: Motorola Computer Group, Urbana Design Center
Sender: sef@uunet.uu.net
Message-Id: <2guvr0INNluh@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 11 Jan 1994 11:48:48 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: willcox@urbana.mcd.mot.com (David A Willcox)
The 1003.1a draft standard will be enter the balloting process in the
first quarter of 1994. (The target is early March.) The balloting group
for this extension to 1003.1 will be closed on January 17. If you would
like to be in the balloting group, and have not already sent in a form,
you will need to contact the IEEE *immediately* at:
Annamarie Kaczmarek
IEEE Standards Office
P.O. Box 1331
Piscataway, NJ 08855-1331
Phone: 908/562-3811
FAX: 908/562-1571
There is a $50 fee. Anyone can be in the balloting group, but only IEEE
and Computer Society members are counted when determining whether the
necessary "approval" level has been reached.
This will be a modification of IEEE Std 1003.1-1993 (1003.1-1990, as
modified in 1993 by 1003.4 with realtime extensions).
The major changes being introduced in this revision are:
- Interfaces moved from 1003.2 to 1003.1 (popen(), regexec(), fnmatch(),
getopt(), etc.) (some mandatory, some optional)
- The data interchange format has been moved to 1003.2.
- A variety of smaller changes and cleanups.
Volume-Number: Volume 33, Number 61
From std-unix-request@uunet.UU.NET Wed Jan 12 14:24:09 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA24340; Wed, 12 Jan 94 14:24:09 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA26995; Wed, 12 Jan 94 14:23:47 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA27384; Wed, 12 Jan 94 11:23:40 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id LAA01370 for std-unix-archive@uunet.uu.net; Wed, 12 Jan 1994 11:23:39 -0800
The posix.1 -1990 specifies the following header file
for chown
#include <sys/types.h>
Does that mean the prototype for this function
needs to be put in sys/types.h?
Well, my doubt is how do you figure out where
to put the prototype?
thanx in advance.
--
srini@cup.hp.com
(408)447-4199(W)
(408)447-5039 - Fax
Volume-Number: Volume 33, Number 62
From std-unix-request@uunet.UU.NET Wed Jan 12 14:24:22 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA24353; Wed, 12 Jan 94 14:24:22 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA27079; Wed, 12 Jan 94 14:23:59 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA27400; Wed, 12 Jan 94 11:23:56 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id LAA01385 for std-unix-archive@uunet.uu.net; Wed, 12 Jan 1994 11:23:54 -0800
Xref: majipoor.cygnus.com comp.std.unix:226
From: wicks@dcdmjw.fnal.gov (Matthew Wicks)
Newsgroups: comp.std.unix
Subject: POSIX.7/COSE relationship
Organization: Kithrup Enterprises, Ltd.
Sender: sef@uunet.uu.net
Message-Id: <2h1ilnINNngf@rodan.UU.NET>
Reply-To: wicks@dcdmjw.fnal.gov (Matthew Wicks)
Nntp-Posting-Host: rodan.uu.net
Summary: Unofficial relationship between POSIX.7 and COSE
In a recent presentation at the CDE Developer's Conference in
San Jose, COSE SysMan representatives gave a progress report in
each area of investigation. Print Spooling, Software Distribution
and User/Group all announced their intention to recommend to the
larger SysMan working group that COSE support the POSIX.7
interfaces. Regarding Backup/Restore, COSE is aware of the
the IEEE Storage Systems Working Group Project 1244 activities,
but has no position at this time.
COSE vendors are also tracking and participating in the ISV-led
DMIG (Data Management Interface Group) effort attempting to
to make the Unix kernel friendly to Backup/Restore and Hierarchical
Storage Management developers.
There is no POSIX activity to track in the area of License Management
("License Server").
It should also be noted that COSE SysMan has consistently kept the
X/Open Systems Management Working Group up-to-date on its progress.
In fact, 3 COSE SysMan individuals also represent their companies
in X/Open SysMan meetings (SCO, IBM and SunSoft). Although using different
individuals, HP, DEC and USG/Novell have coordinated participation in both
COSE SysMan and X/Open SysMan.
Volume-Number: Volume 33, Number 63
From std-unix-request@uunet.UU.NET Thu Jan 20 15:38:36 1994
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAvzsc19320; Thu, 20 Jan 94 15:38:36 -0500
Received: from cygnus.com by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAvzsc20292; Thu, 20 Jan 94 15:38:09 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA15268; Thu, 20 Jan 94 12:36:40 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id MAA09123 for std-unix-archive@uunet.uu.net; Thu, 20 Jan 1994 12:36:39 -0800
Xref: majipoor.cygnus.com comp.std.unix:228
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: doubt on chown
Organization: U.S. Army Ballistic Research Lab, APG MD.
Sender: sef@uunet.uu.net
Message-Id: <2hmpj1INNi35@rodan.UU.NET>
References: <2h1ijlINNna2@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 20 Jan 1994 12:29:21 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
In article <2h1ijlINNna2@rodan.UU.NET> srini@hpcuhe.cup.hp.com (Sreenivasa Rao Tellakula) writes:
>The posix.1 -1990 specifies the following header file for chown
>#include <sys/types.h>
>Does that mean the prototype for this function
>needs to be put in sys/types.h?
No -- the header was indicated since one of the *_t typedefs was
referenced in the description of the chown() interface.
>Well, my doubt is how do you figure out where to put the prototype?
POSIX.1 did not specify that every function be declared in some header.
It is generally clear when a POSIX header *is* required to declare
functions; when not otherwise specified, the application is responsible
for properly declaring them. Many of these functions default to the
right thing, namely function-with-unknown-but-fixed-parameters-returning-int.
I would hope that this would be fixed in a subsequent overhaul of POSIX.1.
Is it in POSIX.1a?
Volume-Number: Volume 33, Number 65
From std-unix-request@uunet.UU.NET Thu Jan 20 15:51:18 1994
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAvzsd20347; Thu, 20 Jan 94 15:51:18 -0500
Received: from cygnus.com by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAvzsd24303; Thu, 20 Jan 94 15:50:15 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA15256; Thu, 20 Jan 94 12:36:22 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id MAA09111 for std-unix-archive@uunet.uu.net; Thu, 20 Jan 1994 12:36:21 -0800
Xref: majipoor.cygnus.com comp.std.unix:227
From: mib@geech.gnu.ai.mit.edu (Michael I Bushnell)
Newsgroups: comp.std.unix
Subject: Re: doubt on chown
Organization: FOO
Sender: sef@uunet.uu.net
Message-Id: <2hmpgtINNhve@rodan.UU.NET>
References: <2h1ijlINNna2@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 20 Jan 1994 12:28:13 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: mib@geech.gnu.ai.mit.edu (Michael I Bushnell)
In article <2h1ijlINNna2@rodan.UU.NET> srini@hpcuhe.cup.hp.com (Sreenivasa Rao Tellakula) writes:
>The posix.1 -1990 specifies the following header file
>for chown
>#include <sys/types.h>
>Does that mean the prototype for this function
>needs to be put in sys/types.h?
No. That (which appears on page 107, line 837) refers to what you
need to include for the prototype on line 838 to be meaningful. In
particular, uid_t and gid_t are needed for the chown prototype and are
found in <sys/types.h>.
>Well, my doubt is how do you figure out where to put the prototype?
Section 2.7.3, pages 32-33, specifies the headers for prototypes of
all Posix.1 functions, except for those which are also ANSI C
functions. Since chown is not listed on the table on page 33, lines
910-927, it is in <unistd.h>, as specified by page 32, lines 903-908.
Or, you could have looked on any Posix system (doesn't HPUX claim to
be Posix compliant?) with `grep chown /usr/include/{*,*/*}'.
-mib
--
+1 617 623 3248 (H) | The soul of Jonathan was bound to the soul of David,
+1 617 253 8568 (W) -+- and Jonathan loved him as his own soul.
1105 Broadway | Then Jonathan made a covenant with David
Somerville, MA 02144 | because he loved him as his own soul.
Volume-Number: Volume 33, Number 64
From std-unix-request@uunet.UU.NET Fri Jan 21 17:26:15 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAvzwb07026; Fri, 21 Jan 94 17:26:15 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAvzwb16991; Fri, 21 Jan 94 17:26:10 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA06846; Fri, 21 Jan 94 14:26:06 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id OAA11533 for std-unix-archive@uunet.uu.net; Fri, 21 Jan 1994 14:26:05 -0800
Xref: majipoor.cygnus.com comp.std.unix:229
From: mib@geech.gnu.ai.mit.edu (Michael I Bushnell)
You are incorrect for ANSI C conformant Posix systems. Posix.1 1990
and 1988 both say:
"Implementations claiming C Standard {2} Language-Dependent Support
shall declare function prototypes for all functions.
"Implementations claiming Common-Usage C Language-Dependent Support
shall declare the return type for all functions not returning a
`plain' int."
The 1990 standand added text to make clear that these declarations for
functions not in the table on page 33 nor in the C standard are to be
found in <unistd.h>.
--
+1 617 623 3248 (H) | The soul of Jonathan was bound to the soul of David,
+1 617 253 8568 (W) -+- and Jonathan loved him as his own soul.
1105 Broadway | Then Jonathan made a covenant with David
Somerville, MA 02144 | because he loved him as his own soul.
Volume-Number: Volume 33, Number 66
From std-unix-request@uunet.UU.NET Mon Jan 24 14:53:41 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAwagt15037; Mon, 24 Jan 94 14:53:41 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAwagt19329; Mon, 24 Jan 94 14:52:10 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA24160; Mon, 24 Jan 94 11:51:56 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id LAA18274 for std-unix-archive@uunet.uu.net; Mon, 24 Jan 1994 11:51:55 -0800
I am trying to integrate the audit_mechanisms of SUN, HP and IBM_RS6000
Workstations. My actual idea is a Central point of Control from where you can
control the different systems via SNMPv2 (which means that I have to define an
Audit-MIB) - and where you collect the logfiles for analysis.
Have you got any address of somebody at POSIX working on the same topic?
Or - is there any POSIX mailing list (e.g. for .4a) ?
--
Friedmund Lassmann
Technical University Munich / Dep. of Computer Science
lassmann@informatik.tu-muenchen.de
Volume-Number: Volume 33, Number 68
From std-unix-request@uunet.UU.NET Mon Jan 24 14:53:59 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAwagt15092; Mon, 24 Jan 94 14:53:59 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAwagt19455; Mon, 24 Jan 94 14:52:35 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA24153; Mon, 24 Jan 94 11:51:27 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id LAA18262 for std-unix-archive@uunet.uu.net; Mon, 24 Jan 1994 11:51:26 -0800
Xref: majipoor.cygnus.com comp.std.unix:230
From: decot@hpax.cup.hp.com (Dave Decot)
Newsgroups: comp.std.unix
Subject: Re: doubt on chown
Organization: Hewlett-Packard
Sender: sef@uunet.uu.net
Message-Id: <2i18k5INNe2k@rodan.UU.NET>
References: <2h1ijlINNna2@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 24 Jan 1994 11:47:17 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: decot@hpax.cup.hp.com (Dave Decot)
DISCLAIMER: Official interpretations come only from IEEE.
> The posix.1 -1990 specifies the following header file for chown
>
> #include <sys/types.h>
>
> Does that mean the prototype for this function
> needs to be put in sys/types.h?
No, that is simply a header required to be included before using chown().
No functions are required to be declared in <sys/types.h>.
> Well, my doubt is how do you figure out where to put the prototype?
The situation with regard to what header has what declarations is very
unclear, and is being corrected in the new revision: POSIX.1a. You might
also want to see Annex C, which contains sample header contents.
The locations of external declarations or prototypes for the functions
are listed in Section 2.7.3. Since chown() is not listed, its declaration
appears in <unistd.h>. See lines 903-908.
It might have been nicer to put it in <sys/stat.h>, with chmod().
Dave Decot, Member of the IEEE P1003.1 Working Group
Volume-Number: Volume 33, Number 67
From std-unix-request@uunet.UU.NET Tue Jan 25 15:12:53 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAwakm16810; Tue, 25 Jan 94 15:12:53 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAwakm13410; Tue, 25 Jan 94 15:10:54 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA22939; Tue, 25 Jan 94 12:09:43 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id MAA18013 for std-unix-archive@uunet.uu.net; Tue, 25 Jan 1994 12:09:43 -0800
Xref: majipoor.cygnus.com comp.std.unix:233
From: mib@geech.gnu.ai.mit.edu (Michael I Bushnell)
Newsgroups: comp.std.unix
Subject: Re: doubt on chown
Organization: Free Software Foundation, Cambridge, MA
Submitted-by: mib@geech.gnu.ai.mit.edu (Michael I Bushnell)
In article <2i18k5INNe2k@rodan.UU.NET> decot@hpax.cup.hp.com (Dave Decot) writes:
>The situation with regard to what header has what declarations is very
>unclear, and is being corrected in the new revision: POSIX.1a. You might
>also want to see Annex C, which contains sample header contents.
Nuts. The text in section 2.7.3 is perfectly clear. On the other
hand, there was a move on (I don't know if it will succeed) to have
Posix.1a move some definitions from one header file to another.
But whether your perceived inclarity will be "corrected" in Posix.1a
is not known yet, because (last I checked) that standard still has an
open balloting group, and is nowhere near being done.
I have, however, always suggested that members of the working groups
essentially disregard most suggestions from the balloting group; your
comment (since you are a member of the working group) adds further
evidence in support of my theory.
--
+1 617 623 3248 (H) | The soul of Jonathan was bound to the soul of David,
+1 617 253 8568 (W) -+- and Jonathan loved him as his own soul.
1105 Broadway | Then Jonathan made a covenant with David
Somerville, MA 02144 | because he loved him as his own soul.
Volume-Number: Volume 33, Number 70
From std-unix-request@uunet.UU.NET Tue Jan 25 21:15:26 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAwall28798; Tue, 25 Jan 94 21:15:26 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAwalk09663; Tue, 25 Jan 94 21:14:55 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA04239; Tue, 25 Jan 94 18:14:48 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id SAA26784 for std-unix-archive@uunet.uu.net; Tue, 25 Jan 1994 18:14:47 -0800
>>The situation with regard to what header has what declarations is very
>>unclear, and is being corrected in the new revision: POSIX.1a. You might
>>also want to see Annex C, which contains sample header contents.
>
>Nuts.
Thank you. I'll remember not to answer any more questions in this forum.
>The text in section 2.7.3 is perfectly clear.
Clarity is relative. The failure of the Synopsis sections to indicate
the full set of headers required is unclear, in my opinion.
>On the other hand, there was a move on (I don't know if it will succeed)
>to have Posix.1a move some definitions from one header file to another.
Yes. The current POSIX.1a draft specifies exactly one header in each
Synopsis section, in which the declarations and all needed symbols are
to appear. Often this requires some minimal duplication of symbols
among the headers, but I think the consistency and reduced strain on the
user's memory is worth it. XPG4 already requires this.
>But whether your perceived inclarity will be "corrected" in Posix.1a
>is not known yet, because (last I checked) that standard still has an
>open balloting group, and is nowhere near being done.
Granted. But some clarification of the requirements, even if the actual
technical situation remains unchanged, is in order, if only to forstall
inquiries such as the one which started this discussion.
You should be aware that the "Working Group" does not have any formal
role in the process once they submit a draft for ballot. Any additional
changes are made by the Balloting Coordinator, who usually appoints some
Technical Reviewers (who are often some small subset of the Working
Group, but not necessarily) to review objections and comments submitted
by the Balloting Group.
>I have, however, always suggested that members of the working groups
>essentially disregard most suggestions from the balloting group;
I'm not sure whether you're advocating that we disregard comments from the
balloting group: the above could certainly be taken that way. The word
"suggested" indicates that you apparently desire this, but then the
following...
>your
>comment (since you are a member of the working group) adds further
>evidence in support of my theory.
...indicates that you are trying to make some kind of ironic observation
of a practice in past ballots.
As a balloter on several past POSIX standards, I have not seen any
evidence that balloters' comments were (intentionally) disregarded.
I don't see how my comments here implied that ballots received will be
essentially disregarded. And I think it's rude of you to suggest that I'm
planning on doing it, when I was simply attempting to provide information.
Dave Decot
Volume-Number: Volume 33, Number 71
From std-unix-request@uunet.UU.NET Tue Jan 25 21:17:37 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAwall28859; Tue, 25 Jan 94 21:17:37 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAwall10841; Tue, 25 Jan 94 21:17:20 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA04368; Tue, 25 Jan 94 18:17:10 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id SAA26851 for std-unix-archive@uunet.uu.net; Tue, 25 Jan 1994 18:17:10 -0800
Xref: majipoor.cygnus.com comp.std.unix:235
From: jazz@hal.com (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: distributed audit
Organization: Kithrup Enterprises, Ltd.
Sender: sef@uunet.uu.net
Message-Id: <2i4jgaINNru0@rodan.UU.NET>
References: <2il8nfINNe8t@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 25 Jan 1994 18:11:22 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: jazz@hal.com (Jason Zions)
>My actual idea is a Central point of Control from where you
>can control the different systems via SNMPv2 (which means that I have to
>define an Audit-MIB) - and where you collect the logfiles for analysis.
>Have you got any address of somebody at POSIX working on the same topic?
>Or - is there any POSIX mailing list (e.g. for .4a) ?
The relevant working group is 1003.6, but they're not working on an audit
MIB, just APIs for auditing. They also have a project (1003.22) for
developing a Guide for distributed security, which may hav additional
information.
The current chair of 1003.6 is Lynne Ambuel; her email address is
ambuel@dockmaster.ncsc.mil.
Jason Zions
Volume-Number: Volume 33, Number 72
From std-unix-request@uunet.UU.NET Thu Jan 27 21:59:18 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAwasx24696; Thu, 27 Jan 94 21:59:18 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAwakm13480; Tue, 25 Jan 94 15:11:10 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA22932; Tue, 25 Jan 94 12:09:41 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id MAA18001 for std-unix-archive@uunet.uu.net; Tue, 25 Jan 1994 12:09:39 -0800
Organization: AT&T Bell Laboratories, Murray Hill NJ
Sender: sef@uunet.uu.net
Message-Id: <2i3tntINNe5i@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 25 Jan 1994 11:59:57 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: andrew@alice.att.com (Andrew Hume)
whenever one deals with collating elements, one is
filled with loathing and despair. nevertheless, i seek illumination
from the cognoscenti.
both sorting and regular expressions have to deal with
input text considered (at least in part) as sequences of collating elements.
when does this consideration occur, and is it fixed (i.e., one answer)?
for example, suppose the only collating elements are {c, ch, hi};
how does one interpret `chi'?
we note in advance that parsing a string into collating
elements is NP-complete, and that several alternate parsings exist.
if you want motivation, consider what happens when we
try to match [^[.ij.]]. against 'ijk': what does the . match?
it can't be `i', but is it the `j' or `k'? (and how did you get that answer?)
[ Note cross-posting and followup lines -- mod ]
Volume-Number: Volume 33, Number 69
From std-unix-request@uunet.UU.NET Fri Jan 28 17:19:31 1994
Received: from relay1 (via relay1.UU.NET) by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAwavx16302; Fri, 28 Jan 94 17:19:31 -0500
Received: from cygnus.com by relay1 with SMTP
(5.61/UUNET-internet-primary) id AAwavx24047; Fri, 28 Jan 94 17:19:02 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA18366; Fri, 28 Jan 94 14:18:59 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id OAA27846 for std-unix-archive@uunet.uu.net; Fri, 28 Jan 1994 14:18:57 -0800
Xref: majipoor.cygnus.com comp.std.unix:236
From: jazz@hal.com (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: doubt on chown
Organization: Kithrup Enterprises, Ltd.
Sender: sef@uunet.uu.net
Message-Id: <2ibvp6INN66t@rodan.UU.NET>
References: <2i4jd3INNrqq@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 28 Jan 1994 13:23:50 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: jazz@hal.com (Jason Zions)
[ Moderator's note: the following is presented as a digest, after the
entire conversation appeared in my mailbox. Both have given their
approval for it. I do not wish to encourage arguments, but there
is a lot of useful information in these messages -- mod ]
From: jazz@hal.com
Subject: Re: doubt on chown
Date: Wed, 26 Jan 94 16:35:33 CST
Michael I Bushnell writes:
>I have, however, always suggested that members of the working groups
>essentially disregard most suggestions from the balloting group; your
>comment (since you are a member of the working group) adds further
>evidence in support of my theory.
I'm interpreting your ambiguous statement as an accusation; that is, it is
your belief that working group members do in fact disregard most suggestions
from the balloting group.
1) As has been pointed out, by the time the ballot group has anything to do,
the working group is no longer associated with the document
2) The rules for ballot resolution are quite clear: either the recommended
change is made, a mutually-acceptable change is made, the submittor
voluntarily withdraws the objection, or the objection must be forwarded to
the IEEE Standards Board's REVCOM when the standard is submitted for
approval. I assure you that REVCOM knows how many there are; the members
read them, as well as the Ballot Coordinator's rebuttal (i.e. reason for
rejection). Approval of standards has in the past been refused when there
have been too many unresolved objections, or if there is any appearence of a
systematic pattern of rejection.
3) Kindly set your accusations, with evidence, down on paper. Submit them to
the Chair of the IEEE Standards Board REVCOM, and send a copy to the Chair
of IEEE Standards Board and to the PASC Vice-Chair for Balloting and PASC
Chair (seems only fair). If the system is as broken as you maintain it is,
you are honor-bound to raise the issue in the appropriate forum where it can
be addressed, i.e. REVCOM. When you want it, I would be happy to send you
the name and address of the current holders of the abovementioned offices.
4) If you're unwilling to take the actions in step three, kindly keep your
unsubstantiated aspersions and accusations of unfair treatment to yourself;
it only serves to piss off those of us who bend over backwards to ensure
every ballot comment and objection is treated with the respect and care the
Officially speaking for none of the above groups, or for any other IEEE
entity.
----
From: mib@gnu.ai.mit.edu (Michael I Bushnell)
Subject: Re: doubt on chown
Date: Wed, 26 Jan 94 19:35:32 -0500
>1) As has been pointed out, by the time the ballot group has anything to do,
>the working group is no longer associated with the document
I was unaware of this; I thought that the technical reviewers were
essentially coterminus with the working group.
>4) If you're unwilling to take the actions in step three, kindly keep your
>unsubstantiated aspersions and accusations of unfair treatment to yourself;
>it only serves to piss off those of us who bend over backwards to ensure
>every ballot comment and objection is treated with the respect and care the
>rules require.
I'm not trying to make an accusation. But don't you think there's
something wrong with someone saying `XXX will be in standard YYY' when
they are a just member of a working group and the balloting group
isn't even known yet? Why is it that the members of working groups
(or at least the one person in question) feel free to make claims
about what will and will not be in the standard? My feeling that a
fait accompli is in progress is not helped by protestations that later
objections will be taken seriously--especially when the comment that
prompted my objection was a comment about what Posix.1a will be.
-mib
----
From: Jason Zions <jazz@hal.com>
Subject: How Posix Standards Are Born (was Re: doubt on chown)
Date: Wed, 26 Jan 1994 19:08:59 -0600
>I'm not trying to make an accusation. But don't you think there's
>something wrong with someone saying `XXX will be in standard YYY' when
>they are a just member of a working group and the balloting group
>isn't even known yet? Why is it that the members of working groups
>(or at least the one person in question) feel free to make claims
>about what will and will not be in the standard? My feeling that a
>fait accompli is in progress is not helped by protestations that later
>objections will be taken seriously--especially when the comment that
>prompted my objection was a comment about what Posix.1a will be.
There's a lot about the process of developing a standard that you don't
understand.
The rough content of a standard is shaped when the project is first
authorized; the scope and purpose of the standard are written and approved
before the working group starts work (and in some cases before the working
group exists!). Anyone can propose a project; as long as the submitter can
convince the PASC Sponsor Executive Committee that they're not going to be
inventing stuff and that there are people who will work on the new standard
and that the resource impact on the rest of the PASC effort won't be too
bad, *and* that the proposed work lies within the scope of PASC, it gets
approved.
PASC standards are more complex than many others; they are frequently pieces
of a larger whole. Coordination requirements from other PASC working groups
sometimes dictate some of the content of a standard, and they certainly
dictate some of the details.
One of the requirements for an approved project in PASC is that they have
some document to start with; the base document serves as a starting point
for change, enhancement, retrenchment, and all that entails. The working
group knows what's in it; as the drafts turn from one to the next, working
group members get a darn good feel for what's stable and what's not.
The current state of 1003.1a is that it's just about ready to go to ballot.
What's *in* it is known; unless the working group somehow is radically
different from the ballot group, the working group members (from whom
Technical Reviewers are almost always chosen) have a pretty good idea as to
what is contentious and what is not.
Balloters can easily remove material; an objection need merely state what's
wrong with what's there and request that it be removed. Large hunks of
1003.4 disappeared that way in ballot. Adding new material in ballot is far
more difficult; the objection *must* contain the new text. You can't just
say "This standard needs a function to do so-and-so and I vote no until you
write it"; this would be referred to as a non-responsive objection. If it
included text in roughly the proper style that defined the so-and-so
function, then the objection would be responsive, even if it meant the
technical reviewers had to spend months hammering it into shape (with the
help of the balloter, of course).
The technical reviewers, and ultimately the ballot coordinator, are held
responsible for *every* responsive objection they receive, whether it's from
someone in the ballot group *or*not*. They answer to IEEE-SB RevCom for
every rejected objection if so asked; RevCom examines the balance of the
ballot group and of the submitters of unresolved objections quite closely.
An objection cannot be ignored; if it is rejected, the rationale for that
rejection must stand up to review. There is a well-defined appeals process
in place that can be used by the submitter of a rejected objection.
Cast your mind back a few years to the approval of the ANSI C spec. That
standard was balloted under many of the same rules which apply to POSIX
specs; approval was delayed by a minimum of six months because one (1!)
balloter believed his objections hadn't been appropriately dealt with. The
entire process was followed, up through appeal. The balloter lost, in the
end, but he can't claim he wasn't listened to, understood, and dealt with.
He just didn't like the results, which is (partly) what happens in the
standards game.
Jason Zions
Volume-Number: Volume 33, Number 73
From std-unix-request@uunet.UU.NET Fri Jan 28 17:20:17 1994
Received: from relay1 (via relay1.UU.NET) by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAwavx16476; Fri, 28 Jan 94 17:20:17 -0500
Received: from cygnus.com by relay1 with SMTP
(5.61/UUNET-internet-primary) id AAwavx24548; Fri, 28 Jan 94 17:19:56 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA18379; Fri, 28 Jan 94 14:19:53 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id OAA27867 for std-unix-archive@uunet.uu.net; Fri, 28 Jan 1994 14:19:52 -0800
From std-unix-request@uunet.UU.NET Mon Jan 31 16:16:49 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAwbgv15598; Mon, 31 Jan 94 16:16:49 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAwbgv01592; Mon, 31 Jan 94 16:16:47 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA25051; Mon, 31 Jan 94 13:16:46 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id NAA15654 for std-unix-archive@uunet.uu.net; Mon, 31 Jan 1994 13:16:43 -0800
Xref: majipoor.cygnus.com comp.std.unix:238
From: ben@REX.RE.uokhsc.edu (Benjamin Z. Goldsteen)
Newsgroups: comp.std.unix
Subject: Is there a good guide to POSIX (XPG3, XPG3, Spec1170, AES)?
Organization: Health Sciences Center, University of Oklahoma
Sender: sef@uunet.uu.net
Message-Id: <2ijsajINNeid@rodan.UU.NET>
Reply-To: benjamin-goldsteen@uokhsc.edu
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 31 Jan 1994 13:13:55 -0800
To: std-unix@uunet.UU.NET
Submitted-by: ben@rex.uokhsc.edu (Benjamin Z. Goldsteen)
Recently I have been told by an employee of a computer company
that sells a UNIX-class system that POSIX only requires that "off_t" be
a signed numerical type. However, somebody from IBM told me a while
ago that "off_t" must be a "long" (and that was why they can't add
support for >2GB files/file systems). I would like to be able to have
the definitive information when working with problems like these (and
also writing and maintaining POSIX-compliant programs). I would prefer
something electronic (or accessible via WAIS, WWW, etc) for easy
searching.
Thank you
P.S.Can anybody tell me what the winners of past WeirdNIX were?
--
Benjamin Z. Goldsteen
Volume-Number: Volume 33, Number 75
From std-unix-request@uunet.UU.NET Mon Jan 31 16:18:15 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAwbgv15849; Mon, 31 Jan 94 16:18:15 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAwbgv02541; Mon, 31 Jan 94 16:18:10 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA25127; Mon, 31 Jan 94 13:18:08 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id NAA15737 for std-unix-archive@uunet.uu.net; Mon, 31 Jan 1994 13:18:07 -0800
Xref: majipoor.cygnus.com comp.std.unix:239
From: louisi@sco.COM (Louis Imershein)
Newsgroups: comp.std.unix
Subject: Re: Paladdium
Organization: The Santa Cruz Operation, Inc.
Sender: sef@uunet.uu.net
Message-Id: <2ijsdoINNep5@rodan.UU.NET>
References: <2ic01gINN6tm@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 31 Jan 1994 13:15:36 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: louisi@sco.COM (Louis Imershein)
In article <2ic01gINN6tm@rodan.UU.NET> leisner@sdsp.mc.xerox.com (Marty Leisner 25733) writes:
>I looked in Posix.2 for the specification for lp -- what printing
>protocol does it use (it specifies the printing program, but I didn't
>see anything about what's on the other side).
There is no specification of print protocols in either POSIX.2 or POSIX7.4.
Both are interface specifications only and neither specifies what
goes across the wire.
Although the utility names are different, about the only feature required
by POSIX7.4 thats not at least supported by the current System V print
system is support for managing multiple documents. So you could submit
a set of documents as one print job, but then be able to keep any one of
the documents in the set from printing.
The nicest things about the POSIX7.4 draft are
a) it offers a C API for print applications.
b) it introduces a standard mechanism for command line object oriented
systems management.
c) it standardizes a well thought out set of printing operations and
management options which are supported by existing implimentations
such as BSD lpr and SYSV lp
d) it provides a significant set of optional extensions (attributes mostly
used in the large systems world).
e) it provides a standard mechanism for vendor extensions (like System V's
-o option).
The biggest disadvantages are
a) its not based on a widely used existing practice.
b) its not complete on its own i.e. you have to read a complementary
ISO standard (the ISO Document Printing Application Standard) to
really understand what POSIX7.4 is all about.
--
Louis Imershein
Distriubuted Objects & Systems Management Engineering
SCO Product Development
Chair, IEEE POSIX 1387.3: Systems Management: User/Group Account Management
Volume-Number: Volume 33, Number 76
From std-unix-request@uunet.UU.NET Mon Jan 31 16:18:32 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAwbgv15944; Mon, 31 Jan 94 16:18:32 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAwbgv02765; Mon, 31 Jan 94 16:18:28 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA25150; Mon, 31 Jan 94 13:18:22 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id NAA15752 for std-unix-archive@uunet.uu.net; Mon, 31 Jan 1994 13:18:20 -0800
> I just saw an article in Open Systems Today by Andy Feibus (andyfe@ost.com)
> talking about
> 1) 1003.7.1 has been redesignated as P1387.4
> 2) there's no meeting of the minds with Posix.2
> When did this happen?
The POSIX system administration projects, formerly 1003.7.*, were
re-numbered following the October 1993 meeting. The project number
mappings are as follow:
Subject Old number New number
Print 1003.7.1 1387.4
Software 1003.7.2 1387.2
User/Group Acct 1003.7.3 1387.3
Overview (none) (1387.1 reserved)
I cannot speak for agreement with 1003.2.
--
Jay Ashford tel: +1 512 838 3402
IBM Corporation fax: +1 512 838 3882
11400 Burnet Road
Austin, Texas 78758
USA
Volume-Number: Volume 33, Number 77
From std-unix-request@uunet.UU.NET Wed Feb 2 17:33:10 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAwbok00360; Wed, 2 Feb 94 17:33:10 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAwbok12199; Wed, 2 Feb 94 17:33:03 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA07156; Wed, 2 Feb 94 14:32:24 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id OAA02427 for std-unix-archive@uunet.uu.net; Wed, 2 Feb 1994 14:32:23 -0800
In article <2ibvp6INN66t@rodan.UU.NET> jazz@hal.com (Jason Zions) writes:
>Balloters can easily remove material; an objection need merely state what's
>wrong with what's there and request that it be removed...
>The technical reviewers, and ultimately the ballot coordinator, are held
>responsible for *every* responsive objection they receive...
>An objection cannot be ignored; if it is rejected, the rationale for that
>rejection must stand up to review...
Except that if it is deemed "unresponsive", much less attention is paid.
This would not be that big a problem, were it not that objections which
read:
Problem: the area is not ready for standardization
Request: remove entire document
tend to be deemed "unresponsive", meaning that there is no need to resolve
them, regardless of their merits.
This is a structural problem with the whole process, alas, not merely
a misdeed of some particular group. There is a deeply ingrained assumption
that if somebody wants a standard in a particular area, there should be one.
--
Belief is no substitute | Henry Spencer @ U of Toronto Zoology
for arithmetic. | henry@zoo.toronto.edu utzoo!henry
Volume-Number: Volume 33, Number 78
From std-unix-request@uunet.UU.NET Wed Feb 2 17:33:10 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAwbok00363; Wed, 2 Feb 94 17:33:10 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAwbok12165; Wed, 2 Feb 94 17:33:00 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA07161; Wed, 2 Feb 94 14:32:25 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id OAA02439 for std-unix-archive@uunet.uu.net; Wed, 2 Feb 1994 14:32:24 -0800
Xref: majipoor.cygnus.com comp.std.unix:242
From: jazz@hal.com (Jason Zions)
Newsgroups: comp.std.unix
Subject: Is there a good guide to POSIX (XPG3, XPG3, Spec1170, AES)?
Organization: Kithrup Enterprises, Ltd.
Sender: sef@uunet.uu.net
Message-Id: <2ip6hdINNmpc@rodan.UU.NET>
References: <2ijsajINNeid@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 2 Feb 1994 13:38:53 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: jazz@hal.com (Jason Zions)
>Recently I have been told by an employee of a computer company that sells a
>UNIX-class system that POSIX only requires that "off_t" be a signed
>numerical type. However, somebody from IBM told me a while ago that
>"off_t" must be a "long" (and that was why they can't add support for >2GB
>files/file systems).
Open your copy of 1003.1-1990 to page 27: line 677 in Table 2-1 contains the
definition of off_t, and lines 683 and 684 in the following text are
definitive:
All of the types listed in Table 2-1 shall be arithmetic types;
pid_t, ssize_t, and off_t shall be signed arithmetic types.
Philosophically, the standard should *never* say "off_t must be a long";
that would unduly constrain implementations. IBM may have trouble coming up
with implementation support for a "long long" type for off_t that doesn't
break backwards compatibility, but that is their problem; they cannot hide
behind the standard by claiming it prevents them from doing to.
>I would like to be able to have the definitive information when working
>with problems like these (and also writing and maintaining POSIX-compliant
>programs). I would prefer something electronic (or accessible via WAIS,
>WWW, etc) for easy searching.
Buy a copy of 1003.1-1990 and use the index. There is no electronic-form of
1003.1-1990 available from the IEEE. I seem to recall someone selling a
CD-ROM version of the standard but have no details. The IEEE is working on
issues of electronic distribution but has no solutions at this time.
>P.S.Can anybody tell me what the winners of past WeirdNIX were?
I can tell you who: Paul Goothers in the _Most_Serious_ category, and
Michael Gersten in the _Most_Demented_ category (see 1003.1-1988, below the
list of working group members).
Jason Zions
Note: the above is not an official statement of the IEEE, IEEE-CS, IEEE-CS
PASC, or any other IEEE body. It is definitely *not* an official
Interpretation of the 1003.1-1990 standard.
Volume-Number: Volume 33, Number 79
From std-unix-request@uunet.UU.NET Fri Feb 4 14:07:49 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAwbvg00720; Fri, 4 Feb 94 14:07:49 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAwbvg11288; Fri, 4 Feb 94 14:07:46 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA20292; Fri, 4 Feb 94 11:02:39 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id LAA04745 for std-unix-archive@uunet.uu.net; Fri, 4 Feb 1994 11:02:37 -0800
Xref: majipoor.cygnus.com comp.std.unix:243
From: rto@sequent.com (Robin O'Neill)
Newsgroups: comp.std.unix
Subject: Was this intentional in POSIX.1-1990?
Organization: Sequent Computer Systems Inc.
Sender: sef@uunet.uu.net
Message-Id: <2iu5tvINNsd2@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 4 Feb 1994 10:59:11 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: rto@sequent.com (Robin O'Neill)
The POSIX.1-1990 standard has changed the traditional function of
kill() when the target of the signal happens to be a zombie process.
But, I don't believe this was the intention of the committee at the
time. Thus, if you are/were a member of this committee please read
on and respond. If I hear that this change was indeed intentional,
then I'll conform (and take the heat from the resulting incompatibility
with existing applications). Otherwise, I'll submit a formal "Request
for Interpretation" to the IEEE Standards Board.
Traditionally, "kill(pid,0)" would fail and return ESRCH if the process
indicated by "pid" has exited. Thus, it was possible to test
whether any arbitrary process (which you had permission to signal) was
still alive.
However, POSIX.1-1990 requires that "kill(pid,0)" return success *until*
the process indicated by "pid" is reaped by wait() or waitpid(). Thus,
performing "kill(pid,0)" can no longer be used to determine whether a
process is still alive since a "false positive" will be returned if the
process has exited but has not yet been reaped by wait() or waitpid()
(i.e., a zombie).
I don't believe that this change of traditional functionality was
intentional since there is no longer any POSIX-specific method to
determine whether an unrelated process is still alive (i.e., this
invalidates the reason for allowing a zero value for the sig parameter
to kill()).
The folks who produce the PCTS (i.e., NIST) have provided a test which
invokes "kill(pid,0)" on an inactive (zombie) process and expects success.
After examining the POSIX.1-1990, I believe they have interpreted the
standard correctly. But, I don't believe that the POSIX.1 committee intended
this interpretation.
The following is the basis of my (and NIST's) interpretation:
From the description of kill() in section 3.3.2.4 of POSIX.1-1990:
[ESRCH] No process or process group can be found corresponding
to that specified by pid.
From the definition of "process lifetime" found in section 2.2.2.68:
The period of time that begins when a process is created and ends when
its process ID is returned to the system.
"AFter a process is created with a fork() function, it is considered
active. Its thread of control and address space exist until it
terminates. It then enters an inactive state where certain resources
may be returned to the system, although some resources, such as the
process ID, are still in use. When another process executes a wait()
or waitpid() function for an inactive process, the remaining resources
are returned to the system. The last resource to be returned to the
system is the process ID. AT THIS TIME, THE LIFETIME OF THE PROCESS
ENDS [capitals added by rto for emphasis]."
Thus, since the process' lifetime ends only after it has been reaped by
a wait() or waitpid() AND since it continues to hold on to its pid until
that time, the kill() function must "find" it even though it may be inactive
(i.e., a zombie).
If the standards committee did not intend this to be the interpretation,
then section 3.3.2.4 of POSIX.1-1990 should have said:
[ESRCH] No ACTIVE process or process group can be found
corresponding to that specified by pid.
--
Robin T. O'Neill Internet: rto@sequent.com
Mail Stop D2-745 Telephone: (503) 578-4213
15450 S.W. Koll Parkway Wireless: N7QPG
Volume-Number: Volume 33, Number 80
From std-unix-request@uunet.UU.NET Fri Feb 4 14:09:12 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAwbvg00872; Fri, 4 Feb 94 14:09:12 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAwbvg11890; Fri, 4 Feb 94 14:09:09 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA20506; Fri, 4 Feb 94 11:09:07 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id LAA04874 for std-unix-archive@uunet.uu.net; Fri, 4 Feb 1994 11:09:06 -0800
Xref: majipoor.cygnus.com comp.std.unix:244
From: kingdon@cygnus.com (Jim Kingdon)
Newsgroups: comp.std.unix
Subject: Re: Is there a good guide to POSIX (XPG3, XPG3, Spec1170, AES)?
>All of the types listed in Table 2-1 shall be arithmetic types;
>pid_t, ssize_t, and off_t shall be signed arithmetic types.
In the ANSI C standard, it is spelled out in detail what an
"arithmetic type" is (section 3.1.2.5; one of the possibilities is an
integral type; "long", "int", etc., are listed but not "long long"),
and there is no provision for adding implementation defined arithmetic
types.
According to the ANSI C rationale (section 3.3.3.4), the fact that
size_t is specified to be an unsigned integral type implies that it
must fit in an unsigned long. That is, taking a variable of type
size_t and casting, assigning, passing, etc. it to a variable of type
unsigned long, and back again, must not lose information.
An arithmetic type, however, can also be floating point. Making off_t
a "double" would be perverse, but apparently legal. I can't think of
any operation which can act on either a double or a long which could
not also act on a "long long", so perhaps a "long long" would also be
legal for this reason.
For a practical consequence of all this, "How do you print an off_t?"
Back to standards lawyering, an additional complication comes when
extending "arithmetic type" from ANSI to POSIX. POSIX doesn't define
"arithmetic type", and doesn't seem to provide any normative statement
of where undefined terms are to be defined (correct me if I am wrong;
I looked in section 2.2 of 1003.1-1990). This would appear to just be
sloppiness, but it sort of leaves us in the lurch with respect to
trying to come up with any interpretation one way or the other.
Volume-Number: Volume 33, Number 81
From std-unix-request@uunet.UU.NET Fri Feb 4 14:27:01 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAwbvh03494; Fri, 4 Feb 94 14:27:01 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAwbvh21514; Fri, 4 Feb 94 14:26:58 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA23081; Fri, 4 Feb 94 11:26:54 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id LAA05481 for std-unix-archive@uunet.uu.net; Fri, 4 Feb 1994 11:26:54 -0800
Xref: majipoor.cygnus.com comp.std.unix:245
From: jazz@hal.com (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: doubt on chown
Organization: Kithrup Enterprises, Ltd.
Sender: sef@uunet.uu.net
Message-Id: <2iu6dqINNl3@rodan.UU.NET>
References: <2ip6erINNmbu@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 4 Feb 1994 11:07:38 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: jazz@hal.com (Jason Zions)
Henry makes an excellent point here:
>Except that if it is deemed "unresponsive", much less attention is paid.
>This would not be that big a problem, were it not that objections which
>read:
>
> Problem: the area is not ready for standardization
> Request: remove entire document
>
>tend to be deemed "unresponsive", meaning that there is no need to resolve
>them, regardless of their merits.
Up until recently this was true. No matter how stupid a standard was, as
long as it had a reasonably balanced ballot group of even small size,
standardization was almost unavoidable. Not only that, but you couldn't stop
it before it started; the rules governing the IEEE-CS Standards Activities
Board were such that any Project Authorization Request which was properly
formed and within IEEE-CS scope *must* be sponsored; if the SAB couldn't find
one of its standards committees to sponsor the beast, the SAB was required to
take on the role of sponsor.
This position arises out of anti-trust considerations, among other things.
Voluntary standards development as it is practiced in the US would be a
violation of the Sherman Anti-Trust Act were it not for a set of rules which
govern that development process; one of those rules is that you can't have a
bunch of companies agreeing that something brought forward by some other
companies could not be a standard. That is, exercising any selectivity at
all would be a form of collusion.
>This is a structural problem with the whole process, alas, not merely
>a misdeed of some particular group. There is a deeply ingrained assumption
>that if somebody wants a standard in a particular area, there should be one.
I'd phrase it slightly differently; there is a deeply ingrained belief that
if someone wants a standard in a particular area, there is no legal way to
say "no".
There is hope that this may change; we can thank the purveyors of IEEE
P1751, the SPARC processor standard, for rubbing the collective noses of the
IEEE Standards Board RevCom in a standard that was so egregiously
ill-conceived that even the power engineers on revcom could understand how
monumentally stupid an idea it was. As of the last RevCom meeting, 1751 was
still unapproved, even though it had ostensibly met its balloting
requirements. I have hope that somehow the members of the IEEE Standards
Board will find some way to legally and ethically kill a project.
Jason Zions
As usual, I'm not speaking on behalf of the IEEE or any of its constituent
parts.
Volume-Number: Volume 33, Number 82
From std-unix-request@uunet.UU.NET Sat Feb 5 16:32:15 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAwbzi10581; Sat, 5 Feb 94 16:32:15 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAwbzi26162; Sat, 5 Feb 94 16:32:14 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA17718; Sat, 5 Feb 94 13:32:08 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id NAA01701 for std-unix-archive@uunet.uu.net; Sat, 5 Feb 1994 13:32:08 -0800
Xref: majipoor.cygnus.com comp.std.unix:246
From: karish@mindcraft.com (Chuck Karish)
Newsgroups: comp.std.unix
Subject: Re: Was this intentional in POSIX.1-1990?
Organization: Kithrup Enterprises, Ltd.
Sender: sef@uunet.uu.net
Message-Id: <2j10b8INN7vt@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 5 Feb 1994 12:42:16 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: karish@mindcraft.com (Chuck Karish)
Robin O'Neill wrote:
>The POSIX.1-1990 standard has changed the traditional function of
>kill() when the target of the signal happens to be a zombie process.
>But, I don't believe this was the intention of the committee at the
>time.
The rationale for kill (POSIX.1-1990, page 242, lines 2486-2493)
shows that this was intentional.
As Mr. O'Neill's letter states, the IEEE Std 2003.1-1992
assertion that addresses this point and the NIST test suite
correctly follow IEEE Std 1003.1-1990. This means that the
appropriate avenue of recourse is to suggest a change to POSIX.1
when that standard is next revised rather than to submit a
request for interpretation.
Chuck Karish karish@mindcraft.com
Mindcraft, Inc. 415 323 9000 x117
Volume-Number: Volume 33, Number 83
From std-unix-request@uunet.UU.NET Sat Feb 5 16:32:16 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAwbzi10587; Sat, 5 Feb 94 16:32:16 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAwbzi26165; Sat, 5 Feb 94 16:32:15 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA17720; Sat, 5 Feb 94 13:32:10 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id NAA01713 for std-unix-archive@uunet.uu.net; Sat, 5 Feb 1994 13:32:10 -0800
Xref: majipoor.cygnus.com comp.std.unix:247
From: decot@hpax.cup.hp.com (Dave Decot)
Newsgroups: comp.std.unix
Subject: Re: Was this intentional in POSIX.1-1990?
Organization: Hewlett-Packard
Sender: sef@uunet.uu.net
Message-Id: <2j10dlINN81p@rodan.UU.NET>
References: <2iu5tvINNsd2@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 5 Feb 1994 12:43:33 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: decot@hpax.cup.hp.com (Dave Decot)
>Traditionally, "kill(pid,0)" would fail and return ESRCH if the process
>indicated by "pid" has exited. Thus, it was possible to test
>whether any arbitrary process (which you had permission to signal) was
>still alive.
I don't believe there is any portable use for kill(pid,0) returning
success *if and only if* the indicated process was still "alive",
for reasonable definitions of "alive".
If "alive" means that it still has its address space and registers, and
it can execute code from the application, the question is begged, "Why do
you want to know whether the process is still alive?"
If for synchronization purposes, when you have no other way to detect
the process's existence, I claim that kill(pid, 0) is insufficient.
What if, when kill(pid, 0) is executed, the indicated process is
executing cleanup code after being signalled with SIGTERM, and will _exit()
a few instructions afterward? The indication that the process was
"alive" at that time is not usefully better than the indication that
the process is "alive" when it has become a zombie.
Other means of synchronization are available to POSIX.1 processes,
such as lock files (albeit this is rather problematic across reboots).
Better mechanisms are available in POSIX.1b-1993 (soon to be
published, and previously known as Draft 14.1 of POSIX.4).
>I don't believe that this change of traditional functionality was
>intentional since there is no longer any POSIX-specific method to
>determine whether an unrelated process is still alive (i.e., this
>invalidates the reason for allowing a zero value for the sig parameter
>to kill()).
There never was, even if kill(0, pid) doesn't succeed for zombies.
Finding out that a process exists doesn't mean it's not exiting after
you find out about it, but before you get a chance to do anything about
it.
The success of kill(0, pid) doesn't guarantee that a subsequent
kill(SIGUSR1, pid), or whatever, will succeed.
In fact, the failure of kill(0,pid) with ESRCH, doesn't even provide
the guarantee that any formerly existing process with that pid has
indeed terminated, since high-level security extensions might cause the
target process to become invisible sometime during its lifetime.
Dave Decot
Volume-Number: Volume 33, Number 84
From std-unix-request@uunet.UU.NET Sat Feb 5 16:32:17 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAwbzi10594; Sat, 5 Feb 94 16:32:17 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAwbzi26175; Sat, 5 Feb 94 16:32:16 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA17722; Sat, 5 Feb 94 13:32:11 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id NAA01725 for std-unix-archive@uunet.uu.net; Sat, 5 Feb 1994 13:32:11 -0800
Xref: majipoor.cygnus.com comp.std.unix:248
From: hlj@posix.COM (Hal Jespersen)
Newsgroups: comp.std.unix
Subject: Re: Is there a good guide to POSIX (XPG3, XPG3, Spec1170, AES)?
Organization: POSIX Software Group, Redwood City, CA
>Back to standards lawyering, an additional complication comes when
>extending "arithmetic type" from ANSI to POSIX. POSIX doesn't define
>"arithmetic type", and doesn't seem to provide any normative statement
>of where undefined terms are to be defined (correct me if I am wrong;
>I looked in section 2.2 of 1003.1-1990). This would appear to just be
>sloppiness, but it sort of leaves us in the lurch with respect to
>trying to come up with any interpretation one way or the other.
The POSIX.1 working group chose to not include definitions for many
terms basic to computer science. IEEE Std 100 provides a lot of such
definitions and is considered to be in the normative hierarchy of
IEEE standards even if it is not listed in 1.2. [I don't have one
handy, so don't know if this term is covered.]
Looking back through my SCCS files, I see that the description of off_t
was changed from an "integral type" to an "arithmetic type" during
balloting. (Unfortunately, I seem to have neglected to update the
rationale on this point because it still says "integral".)
If you find anything unclear, please request an interpretation.
Since a revision to IEEE Std 1003.1-1990 is now getting ready for
ballot, this is a good time to do so. As all IEEE standards say:
Interpretations: Occasionally questions may arise regarding the meaning
of portions of standards as they relate to specific applications. When
the need for interpretations is brought to the attention of the IEEE, the
Institute will initiate action to prepare appropriate responses. Since
IEEE Standards represent a consensus of all concerned interests, it is
important to ensure that any interpretation has also received the
concurrence of a balance of interests. For this reason, the IEEE and the
members of its technical committees are not able to provide an instant
response to interpretation requests except in those cases where the
matter has previously received formal consideration.
Comments on standards and requests for interpretations should be
addressed to:
Secretary, IEEE Standards Board
445 Hoes Lane
P.O. Box 1331
Piscataway, NJ 08855-1331
Hal
Volume-Number: Volume 33, Number 85
From std-unix-request@uunet.UU.NET Sat Feb 5 20:32:11 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAwbzy18416; Sat, 5 Feb 94 20:32:11 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAwbzy23223; Sat, 5 Feb 94 20:32:10 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA23022; Sat, 5 Feb 94 17:32:03 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id RAA04062 for std-unix-archive@uunet.uu.net; Sat, 5 Feb 1994 17:32:02 -0800
Xref: majipoor.cygnus.com comp.std.unix:249
From: decot@hpax.cup.hp.com (Dave Decot)
Newsgroups: comp.std.unix
Subject: Re: Is there a good guide to POSIX (XPG3, XPG3, Spec1170, AES)?
>For a practical consequence of all this, "How do you print an off_t?"
Wouldn't this work?
off_t offset;
...
(void)printf("offset = %g\n", (double)offset);
Dave Decot
Volume-Number: Volume 33, Number 86
From std-unix-request@uunet.UU.NET Mon Feb 7 14:51:00 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAwcgl07437; Mon, 7 Feb 94 14:51:00 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAwcgl13707; Mon, 7 Feb 94 14:50:58 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA01497; Mon, 7 Feb 94 11:50:56 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id LAA26256 for std-unix-archive@uunet.uu.net; Mon, 7 Feb 1994 11:50:54 -0800
Xref: majipoor.cygnus.com comp.std.unix:250
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: Was this intentional in POSIX.1-1990?
Organization: U.S. Army Ballistic Research Lab, APG MD.
Sender: sef@uunet.uu.net
Message-Id: <2j65p6INN6e4@rodan.UU.NET>
References: <2iu5tvINNsd2@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 7 Feb 1994 11:45:42 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
In article <2iu5tvINNsd2@rodan.UU.NET> rto@sequent.com (Robin O'Neill) writes:
>I don't believe that this change of traditional functionality was
>intentional since there is no longer any POSIX-specific method to
>determine whether an unrelated process is still alive (i.e., this
>invalidates the reason for allowing a zero value for the sig parameter
>to kill()).
We know it *was* intentional because this issue is discussed in the
Rationale that's attached to the standard. According to the Rationale,
existing behavior varied and the POSIX.1 concept of "process lifetime"
settles the matter as you described it. (Actually I don't think it is
logically deducible from the standard itself, but the Rationale can be
used to decide what the intent is.)
As to whether this aspect of the standard is reasonable, actually I
thought we had deliberately left the vague wording about pid being
"valid" in the spec in order to accommodate either implementation..
Volume-Number: Volume 33, Number 87
From std-unix-request@uunet.UU.NET Mon Feb 7 14:51:24 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAwcgl07526; Mon, 7 Feb 94 14:51:24 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAwcgl13861; Mon, 7 Feb 94 14:51:19 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA01521; Mon, 7 Feb 94 11:51:10 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id LAA26273 for std-unix-archive@uunet.uu.net; Mon, 7 Feb 1994 11:51:10 -0800
Xref: majipoor.cygnus.com comp.std.unix:251
From: ericb@lsid.hp.com (Eric Backus)
Newsgroups: comp.std.unix
Subject: Re: Is there a good guide to POSIX (XPG3, XPG3, Spec1170, AES)?
> >For a practical consequence of all this, "How do you print an off_t?"
> Wouldn't this work?
>
> off_t offset;
> ...
> (void)printf("offset = %g\n", (double)offset);
A. Is it really possible for off_t to be non-integral? If so, why?
B. I don't believe POSIX places an upper limit on the number of bits
in a long (or an off_t), so isn't it in theory possible for an
off_t to be larger than the maximum value representable by a
double?
--
Eric Backus
ericb@lsid.hp.com
(206) 335-2495
Volume-Number: Volume 33, Number 88
From std-unix-request@uunet.UU.NET Mon Feb 7 14:52:48 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAwcgl07668; Mon, 7 Feb 94 14:52:48 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAwcgl14905; Mon, 7 Feb 94 14:52:40 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA01566; Mon, 7 Feb 94 11:52:33 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id LAA26339 for std-unix-archive@uunet.uu.net; Mon, 7 Feb 1994 11:52:32 -0800
Xref: majipoor.cygnus.com comp.std.unix:252
From: hp@vmars.tuwien.ac.at (Peter Holzer)
Newsgroups: comp.std.unix
Subject: Re: Is there a good guide to POSIX (XPG3, XPG3, Spec1170, AES)?
Organization: Technical University, Vienna, Dept. for Realtime Systems, AUSTRIA
>>For a practical consequence of all this, "How do you print an off_t?"
>Wouldn't this work?
> off_t offset;
> ...
> (void)printf("offset = %g\n", (double)offset);
Not necessarily. If off_t is a 64 bit int and double is 64 bits also,
it will lose the lower bits if offset is large enough.
for (i = 0; i < sizeof (off_t); i ++) {
printf ("%x ", ((unsigned char *)&offset)[i];
}
works for any (even non-arithmetic) representations of off_t. It is
rather awkward, though.
--
hp@vmars.tuwien.ac.at | Peter Holzer | TU Vienna | CS/Real-Time Systems
Volume-Number: Volume 33, Number 89
From std-unix-request@uunet.UU.NET Mon Feb 7 23:33:31 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAwchu24918; Mon, 7 Feb 94 23:33:31 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAwchu01447; Mon, 7 Feb 94 23:33:30 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA12348; Mon, 7 Feb 94 20:33:23 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id UAA13841 for std-unix-archive@uunet.uu.net; Mon, 7 Feb 1994 20:33:22 -0800
Xref: majipoor.cygnus.com comp.std.unix:253
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: Is there a good guide to POSIX (XPG3, XPG3, Spec1170, AES)?
Organization: U.S. Army Ballistic Research Lab, APG MD.
In article <2j65vvINN70n@rodan.UU.NET> hp@vmars.tuwien.ac.at (Peter Holzer) writes:
>> (void)printf("offset = %g\n", (double)offset);
>Not necessarily. If off_t is a 64 bit int and double is 64 bits also,
>it will lose the lower bits if offset is large enough.
Hm, let's see, say 50 bits: 2^50 ~ 10^15 = 1000 Terabytes, not
apparently a big problem (if the default precision for %g is changed
so all the significant bits are displayed)
Volume-Number: Volume 33, Number 90
From std-unix-request@uunet.UU.NET Tue Feb 8 13:34:23 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAwcjy21396; Tue, 8 Feb 94 13:34:23 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAwcjy24556; Tue, 8 Feb 94 13:33:15 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA17149; Tue, 8 Feb 94 10:33:08 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id KAA01580 for std-unix-archive@uunet.uu.net; Tue, 8 Feb 1994 10:33:07 -0800
Xref: majipoor.cygnus.com comp.std.unix:254
From: hp@vmars.tuwien.ac.at (Peter Holzer)
Newsgroups: comp.std.unix
Subject: Re: Is there a good guide to POSIX (XPG3, XPG3, Spec1170, AES)?
Organization: Technical University, Vienna, Dept. for Realtime Systems, AUSTRIA
>>Not necessarily. If off_t is a 64 bit int and double is 64 bits also,
>>it will lose the lower bits if offset is large enough.
>Hm, let's see, say 50 bits: 2^50 ~ 10^15 = 1000 Terabytes, not
>apparently a big problem (if the default precision for %g is changed
>so all the significant bits are displayed)
It isn't much of a problem for physical files, but it can be a problem
for special devices. For example, on a 64 bit machine, the kernel might
be mapped at addresses starting at 2^63. If some program (e.g., ps)
wants to record offsets into /dev/kmem, so that it doesn't have to call
nlist every time it is called, it must not cast the offsets to double.
Or consider a distributed database, where the upper 32 bits of the
offset indicate the IP address of the server.
--
hp@vmars.tuwien.ac.at | Peter Holzer | TU Vienna | CS/Real-Time Systems
Volume-Number: Volume 33, Number 91
From std-unix-request@uunet.UU.NET Tue Feb 8 18:44:39 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAwcks26631; Tue, 8 Feb 94 18:44:39 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAwcks28892; Tue, 8 Feb 94 18:44:37 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA26450; Tue, 8 Feb 94 15:44:32 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id PAA09397 for std-unix-archive@uunet.uu.net; Tue, 8 Feb 1994 15:44:31 -0800
Xref: majipoor.cygnus.com comp.std.unix:255
From: knighten@intel.com (Robert L. Knighten)
Newsgroups: comp.std.unix
Subject: Have you returned your P1003.18 ballot?
Organization: Intel Supercomputer System Division, Beaverton, OR
Sender: sef@uunet.uu.net
Message-Id: <2j97mfINNpb7@rodan.UU.NET>
Reply-To: knighten@SSD.intel.com (Bob Knighten)
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 8 Feb 1994 15:36:47 -0800
To: std-unix@uunet.UU.NET
Submitted-by: knighten@intel.com (Robert L. Knighten)
Draft 10 of P1003.18, the POSIX Interactive Systems Application Environment
Profile, is currently in ballot. The due date for the ballot is February 10
so if you are part of the ballot group and have not yet returned your ballot,
please do so NOW!
Thank you,
Bob Knighten
Chair, P1003.18
--
Robert L. Knighten
knighten@ssd.intel.com
Volume-Number: Volume 33, Number 92
From std-unix-request@uunet.UU.NET Tue Feb 8 18:47:26 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAwckt26818; Tue, 8 Feb 94 18:47:26 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAwckt00969; Tue, 8 Feb 94 18:47:24 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA26496; Tue, 8 Feb 94 15:47:21 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id PAA09462 for std-unix-archive@uunet.uu.net; Tue, 8 Feb 1994 15:47:20 -0800
Xref: majipoor.cygnus.com comp.std.unix:256
From: rto@sequent.com (Robin O'Neill)
Newsgroups: comp.std.unix
Subject: Re: Was this intentional in POSIX.1-1990?
Organization: Sequent Computer Systems Inc.
Sender: sef@uunet.uu.net
Message-Id: <2j980kINNpn6@rodan.UU.NET>
References: <2j10b8INN7vt@rodan.UU.NET>
X-Submissions: std-unix@uunet.uu.net
Date: 8 Feb 1994 15:42:12 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: rto@sequent.com (Robin O'Neill)
In article <2j10b8INN7vt@rodan.UU.NET> karish@mindcraft.com (Chuck Karish) writes:
>The rationale for kill (POSIX.1-1990, page 242, lines 2486-2493)
>shows that this was intentional.
>
>As Mr. O'Neill's letter states, the IEEE Std 2003.1-1992
>assertion that addresses this point and the NIST test suite
>correctly follow IEEE Std 1003.1-1990. This means that the
>appropriate avenue of recourse is to suggest a change to POSIX.1
>when that standard is next revised rather than to submit a
>request for interpretation.
Many thanks to Chuck! I should have read the rationale first :-(.
The rationale is quite clear. However, the standard still does
not present any method to determine whether an *unrelated* process
(for which you have permission to signal) has exited. The rationale
states:
In particular this means that an application cannot have a
parent process check for termination of a particular child with
kill() (usually this is done with the null signal; this can
be done reliably with waitpid()).
While this is correct, there is still no provision in POSIX.1 to allow
a process to check for termination of a grandchild (or any other
unrelated process). For example, it would be nice if a process were
able to determine whether a grandchild (or some totally unrelated
process), which has created a lock file, has exited without deleting
the lock file. Also many applications attempt to kill(pid,SIGTERM) a
(potentially unrelated) process, check whether the process has exited
via kill(pid,0) (since it may have been catching SIGTERM signals), and
then apply the more ruthless kill(pid,SIGKILL) if it hasn't terminated
after a reasonable period of time (i.e., 1 or 2 seconds). This is the
typical method for allowing a process the opportunity to clean up and
exit gracefully before being shot to death.
Thus, I'll take the approach recommended by Chuck and suggest a change for
the next revision of POSIX.1
--
Robin T. O'Neill Internet: rto@sequent.com
Mail Stop D2-745 Telephone: (503) 578-4213
15450 S.W. Koll Parkway Wireless: N7QPG
Beaverton, Or 97006 In Person: Hey You!
Volume-Number: Volume 33, Number 93
From std-unix-request@uunet.UU.NET Thu Feb 10 04:16:18 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAwcpx05913; Thu, 10 Feb 94 04:16:18 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAwcpu07889; Thu, 10 Feb 94 03:36:32 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA01495; Thu, 10 Feb 94 00:36:28 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id AAA08104 for std-unix-archive@uunet.uu.net; Thu, 10 Feb 1994 00:36:27 -0800
Xref: majipoor.cygnus.com comp.std.unix:257
From: henry@zoo.toronto.edu (Henry Spencer)
Newsgroups: comp.std.unix
Subject: Re: Was this intentional in POSIX.1-1990?
In article <2j980kINNpn6@rodan.UU.NET> rto@sequent.com (Robin O'Neill) writes:
>... For example, it would be nice if a process were
>able to determine whether a grandchild (or some totally unrelated
>process), which has created a lock file, has exited without deleting
>the lock file...
Bad example. What do you *do* once you've determined this? Hint: just
charging ahead on the assumption that everything except the lock file is
in a consistent state is *not* wise.
Breaking the lock is the easy part. Recovering from the screwup that
caused an orphaned lock to be left around is a lot harder, in general.
In at least 90% of the cases where people want to break locks, it's the
wrong approach to the problem, a band-aid on a compound fracture.
The right approach is to fix the code so processes holding locks don't
die randomly.
--
Belief is no substitute | Henry Spencer @ U of Toronto Zoology
for arithmetic. | henry@zoo.toronto.edu utzoo!henry
Volume-Number: Volume 33, Number 94
From std-unix-request@uunet.UU.NET Thu Feb 10 14:38:55 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAwcrm01136; Thu, 10 Feb 94 14:38:55 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAwcrm16768; Thu, 10 Feb 94 14:37:46 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA20742; Thu, 10 Feb 94 11:37:45 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id LAA22392 for std-unix-archive@uunet.uu.net; Thu, 10 Feb 1994 11:37:38 -0800
Xref: majipoor.cygnus.com comp.std.unix:258
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: Is there a good guide to POSIX (XPG3, XPG3, Spec1170, AES)?
Organization: U.S. Army Ballistic Research Lab, APG MD.
In article <2j8liuINNk34@rodan.UU.NET> hp@vmars.tuwien.ac.at (Peter Holzer) writes:
>It isn't much of a problem for physical files, but it can be a problem
>for special devices. For example, on a 64 bit machine, the kernel might
>be mapped at addresses starting at 2^63.
I thought /dev/kmem was supposed to map the addresses to a reasonable
0-based range on systems like that?
Clearly we are beyond 32 bits at this point, but I don't think we're
contemplating dealing with objects that actually have sizes needing
64 bits. Using the address bits to encode funny stuff isn't quite
Kosher and it's not clear that "seek offsets" make much sense for
these. Some time ago I suggested to Dennis Ritchie that small
*negative* absolute offsets would be an interesting way to access
e.g. inode attributes for an open file, but that idea didn't go over
very well.
The C standard introduced f{get,set}pos functions using "magic cookies"
specifically to allow implementations to represent arbitrarily large
offsets regardless of the available arithmetic data types known to
the programming language translator. Additional functions could be
created to help manipulate these cookies, e.g. to print them nicely
or to do arithmetic with them.
Volume-Number: Volume 33, Number 95
From std-unix-request@uunet.UU.NET Fri Feb 11 16:47:43 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAwcvn26164; Fri, 11 Feb 94 16:47:43 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAwcvn28013; Fri, 11 Feb 94 16:47:40 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA25120; Fri, 11 Feb 94 13:47:51 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id NAA29164 for std-unix-archive@uunet.uu.net; Fri, 11 Feb 1994 13:47:32 -0800
Xref: majipoor.cygnus.com comp.std.unix:259
From: jb@vnet.IBM.COM (Jason Behm)
Newsgroups: comp.std.unix
Subject: Re: Was this intentional in POSIX.1-1990?
Organization: IBM Risc System/6000 Division - Austin, TX USA
Sender: sef@uunet.uu.net
Message-Id: <2jgs70INNmed@rodan.UU.NET>
References: <2j10b8INN7vt@rodan.UU.NET>
Reply-To: jb@vnet.IBM.COM
X-Submissions: std-unix@uunet.uu.net
Date: 11 Feb 1994 13:09:52 -0800
To: std-unix@uunet.UU.NET
Submitted-by: jb@vnet.IBM.COM (Jason Behm)
In <2j980kINNpn6@rodan.UU.NET> Robin O'Neill writes:
>Thus, I'll take the approach recommended by Chuck and suggest a change
>for the next revision of POSIX.1
Should this requested be made during balloting for 1003.1a (for which
the ballot group just formed)? Or should Robin wait for some later
revision to make the request?
Just curious,
Jason Behm
jb@vnet.ibm.com
Volume-Number: Volume 33, Number 96
at 2^31, and I was
just extrapolating this to 64 bit machines. Can anyone with an Alpha or
R4000 tell us how this is handled?
> Some time ago I suggested to Dennis Ritchie that small
>*negative* absolute offsets would be an interesting way to access
>e.g. inode attributes for an open file, but that idea didn't go over
>very well.
Doesn't the 4.4bsd file system use a similar scheme?
hp
hp@vmars.tuwien.ac.at | Peter Holzer | TU Vienna | CS/Real-Time Systems
Volume-Number: Volume 33, Number 97
From std-unix-request@uunet.UU.NET Fri Feb 11 16:47:54 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAwcvn26187; Fri, 11 Feb 94 16:47:54 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAwcvn28136; Fri, 11 Feb 94 16:47:51 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA25134; Fri, 11 Feb 94 13:48:05 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id NAA29188 for std-unix-archive@uunet.uu.net; Fri, 11 Feb 1994 13:47:47 -0800
Xref: majipoor.cygnus.com comp.std.unix:261
From: potter@netcom.com (David Potter)
Newsgroups: comp.std.unix
Subject: Re: Was this intentional in POSIX.1-1990?
Organization: Netcom - Online Communication Services (408 241-9760 guest)
I would like to add my support for Robin O'Neill. I use kill(pid,0)
to ask if my client process is still running. The server needs to
clear a pid field in shared memory if the client process is gone.
The real issue is, how can we ask if any particular process is still
running? I don't want "false positive" either.
--
David Potter, Open System Performance, Inc., (916)987-7531
potter@osperf.com
Volume-Number: Volume 33, Number 98
From std-unix-request@uunet.UU.NET Mon Feb 14 14:43:18 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAwdgg02764; Mon, 14 Feb 94 14:43:18 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAwdgg06627; Mon, 14 Feb 94 14:43:15 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA15150; Mon, 14 Feb 94 11:44:02 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id LAA20232 for std-unix-archive@uunet.uu.net; Mon, 14 Feb 1994 11:43:11 -0800
Xref: majipoor.cygnus.com comp.std.unix:262
From: jazz@hal.com (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: Was this intentional in POSIX.1-1990?
Organization: Kithrup Enterprises, Ltd.
Sender: sef@uunet.uu.net
Message-Id: <2jojo8INN1vh@rodan.UU.NET>
References: <2jgsfnINNmrf@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 14 Feb 1994 11:34:32 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: jazz@hal.com (Jason Zions)
>Should this requested be made during balloting for 1003.1a (for which
>the ballot group just formed)? Or should Robin wait for some later
>revision to make the request?
If none of the material you'd want to change appears in the text of 1003.1a,
and you can't find an interpretation of the scope and purpose of the PAR for
1003.1a that makes it clear that 1003.1a is supposed to fix this sort of
thing, you can't fix it that way; the entire 1003.1-1990 document is *not*
open for revision by the ballot group for 1003.1a. You could ask one of the
groups developing amendments to 1003.1-1990 that haven't entered ballot to
put it in their draft and revise their PAR scope and purpose appropriately;
today, that means 1003.1g and 1003.1e (.12 and .6, respectively), I think.
I suspect the 1003.1a PAR purpose does include some sentence along the lines
of "fix bugs"; if so, then it is within scope for 1003.1a to change this,
and you should file a ballot objection containing the precise text you wish
to see appear in 1003.1a (i.e. the precise changes you want to make in
1003.1-1990). Be prepared for a response along the lines of "reduces the
concensus of the ballot group"; try to campaign ahead of time to get fellow
balloters to support this particular objection of yours by reference. That
is, post to this mailing list the exact objection and ask people to include
in their ballots an objection that reads "I support objection so-and-so from
Jason Behm at IBM regarding such-and-such."
Good luck.
Jason Zions
Not speaking for IEEE etc.
Volume-Number: Volume 33, Number 99
From std-unix-request@uunet.UU.NET Mon Feb 14 14:43:34 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AAwdgg02773; Mon, 14 Feb 94 14:43:34 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAwdgg06743; Mon, 14 Feb 94 14:43:30 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA15168; Mon, 14 Feb 94 11:44:18 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id LAA20244 for std-unix-archive@uunet.uu.net; Mon, 14 Feb 1994 11:43:27 -0800
Xref: majipoor.cygnus.com comp.std.unix:263
From: karish@mindcraft.com (Chuck Karish)
Newsgroups: comp.std.unix
Subject: Re: Was this intentional in POSIX.1-1990?
Organization: Kithrup Enterprises, Ltd.
Sender: sef@uunet.uu.net
Message-Id: <2jojsiINN25r@rodan.UU.NET>
References: <2jojo8INN1vh@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 14 Feb 1994 11:36:50 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: karish@mindcraft.com (Chuck Karish)
potter@netcom.com (David Potter) wrote:
>I would like to add my support for Robin O'Neill. I use kill(pid,0)
>to ask if my client process is still running. The server needs to
>clear a pid field in shared memory if the client process is gone.
>
>The real issue is, how can we ask if any particular process is still
>running? I don't want "false positive" either.
Have the client set an advisory lock on a pre-arranged portion
of a file. When the client terminates, the lock is released
(POSIX.1 page 125 lines 461-463).
Henry Spencer raised the critical issue: it is difficult to
define a unique moment when a process ceases to exist. Is it a
zombie after it has called exit() but before its exit processing
is complete?
The determination of the end of the interesting portion of a
process's activity should be tailored to the specific use. Look
at the resource you're interested in, and detect whether the
other process has given it up. If that's hard to do, set up a
convention that allows the other process to announce that it's
done.
I don't know of a way that POSIX.1 could be changed to handle
this. Once exit() or _exit() or whatever is called, the process
goes away. The tear-down processing may or may not be done with
the protection of a signal mask that prevents the former process
from receiving signals.
The procedure for fixing this through an objection to POSIX.1a
would be to suggest alternate wording. I haven't seen a concrete