HDTenEightyP/NetNews huggingface dataset:
From: cfraizer@bronze.ucs.indiana.edu (Colin Fraizer)
Subject: Mwm and two monitors on one DECstation 5000/120
Organization: Indiana University
Distribution: na
Date: Tue, 21 Jul 92 19:36:58 GMT


I recently received a 19" monochrome (mx) monitor and card which I've
added to my DECstation 5000/120 which already had a 16" color (cx) monitor
and card.  I want to be able to use both monitors with X and Mwm.

Both monitors successfully perform the diagnostics, but I am unable
to make Xws and/or Mwm work with the second monitor (slot 1).
Any suggestions?

Thanks in advance,
--Colin
-----------------------------------------------------------------------
Colin Fraizer                                      cfraizer@indiana.edu      
Indiana University Computing Services              Network Applications
-----------------------------------------------------------------------
Xref: sparky comp.sys.dec:4111 misc.forsale.computers:27216 misc.forsale:21594
From: v076n3w7@ubvmsb.cc.buffalo.edu (Gandalf the Grey)
Newsgroups: comp.sys.dec,misc.forsale.computers,misc.forsale
Subject: UVII for sale
Date: 21 Jul 92 18:02:00 GMT
Organization: University at Buffalo
News-Software: VAX/VMS VNEWS 1.41

I have a MicroVAX II which I would like to sell. It is currently diskless,
but if you need it to have disks of some sort, talk to me. I can get most
any kind of disk / disk controller. If you already have a large disk (>150meg)
then I can install it.

BA123 World box
KA630 MVII cpu with cabkit
MS630-CA compatible 8meg board
MS630-CA compatible 8meg board
DEQNA ethernet controller (supposedly support stops at VMS V5.4-3)
DHV11 8 port asynchronous mux

I am asking $1300 plus shipping (<$100 for most places in the US) or best
reasonable offer. There are no licenses available. I guarantee everything 
works, and I will put a 30 day warantee on it.

Thanks,
Chris Kalisiak
V076N3W7@ubvms.cc.buffalo.edu
From: stephen.dawson@canrem.com (stephen dawson)
Newsgroups: comp.sys.dec
Subject: financial statements
Date: 24 Jul 92 22:45:35 GMT
Reply-To: "stephen dawson" <stephen.dawson@canrem.com>
Distribution: comp
Organization: Canada Remote Systems

Can someone on the net who has Digital's latest annual financial
statements post them?

I don't need the notes, just the Balance Sheet, Income Statement,
Statement of Changes in Financial Position and Statement of Retained
Earnings.

Many thanks!

    STEPHEN
    ^^^^^^^
 stephen.dawson@canrem.com
 Entered 07-24-92 at 7:28am in Downsview, Ontario

 * DeLuxe2/386 1.25 #3969 * Most rules for success don't work if you don't.
--
Canada Remote Systems  - Toronto, Ontario/Detroit, MI
World's Largest PCBOARD System - 416-629-7000/629-7044
Newsgroups: comp.sys.dec
From: cmr@world.std.com (Charles M Richmond)
Subject: Re: mystery modem card
Organization: Integrated International Systems Corp. One Longfellow Place, Suite 3309, Boston, Ma.
Distribution: comp,vmsnet
Date: Sat, 25 Jul 1992 10:22:16 GMT

rocker@csa.bu.edu (The Long Haired One) writes:


>I've got a card I need to be identified. I know its a type of DEC modem
>from long ago. Its mint condition and is on a card, seemingly an internal
>version or maybe a rack version. Can someone tell me more?

>mainly I would like to know what it is, so I can figure out what it is
>worth to sell.

>here's the relevant numbers I can find on it...

>DF03-R
>C5000 5014854D

>I beleive a DF03 is like a 300bps or 1200bps modem.

>anyone know?
>thankx for any info in advance

>-Rocker

The DF03 was a 1200 baud modem. You can find references to it in the
addmodems file in /usr/lib/uucp. I do not know about an internal version.
Can you tell us more about the board geography? Is it a Qbus card or
an ISA bus card? I have seen 2 different DEC ISA bus cards. The DEC
command set is quite different also, not at all Hayes compatible for the
DF series or the "Scholars". The 2 that I have worked with are "AT" (Hayes)
compatible.

Charlie
-- 
*****************************************************************************
*  Charles Richmond 	Integrated International Systems Corporation        *
*  cmr@world.std.com	(Temporary) crichmond@mr4dec.enet.dec.com           *
*  Specializing in UNIX, X, Image Processing, and Communications.           *
Newsgroups: comp.sys.dec,comp.unix.ultrix
From: sspatter@netcom.com (Samuel Scott Patterson)
Newsgroups: comp.sys.dec,vmsnet.pdp-11
Subject: Ack!!
Date: 29 Jul 92 03:46:24 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

