HDTenEightyP/NetNews huggingface dataset:
From: G.Eustace@massey.ac.nz (Glen Eustace)
Subject: Re: Ultrix vesion of 4.3 syslog - background
Organization: Massey University, Palmerston North, New Zealand
X-Reader: NETNEWS/PC Version 2c
Date: Wed, 23 Dec 92 21:07:12 GMT

Thanks to all those who have pointed me in the right direction re:
archive sites.

This request was the beginning of trying to solve a problem on a
DECStation 5000/240.  This machine will be running as a server in a
locked room at a remote site.  I want to ensure that when it is
checked ( infrequently ) we know about all interesting activity.

I want to be able to put a printer on one of the serial ports and log
all console activity, both at boot time and in the 'X console msgs
window'.  The response from DEC at this stage is that this can't be
done :-(

I also wanted all messages of importance to be sent to a central
server in the hope that one of our operators will notice and act on
anything of consequence.  Hence my desire to get 4.3 syslogd working.

If any one has any suggestions or has done something similiar I would
be interested in your comments.

Thanks.


-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Glen Eustace, Systems Software Manager | EMail: G.Eustace@massey.ac.nz
Computing Services, Massey University, | Phone:         +64 6 350 5161
Palmerston North,  New Zealand. GMT-12 | Fax:           +64 6 350 5607

Newsgroups: comp.unix.ultrix
From: frank@croton.nyo.dec.com (Frank Wortner)
Subject: Re: Unix freeware CD-ROMs
Reply-To: frank@nyo.dec.com
Organization: Digital Equipment Corporation
Date: Thu, 31 Dec 1992 14:24:54 GMT


In article <wilko.725752354@spoetnix.idca.tds.philips.nl>, wilko@russia.idca.tds.philips.nl (Wilko Bulte) writes:
mjr.
|>
|>Hmm, government apparantly never heard the word 'data network' ;-)
|>

A story:

	During a Senate hearing, a proposed new high speed network was refered
to as a "data highway."  One Senator, not impressed by the need for such a
facility said, "Why do we need a data highway when we have a perfectly good
concrete one?"

	Now you know why "the government" continues to establish and promote
regulations that fly in the face of common sense.

					Happy New Year!

					Frank
From: tsien_r@wums.wustl.edu
Newsgroups: comp.unix.ultrix
Subject: popper1.831 on ultrix 42.a help/info
Date: 22 DEC 92 10:04:39 GMT
Organization: MIT PLASMA FUSION CENTER
NNTP-Posting-Host: msnews.wustl.edu

hi ultrix gurus:
i am having some porblems installing popper 1.831 onto an ultrix4.2a sys
if popper does not work on ultrix 4.2a, then info on alternative software

any help/info/advice is greatly appreciated!

thanks in adance ! ahppy holidays!

randolph tsien
washington university in st. louis
pharmacology
tsien@pharmdec.wustl.edu
tsien_r@wums.wustl.edu

p.s. please email me as i do not check this bulletin very often..thanks
.
Newsgroups: comp.unix.ultrix
From: sci213v@monu6.cc.monash.edu.au (Mr P Freeman)
Subject: Dump parameters for TZK10 tape drive
Keywords: dump parameters, TZK10
Organization: Monash University, Melb., Australia.
Date: Wed, 30 Dec 1992 23:58:07 GMT

I am interested to know what parameters to pass to the dump command (on
Ultrix 4.2) so that it has the correct info regarding tape length, density,
etc for the TZK10 tape drive when using 150, 250, 320 and 525 Megabyte tapes.

Any help would be appreciated.

Regards,

Paul Freeman
Email: sci213v@monu6.cc.monash.edu.au
From: iglesias@draco.acs.uci.edu (Mike Iglesias)
Subject: Re: sendmail.cf which handles bitnet
Newsgroups: comp.unix.ultrix
Organization: University of California, Irvine
Date: 26 Dec 92 16:00:20 GMT

