HDTenEightyP/NetNews huggingface dataset:
From: alan@nabeth.enet.dec.com (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
Subject: Re: Upgrading to 65+ users
Reply-To: alan@nabeth.enet.dec.com (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
Organization: Digital Equipment Corporation
Date: Thu, 20 Aug 1992 03:57:16 GMT



In article <10958@platypus.uofs.uofs.edu>, bill@prijat.cs.uofs.edu (Bill Gunshannon) writes:
>
> [ The customer asks how to install a user upgrade from tape. ]
>

There's not a manual page for it on my system (V4.2), but I think
you use /etc/install_upgrade.  If I remember correctly the upgrade
is a tar(5) archive with one file on it; /upgrade.  After the days
of getting a different machdep.o and before LMF, this file would be
read by something called from /etc/rc when the system went multi-user
and it would perform whatever magic was required to put the user
limit in place.

With LMF I believe some part of LMF looks for the file and fakes up
a LMF database entry based on the upgrade file.

>bill
>
>-- 
>     Bill Gunshannon  
--
Alan Rollow				alan@nabeth.cxo.dec.com



Newsgroups: comp.sys.dec
From: evansg@uproar.enet.dec.com (Gwyn Evans @ IME)
Subject: Re: Alpha benchmarks
Keywords: alpha, benchmarks
Reply-To: evansg@uproar.enet.dec.com (Gwyn Evans @ IME)
Organization: Digital Equipment Service Industries Solutions Company Ltd
Date: Thu, 13 Aug 1992 09:31:21 GMT


In article <1992Aug12.160844.2486@nosc.mil>, lem@nosc.mil (Lemuel L. Davis)
writes:
>Has anyone run or had DEC run any becnhmarks on Alpha systems? 

    I was under the inpression that the users of Alpha porting machines
had to sign agreements that they would _not_ run any benchmarks, as the
machines that were being shipped were not representitive of the final
configuration. Things such as compilers & microcode being optimised for
ease of debugging, the OS & libraries built with debug, etc, etc.
    Human nature being what it is, I'd expect that your benchmarks come
from such a machine. Would you care to post the details, i.e. where and
who they come from and what tests were run?

Gwyn
--
+======================================================================+
| Gwyn Evans  | evansg@uproar.enet.dec.com |  Uxbridge, Middlesex, UK  |
| DESISCo - Digital Equipment Service Industries Solutions Company Ltd |
|  Views expressed and statements made are mine and not those of DEC   |
+======================================================================+
Newsgroups: comp.sys.dec
From: schneck@Physik.TU-Muenchen.DE (Bernhard Schneck)
Subject: Re: floppy drive rx26 on a personal decstation?
Organization: Leibniz-Rechenzentrum, Muenchen (Germany)
Date: Thu, 13 Aug 1992 20:15:49 GMT

>>My guess is that when I pop in one of the two disks they provide you with
>>that you have to use newfs to format the disk, and then use mount to get to

You can also use the "mtools" package posted do comp.sources.misc some
time ago to read/write ms-dumb format floppies in the DEC.  This also
saves you some headache with special files and suid progs on the disk.

\Bernhard.
--
Bernhard Schneck              | Email: Bernhard.Schneck@Physik.TU-Muenchen.DE
GeNUA Gesellschaft fuer Netz- | TU Muenchen Physik | There is no problem so big
und UNIX-Administration mbH   | 8046 Garching      | that it cannot be run away
8000 Muenchen 83, Germany     | Germany            | from.   Illusions, R. Bach
Newsgroups: comp.sys.dec
From: aj681@cleveland.Freenet.Edu (Carlin Wiegner)
Subject: MicroVAX I or II wanted! 
Organization: Case Western Reserve University, Cleveland, Ohio, (USA)
Date: Sat, 15 Aug 92 18:45:29 GMT


If you have a MicroVAX I or II for sale please respond but only
if you want under $800... Thanks...
CW
P.S. Please email responses...
CW
-- 
Carlin Wiegner a.k.a. C-Man based here in Cleveland, Ohio, USA!
aj681@cleveland.freenet.edu or rhino@r2d2.eeap.cwru.edu
"Anything less [than a NeXT] would be uncivilized..."
From: young@eg.ecn.purdue.edu (Mike Young)
Newsgroups: comp.sys.dec
Subject: Re: ACP stuff now available via FTP
Date: 20 Aug 92 13:54:10 GMT
Organization: Purdue University Engineering Computer Network

In article <59010004@acf3.NYU.EDU> tihor@acf3.NYU.EDU (Stephen Tihor) writes:
	>You didn;t seem to indicate where.

	Sorry, I thought I did. Anonymous FTP to en.ecn.purdue.edu
	(128.46.128.59), in directory pdp11.



--
    |  Mike Young KA9HZE                |       young@ecn.purdue.edu    |
    |  Purdue University EE Dept.       |       ...!pur-ee!young        |
    |  W. Lafayette, IN  47907          |                               |
    _____________________________________________________________________
Xref: sparky comp.sys.dec:4536 comp.os.vms:13648
From: brydon@asl.slb.com (Harvey Brydon (918)250-4312)
Newsgroups: comp.sys.dec,comp.os.vms
Subject: Re: DUPLICATING TA90s ???
Date: 14 Aug 92 12:15:09 GMT
Reply-To: brydon@asl.slb.com
Organization: Schlumberger/Anadrill Sugar Land, TX

In article <1992Aug11.123646.20532@ultb.isc.rit.edu>, ecldco@ultb.isc.rit.edu
(E.C. Loyd) writes:
>[lots of stuff relating to copying TA90s deleted]
>>A warning! It is important to note that when you copy tapes, 
>>error blocks may appear/disappear. If you are copying VMS BACKUP 
>>savesets, it is extremely important that you leave on the CRC 
>>checking and redundancy grouping capabilities of VMS BACKUP. 
>>Otherwise, there is a distinct chance that your saveset may get 
>>corrupted. 
>
>But what we here at RIT would like to do it copy, bit-for-bit, one tape to
>another tape.  There would be no loss of data in this fashion.

There is a backup qualifier called /INTERCHANGE that changes the
characteristiics of error block recovery on tape [I think a 'small' blocksize
such as 8192 might have to be specified as well - (?)].  Both /INTERCHANGE and
/BLOCK=8192 are specified on VMSINSTAL savesets for example, which allows you
to use the COPY command between disk/tape, disk/disk and tape/tape.

I think the answer is that if you have tapes that you want copied that don't
meet the above criteria, you are out of luck in terms of reliable data
transfer.  You might be able to play games with them to get partial recovery,
but I wouldn't want to depend on the results.
____________________________________________________________________________
Harvey Brydon         | Internet:   brydon@dsn.SINet.slb.com
Dowell Schlumberger   | P.O.T.S.:   (918)250-4312
  ...then there was the Aggie that won a gold medal and had it bronzed.
From: terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.)
Newsgroups: comp.sys.dec
Subject: Re: How to read/write VMS (RMS?) disk blocks asynchronously
Date: 12 Aug 92 16:12:43 GMT
Organization: St. Peter's College, US

In article <MRL.92Aug11103051@sun4.uai.com>, mrl@uai.com (Mark R. Ludwig) writes:
> I've read much of the RMS Reference, and concluded that the
> asynchronous support there is quite limited, because it only allows
> one operation at a time (on a FAB, or RAB, I forget exactly which).
> For our application it is not feasible to have multiple FABs or RABs
> for a single file.

  Look at the read-ahead and write-behind options and the multibuffer count.
In VAX C you can specify these options in the fopen() statement as rah=n,
wbh=n, mbf=n. These must exist in RMS, rather than being C-specific. Try
looking in the Master Index for these items.

	Terry Kennedy		Operations Manager, Academic Computing
	terry@spcvxa.bitnet	St. Peter's College, Jersey City, NJ USA
	terry@spcvxa.spc.edu	+1 201 915 9381
Newsgroups: comp.sys.dec
From: dierick@brsux0.bro.dec.com (Dierick Dominique)
Subject: Re: Bug in PostScript Previewer: dxpsview
Reply-To: dierick@ketje.enet.dec.com
Organization: Digital Equipment Corporation, Brussels
Date: Fri, 21 Aug 1992 07:47:48 GMT


In article <1992Aug21.035749.18907@walter.bellcore.com>, hsong@ardour.bellcore.com (G. Hugh Song) writes:
>Newsgroups: comp.sys.dec
>From: hsong@ardour.bellcore.com (G. Hugh Song)
>Subject: Bug in PostScript Previewer: dxpsview
>
>It has been a long time since I visited this newsgroup.  I am using
>Ultrix 4.0 on DS5000/200.  It has been known that dxpsview on this 
>machine has a bug which seems to make conflicts with X windows.
>Also, I have to choose the last row in the option menu before I start
>anything.  That option is something like "follow action" which has no
>meaning since I cannot even start dxpsview without choosing it.
>
>Has there been a better solution for this bug?
>
>Thank you.
>
>	Hugh
>	hsong@ardour.bellcore.com
>

The latest, greatest Motif 1.1.3 for Ultrix 4.2 contains an improved
document viewer dxvdoc which imho is more interesting then dxpsview.


Dominique Dierick
Newsgroups: comp.sys.dec
From: alan@wam.umd.edu (Alan J. Schunemann)
Subject: What's the difference between a 5000/200 and a 5000/120?
Originator: alan@rac2.wam.umd.edu
Organization: University of Maryland at College Park
Date: Thu, 13 Aug 1992 13:00:26 GMT

Thanks!
-- 
_________________________________________________________________
Alan Schunemann       "Well, what shall we throw away this year?"
alan@wam.umd.edu      -Andrew Carnegie
Newsgroups: comp.sys.dec,comp.windows.x
From: mosedale@genome.stanford.edu (Dan Mosedale)
Subject: VXT 2000 X terminal: user-level authentication?
Organization: Stanford Yeast Genome Project
Date: Fri, 21 Aug 92 17:35:56 GMT

I'm trying to convince some DEC VXT 2000 X terminals to give me
user-level authentication (i.e. MIT-MAGIC-COOKIE-1, or better yet,
XDM-AUTHORIZATION-1).

I'm using the VXT 1.1 software, which seems to say that it can't be
done.  However, doing a 'strings' on the server binary turns up
strings such as 'MIT-MAGIC-COOKIE-1' and 'XDM-AUTHORIZATION-1',
implying that the code is, in fact, there.

I am assuming what's happening is that the VXT is disabling security by
sending empty Authentication Name and Authentication Data fields in
its XDMCP Request packet, though I don't know that this is the case.

Interestingly enough, my .Xauthority does get a new magic-cookie upon
each login, but the X display is clearly only paying attention to
xhost level stuff.

Any clues on how to make this work would be much appreciated.

Dan Mosedale
mosedale@genome.stanford.edu
From: ivie@cc.usu.edu (CP/M lives!)
Newsgroups: comp.sys.dec
Subject: Re: Running RZ55's on non-DEC machines?
Date: 12 Aug 92 09:11:40 MDT
Organization: Utah State University

In article <TYTSO.92Aug12010651@SOS.mit.edu>, tytso@athena.mit.edu (Theodore Y. Ts'o) writes:
> I've been told that the RZ55 will not work if you try connecting it to a
> SCSI card on a PC --- say, an Adaptec 1542B.  Is this true?  If so, can
> someone tell me why?
> 
> I tried hooking up a RZ55 to a Macintosh, and tried running the SCSI
> Manager on it.  It didn't work; nearly every operation it tried to do
> returned the Sense code error "Drive not ready".  Is there some sort of
> DEC proprietary command that the drive is expecting before it will
> start working?

No, it's expecting a standard SCSI command to spin up before it starts
working. Most everyone but DEC assumes the drive spins up at power on, so
they don't send the command.

Roger Ivie
ivie@cc.usu.edu
From: havemann_l@spcvxb.spc.edu
Newsgroups: comp.sys.dec
Subject: Re: VAX QUESTIONS FROM BEGINNER!
Date: 17 Aug 92 14:46:58 GMT
Organization: Lee Havemann, HSH Associates

In article <1992Aug15.091605.199@rlgsc.com>, gezelter@rlgsc.com writes:
> In article <1992Aug15.031519.27932@usenet.ins.cwru.edu>, aj681@cleveland.Freenet.Edu (Carlin Wiegner) writes:
>> 
>> I'm thinking of buying a used VAX -11/780 but I have a couple of
>> questions....
>> 
>> -- 
>> Carlin Wiegner a.k.a. C-Man based here in Cleveland, Ohio, USA!
>> aj681@cleveland.freenet.edu or rhino@r2d2.eeap.cwru.edu
>> "Anything less [than a NeXT] would be uncivilized..."
> -- 
> Carlin,
>  
> At the risk of depressing the market value of used 780s, I note 
> that unless you are getting power, air conditioning, and office 
> space for free, the 780 is extremely expensive relative to the 
> latest (or for that matter last 6!) generations of small vax 
> hardware. So, you may want to check into the cost of the small 
> VAXstation 4000/VLC.
>  
> - bob
> +--------------------------------------------------------------------------+
> | Robert "Bob" Gezelter                       E-Mail:  gezelter@rlgsc.com  |
> | Robert Gezelter Software Consultant         Voice:   +1 718 463 1079     |
> | 35-20 167th Street, Suite 215               Fax:       (on Request)      |
> | Flushing, New York  11358-1731                                           |
> | United States of America                                                 |
> +--------------------------------------------------------------------------+



You mean that there's a market value on a /780??  I thought people were 
giving them away as nautical stabilizers.. :-)



-- 

 Lee Havemann, Sys_op    HSH Associates          (201) 838-3330 
 Havemann_l@spcvxa.spc.edu      -      Havemann_l@spcvxa.bitnet
 "Any opinions expressed are not necessarily those of anyone else, 
  including myself."                     
Newsgroups: comp.sys.dec,comp.unix.ultrix
From: mjo@ef2007.efhd.ford.com (Mike O'Connor)
Subject: Stuff I can serve to conserve on disk space
Followup-To: comp.unix.ultrix
X-Disclaimer: Not an official spokesperson for Ford OPEO
Reply-To: Mike O'Connor <mjo@fmsrl7.srl.ford.com>
Organization: International Affairs, Overseas Engineering, "Fordz"
Date: Tue, 18 Aug 1992 13:24:45 GMT

I'll be getting a lot of DECstations clients running in a
non-DECnet/TCP-IP/X environment.  They'll be connecting to a DEC
"server" of some description and all will running the same version of
Ultrix (I hope :) ).  I'd like to pare down on the amount of disk
space that each client takes for the OS load.  Besides man pages, what
are other sorts of things that I can either:

	A.  Serve from my server
	B.  Probably get rid of

-- 
 Michael J. O'Connor           |  Internet:  mjo@fmsrl7.srl.ford.com
 Ford Motor Company, OPEO      |  UUCP:      ...!{backbone}!fmsrl7!mjo
 20000 Rotunda, Bldg. 1-3001   |  Phone:     +1 (313) 248-1260
 Dearborn, MI  48121           |  Fax:       +1 (313) 323-6277
Xref: sparky comp.sys.dec:4500 vmsnet.pdp-11:612 aus.general:1480
From: jerry@marin.uucp (Jerry C. Hudgins)
Newsgroups: comp.sys.dec,vmsnet.pdp-11,decus.pdp11,aus.general
Subject: Re: PDP-11 version of PASCAL wanted in OZ.
Distribution: world
X-NewsSoftware: GRn 1.16e (7/4/92) by Mike Schwartz & Michael B. Smith
Date: 13 Aug 92 01:36:49 EDT
Organization: Private Use

In article <1992Aug12.123633.3575@spcvxb.spc.edu> terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.) writes:
> In article <1992Aug11.231307.14379@decus.com.au>, geremin@decus.com.au writes:
> > 		I have had a request from a member in Tasmania who
> > needs a copy of a PASCAL compiler for either RSX or RSTS. 
> 
>   DEC once offered an RSX Pascal, but I don't know a lot about it.
> 
> > 		I have located a manual for Oregon PASCAL v1.2 
> > that was released for RSTS/E v7. and is dated circa 1980.
> 
>   Yup - that's Oregon Software's PASCAL. The latest version I'm aware of for
> RSTS is PASCAL2 V2.1E. This still runs on RSTS V10.x.
> 
>   They no longer sell or support it, although they might sell you a copy if
> you asked real nice 8-). I assume you have their address, since you have an
> old manual. Feel free to write if you need more info.
> 
> 	Terry Kennedy		Operations Manager, Academic Computing
> 	terry@spcvxa.bitnet	St. Peter's College, Jersey City, NJ USA
> 	terry@spcvxa.spc.edu	+1 201 915 9381

