HDTenEightyP/NetNews huggingface dataset:
From: stevea@i88.isc.com (Steve Alexander)
Subject: Re: Does anyone have a port of XNTP3 for SVR4.
Organization: Lachman Technology, Inc., Naperville, IL
Date: Sat, 09 Jan 1993 18:58:33 GMT

In article <C0GEEn.FKD@agora.rain.com> rgrimes@agora.rain.com (Rodney Grimes) writes:
>Hi,
>I am trying to get XNTP V3 running on a SVR4 system.  I got it to
>compile and I can talk to it with xntpdc and ntpq.  It seems to 
>come up and get the time from the servers I have listed and then
>it just sits, it never seems to talk to the other servers again.

I haven't looked at XNTP V3 yet, but we had problems with XNTP V2 on SVR4
because of socket operations being done from the SIGIO handler.  On SVR4,
SIGIO is defined as SIGPOLL.  Due to the design of the socket emulation 
package, the socket library uses SIGPOLL for its own purposes, and there is a 
bizarre sequence of events that can cause you to come out of the signal 
handler for SIGIO with SIGIO held.  It's something like:

	sigset(SIGIO, input_handler)
	...
	input_handler() (called due to SIGIO) at this point, SIGIO is SIG_HOLD,
		because you are in the handler
	recvfrom()
		-- set SIGPOLL to SIG_IGN and save the old value
		-- do socket stuff
		-- reset SIGIO to old value, which is SIG_HOLD
	return from input_handler with SIGIO held

This is bad, because you will never find out about messages on your sockets
again.  The fix was to do a sigset(SIGIO, handler) before exiting the SIGIO
handler.  Sigrelse(SIGIO) might work too, but I don't remember the exact
details anymore.

As I said, I haven't looked at XNTP V3, so this may be useless information,
but we did see similar problems with V2, so you may want to look for this
sort of behavior.  I believe that ntpdate had a similar problem.

Good luck,
-- Steve
-- 
Steve Alexander, Lachman Technology, Inc. | stevea@isc.com
(708) 505-9555 x256 FAX: (708) 505-9574	  | ...!{sun,ico}!laidbak!stevea
From: iglesias@draco.acs.uci.edu (Mike Iglesias)
Newsgroups: comp.protocols.time.ntp
Subject: clepsydra.dec.com?
Date: 9 Jan 93 05:58:46 GMT
Organization: University of California, Irvine

Anyone know what's happened to clepsydra.dec.com?  It's been off the
air for some time now.


Mike
From: CASNER@ISI.EDU (Stephen Casner)
Newsgroups: comp.protocols.time.ntp
Subject: Seeking NTP for IBM MVS and OS/2
Date: 7 Jan 93 05:28:51 GMT
Distribution: inet
Organization: The Internet

Are there any implementations of NTP available for IBM mainframes
and for PC's running OS/2?
                                                        -- Steve
-------
From: sasurguine@cudnvr.denver.colorado.edu
Newsgroups: comp.protocols.time.ntp
Subject: Configuring XNTP on IPX ... with Multinet NTP Rev 1
Date: 12 Jan 93 09:38:56 GMT

I have a Serious Problem configuring XNTP on a SPARC IPX so that it will
grab its clock from a Micro VAX which is running Version/Rev 1 NTP via
Multinet.

I have configured ntp.conf in my xntp/conf directory several ways.  Both
with and without the version 1 entry.  My current config file is:

server 128.125.224.50             version 1                      #Our Vax

I have also tried:

server 120.125.224.50             #Our Vax

And:

peer   128.125.224.50             version 1

And:

peer 128.125.224.50               #Our Vax

Nothing Works.  Not only do I still have 2 machines roughly 6 mintues apart,
but the SPARC still shows MST not GMT.

HELP!!
help certainly SOMEONE out ther has come accross this configuration.

Thanks For Your Support :-)

Scott A. Surguine
                                
I have contacted our TCP vendor for Vax Multinet. They have been little or no
help.  Certainly SOMEONE out there has been through this

