HDTenEightyP/NetNews huggingface dataset:
From: terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.)
Newsgroups: comp.sys.dec
Subject: Re: Help with Maxtor XT-2190
Date: 9 Nov 92 01:37:24 GMT
Organization: St. Peter's College, US

In article <DGRAY.92Nov8104036@menudo.uh.edu>, dgray@menudo.uh.edu (Dennis Gray Jr.) writes:
> Does this mean that you can use any MFM drive in a micro vax?  (how
> about a vax station?)  If this is true, is there a MAX # of
> heads/cyls?

  Nope. The earlier controllers (RQDX1, RQDX2) did various "unnatural acts"
(illegal seeks, selecting nonexistant heads, etc.) to guess what drive type
was attached. Even a drive with the same geometry might not work, depending
on the response it gives to such illegal commands. That's why the RD53 has
the R7 jumper - to change it's behavior to make it distinguishable from the
earlier drives.

  The RQDX3 can support other geometries, but you have to enter the size of
all of the MSCP regions and the controller does no checking of the values,
so you can (for example) have a drive that acts fine until the first time it
does a bad block replacement, and then becomes unusable.

  In general, it's best to stick with the recognized drives (RD51=ST412,
RD52=Q540/3046/5540(heh!), RD53=1325/1335, RD54=2190) or to get a new con-
troller and drive using some other interface (ESDI/SCSI) if you need more
speed/capacity.

	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
From: pavlov@niktow.canisius.edu (Greg Pavlov)
Newsgroups: comp.sys.dec
Subject: Re: Alpha speed?
Date: 13 Nov 92 17:07:16 GMT
Organization: Canisius College, Buffalo NY. 14208

In article <RICHARD.92Nov12152902@chemeng.stanford.edu>, richard@chemeng.stanford.edu (Richard Schiek) writes:
> 
> In all the technical blurbs for the new DEC Alpha chip, they call it a
> 300MHz chip.  Yet, in all the new systems that DEC is shipping, the
> chip is running at 140 MHz max.  Why is it called a 300MHz chip when
> only 140 MHz systems are for sale?  
> 
  You might want to put your glasses on ... or get yourself a pair :-)

  The only "300" that I have seen in DEC's public releases has been 300 MIPS

  The new systems contain ALPHA cpus that range from 133 to 200 MHz.

  The REAL question here may be why DEC is limiting "workstation"-class 
  machines to the lower end of the range.  Too many of us who have been
  using "workstation" platforms as multi-user and/or server systems ??
  Though this may simply be a conflict between what us UNIX folks are
  used to and what VMS folks are used to paying.


   pavlov@fstrf.org
From: kevinn@kpc.com (Kevin Nguyen)
Newsgroups: comp.sys.dec
Subject: Help Need for DEC Verifier and Exerciser Tool
Date: 12 Nov 92 20:52:54 GMT
Organization: Kubota Pacific Computer Inc, Santa Clara, CA

Hi everyone,

I am trying to setup the DEC (VET) Verifier and Exerciser Tool program in 
my DEC 5000 and Alpha systems, so I can run them over the network.  Do you
know anything about this program.  I can't believe the DEC customer support
people don't this program.

Thanks in advance.

Kevinn
-- 

Kevin Nguyen				Kubota Pacific Computer Inc.
Internet E-mail kevinn@kpc.com		uucp E-mail kpc.com!kevinn
Xref: sparky comp.sys.dec:5944 comp.os.vms:17924 comp.sys.vms:54 comp.org.decus:976 vmsnet.networks.misc:120 vmsnet.misc:1006
From: cjones@dbaccess.com (Carl Jones)
Newsgroups: comp.sys.dec,comp.os.vms,comp.sys.vms,comp.org.decus,vmsnet.networks.misc,vmsnet.misc
Subject: DECnew/SNA APPC/LU6.2
Keywords: communications DECnew SNA LU6.2 APPC bug
Date: 13 Nov 92 16:30:23 GMT
Followup-To: steve@dbaccess.com
Organization: Cross Access Corp., Santa Clara, CA

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Help needed with DECnet/SNA APPC programming interface (a DEC product)!