On RSX, the version number got at least as high as V2.1G.  This one was
shipped to me a few years ago under an update agreement, though I never got
around to performing the upgrade from V2.1F.  This was a decent, reliable
compiler - in complete contrast to Digital's Pascal for RSX.  That was the
buggiest piece of DEC software that I've personally worked with (and I had
a copy of RSTS/E BP2 V2.0, too).

-- 
----------------------------------------------------------------------------
Jerry C. Hudgins                   Internet: jerry%marin.uucp@seq.uncwil.edu
125 Cherokee Trail                 UUCP    : uunet!marin!jerry
Wilmington, NC 28409-3407 (USA)    Voice   : (919) 392-2358
From: t68@nikhefh.nikhef.nl (Jos Vermaseren)
Newsgroups: comp.sys.dec
Subject: question about files and C in VMS
Date: 20 Aug 92 15:55:57 GMT
Organization: Nikhef-H, Amsterdam (the Netherlands).


HELP!!!!!

I have a problem with C under VMS that has bothered me and many
others for a while. It has to do with filepositioning from C programs.
I have to port a C program to VMS and the program will read part of a
text file into a buffer. Then it may go to another part of the file
(or it may not) and at a later stage I want to reposition the file and
read the next so many bytes. Originally I got into problems because
the read command refused to read more than one line at a time.
According to the manual fread, fwrite, fseek and ftell emulate the
regular C file operations, so I started using those.
Problem: fseek refuses to position in the middle of a line.
Solution: read (for instance) 1024 bytes, skip back to the last
linefeed, recompute the position and do an fseek to this position.
Suddenly this does not work anymore. It appears that the file that is
to be used as input came by ftp and is not in the form of lines, but
in blocks of 80 characters, no matter what characters they are.
Example:
    fseek(handle,0,SEEK_CUR);   /* first time might be superfluous of course */
    ftell(handle);  --> 0
    fread(...,1024,...);
    fseek(handle,1023,SEEK_SET); /* we have to skip one back */
    ftell(handle);  --> 1120   ?????

    fseek(handle,1120,SEEK_SET);
    fread(...,1024,...);  This time it looses the line with 1024 in it.