In article <1hfadeINNdfn@msuinfo.cl.msu.edu> fox@rudolf.nscl.msu.edu (Ron Fox) writes:
>  Does anybody have or know of a modified version of DEC's sendmail.cf
>file which can also deal properly with the .bitnet domain via CUNYVM
>or any other gateway?  I'm running ultrix 4.3  The config file should also
>properly handle MAIL-11 and all the other .xxxx domains.

Add a line like this in the machine-dependent part of ruleset 0 (make
sure to use tabs for whitespace):

R$*<@$+.BITNET>$*	$#tcp$@bitnet.gateway.here$:$1<@$2.BITNET>$3	BITNET

Replace "bitnet.gateway.here" with the name of a nearby BITNET<->Internet
gateway, like cunyvm.cuny.edu.


Mike Iglesias                        Internet:    iglesias@draco.acs.uci.edu
University of California, Irvine     BITNET:      iglesias@uci
Office of Academic Computing         uucp:        ...!ucbvax!ucivax!iglesias
Distributed Computing Support        phone:       (714) 856-6926
Newsgroups: comp.unix.ultrix
From: osyjm@cs.montana.edu (Jaye Mathisen)
Subject: Re: Rlogin vs telnet puzzler
Organization: CS
Date: Tue, 29 Dec 1992 19:45:12 GMT

In article <1992Dec29.193912.18402@coe.montana.edu> osyjm@cs.montana.edu (Jaye Mathisen) writes:
>
>
>DS5000/240, Ultrix 4.3.
>
>Under what circumstances should a rlogin return 'Host unknown', but
>telnet "Do the right thing?".
>
>A professor here is trying to get to inel for some work.
>
>schizo:~ % rlogin inel.gov
>inel.gov: Host is unreachable

And if I wouldn't put words in to the error messages, transliterating
unknown into unreachable, I would be a lot better off :).

Egads, this is irritating.
-- 
 Jaye Mathisen, COE Systems Manager                (406) 994-4780
 410 Roberts Hall,Dept. of Computer Science
 Montana State University,Bozeman MT 59717	osyjm@cs.montana.edu
Newsgroups: comp.unix.ultrix
From: anthony@yarra-glen.aaii.oz.au (Anthony Baxter)
Subject: Re: RPC can't encode arguments
Organization: Australian Artificial Intelligence Institute
Date: Fri, 25 Dec 1992 13:07:17 GMT

envbvs@epb11.lbl.gov (Brian V. Smith) writes:

>|> Out of the blue one of our Vaxstation II's running Ultrix 4.2 is printing the
>|> following message on the console:  RPC: can't encode arguments.
>|> 
>|> It is not going into the syserr log file, just on the screen.
>|> I tried rebooting to no avail.  Is there any way to know which program
>|> is causing this and why?


We found this was caused by a Sun on the same network bombing the decstation
with lockd packets. We do a tcpdump (or etherfind) to find which one is
doing it, then kill the lockd and restart it (on the sun.) It's possible
that one of the sun patches fixes this problem, I just havent got around to
applying them yet.


Anthony
-- 
 anthony baxter                 australian artificial intelligence institute
email : anthony@aaii.oz.au         1 grattan st, carlton, australia 3053
    /\/\||                                 phone : +613 663 7922
From: meilak@qut.edu.au
Newsgroups: comp.unix.ultrix
Subject: 4.3 syslog problem
Date: 22 Dec 92 11:48:40 EST
Organization: Queensland University of Technology

Hi people,

I have been setting up a DEC5000/133 workstation that came with 4.3 Ultrix
installed on it and have gotten stuck with trying to get syslog to work on it. 

The problem is that nothing gets written to the file /var/spool/mqueue/syslog.

Syslog works fine on our 4.2A machines. I have checked file permissions and
the format of syslog.conf. And tried the -d flag to syslog. The only thing left
for me to try is to copy a 4.2A binary accross and see if that works.

Unfortunately, no notes/doc came with the machine on 4.3 bugs/updates on 4.2.

Is this a bug or have I stuffed the installation?

Thanks in Advance

bjm
From: perf@efd.lth.se (Per Foreby)
Newsgroups: comp.unix.ultrix
Subject: uncodumented config options
Date: 21 Dec 92 12:33:38 GMT
Reply-To: perf@efd.lth.se (Per Foreby)
Organization: Lund Institute of Technology