We urgently need a solution to a problem we have encountered with this
product.  When we code to the interface specifications, the program aborts with
an access violation during an AST; the symbolic dump suggests a default user
AST dispatcher is the routine with the problem.  The access violation occurs
during a reference to what appears to be a control structure malloc'ed by the
product and not completely filled in (the pointer is zero).

If this sounds familiar, or you have access to source code in any form, we'd
like very much to talk to you (no secrets being sought; just confirmation of
the problem and a workaround).  Please contact Steve Suttles or Peter Castro at
Cross Access Corporation, (408)735-7545.  If you have (internet) e-mail access,
send to steve@dbaccess.com .  Tons of additional information are available upon
request...

Thanks in advance!

sas

-- 
Carl Jones                        INTERNET: cjones@dbaccess.com
c/o CROSS ACCESS CORPORATION      UUCP: {uunet,sgiblab}!troi!cjones
2900 Gordon Avenue, Suite 100     FAX: (408) 735-0328
Santa Clara, CA 95051             TEL: (408) 735-7545
Newsgroups: comp.sys.dec
From: pettengill@cvg.enet.dec.com ()
Subject: Re: VS4090 fddi boot?
Keywords: VAXststion fddi boot
Reply-To: pettengill@cvg.enet.dec.com ()
Organization: Digital Equipment Corporation
Date: Fri, 13 Nov 1992 18:02:16 GMT


In article <1dv97cINNqe6@fnnews.fnal.gov>, jhf@d0xs1.fnal.gov (John Featherly) writes:
|>
|>We just received our VS4000 TCA boards, great!
|>
|>Plug one into a 4000-M90 and stick an fddi board on, looks okay so far.
|>
|>Finally find the network address of the board by running the MIPS console
|>emulator and doing "t tc0 cnfg", looks good.
|>
|>How do you get it to boot over the fddi adapter?

You can't.  Its not currently supported and its not clear that it will be.