and after the next seek and tell it positions the file at a value which is
something like 29000
Other attempt:
    fseek(handle,0,SEEK_CUR);   /* first time might be superfluous of course */
    ftell(handle);  --> 0
    fread(...,1024,...);
    fseek(handle,0,SEEK_SET);
    fseek(handle,1023,SEEK_CUR); /* rebuild it from the start */
    ftell(handle);  --> 14   ?????
Now what?
Whenever I go to someone who is a local VMS guru I get this look and
finally the remark: YESSSSS. This is a famous problem. If you ever
find this out, please let me know.
So I get the feeling that
a: most of these library functions do not do what the manual says they
   should do.
b: nobody ever uses them anyway.
Is there a global guru who can help me position my files in a filetype
independent way? This would make me very happy.

Thanks in advance
Jos Vermaseren
Newsgroups: comp.sys.dec
From: tihor@acf3.NYU.EDU (Stephen Tihor)
Subject: Re: MAILbus interconnection
Organization: New York University
Date: Fri, 21 Aug 1992 15:03:00 GMT

I would massively recomend the PMDf solutionover DEC's.  Our main site decided
against MR in general so we didn;t need it but at least one other campus decided to
choose to use it.  And Frankly Innosoft and the folks there are wonderful.
Newsgroups: comp.sys.dec
From: cballen@hubcap.clemson.edu (charles allen)
Subject: Re: Cache parity errors on DS5000/200
Organization: Clemson University
Date: Thu, 20 Aug 1992 19:34:30 GMT