The "Configuration File Maintenance" manual specifies far from all the
options and pseudo-devices. Maybe DEC doesn't think that we are supposed
to know about them. Does anyone have a complete list or at least an 
explanation of the ones I've found which aren't in the manual:

options         BINARY
options         NETMAN
options         CDFS
pseudo-device   netman
pseudo-device   fddi
pseudo-device   sl
pseudo-device   xcons
pseudo-device   ws
pseudo-device   tc
pseudo-device   tb
pseudo-device   pcm
pseudo-device   gwscreen
pseudo-device   cdfs
pseudo-device   msdup
pseudo-device   xisoftdev

-- 
Per Foreby (perf@efd.lth.se)
System manager @ EFD, Lund Institute of Technology
Snailmail: DDG, Maildelivery 7, PO BOX 118, S-221 00 LUND, SWEDEN
Phone: +46 46 107492, Fax: +46 46 104013
From: kchiles@olympic.llnl.gov (Keith Chiles)
Newsgroups: comp.unix.ultrix
Subject: 4.3 and shared modems
Date: 21 Dec 92 16:43:55 GMT
Reply-To: kchiles@olympic.llnl.gov (Keith Chiles)
Organization: Digital Equipment Corporation

HOHOHO Netland,

For those who might be affected by this, I have found an 
interesting feature in Ultrix 4.3 that kindly resets the 
kernel when you exit a tip session.  In fact it works with 
several packages as they hang up a shared modem line.
The way it seems to work is that if you have a 5000/125
or a 5000/25, and you are using tip with a modem configured
as being shared, when the modem hangs up the line it
lets the kernel shut down (Just ignore those old panic 
messages, the're not important anyway) and allows you
to boot a new kernel from the >> prompt.  This is much
better than 4.2's old method of just hanging up the line
and going on with things.

The workaround is to avoid shared modem use.  I was just
wondering if anyone else was encountering this problem 
and if you are, you might not want to spend a whole lot
of time trying to figure out what you are doing wrong.
If you are considering going up to 4.3, you might want 
to move carefully and with real neat 4.2 backups if you 
are working with a communications front-end. I also hear
this feature works for uucp.

Cheers, Keith
kchiles@arac.llnl.gov
From: vaisanen@joyds2.joensuu.fi (Jarmo Vaisanen)
Newsgroups: comp.unix.ultrix
Subject: Re: Unix freeware CD-ROMs & 'Cryptography War'
Date: 31 Dec 92 08:24:09 GMT
Reply-To: vaisanen@joyds2.joensuu.fi (Jarmo Vaisanen)
Organization: University of Joensuu, Computer Center

In article <wilko.725752354@spoetnix.idca.tds.philips.nl>, wilko@russia.idca.tds.philips.nl (Wilko Bulte) writes:
|>mjr@TIS.COM (Marcus J. Ranum) writes:
|>>	Government hassle, not legal hassle. The EFCDROM had the sources
|>>for "crack", which included a fast DES implementation. Unfortunately,
|>>that made the EFCDROM a munition and unexportable. I believe that another
|>>version without the deadly weaponry ;) was pressed.
|>
|>Hmm, government apparantly never heard the word 'data network' ;-)
|>
|>Wilko

I really hope that President Clinton (or Gore) would do something
to end this silly 'cryptograhy war' between USA and the rest of
World :-}

-----------------------------------------------------------------------
Jarmo Vaisanen          vaisanen@joyds2.Joensuu.FI      (Internet)
University of Joensuu   JVAISANEN@FINUJO                (EARN, BITNET)
Computer Center
From: wilko@russia.idca.tds.philips.nl (Wilko Bulte)
Newsgroups: comp.unix.ultrix
Subject: Re: Unix freeware CD-ROMs
Date: 30 Dec 92 21:52:34 GMT

mjr@TIS.COM (Marcus J. Ranum) writes:

>wilko@russia.idca.tds.philips.nl (Wilko Bulte) writes:
>>To the best of my knowledge the distribution of the European Freeware CDROM
>>was stopped because of some legal hassle.