|>
|>I finally just booted from the ethernet adapter, turned off DECnet on ethernet
|>and turned it on for fddi (don't want to be a router).  This is VMS V5.5-2HW
|>by the way.
|>

Thats the recommended way to set it up.  Once the system gets sysboot, etc
loaded, it will start using fddi for those systems reachable with FDDI, so
you don't have to have FDDI on all systems nor do you need a bridge between
FDDI and ethernet.

mulp
DEC, CVG cluster busters
Newsgroups: comp.sys.dec,news.software.readers
From: sf@cc.ic.ac.uk (Susan Feng)
Subject: Problem with xrn-6.17 on DECstation, Cannot perform malloc
Originator: sf@cc.ic.ac.uk
Organization: Imperial College Computer Centre
Date: Fri, 6 Nov 92 16:41:49 GMT

I can't get xrn work on my DECstation 5000/120. When invoked,
it takes long time and returns error:-

X Toolkit Error: Cannot perform malloc

Can anyone points me what is wrong?

The system information is:-

ULTRIX V4.2A(Rev. 47) System #3
uname -a
ULTRIX phcmde 4.2 0 RISC

Thanks a lot.

Susan Feng
-- 
--------------------------------------------------------------
Xueshan Feng (Susan Feng)         | Tel.: (071) 5895111 x 4975
Computer Centre, Imperial College | E-mail: s.feng@cc.ic.ac.uk
--------------------------------------------------------------
From: oberman@ptavv.llnl.gov
Newsgroups: comp.sys.dec
Subject: Re: HELP: Decnet Phase-IV routing
Date: 6 Nov 92 17:51:33 GMT
Distribution: na

In article <jjr.720993680@gw.alantec.com>, jjr@alantec.com (Janardan Ramesh) writes:
> I am in the process of implementing DECNET phase-IV routing. When a node is
> configured as a level 2 router, it is necessary to assign a different node ID
> for each area the router is connected to? Should the router maintain a
> different routing data base for each area? These concepts have not been
> addressed clearly in the routing specification.
> 
> The configuration I was referring to, is shown below:
> 
> 
>     --------------------------- (area 1)
> 		  |
> 	 ------------------- 
> 	| Router            |
> 	 -------------------
> 		  |
>     --------------------------- (area 2)


Sorry, but this configuration won't work. You must have an area router in each
area and they must be connected. So you end up with:

      
    --------------------------- (area 1)
		  |
	 ------------------- 
	| Router (1.x)      |
	 -------------------
		  |
	 ------------------- 
	| Router (2.x)      |
	 -------------------
		  |
    --------------------------- (area 2)

Of course, each area router may connect with more than one other area.

The node number portion of the address of the router is not significant unless
there are more than one path between areas with identical cost. In that case
the router with the highest address will be used. Please note that this can
easily result in asymetrical routes if you don't assign addresses correctly.

Also, unlike IP, DECnet assigns addresses to nodes, not interfaces.

I'm not clear on just what you mean by "routing data base". The routing data
base is built by the routers. You don't maintain anything. If you mean the
database of node names to addresses, you normally have only one unless you are
doing something unusual. All nodes should copy this single database to their
own systems on a regular basis.

But this data base is only for human interface. Routing makes no use of it nor
does any part of DECnet except the user interface and the odd case of "poor
man's routing" (PMR).

R. Kevin Oberman			Lawrence Livermore National Laboratory
Internet: koberman@llnl.gov		(510) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.
Newsgroups: comp.sys.dec
From: dgray@menudo.uh.edu (Dennis Gray Jr.)
Subject: Please help with Vax Station
Reply-To: DGray@uh.edu
Organization: University of Houston
Date: Sat, 7 Nov 1992 06:17:24 GMT


Hello Vax experts!

I just received a Vax Station II and I have several problems, and most
likely more that I don't know about...

First, this machine doesn't have any monitor or terminal.  So this
brings up two questions:

	Can I get a graphics monitor and keyboard for it? And if
	so, what is the part number?  More information on this set
	up:  The "card" for this is in slot "b" in the case.  There
	are two 15 pin sockets on it, one male one female.  Connected
	to the back of it there are two wires going to one of the
	plane -- one is a 20 pin ribbon cable, the other is a single
	wire that has a single pin going to a plane.  Written on the
	card it says "50-16468-01-C1" and "QVSS PATCH PANEL".  Any
	information you have on what this is, or what I can put on it
	would be greatly appreciated.

	Can I hook up a PC to be a dumb terminal to this?  I think the
	other card is applicable here:  Two dials, a switch, a 9 pin
	male connector and an LED readout.  The switch has two
	positions: one is labeled as a cirle with a dot above it, the
	other has a circle with the dot in it -- the latter also has a
	circle with an equilateral triangle in it.  One of the dials
	has three positions: one with an arrow pointing to the right,
	one with an outline of a face profile, one with a circle that
	has a "t" in it (there is also an arrow pointing allong the
	circle's circumference).  The other dial has several positions
	and is labled "baud" -- each position is a baud rate.  When
	the machine is powered up the LED says "A".

There might also be a problem with the machine actually booting up.
Since I have no interface with the machine, I don't know what it
does...  I have a tape (TK50) with unknown contents.

Any help will be GREATLY appreciated.

Thank you,
-dennis
---
Dennis Gray, Jr.                                        DGray@uh.edu
"You askin' to become a pile of zeros?  I could put you away so good
that Peter Norton couldn't find you with his arms unfolded."
			  - Lincoln Spector
From: pamars@MAGEC.COM (P.A. Marshall)
Newsgroups: comp.sys.dec
Subject: Puzzling VAX failure
Keywords: uVAX-3, VCB02
Date: 6 Nov 92 19:30:18 GMT
Organization: MAGNAVOX Electronics Systems Co., Fort Wayne

I am having a puzzling problem with a uVAX-3 I recently purchased.  The
system is made of a BA123, KA650, (3)MS650, TQK50/TK50, 8 plane VCB02,
VR290 and a Emulex QD32.  When I first got the system the VCB02 worked
but I had a problem with the TK50, so the system was never on for long
but it was powered up and down servial times.  After the TK50 problem
was fixed I was formating the drives via the QD32 (takes a while) and
the VCB02/VR290 stopped working.  I had a RS232 console cable, and just
unpluged the cable to the VR290, pluged in a VT220 and reformated the
drives.  A day or so later I went back to load software and the system
would not come up, the CPU card stalled in selftest 3.  I found that
removing the VCB02 card set allowed me to boot the system, so I aranged
a swap of the VCB02 card set.  Same results with the new card set.
I am stumped, what am I missing?  I am 100% certain that the system
booted more that once with the VCB02 card set still in the back plane
the night it first failed.  One more item, the original VCB02 card set
checked out OK when it was returned.  The party I got the system from
thinks that the next step is swapping the VR290, but I can't see how a
bad VR290 could cause the problem I am seeing.

Xref: sparky comp.sys.dec:5820 comp.os.vms:17600
From: dwight@geohub.gcn.uoknor.edu (Dwight D. Moore)
Newsgroups: comp.sys.dec,comp.os.vms
Subject: Re: alpha memory requirements (vs vax) ?
Date: 6 Nov 92 17:29:41 GMT
Article-I.D.: constell.1992Nov6.172941.28490
Reply-To: dwight@geohub.gcn.uoknor.edu
Organization: Geosciences Computing Network, Univ. of Oklahoma
Originator: usenet@kittyhawk.ecn.uoknor.edu

In article <1992Nov5.113540.1@uwovax.uwo.ca>, brent@uwovax.uwo.ca (Brent Sterner) writes:

|>   Just curious about memory demands for alpha.  I'm running a VAX 4500
|>with 128 MB memory.  Of that, SHO MEM tells me "38393 pages are permanently
|>allocated to VMS".  How big is VMS on an alpha system?  (Perhaps someone with
|>an alpha could post the last line from SHO MEM, though it might be misleading
|>if there is a lot of dbugging code still in place.  Perhaps someone inside
|>DEC has a non-debugging system they could use.)  Is there a rule of thumb for
|>typical programs ("alpha memory needs"/"vax memory needs" ~= "constant")?
|>Does a typical user (VAXC or FORTRAN) program require more or less memory on
|>an alpha system?
|>   Thanks,  b.
|>--
|>Brent Sterner                       Manager, Academic Technical Support
|>

Here it is on a DEC 3000/500 (Flamingo) running OpenVMS 1.0 (field test)
    "Of the physical pages in use, 934 pages are permanently allocated to VMS."

However, this is misleading since the OpenVMS is using "pagelets" and variable size pages.
The SYSGEN parameter PAGE_SIZE on our machine is 8192. I believe the pagelets are 512
byte blocks.  This usage on your system will depend on SYSGEN parameters, e.g. how
much  GBL pages/sections you set up.

----------------------------------------------------------------------------
Dwight D. Moore
Geosciences Computing Network
University of Oklahoma

dwight@geohub.gcn.uoknor.edu (129.15.40.10)
These opinions do not necessarily represent the opinions of OU or the GCN.
----------------------------------------------------------------------------
Newsgroups: comp.sys.dec,comp.os.vms
From: weikl@ee3ds1.ilt.fhg.de (Dr.B.Weikl)
Subject: Re: alpha memory requirements (vs vax) ?
Reply-To: weikl@ilt.fhg.de
Organization: ilt-fhg
Date: Fri, 13 Nov 92 07:55:21 GMT


BTW, does anybody known with which memory the memory of a DEC/3000-500 is compatible? I've heard it would be the same as in a DECstation 5000. Does anybody know the order number of compatible memory?

Thanks!

-- Bruno
=====================================================
# Dr. Bruno Weikl                                   #
# Fraunhofer-Gesellschaft Institut fuer Lasertechnik#
# Steinbachstr. 15, D-5100 Aachen, Germany          #
# InterNet     : weikl@ilt.fhg.de                   #
# Phone        : +49/241/8906-134, -0,              #
# Fax          : +49/241/8906-121                   #
# Telex        : 832267 fhilt d                     #
====================================================#
Newsgroups: comp.sys.dec
From: gazzer@gjw1992.demon.co.uk (Gary John Walker)
Subject: VAX 7610 
Distribution: world
Organization: Just Me
Date: Mon, 9 Nov 1992 06:05:45 +0000


In article <4NOV199221584930@inews> prangley@inews writes:

>
>
>
          
        You've just upgraded this 7610 with an Alpha board and 
        you're gob-smacked - yes?       ;-)


          -------------------------------------------------
          Gary John Walker     gjwalker@gjw1992.demon.co.uk
          -------------------------------------------------
From: jhf@d0xs1.fnal.gov (John Featherly)
Newsgroups: comp.sys.dec
Subject: VS4090 fddi boot?
Keywords: VAXststion fddi boot
Date: 13 Nov 92 03:59:40 GMT
Article-I.D.: fnnews.1dv97cINNqe6
Reply-To: jhf@d0xs1.fnal.gov (John Featherly)
Distribution: world
Organization: D0 Experiment
NNTP-Posting-Host: d0xs1.fnal.gov


We just received our VS4000 TCA boards, great!

Plug one into a 4000-M90 and stick an fddi board on, looks okay so far.

Finally find the network address of the board by running the MIPS console
emulator and doing "t tc0 cnfg", looks good.

How do you get it to boot over the fddi adapter?

Tried many things, VAX console ROM is clueless about FCA0 ...
the most promising turned out to be "t tc0 boot mop" in the MIPS emulator
but still no go (yes I did change the hardware address on the load host).

Anyone have any clues?

I finally just booted from the ethernet adapter, turned off DECnet on ethernet
and turned it on for fddi (don't want to be a router).  This is VMS V5.5-2HW
by the way.

--
--------------------------------------------------------------------------------
   John Featherly                                    jhf@d0xs1.fnal.gov
   D-Zero Experiment at Fermi Lab                        (708) 840-4508
--------------------------------------------------------------------------------
Xref: sparky comp.sys.dec:5829 vmsnet.pdp-11:825
Newsgroups: decus.pdp11,comp.sys.dec,vmsnet.pdp-11
Subject: Kennedy 6600/6550/6500 Setup Info WANTED.
From: geremin@decus.com.au
Date: 7 Nov 92 08:37:02 AEST
Organization: DECUS, South Pacific Chapter

Hi All,
	I am in urgent need of Technical Info for the Kennedy 
6600 tape drive. (Similar to TK25) - Info on Kennedy 6500 or 6550 
may also be suitable.

	I need info on jumper settings for the read/write control 
board built into the drive. Also switching from 110 to 240 volts.

	E-mail replies (or phone calls if you are in Oz).

Regards, John G.
 
v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v
  John Geremin,  Trainee Guru,  PDP-11 SIG,  DECUS Australia, 
IN%"geremin@decus.com.au"        voice:  02  764 4855 (home/wk)
-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-
Newsgroups: comp.sys.dec
From: sharpe@adodem.enet.dec.com
Subject: Re: XView 3.0 on decstation 5000/25
Organization: Digital Equipment Corporation
Date: Tue, 10 Nov 1992 15:20:15 GMT


In article <lynchh.721291860@marsh>, lynchh@cs.curtin.edu.au (Huw Lynch) writes...
>Has anyone managed to compile XView 3.0 on a dec station 5000?
> 
>I keep getting "Unknown size" errors during compilation.
> 
> 
Yup, sure did :-)

1 dozen Eagle Blue seems like a good rate :-)