valerie@cs.umass.edu (Valerie Caro) writes:


>   In the past few months we have started getting alot of
>   Cache parity errors on several of out DECstation 5000/200's.
>   This only started happening after these machines were updated
>   to Ultrix 4.2a, but I am not sure if that is related. Can
>   anyone tell me what causes these errors? Is this necessarily
>   a hardware problem?

>	       Thanks,
>	       Valerie Caro

>	       valerie@cs.umass.edu

We began experiencing these errors.  We do not know exactly when
it started.  But it could have been because of Ultrix 4.2a.
On a 5000/240 the errors were infrequent.  On a 5000/200 they 
occurred twice an hour on average.  It seemed tied the the # of 
seconds on the clock.  IE: the occurance pattern was like:
4:28:43
4:58:43
5:28:43
5:43:43
6:28:43
...

The seconds # changed every time we rebooted it.
 
Digital replaced the system board on both.  
 
I just checked.  The 240 is OK now, the 200 just spat out 2 errors
today after being up for 2 days.  They had the same # of seconds.
 
We have another 200 with no problem.
We have other 240s with no problem.
So, you tell me?
 
Charles Allen
CBALLEN@CLEMSON.CLEMSON.EDU
From: jvh@cs.hut.fi (Johannes Helander)
Newsgroups: comp.sys.nsc.32k
Subject: 32532 Mach port available
Date: 21 Aug 92 23:17:51 GMT
Organization: Helsinki University of Technology, CS Lab.