Newsgroups: comp.protocols.time.ntp,comp.sys.mips
From: ajudge@maths.tcd.ie (Alan Judge)
Subject: Running xntp3 on MIPS RISC/os 5.01
Organization: Dept. of Maths, Trinity College, Dublin, Ireland.
Date: Tue, 5 Jan 1993 18:13:55 GMT

I am attempting to run xntp3 on an R4000 based MIPS box running
RISC/os 5, having previously had no trouble under RISC/os 4.51 with
R3000 boxes.

The main problem seems to be that (as documented only in the svr4 man
set from mips, and not the bsd43 man set) settimeofday ignores the
usecond part altogether.  To quote:
     The implementation of settimeofday ignores the tv_usec
     field of tp.  If the time needs to be set with better
     than one second accuracy, call settimeofday for the
     seconds and then adjtime for finer accuracy.

Now, what I have been trying to do is run ntpdate at startup to get
things roughly correct, and then run xntpd with SLEWALWAYS defined.
This doesn't seem to be working at all well.  As far as I can tell
ntp.drift always contains 0.00000 and the time frequently seems to
slide as much as several seconds off.

I tried with tickadj at 5 and 40.

Is SLEWALWAYS known to work?  (I had a look at the code, but I don't
know enough about NTP.  It seems that ntp_unixclock.c ignores
attempted steps altogether, but ntp_loopfilter.c:localclock isn't
modified on SLEWALWAYS and tries to call step_systime anyway.)

Can anyone enlighten me?

Has anyone got this combination to work correctly?


I really need to get this working, as we will soon be upgrading one of
our main stratum 2 clocks to RISCos 5, and would rather not have to
close down the service and inconvenience people all over Europe.
-- 
Alan Judge   ajudge@maths.tcd.ie  a.k.a. amjudge@dsg.cs.tcd.ie +353-1-7021782

"The path of my life is strewn with cowpats from the devils' own herd."
                                          -- Edmund Blackadder II
From: sboyle@wv.mentorg.com (Sean Boyle)
Newsgroups: comp.protocols.time.ntp
Subject: NEC NEWS
Date: 5 Jan 93 17:24:48 GMT
Distribution: inet
Organization: The Internet

Has anyone ported V3 to NEC?  There doesn't seem to be any ifdefs to
take into consideration their <string.h> -vs- <strings.h>, the need for
sockio, the nlist structure is different, etc...  I'd love to have a
patch or SOMETHING...

-- 
            +------------------------+------------------------------+
            | sean_boyle@mentorg.com |  Mentor Graphics Corporation |
            | uunet!mntgfx!sboyle    |  8005 S.W. Boeckman Road     |
            |                        |  Wilsonville, OR 97070-7777  |
            |       "Intrinsically lazy, therefore creative"        |
            +------------------------+------------------------------+
From: mogul@pa.dec.com (Jeffrey Mogul)
Newsgroups: comp.protocols.time.ntp
Subject: Re: clepsydra.dec.com?
Date: 12 Jan 1993 00:15:03 GMT
Organization: DEC Western Research
Distribution: inet
NNTP-Posting-Host: jove.pa.dec.com

In article <2B4E6996.22476@news.service.uci.edu> iglesias@draco.acs.uci.edu (Mike Iglesias) writes:
>Anyone know what's happened to clepsydra.dec.com?  It's been off the
>air for some time now.

We too are at the mercy of a dead floppy drive.  I could probably
find one in DEC's internal used-equipment database, but it's not
worth the bother.  I'm trying to arm-wrestle someone into connecting
our GOES clock to an ULTRIX box running xtnp3, which would make everyone
(including Dr. Fuzzball himself) happier than if we tried to revive
the poor little fuzzy.

At some point, the new host will probably find itself with the alias
"clepsydra.dec.com", and possibly even the same IP address.  But don't
hold your breath; it's not a technical problem, and it's not a political
problem, it's just lack of time.