>	Government hassle, not legal hassle. The EFCDROM had the sources
>for "crack", which included a fast DES implementation. Unfortunately,
>that made the EFCDROM a munition and unexportable. I believe that another
>version without the deadly weaponry ;) was pressed.

>mjr.

Hmm, government apparantly never heard the word 'data network' ;-)

Wilko


--
 |   / o / /  _   Wilko Bulte               Domain: wilko@idca.tds.philips.nl
 |/|/ / / /( (_)  EasyNet: HLDE01::BULTE_W  uucp  : [mcsun,sun4nl]!philapd!wilko
|d|i|g|i|t|a|l|  Equipment  Enterprise  -  IISS/SE   voice: +3155-432372
fax: +3155-432103 DTN: 829 2372 PO Box 245 - 7300 AE Apeldoorn - The Netherlands
Newsgroups: comp.unix.ultrix
From: alan@nabeth.cxo.dec.com (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
Subject: Re: Some buffer cache questions
Reply-To: alan@nabeth.cxo.dec.com (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
Organization: Digital Equipment Corporation
Date: Wed, 30 Dec 1992 01:03:15 GMT


In article <1992Dec29.224612.14664@pony.Ingres.COM>, rog@Ingres.COM (Roger Taranto) writes:
>
>In article <1992Dec23.205149.2489@nntpd2.cxo.dec.com> alan@nabeth.enet.dec.com (Alan Rollow - Alan's Home for Wayward Tumbleweeds.) writes:
>>[ I mention large buffer caches and delay_wbuffers ]
>
>So, what am I supposed to be watching the delay_wbuffers for?
>

This is a variable in param.c that has two values, zero and non-zero.
The default is zero.  When set to zero the buffer cache code schedules
data writes as buffer are filled by the user.  These writes are
asynchronous.  When set to non-zero data buffers are only written
when explicitly flushed (fsync(2), sync(2), etc) or a buffer is
needed to satisfy a read and a dirty one is written to free up a buffer.

An affect of having delay_wbuffers set to a non-zero value is that
the cache will fill up between update's calls to sync(2) and then
every so often there will be a flurry of writes as all the dirty
buffer are flushed.  Another affect is that the cache may have a
lot of stale data sitting around in the cache between syncs, the
classic UNIX buffer cache problem.

For small caches this may be an interesting problem.  As you
increase the size of the cache there's the potential for more
stale data to be lost or more dirty that needs to be written
out.  The "flurry" of writes can look like blizzard with a
big enough cache.

Related to this thread, Greg Pavlov at karloff.fstrf.org asked
what sort of trouble I had with large cache configurations.  The
very large cache configuration I had was a 80% of 256 MB on a
DECsystem 5800.  I believe it was a single CPU system.  Whether
it was an ULTRIX bug of the time, a 5800 specific problem or the
version of the Striping driver I was working on the time, the
system hung during one of my BIG cache flushes.  I had turned
off update and wanted to see how long it took to flush the
entire cache, after having filled it.  I wasn't able to reproduce
the hang.  I also vaguely recall having to come up with some
creative configuration lies to get a big enough system page
table to map a cache that big.

FWIW: The BIG cache flush probably took around 100 seconds.  I was
writing to a stripe set of RA90s all on an HSC70.  I was keeping the
HSC and CIBCA-BA VERY busy...  I'd love to try it on a VAX with a
CIXCD and two HSCs sometime...

>-Roger
>rog@ingres.com
>
--
Alan Rollow				alan@nabeth.cxo.dec.com

Newsgroups: comp.unix.ultrix
From: john@iastate.edu (John Hascall)
Subject: fstat bogosity
Organization: Iowa State University, Ames, IA
Date: Fri, 1 Jan 1993 17:37:57 GMT

Well, if anyone at DEC still cares about Ultrix (V4.2a in our case), the man
page for fstat() says:

     Restrictions
          Applying fstat to a socket returns a zeroed buffer and [EOPNOT-
          SUPP].

It appears to be the case that fstat(sockFD, &stbuf) is not returning an error,
and in the case of a TCP socket (AF_INET, SOCK_STREAM) it appears that
stbuf.st_blksize is being filed in with the socket MaxSegSiz value.

I also don't see why it would be so much trouble to fill in .st_mode = S_IFSOCK
either.

John
#include <std/gripe/noUsenetSPR.h>
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systmes Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551
Newsgroups: comp.unix.ultrix
From: roland@quadsys.com (Roland Besserer)
Subject: ULTRIX 4.3 vs 4.2A
Organization: QUAD Systems
X-Newsreader: Tin 1.1 PL3
Date: Fri, 1 Jan 1993 03:51:07 GMT


I'm still running 4.2A on my 5000/200 and my company also runs 4.2A
on all their 5000/125s. I was wondering what exactly the differences
are between 4.2A and 4.3 and if upgrading will be worthwhile?

-- 

Roland Besserer
QUAD Systems
roland@quadsys.com
Newsgroups: comp.unix.ultrix
From: btaylor@mcl.bdm.com (Brent Taylor)
Subject: Ultrix 4.3 & DECnet/OSI 5.1 bug
Date: Wed, 30 Dec 92 16:54:39 GMT
Organization: BDM International, Inc.

There is a bug in DECnet/OSI version 5.1 when used with Ultrix 4.3. The
problem exists with the 'net_common.o' file in your BINARY directory. It
effects the multicasting logic so that dns clerks will not be able to
locate their servers.

You need a copy of the corrected 'net_common.o' file from DEC. Replace this
file and recompile the kernel. This seems to solve the problem.
Newsgroups: comp.unix.ultrix
From: streater@unixhub.SLAC.Stanford.EDU (Tim Streater)
Subject: Ultrix 4.2C dxmail wrapping problem
Organization: Stanford Linear Accelerator Center
Date: Wed, 30 Dec 1992 02:45:37 GMT

A while ago someone posted how to set things so that if I am sending a new mail
item, then as I type in the window it wraps at the right hand edge instead of
disappearing off the right hand edge. I did set this but need reminding where
it was that I set it (sorry!).

The wrapping works fine but it also does it in the To: line, with the result
that when I click the "Send" button in the window, the mail soon returns with
the complaint that it found a newline in the To: line. The wrapping is working
too well, in other words. How can I prevent this and keep the wrapping in the
body of the mail item?

Finally - is there a way to have create and use nicknames with dxmail - or even
name-lists so I don't have to type the same list of names over and over again?

Thanks - tim.
Newsgroups: comp.unix.ultrix
From: rosenth@vision.ethz.ch (Lukas Rosenthaler)
Subject: mapping file to memory with mmap ???
Summary: How to map a file into memory
Keywords: memory management mapping
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Mon, 21 Dec 1992 20:54:09 GMT

Hello,
I have a small problem porting VAX/VMS applications to Ultrix and other
unixes. The guy who wrote the VMS code used the method of "mapping" a file
directly into memory and thus using the page mechanism for I/O. This is very
efficient and fast (- even on a VAX :-)  ) On some flavors of Unix (say
Convex and Irix), there is a system call "mmap(...)" which does exactly the
same. Also Ultrix knows "mmap", but it seems to work only with a file
descriptor of a character device and therefore not suitable to map a regular
file into memory. Any suggestions ???

Any help will be appreciated !

Please followup or send mail to "rosenth@comp.bioz.unibas.ch"

Thanks all,

	Lukas Rosenthaler
	Biocomputing
	Biocenter of the University of Basel
	Switzerland


The appropriate seasonal greetings apply !!
From: iversen@dsfys1.fi.uib.no (Per Steinar Iversen)
Newsgroups: comp.unix.ultrix
Subject: Re: TPU for Ultrix?
Date: 21 Dec 92 07:22:16 GMT
Reply-To: iversen@vsfys1.fi.uib.no
Organization: Department of Physics, University of Bergen, Norway


In article <1992Dec21.082624.1@phcu.helsinki.fi>, aalto@phcu.helsinki.fi (Erkki '\\rkki' Aalto, University of Helsinki) writes:

>Has anyone any experience on DEC's tpu-editor for Ultrix? We have been using
>nu/TPU, but the old version is buggy and the new one is completely impossible.
>Is DEC's editor good? Will it be available for Alpha/OSF/1, too?
>
>Erkki Aalto
>
>University of Helsinki
>
>FINLAND
>

I have used it for some time. It is very nice and even compiled my custom VMS
EVE extensions with no problems. My only gripe is that it is a bit slow loading
the section file on my DECstation 5000/200, so for small edits I prefer vi - 
this is however much the same as under VMS where I prefer EDIT/EDT for quick
editing session.

DECtpu is certainly the best editor I have used on any Unix system so far...

-psi

+------------------------------------------------------------------------------+
! Per Steinar Iversen    ! Internet:     iversen@vsfys1.fi.uib.no              !
! Fysisk Institutt       ! BITnet:       iversen@cernvm.bitnet                 !
! Universitetet i Bergen ! HEPnet:       VSFYS::IVERSEN (VSFYS=21.341=21845)   !
! Allegaten 55           ! Phone:       +47 5212770                            !
! N-5007 Bergen          ! Fax:         +47 5318334                            !
! NORWAY                 !                                                     !
+------------------------------------------------------------------------------+
Newsgroups: comp.unix.ultrix
From: anthony@yarra-glen.aaii.oz.au (Anthony Baxter)
Subject: Re: Traceroute
Organization: Australian Artificial Intelligence Institute
Date: Sun, 27 Dec 1992 11:28:13 GMT

eec@po.CWRU.Edu (Edward E. Conroy) writes:


>I downloaded a programme called 'traceroute' to allow me to trace
>network connexions and gain information about them. The distri-
>bution contained references to a necessary kernel modification.
>Has anyone done this already? I'm running Ultrix my4.3 on
>a DECStation 5000. Any help would be appreciated.

Try installing the UDXINET430 (TCP/IP Networking Util Extension) subset - 
it has traceroute in it, and it works fine. UDXMAN430 has the manual page 
for traceroute in it.

Anthony
-- 
 anthony baxter                 australian artificial intelligence institute
email : anthony@aaii.oz.au         1 grattan st, carlton, australia 3053
    /\/\||                                 phone : +613 663 7922
Newsgroups: comp.unix.ultrix
From: ccksb@trentu.ca (Ken Brown)
Subject: talk - waiting for invitation on caller's machine
Organization: Trent University, Ontario
Date: Fri, 1 Jan 1993 20:02:12 GMT


Probably a simple answer exists for this.

When initiating a `talk' I find that I get a connection and then;

[Waiting for invitation on Caller's machine]

I don't quite understand this.  Aren't I the caller and haven't I issued
an invitation by initiating a talk session?  Can anyone explain this and
offer a solution so that talk functions?  If this is a faq, maybe
someone will point me to the correct docs.  Thanks in advance...
-- 
Ken Brown                                   internet: kbrown@trentu.ca
Trent University Computing & Telecommunications  tel: (705)748-1540
Peterborough, Ontario, Canada, K9J 7B8           fax: (705)748-1246
From: iglesias@draco.acs.uci.edu (Mike Iglesias)
Subject: Re: Rlogin vs telnet puzzler
Newsgroups: comp.unix.ultrix
Organization: University of California, Irvine
Date: 29 Dec 92 20:53:08 GMT

In article <1992Dec29.193912.18402@coe.montana.edu> osyjm@cs.montana.edu (Jaye Mathisen) writes:
>A professor here is trying to get to inel for some work.
>
>schizo:~ % rlogin inel.gov
>inel.gov: Host is unreachable
>
>I can't think of anything on my end that would do such a thing, so maybe
>it's on their end.  Perhaps a gateway that only allows connections on certain 
>ports?  ie, it blocks connections to 513, but allows connections to 23?

The last gateway before inel.gov is returning host unreachable for rlogins,
so it's a pretty safe bet they are blocking rlogin to that system.  tcpdump
and traceroute are useful utilities for figuring out problems like this.


Mike Iglesias                        Internet:    iglesias@draco.acs.uci.edu
University of California, Irvine     BITNET:      iglesias@uci
Office of Academic Computing         uucp:        ...!ucbvax!ucivax!iglesias
Distributed Computing Support        phone:       (714) 856-6926