Ack!!

     I figured out what's wrong with my M7856 card!  I took a closer look
at it to see if by some chance I had some jumpers wrong or something and
I happened to notice 3 desodered areas on the board where someone 
decided to borrow a few chips!  Anyone know where I can pick up a new
M7856 reasonably cheap that works?

						-Scott

---------------------------------------------------------------------
sspatter@netcom.netcom.com
Samuel Scott Patterson  365-J Western Drive, Santa Cruz CA 95060
(408)459-6790
---------------------------------------------------------------------
Xref: sparky comp.sys.dec:4155 alt.folklore.computers:11021
From: gheim@eng.auburn.edu (Greg Heim)
Newsgroups: comp.sys.dec,alt.folklore.computers
Subject: Cadmus or PCS info needed!
Date: 23 Jul 92 17:34:24 GMT
Organization: Alabama Department of Tourism (NOT!)


I have a CPU for a Q-Bus apparently manufactured by a company called
Cadmus around '85.  The company is supposedly now called PCS (a german
company).  I would like to get information on my board, but don't know
how to contact these people.  Anyone know anything about them or even
what PCS stands for?  I would guess they were in Colorado but not
really sure.  If _you_ have documentation, that would be even better.
This is what the board looks like...



            ___ "HANDLE # 937 MFG. BY DIGITAL EQUIPMENT CORP. MAYNARD, MASS"
            |
            v 
        \___/                                                  \___/
    _____|_|____________________________________________________|_|___    
   |                   |||||||||||||| ||||||||||||||                o |
   |       _               Two 40-pin Connectors              Halt LED|
   |      |_|                                                         |
   |    4-pin                                                         |
   |    jumper               --------- -------                        |
   |    block                |       | |     |                        |
   |                         --------- |     |         _____          |
   |                         --------- |     |        |20MHz|         |
   |                         |       | |68010|        |_____|         |
   |                         --------- |     |                        |
   |                           PROMs   |     |        .-.             |
   |                                   |     |        |_|             |
   |                                   |_____|    3-pin jumper block  |
   |  ___                                                             |
   | |   |                                                            |
   | |   | Battery                                                    |
   | |___|                                                            |
   |_              __-.              _-.              __-.           _|
     |            |   |             |  |             |   |          |
     |____________|   |_____________|  |_____________|   |__________|

                               Figure 1.0
			 (Non-artist's rendition)


Thanks for any help,

Greg



Ask to see my resume! | Graduating in August.  Looking for job in Atlanta area.
                      | 3+ Years _real_ experience in... UNIX administration,
Greg Heim             | Relational database design, PC Hardware/Software Support
gheim@eng.auburn.edu  | Shell programming. Resourceful problem solver. Hire me!
Xref: sparky comp.sys.dec:4181 alt.folklore.computers:11090
From: lupe@ukw.uucp (Lupe Christoph)
Newsgroups: comp.sys.dec,alt.folklore.computers
Subject: Re: Cadmus or PCS info needed!
Date: 24 Jul 92 06:02:51 GMT
Organization: cic

gheim@eng.auburn.edu (Greg Heim) writes:


>I have a CPU for a Q-Bus apparently manufactured by a company called
>Cadmus around '85.  The company is supposedly now called PCS (a german
>company).  I would like to get information on my board, but don't know
>how to contact these people.  Anyone know anything about them or even
>what PCS stands for?  I would guess they were in Colorado but not
>really sure.  If _you_ have documentation, that would be even better.
>This is what the board looks like...

(Picture deleted)

Almost correct. The German company was (and is called) PCS,
Periphere Computer Systeme. They are located in Munich.

PCS started out manufacturing data entry equipment. Later they built
one of the first Unix machines, based on the Q-Bus, with a Motorola
68010. That is the board you have. The machine was called Cadmus 9000.

The two 40-pin connectors are for the memory bus.

I have used this machine a long time ago. At a time it came
with 8" floppies. I'm not ure about the unix variant, though.
PCS did their own port. Could have been Version 7.

BTW, they had for a short time a US subsidiary named PCS Cadmus.
I'm not sure about it's fate, but I think it got sold to Apple.
-- 
| ...!unido!ukw!lupe  (German EUNet, "bang")     |  Disclaimer:            |
| lupe@ukw.UUCP       (German EUNet, domain)     |  As I am self-employed, |
| suninfo!alanya!lupe (Sun Germany)              |  this *is* the opinion  |
| Res non sunt complicanda praeter necessitatem. |  of my employer.        |
Newsgroups: comp.sys.dec
From: levy@levy.fnal.gov
Subject: Re: DEC deal with Bush
Organization: Fermilab Computing Division
Date: Mon, 27 Jul 1992 17:17:56 GMT