-Jeff
From: kenh@leps5.phys.psu.edu (Ken Hornstein)
Newsgroups: comp.protocols.time.ntp
Subject: xntp3 refuses to talk from little-endian to big endian machines
Date: 12 Jan 1993 14:29:50 GMT
Organization: Penn State, Laboratory for Elementary Particle Science
Distribution: inet

I have been trying to get xntp3 (the latest version from louie.udel.edu)
working on the following machines:

	Vax 11/750 	    - BSD 4.3
	DECstation 3100     - Ultrix 4.0
	DECstation 5000/240 - Ultrix 4.3

On all these machines, xntp3 has the same problem: it will only talk to
another xntp daemon that is running on one of these machines.  Xntpdc will
only talk to a daemon on one of these machines; when trying to talk to
another machine, it times out.  Xntpdc's on other machines cannot talk
to these daemons.  It _looks_ like there is a byte-order problem, but
I have not gone that far into the problem.  Does anyone else run xntpd on
a little endian machine?  If so, please let me know what you did to get it
to work!

--Ken
From: ajudge@maths.tcd.ie (Alan Judge)
Newsgroups: comp.protocols.time.ntp
Subject: Problems with xntp and MIPS RISC/os 5.01
Date: 11 Jan 93 14:51:25 GMT
Distribution: inet
Organization: The Internet

[Sorry to those who have already seen this in news.]

We are trying to run xntp 3 under MIPS RISC/os 5.01 on an R4000 based
MIPS box.  We already have xntp 3 running fine on RISC/os 4.51 R3000
machines;  these machines will be upgraded soon, and one of them is a
fairly well used Stratum 2, hence the urgency of the problem.

Anyway, the main problem is that settimeofday seems to work oddly
under RISC/os 5.  To quote:
     The implementation of settimeofday ignores the tv_usec
     field of tp.  If the time needs to be set with better
     than one second accuracy, call settimeofday for the
     seconds and then adjtime for finer accuracy.

This seems to cause xntp a good deal of indigestion and it never
settles down.  The time drifts quite a lot off (like 5-10 seconds and
more).


Since the standard code didn't work, I had a rummage in the code and
noticed SLEWALWAYS.  I tried defining this, and despite using several
different tickadj values, xntp never worked properly and in some cases
went total wild (drifting over a minute off in a few hours).

I've even tried some other hacks in ntp_loopfilter.c (which doesn't
seem to depend on SLEWALWAYS, even though it looks like it should),
but have had no success.


So, can anyone tell me:
	Does the SLEWALWAYS code work?
	Do I need to do anything else?

Any suggestions that I could try?
--
Alan
Xref: sparky comp.networks.noctools.wanted:1 comp.protocols.tcp-ip:5787
From: scoggin@delmarva.com (John K. Scoggin, Jr.)
Newsgroups: comp.networks.noctools.wanted,comp.protocols.tcp-ip
Subject: Looking for tools
Date: 1 Jan 1993 19:43:30 GMT
Organization: Delmarva Power & Light Company
Distribution: world
Reply-To: scoggin@delmarva.com
NNTP-Posting-Host: mercury.delmarva.com
Keywords: NNam NCNS

In the Internet System Handbook, two tools are mentioned which appear to be quite useful:
	NCNS	network performance measurement tool from CMU
	NNam	network analysis tool from Merit

Does anyone know how to go about procuring copies of these tools?
---
+---------------------------------------------------------------------+    
|  John K. Scoggin, Jr.			Email: scoggin@delmarva.com   |
|  Supervisor, Network Operations       Phone: (302) 451-5200         |
|  Delmarva Power & Light Company       Fax:   (302) 451-5321         |
|  500 N. Wakefield Drive               NOC:   (800) 388-7076         |
|  Newark, DE 19714-6066		                              |
+---------------------------------------------------------------------+
From: duke@portal.paperboy.osf.org (Duke Robillard)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.7b: Software Administration
Date: 10 Jan 1993 03:46:35 -0800
Organization: UUNET Communications
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: duke@portal.paperboy.osf.org (Duke Robillard)

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

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

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

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

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

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

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

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

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