Regards
Richard Sharpe
These opinions be mine, Digital has its own.
Newsgroups: comp.sys.dec,comp.os.vms
From: jbotz@mtholyoke.edu (Jurgen Botz)
Subject: Re: alpha memory requirements (vs vax) ?
Organization: Mount Holyoke College
Date: Fri, 13 Nov 1992 14:49:36 GMT

In article <1992Nov13.133438.8279@engage.pko.dec.com> jackson@pravda.enet.dec.com () writes:
>The memory for the new systems is priced at $125/MB, which is considerably 
>less than memory from Digital only a few weeks ago. In fact, Digital memory
>is less expensive than that of a third party who announced their memory
>for the DEC 3000 family before we announced the products.  We'll also trade
>in memory from a current workstation when you're upgrading to allow you
>to protect the investment that you've made in memory for our existing products.

Nonetheless it's too expensive... 70ns 1Mb chips are selling for less
than $2.50 per in volume... that works out to less than $25 for a
9-chip SIMM.  If your manufacturing cost is as high as $10/SIMM,
that's still nearly a 300% markup.

These kinds of rediculous markups on memory are common amongst system
vendors however, so on this one DEC isn't alone at least.  I
personally consider this typically nearsighted stupidity, however...
the vendors should have an interest in seeing their systems in
customers hands equipped with as much memory as possible, because that
does the most to increase the perceived price/performance ration of
the system overall.  IMHO memory is a little like tech-support... you
shouldn't be trying to make huge profits on it, you should be trying
to get it delivered as effectively as possible to improve your overall
reputation and acceptance with your customers.