A free port of the Mach 3.0 micro-kernel to the pc532, a National
Semiconductor 32532 based single board computer, is now available.

This is a first public version. Improvements are still needed in some
areas and bug reports / fixes are most welcome: send them to
mach-532-bugs@cs.hut.fi. Also, this is not a complete operating
system. A Un*x server is still needed to run application programs.

A port of the 4.3BSD emulation along with libraries and user programs
has been done and it comes up multi-user but it will not be
distributed due to licensing restrictions.

A version of the net2 based bnr2ss server has been done but it is not
yet in a useful state.  (Unfortunately also the freeness of this along
with the rest of net2, most of which has been built and ported to the
pc532, has been cast in doubt by the Dark Forces).


The porting was done at Helsinki University of Technology by
Johannes Helander, Tero Kivinen, and Tatu Ylonen as an attempt to
obtain some familiarity with the Mach operating system and to get a
real operating system for the pc532.

Many thanks to the Carnegie Mellon Mach group for designing this
superb operating system and for their openness and help. Thanks to
Dave Rand and George Scolaro for designing the pc532 and making the
design freely available. Thanks to Jukka Virtanen, Ian Dall, and Jukka
Partanen for contributing time to this effort as well as to Bruce
Culbertson and Bob Krause for the disassembler.


The sources can be obtained through anonymous ftp from nic.funet.fi in
directory pub/mach/pc532-src. The file pc532.MK78.tar.Z (245737 bytes)
is a set of add-on files to the kernel version MK78 as distributed by
CMU. Some binaries can be found in pub/mach/pc532-bin.