Volume-Number: Volume 30, Number 19
From: preece@urbana.mcd.mot.com (Scott E. Preece)
Newsgroups: comp.std.unix
Subject: Re: POSIX - Caving In Under Its Own Weight (Long)
Date: 4 Jan 1993 16:29:05 -0800
Organization: Motorola MCG, Urbana Design Center
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: preece@urbana.mcd.mot.com (Scott E. Preece)

The problem is that in the current environment saying "Don't make us
write test methods" really means "We think it's better to send the
standard our a little half-baked than to take the time to remove another
round of ambiguities."  That *may* be the right answer.  It may very
well be that more ambiguities will be exposed and interpreted by getting
the standard out for people to implement.  On the other hand, it also
may be that each implementor will guess and interpret when faced with
ambiguity, rather than seeking interpretation through inconvenient and
possibly slow official channels.

What is important about the test method requirement is that it requires
the standard writers to translate the specification into another form.
There is no structural guarantee that the alternative form will be
complete or perfect, but there is a high probability that *some*
ambiguities will be exposed.

My experience with trying to get a system to meet a standard that was
intended to be quite unambiguous (the 88000 version of the SVR4 ABI) is
that none of the existing standards is there yet and that forcing the
authors to think about them a little longer and in a different form is
for the good, though I must also acknowledge that I don't know how my
own work group is going to get that work done, either.

If we can't keep our people and our companies interested, we're going to
be stuck with one unambiguous standard: what runs successfully on NT on
the architecture whose name I prefer to leave unuttered...  I think that
would be for the worse, and I hope I would feel that way even if it were
our architecture that were the common reference.

--
scott preece
motorola/mcg urbana design center	1101 e. university, urbana, il   61801
uucp:	uunet!uiucuxc!udc!preece,	 arpa:	preece@urbana.mcd.mot.com
phone:	217-384-8589			  fax:	217-384-8550


Volume-Number: Volume 30, Number 17
From: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.7b: Software Administration
Date: 10 Jan 1993 04:32:45 -0800
Organization: Naval Research Laboratory, DC
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson)

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

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

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

Ran
atkinson@itd.nrl.navy.mil

Volume-Number: Volume 30, Number 23
From: carson@tron.UUCP (Dana Carson)
Newsgroups: comp.std.unix
Subject: extended ar
Date: 10 Jan 1993 03:48:29 -0800
Organization: Westinghouse Electric Corporation, Baltimore MD.
NNTP-Posting-Host: ftp.uu.net
Summary: long file names in ar
Keywords: ar
X-Submissions: std-unix@uunet.uu.net

Submitted-by: carson@tron.UUCP (Dana Carson)

   We need an extended ar that can handle file names > then 15
characters.  I've been somewhat following the POSIX effort but haven't
had the time to really track it in detail.  Have any changes been proposed
for ar in POSIX.2 (that sounds like the right place)?  If so I'd like to
stick with them so that we don't have to worry about it later, if not we
roll out own.

--
Dana Carson
Westinghouse Electronic Systems Group  Mail Stop 1615
net: carson@tron.bwi.wec.com
     ...!uunet!tron!carson
AT&T: (410) 765-3513
WIN:  285-3513

Volume-Number: Volume 30, Number 22
From: peter@ferranti.com (peter da silva)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.7b: Software Administration
Date: 4 Jan 1993 16:27:42 -0800
Organization: Xenix Support, FICC
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: peter@ferranti.com (peter da silva)

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

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

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

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

Volume-Number: Volume 30, Number 16
From: mgc@controls.ccd.harris.com (Mario Coronado)
Newsgroups: comp.std.unix
Subject: XPG3
Date: 10 Jan 1993 03:47:46 -0800
Organization: Harris Controls
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: mgc@controls.ccd.harris.com (Mario Coronado)

I would appreciate if anybody had any pointers or info about XPG3 and
the relation between POSIX and XPG3.