For the more popular personal computers you can get a 4MB SIMM at 70ns
for less than $125.  And don't tell me that it's lower quality... I've
installed probably 1,000 Megabytes of these things in both personal
computers and workstations (including DEC workstations), and if
anything I've had relatively more problems with the workstations.
--
Jurgen Botz                  |   Internet: JBotz@mtholyoke.edu
Academic Systems Consultant  |     Bitnet: JBotz@mhc.bitnet
Mount Holyoke College        |      Voice: (US) 413-538-2375 (daytime)
South Hadley, MA, USA        | Snail Mail: J. Botz, 01075-0629
Newsgroups: comp.sys.dec,misc.forsale.computers.workstation,tx.wanted,uh.wanted
From: dgray@menudo.uh.edu (Dennis Gray Jr.)
Subject: Vax monitor WANTED
Reply-To: DGray@uh.edu
Organization: Academic Computer User Services
Date: Sun, 8 Nov 1992 07:52:27 GMT

In article <1992Nov7.072010.4344@spcvxb.spc.edu> terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.) writes:

     It's a QVSS, like it says. It's a bitonal (B&W only, no shades) card
   which generates a 1024x864 image. Common monitors for this were the VR260
   and VR262. The VR150 should also work. The cable that connects the patch
   panel to the monitor is (I think) a BC18S-10 (that's from memory, I'm at
   home). A LK201 keyboard (same as that on a VT2xx/3xx) plugs into the
   cable assembly. A VSXXX mouse completes the system. An optional digitizer
   tablet plugs into the other 15-pin connector.