New versions matching future CMU versions will be added when needed.
Other useful sources and binaries, such as bnr2ss, libc, user
programs, etc. will be added as soon as they work well enough and
their uncontaminatedness has been verified.

There is a mailing list mach-532@cs.hut.fi for persons interested in
continued development of Mach for the pc532. To be added to the list
or to be removed from it, please send mail to mach-532-request@cs.hut.fi.

	Johannes
Newsgroups: comp.sys.nsc.32k
From: xrolfa@dna.lth.se (Rolf Andersson)
Subject: Argh.....
Organization: Lund Institute of Technology, Sweden
Date: Fri, 21 Aug 1992 17:41:59 GMT

My harddisk Miniscribe 9380S is not working anymore. When I try to
read (boot) with the minix monitor it gives the following error msg:
SCSI failure, key 0x2, code 0x22, log adr 0x0, sense buf 0x1530.

Maybe someone has any idea what this means. Perhaps a reformatting will
help? Or controller board swap (anyone have a spare?).

HH
Rolf


-- 
------------------------------------------------------------------------------
Rolf Andersson            ! INTERNET: xrolfa@dna.lu.se
Magistratsvagen 49C       ! UUCP: ...!{uunet,mcvax,munnari}!enea!dna.lu!xrolfa
S-222 43  Lund, Sweden    ! PHONE:    int+46-46126845
------------------------------------------------------------------------------


Newsgroups: comp.sys.nsc.32k,comp.os.mach