thanks

-- 
Mario G. Coronado
Harris Corporation

Volume-Number: Volume 30, Number 21
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.7b: Software Administration
Date: 11 Jan 1993 19:20:26 -0800
Organization: U.S. Army Research Lab, APG MD.
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)

In article <1ip51dINNp41@ftp.UU.NET> atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson) writes:
>  Doug Gwyn <gwyn@smoke.brl.mil> has been using such generalised batch
>software on UNIX systems.  I think his stuff might even be freely
>distributable.

Actually, the BRL Multiple-Device Queueing System was originally developed
some 10 years ago by Douglas P. Kingston III with assistance from Michael
J. Muuss.  When DPK moved on to greener pastures, as his last team leader
I inherited the maintenance responsibility for his software, and have kept
it up to date with bug fixes, portability enhancements, and support for a
variety of additional "devices" (some of which are actually interfaces to
services such as FTP, remote lpd, and remote MDQS).  The current release
is kept available for anonymous FTP on host FTP.ARL.ARMY.MIL (aka
FTP.BRL.MIL) as a compressed tar archive named arch/mdqs.tar.Z.  (Remember
to set BINARY transfer mode before fetching.)

The advantages of MDQS are that it supports multiple servers per queue,
and each server is expected to simply deliver the data to the "device"
using whatever protocol the device demands -- extra garbage should be
added before spooling the data.  There is no presumption that the
spooled data is text nor that the device is a printer, although there
is optional support for that mode of operation (banner pages, etc.)
There are some shell scripts included to emulate UNIX "lp" and "lpr"
interfaces (also QMS/Imagen's "ipr"); the "lpr" one is being overhauled
and a much improved emulation of modern "lpr"s should be available (in
an updated MDQS distribution) soon.

For further information, look in some really old USENIX Conference
Proceedings, or retrieve the MDQS distribution, unpack it, and read
the documentation (which includes the USENIX paper and an
administration/internals guide).

My personal opinion from having worked with/on MDQS for years is that
it is a good UNIXy spooling system that can and should be extended to
meet evolving requirements.  It covers pretty much the same functions
as the more common "lp" and "lpr" (lpd-based) spoolers and on several
of our systems it totally replaced them.  ("lpr"/lpd was resurrected
unnecessarily on some local systems when their system administrators
didn't know how to get some commercial software to work with MDQS.)


Volume-Number: Volume 30, Number 24
From: matt@iqsc.COM (Matt Reedy)
Newsgroups: comp.std.unix
Subject: Posix compliance (application)
Date: 10 Jan 1993 03:47:02 -0800
Organization: IQ Software Corp.
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: matt@iqsc.COM (Matt Reedy)

Where may I obtain information about certifying that my *application* is
POSIX compliant?  I know about the NIST, X/Open and AT&T conformance suites, 
but as I read about those, I surmise that they are geared to *operating system*
compliance as opposed to application compliance.  Can someone assist me?
Thanks in advance.

-- 
Matthew Reedy                 UUCP: uunet!iquery!matt
IQ Software Corporation       Internet: matt@iqsc.COM
400 N Loop 1604 E, Suite 100
San Antonio, TX  78232        (512) 490 6684  Fax: (512) 490-3590

Volume-Number: Volume 30, Number 20
Xref: sparky comp.std.misc:168 comp.dcom.modems:19074
From: andrew@alice.att.com (Andrew Hume)
Newsgroups: comp.std.misc
Subject: iso 9000-3
Date: 10 Jan 93 14:49:22 GMT
Organization: AT&T Bell Laboratories, Murray Hill NJ


	I am talking to some folks within AT&T about what
compliance to ISO 9000-3 entails. This is a standard that (roughly)
specifies various aspects of industrial strength software
development processes. there are a few concepts i would like
to clarify with anyone who is at least somewhat experienced
with ISO 9000-3. could any such folks please email me at
andrew@research.att.com?

	thanks,
		andrew
Newsgroups: comp.std.misc,comp.dcom.modems