In article <1992Jul24.082147.20043@panix.com>, tls@panix.com (Thor Lancelot Simon) writes:
> In article <1992Jul23.171737.7106@PA.dec.com> mok@fortsc.enet.dec.com (Charles Mok) writes:
>>
>>In article <STRANGE.92Jul23171445@hang.dec.com>, strange@zk3.dec.com (Steve Strange) writes...
>>....rumor deleted
> 
>>How can anyone believe some rumor as silly as that?  
>>
>>1.  Bush is not as dumb as that.
> 
> Most likely true.
> 
>>2.  DEC is definitely not as important as that.
> 
> Well, further big layoffs at DEC would probably make Page 1 of the WSJ.
> Probably not _that_ important, but up there.  Now if it were IBM... :-(
> 
>>3.  No government contract is worth risking the integrity of the company like  
>>    that.  Not for this company.
> 
> I'm not very sure DEC has any integrity left.  What's there to risk?  First
> the whole Jupiter mess, and then the bit about OSF/1 on MIPS.  Oh, so sorry.
> I guess in the latter case, promises were simply _about_ to be broken.  On the
> other hand, maybe we were all just being jerked around to see what kind of
> response there'd be.  
> 
> I think I'd probably still buy hardware from DEC, if I could afford to, in any
> of my capacities.  Why?  Because Alpha looks like a very nice architecture.  On
> the other hand, any talk of integrity is right out.  I worked at DEC.  I won't
> trust them any further than I can throw a 2060.
>>
>>Charles
>>
>>
>>---
>>Charles Mok/Digital Equipment Corporation
>>Santa Clara Commercial Account Group, Santa Clara, California
>>INTERNET: mok@fortsc.enet.dec.com  UUCP: ....!decwrl!fortsc.dec.enet.com!mok
>>---
> 
> 
> -- 
> Thor Lancelot Simon	 tls@panix.COM
> 
> "Better be careful there.  John might decide to start taking legal action
> against people who refuse to buy stuff from him."  --Kevin McBride

I missed the original post.  Could someone please e-mail it to me?

================================================================================
[ Mark E. Levy, Fermilab          |                                            ]
[ BitNet:   LEVY@FNAL             | Unix is to computing                       ]
[ Internet: LEVY@FNALD.FNAL.GOV   |       as an Etch-a-Sketch is to art.       ]
[ HEPnet/SPAN: FNALD::LEVY (VMS!) |                                            ]
================================================================================

Newsgroups: comp.sys.dec
From: butler@quest.comm.mot.com (Jim Butler)
Subject: "Silo" prob: High serial spd. needed w/ Utrx4.2
Reply-To: butler@quest.comm.mot.com (Jim Butler)
Organization: Land Mobile Products Sector, Motorola, Inc.
Date: Sun, 26 Jul 1992 23:04:16 GMT
Keywords: silo serial slip 


	Hello everyone,


	Having recently acquired a pair of v.fast modems, I would like
to implement SLIP on my DEC 5000/125.  However, after running remote logins
(not SLIP, just std. logins) for a while, a couple of us here have noticed
what appears to be an over-run condition occuring on the DEC 5000.  The
session manager on the machine notes something called a "silo error" or 
"silo overflow" (pardon me, I don't remember which).  We think that it may
be attributable to an overflow of the DUART on the DEC 5000, but we're not
certain.


	Thus, I have the following questions:


	(1) Has it been documented that the "default" maximum *effective* 
	    DUART throughput of the DEC 5000 is limited, and if so, to what
	    value (we stop having problems at 9600)?

	(2) If (1) above is generally true, is there then a means of
	    increasing the *effective* throughput to the DUART?



	BTW, I'm aware that the DUART hardware will run up to 204000 baud.
It appears that the machine's software is not properly set up to support that
high a data rate to/from the DUART.


	Thanks,


	Jim


----------------------------------------------------------------------------
Jim Butler                                | Internet: butler@Quest.comm.mot.com
Motorola, Inc.                            | FAX:   708-576-3240
Land Mobile Products Sector Research      | Phone: 708-576-5962
Schaumburg, Illinois USA                  |
-----------------------------------------------------------------------------
Newsgroups: comp.sys.nsc.32k
From: DALL@hfrd.dsto.GOV.AU
Newsgroups: comp.sys.nsc.32k
Subject: Mach on PC532 <-SCSI-> NeXT ?  Thoughts?
Date: 23 Jul 92 00:54:06 GMT
Organization: Association for the Prevention of Polar Bears and Kangaroos

pc532@bungi.com writes:
 > Soon, I hope, the folks working with Mach on the PC532
 > will be able to make their work available to those without
 > UNIX source licences.

The micro kernel is free of nasty licences, the unix server isn't.

There are a number of possibilities for a licence free server.
As I understand it, these are the CMU multi server, the GNU Hurd
and the BSD Net2 based server. The last one has the most hope
of being available early and had been done for the 386.

It wouldn't be too big a job to do the PC532 port, but I don't
know of anyone actually doing it.


 > When that happy day comes, I'd like
 > to use the SCSI bus as an IPC channel between my PC532 and
 > my NeXT.  What do people think of this idea?

Well, we all want to use SCSI as an IPC bus. I've got this
Sun 3/50 I want to talk to.

 > I already plan
 > to write the relevant drivers,

We are using a layered approach to the scsi drivers. There is a
machine dependent part, a machine and scsi device independent part and
a SCSI device (disk, tape, cpu, communications) dependent parts.  The
support for SCSI 2 cpu and communication devices is being added by CMU
people (Alessandro Forin).

Write the machine dependent parts and everything else should work for
free, in theory. In practice, I can't get tapes to work yet.

Our machine dependent SCSI code still needs work. The HUT guys did the
original work and I am trying to clean up/debug it with as much time
as I can spare.  Currently we don't support disconnect/reselect or
target mode. The former is pretty essential from a performance point
of view and the latter is essential for scsi2 cpu and communication
devices.

 > but what schemes are there for
 > sharing compute power between dissimilar processors?

The most promising is NORMA. I forget what it actually stands for, but
basically (from memory) it allows memory objects to be shared over a
network as if it were on the same machine. I think it even fixes up
byte order problems etc. You can, apparantly, write a process to take
advantage of multi-cpu and it works the same whether the CPU's are
tightly coupled or very loosly (NORMA) coupled.

This sounds very nifty. The only published performance figures were
over ethernet. They got linear speed up for some sorts of problems
up to about 4 processors. With SCSI communications, the tradeoffs
would be different of course and maybe NORMA would be useful
over a wider class of problems.

(Disclaimer: I have zero experience with NORMA, I just read a paper.)

Ian
From: mattias@lysator.liu.se (Mattias Olofsson)
Newsgroups: comp.sys.nsc.32k
Subject: Anyone working on a BSD port?
Keywords: pc532, bsd, cross compiling
Date: 23 Jul 92 14:24:28 GMT
Organization: Lysator Computer Club, Linkoping Institute of Technology, Sweden


 Some time ago, there was talk about porting BSD (net2 i presume)
to the pc532. Is anyone working on it, or did the idea just fade
away? If not, is there anything organized or just some solitude
hacking?

 I have recently (ie. today) been thinking about setting up a
crosscompiling environment for the pc532 on our sparcserver. The
purpose is trying to port BSD (didn't guess that, did you? ;) Have
anyone else already done this or do I have to start from scratch?

 I guess gcc and gas are the best choices for compiling, and ld, ar,
ranlib and libc is available both from FSF and the net2 release. Do
I need anything else?

 Note: I'm not too used to kernel hacking, so don't expect me to port
BSD for you. I'm doing this for learning unix and for my own pleasure.
If I happen to come up with something useful, I don't mind...
--
---
A religion dies when it is proven true. Science |       Mattias Olofsson |
is the record of dead religions.    Oscar Wilde | mattias@lysator.liu.se |
From: athos@eyrie.img.com.au (David Burren)
Newsgroups: comp.sys.nsc.32k
Subject: Re: Mach on PC532 <-SCSI-> NeXT ? Thoughts?
Date: 24 Jul 92 23:13:03 GMT
Organization: img Consultants, Melbourne, Australia

In <920724120859.111bf@hfrd.dsto.gov.au> DALL@hfrd.dsto.GOV.AU writes:

>In case I gave the wrong impression, there is a PC532 mach and it works.
>There isn't a *licence free* pc532 mach *server*.

Which brings us to the obvious questions:  Where is this PC532 Mach available?
What MK level is it up to?

It sounds as though it's progressed a bit beyond what the HUT guys did with
it.  Last time we spoke to them they didn't want to release it (that _was_
quite some time ago).
Does it support the 6250 controller?

- David B.
  athos@img.com.au
Newsgroups: comp.sys.nsc.32k
From: rickr@virtech.vti.COM (Rick Rodman)
Subject: Some mail (fwd)
Organization: Association for the Prevention of Polar Bears and Kangaroos
Date: Fri, 24 Jul 1992 01:40:23 GMT

Forwarded message:
>From uunet!IBMMAIL.ibmx400.nl!ARNOL7.ARNOLD Thu Jul 16 10:31:35 1992
X400-Received: by mta relay.surfnet.nl in /PRMD=surf/ADMD=400net/C=nl/; Relayed;
               Thu, 16 Jul 1992 15:40:34 +0200
X400-Received: by /ADMD=400NET/C=NL/; Relayed; Thu, 16 Jul 1992 15:39:20 +0200
X400-Received: by /ADMD=IBMX400/C=GB/;
               attempted /PRMD=IBMMAIL/ADMD=IBMX400/C=GB/; Relayed;
               Thu, 16 Jul 1992 16:39:40 +0200
X400-Received: by /PRMD=IBMMAIL/ADMD=IBMX400/C=GB/; Relayed;
               Thu, 16 Jul 1992 15:39:35 +0200
Date: Thu, 16 Jul 1992 15:39:35 +0200
X400-Originator: ARNOL7.ARNOLD@IBMMAIL.ibmx400.nl
X400-Recipients: virtech!rickr@uunet.UU.NET
X400-Mts-Identifier: [/PRMD=IBMMAIL/ADMD=IBMX400/C=GB/;AzZmoCCa+19920716143935070003]
X400-Content-Type: P2-1984 (2)
From: uunet!IBMMAIL.ibmx400.nl!ARNOL7.ARNOLD
Message-Id: <0003*/G=ARNOL7/S=ARNOLD/PRMD=IBMMAIL/ADMD=IBMX400/C=NL/@MHS>
To: virtech!rickr
Subject: Some mail

To: 15888   --IBMMAIL

From:    S. J. Arnold           ext. 2476
         Room  814, Munich  Isar Building
         European Patent Office -- Munich
Subject: Some mail
Hi Rick,
you're the second person in the whole of the world that I can talk to.
Isn't I*M wonderful?!  It's not clear from your mail exactly where you
are, but I guess somewhere in the USA.  Do you have german ancestry?
Your German is certainly better than the average American's.  And I
thought Tanenbaum was something to do with Minix.

As for my 532 adventures, I haven't had many of those yet, since I only
just got mine running.  However in case the news hasn't filtered through
yet, Mark Munkacsy's /WE mod seems to be essential with 4M SIMMs.  We
couldn't get any to work without it.  Also 74ALS6311s are impossible to
obtain in Munich, so I use a 10k resistor between pins 18 and 20 of the
socket.  This should suffice until someone sends one from the States.

I don't know whether this connection will help with the ftp archives.
My employer (the European Patent Office - well someone has to work
there and they say Einstein's most productive years were at the patent
office in Bern) provides this system for sending useful messages such
as "how about coffee" to the office next door.  Overkill if ever I saw
it.  So I can't put megabytes of personal stuff on it, and even if I
could I guess you can't call up and fetch it.  I could read stuff in
and send it on request, but then I guess that service is available via
Julian and the PCS guys anyway.
Anyway before I write any more, i'll see if I can send this first.
Please let me know if it arrives OK
All the best
Stuart Arnold

Newsgroups: comp.sys.nsc.32k
From: rickr@virtech.vti.COM (Rick Rodman)
Subject: SCSI API
Organization: Association for the Prevention of Polar Bears and Kangaroos
Date: Fri, 24 Jul 1992 01:53:43 GMT

Whoa, now the Mach prospective porters are hitting a topic close to my heart.
We should standardize on a SCSI API.  I would like to have this, not just
for inter-computer (host-to-host) data transfer, but also for all the neat
new SCSI peripherals, such as scanners, that are coming out.

In my opinion, we should have an API in the kernel which is a device driver
and provides only very simple services.  The disk device driver should go
through that device driver... it should be possible for me to send any
CDB and get results.  The driver could internally handle disconnects and
reconnects without bothering me about it.  Something like ASPI, but more
convenient; or something like the RAW command in the PC532 monitor, which
is really nice.

Also, it might be good to use the Adaptec chip for the external SCSI port,
and leave the other chip for local drives.  (Hm, this contradicts what I
said above)  That is to say, the Adaptec chip device driver would have
read/write/ioctl access for non-file-system peripherals such as tape,
scanner, etc. that would be controlled by application software.  Then if
something clobbers the external bus the system stays up.

Supposedly ANSI has defined a "Common Access Method" (CAM) specification
which says how SCSI should look to application code.  Anyone have a copy
and any comments on it?

Newsgroups: comp.sys.nsc.32k