I am also told that a VR160 minotor will work with this system.  So if
you have a monitor (and preferably a keyboard, mouse and cables) that
you would like to part with, please let me know.

Thanks a million,
-dennis
---
Dennis Gray, Jr.                                        DGray@uh.edu
"You askin' to become a pile of zeros?  I could put you away so good
that Peter Norton couldn't find you with his arms unfolded."
			  - Lincoln Spector
Newsgroups: comp.sys.dec
From: avolio@dco.DEC.COM (Frederick M. Avolio)
Subject: Re: dxmail on ULTRIX
Reply-To: avolio@dco.DEC.COM (Frederick M. Avolio)
Organization: Digital Equipment Corp., Washington ULTRIX Resource Center
Date: Thu, 12 Nov 1992 18:20:35 GMT


In article <1drnfhINN3cj@ef2007.efhd.ford.com>, mjo@slee10.srl.ford.com (Mike O'Connor) writes:
>:>It's a good address because I had someone on a SUN forward it for me.
>
>It's NOT a good address.  "!" mixed with "@" and "%" mixed with "@"
>can cause problems, and "!" and "%" mixed with "@" usually DOES cause
>problems.  


Nonsense.  It is a perfectly good address.  Good, bad, and ugly are
three different things.  It is an ugly address.  It is confusing only to
someone who doesn't know the rules (@ has precedence), and for broken
sendmail.cf files.

ULTRIX's standard sendmail.cf is broken in that it did not give @ priority
the way most of the world does.  It has been fixed in OSF/1 and in the
original posters situation as well.

f