HDTenEightyP/NetNews huggingface dataset:
From: jeh@cmkrnl.com
Newsgroups: comp.sys.dec
Subject: Re: Ultrix 4.2a on CD-ROM (and DS 5000/125)
Date: 15 Apr 92 22:08:30 GMT
Article-I.D.: cmkrnl.1992Apr15.150830.429
Organization: Kernel Mode Consulting, San Diego CA

In article <1992Apr15.055232.14113@athena.mit.edu>, ankleand@mtl.mit.edu 
(Andrew Karanicolas) writes:
> I have some questions about Ultrix 4.2a:
> 
> (1) Does anyone know for sure whether Ultrix 4.2a is available on CD-ROM?

yes.  I have held the CD-ROM disk in question in my own two hands, and 
attempted to do an install on a DS5000/125 therefrom. 

> As I understand, Ultrix can come installed on the 125 and possibly the
> 200.

Funny you should mention that.  To anyone contemplating purchasing a /125, I
*strongly* recommend a config with factory-installed software, at least for
now.  One of my clients has one of these beasts and the installation procedure
from the 4.2A CD-ROM usually -- but not always -- ends up with error messages
about undefined symbols with 'dc' and 'kn02' prefixes.  (This is with a DEC
person doing the installation, not me.  I wouldn't be involved in this at all,
this is *way* out of my field, but I had already established to my client that
I'm good at troubleshooting things I've never seen before.  I did get it to
work once, but I can't reconstruct what I did....) 

> 
> Please e-mail relevant information.  Thanks,

ok, I'll mail it too, but this is as much a plea for help on the 5000/125 
problem (ie, has anyone else encountered this, and how did you fix it ) as an
answer to your question, so I'll post this as well. 

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
Chair, VMS Programming and Internals Working Group, U.S. DECUS VAX Systems SIG 
Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh
From: azog@thoth.rent.com (Billy D'Augustine)
Newsgroups: comp.sys.dec
Subject: VAX 730 help
Date: 10 Apr 92 06:46:09 GMT
Organization: Cranial Construction Corp


Since I cant seem to get rid of my non-working VAX 730, Im going to
do the next best thing... try to get it working. Hopefully someone
here can help me find what may be the problem.

Normally, when I power the beast on, I would give power to the R80
drive, wait for a minute or two too let the motor speed stabilize.
The I would power on the VAX. At that point, normally, the drive
kicks in with a nice healthy _WHUMP_ and goes ready after a few
seconds (and sometimes blows fuses:-)

What happens now is the drive spins, but never goes ready. I turn on
the VAX, and it goes thru loading the microcode off the TU58 tape, and
at the point where it wants to load VMS, since the drive isnt ready, 
it just kinda heaves up all over the place.

This is kind of a bummer, since Ive got this big box and now it doesnt
work... I seem to think its a cable problem, but I cant find any 
obvious defects in the cable. And the way the thing is, it seems next
to impossible to pull out the cable (actually, two or more?) to
try to test continuity.

Anyone know offhand what I might look at next? Is there a diagnostic
tape I can boot, or similar? Ive got a standalone backup built on an
RL02 pack, but I havent yet tried to boot that, to see if maybe the
RB730 is at fault. (I hope not!)

Please reply via mail, as I dont recive this newsgroup.

Thanx

-- 
Billy D'Augustine                | "Wish I had some goddamned milk!
...rutgers!bobsbox!thoth!azog    | "Cheerieos just aint the same!"
azog@thoth.rent.com              | - Stormtroopers of Death (SOD)
From: bouillin@tele.nokia.fi (Claude Bouillin)
Newsgroups: comp.sys.dec
Subject: VT100
Date: 7 Apr 92 13:46:11 GMT
Distribution: comp
Organization: kpd

Could anybody tell me if the standard DEC VT100 has ever been
published?
Is it available in paper or electronic form? Any help would be
greatly appreciated.

	Thanks in advance.
--
--------------------------------------------------------------------------------
 Claude Bouillin - Telenokia, Kilo TL4e
 Nokia Telecommunications, PO box 12, 02611 Espoo, Finland         Tel 511 7736
--------------------------------------------------------------------------------
Xref: sparky comp.sys.dec:2504 comp.os.vms:8104
From: shah@santur.tay1.dec.com (Amitabh Shah)
Newsgroups: comp.sys.dec,comp.os.vms
Subject: Re: tps benchmarks for VAX 3900
Date: 9 Apr 92 14:41:11 GMT
Followup-To: comp.sys.dec
Organization: Digital Equipment Corporation, TAY1, Littleton MA
In-reply-to: amf@amfent.Gwinnett.COM's message of 8 Apr 92 16:36:49 GMT


On 8 Apr 92 16:36:49 GMT, amf@amfent.Gwinnett.COM (Andy Feibus) said:
> Xref: nntpd.lkg.dec.com comp.sys.dec:9703 comp.os.vms:51727

>> On 6 Apr 92 16:56:42 GMT, mdchaney@bronze.ucs.indiana.edu (M Darrin Chaney) s
>>> Does anyone have the TPPC results for a VAX 3900.  I'm particularly
>>> interested in the tpsA-Local.

>> No, there are no TPC-A results announced on the VAX 3900. Nor are they likely
>> to be announced. The closest machine that DEC has annouced TPC-A results for 
>> the MV 3100-30, which is 21.6 tpsA-local (@$8.6K/tps). 3900 is rated at aroun
>> 4 vups, while the 3100-30 is rated at around 5 vups. You make the final
>> extrapolation.
 
> Arrgg!  Bad advice, Amitabh.

> You cannot extrapolate TPC-A numbers for one system by using another
> system.  He'll have just as much luck trying to extrapolate TPC-A numbers
> for the 3100-30 by using a different DBMS.  Or an RS-6000.  It just doesn't 
> work that way.

I disagree with you. People extrapolate results all the time. Just peek over
into comp.benchmarks. As a Digital representative to the TPC, I know enough
that I can not publicly extrapolate any TPC results. That is why I left the
final step to Darrin. I do not even suggest whether the extrapolation is
linear or non-linear, etc. 

OTOH, I actually have an estimated tpcA-local number for the 3900. It is
extrapolated from various pieces of data, but it is outdated (we have had
newer software releases, better understanding of TPC-A benchmark, etc). But I
would never disclose it publicly, since it is disallowed by the TPC. But this
restriction is only on the TPC members. The customers of these vendors are
free to estimate and extrapolate as much as they want. Indeed, this will be
the case for systems such as the 3900 which is no longer made by DEC, and
hence will never get an official tpc-a number. 

One final note. While TPC-A is a good system level benchmark, it is not
perfect. TPC-C, the benchmark that the TPC is developing, and is expected to
be released soon, will be a better system level benchmark than TPC-A. But,
even TPC-C will not be perfect. Finally, the customer will have to look at all
the available data, use their own benchmarks, and use judicious extrapolation
to consider their final needs.

-amitabh.

--
______________________________________________________________________________
Amitabh Shah                                   shah@tay1.dec.com----(INTERNET)
Digital Equipment Corporation                  santur::shah----------(EASYNET)
Software Performance Group                     +1 508 952 4430---------(PHONE)
151 Taylor St. Littleton MA 01460              +1 508 952 4197-----------(FAX)
From: alan@shodha.enet.dec.com ( Alan's Home for Wayward Notes File.)
Newsgroups: comp.sys.dec
Subject: Re: How compatible is a Decstation 5000 connected to a VAX 6000??
Date: 9 Apr 92 22:04:27 GMT
Organization: Digital Equipment Corp. - Colorado Springs, CO.

In article <1992Apr9.174633.3940@mahendo.jpl.nasa.gov>, robert@triton.jpl.nasa.gov (Robert Angelino) writes:
> Dec World,
> 	I'm trying to convince some managers to off-load some of the
> CPU on the VAX by getting DECstation 5000s and connecting them on 
> a network so that the two machines (VAX and DECstation) can talk
> to each other, exchange files, compile and run the same programs, etc..
> I know DECstations run Ultrix, but how compatible are the two OSs???

How compatible are VMS and ULTRIX?  Not very, but it depends on what
you're doing.  You'd have a hard time running a DCL command procedure
on an ULTRIX system, be it VAX or MIPS.  Various VMS layered products
do a fair job of hiding incompatibilities.

> Can I access files from the VMS system without having to tell it to
> go to the DECstation disk and vice versa (something like NFS on VMS)??

Look at UCX.  Among it's features are an NFS server for VMS.

> Can I port my VMS program to the the DECstation without changing
> anything???  

That depends on how portable your programs are.  Do they take advantage
of any VMS system services or run time libraries?  Any compiler extensions
the VMS compiler support?

> Do I have to worry about byte order and fun stuff like that??   

Not byte order.  Floating point format yes, but not byte order.

> How compatible are binary files???

Depends on the binary data.  If they're nicely aligned integers you
shouldn't have any problem.  Floating point numbers are another matter,
but if you're using FORTRAN there's a feature a DEC FORTRAN that will
do the conversion for you.  Complex data structure are the hardest part
because the VMS languages don't enforce any sort of reasonable data
alignment, unless you explicitly tell them to (VAX C).  The DECsystems
though like seeing well aligned data.

> Can I download a VMS
> binary file with varirable length records and have the DECstation
> able to read it with problems???

You'll probably have to write a program that understands variable
length records and do something reasonable with them.

> Can I do all these thngs with
> the system (DECstation) out of the box or am I wishful thinking???

If your program is portable and you're only using nicely aligned
integer binary data, then the odds are good.  If you're using
VMS system service and run time library stuff, have complex data
structures that include floating point number and poorly aligned
data, the odds are bad.
> 
> Any responses are welcome.
> -- 
-- 
Alan Rollow				alan@nabeth.cxo.dec.com

Newsgroups: comp.sys.dec
From: redmill@ee.eng.ohio-state.edu (Keith A. Redmill)
Subject: Xwindows for VaxStations 2000
Originator: redmill@columbia.eng.ohio-state.edu
Organization: The Ohio State University Dept of Electrical Engineering
Date: Thu, 16 Apr 1992 17:13:08 GMT

In our department we have several Vaxstation 2000 machines (running VMS 5.3)
that should make excellent xwindows terminals.  We talked to our DEC
salesrep about this and apparently DEC has produced an Xwindows package,
but he doesn't know anything about it.

Has anyone installed and used this or other xwindows packages?
Does decus or some other organization have an xwindows implementation
  the would run on our hardware?

Thanks.
keith
-- 
Keith A. Redmill     (redmill@ee.eng.ohio-state.edu)
   Not everything that counts can be counted.
   Not everything that can be counted counts.  -Charles Garfield
Xref: sparky comp.sys.dec:2446 comp.os.vms:8005
From: shah@santur.tay1.dec.com (Amitabh Shah)
Newsgroups: comp.sys.dec,comp.os.vms
Subject: Re: tps benchmarks for VAX 3900
Date: 6 Apr 92 20:40:54 GMT
Followup-To: comp.sys.dec
Organization: Digital Equipment Corporation, TAY1, Littleton MA
In-reply-to: mdchaney@bronze.ucs.indiana.edu's message of 6 Apr 92 16:56:42 GMT


On 6 Apr 92 16:56:42 GMT, mdchaney@bronze.ucs.indiana.edu (M Darrin Chaney) said:
> Xref: nntpd.lkg.dec.com comp.sys.dec:9648 comp.os.vms:51639

> Does anyone have the TPPC results for a VAX 3900.  I'm particularly
> interested in the tpsA-Local.

No, there are no TPC-A results announced on the VAX 3900. Nor are they likely
to be announced. The closest machine that DEC has annouced TPC-A results for is
the MV 3100-30, which is 21.6 tpsA-local (@$8.6K/tps). 3900 is rated at around
4 vups, while the 3100-30 is rated at around 5 vups. You make the final
extrapolation. 

Hope this helps somewhat.

-amitabh.
______________________________________________________________________________
Amitabh Shah                                   shah@tay1.dec.com----(INTERNET)
Digital Equipment Corporation                  santur::shah----------(EASYNET)
Software Performance Group                     +1 508 952 4430---------(PHONE)
151 Taylor St. Littleton MA 01460              +1 508 952 4197-----------(FAX)

--
______________________________________________________________________________
Amitabh Shah                                   shah@tay1.dec.com----(INTERNET)
Digital Equipment Corporation                  santur::shah----------(EASYNET)
Software Performance Group                     +1 508 952 4430---------(PHONE)
151 Taylor St. Littleton MA 01460              +1 508 952 4197-----------(FAX)
From: pniy@vax5.cit.cornell.edu
Newsgroups: comp.sys.dec
Subject: Re: DECstation 5000/240
Date: 6 Apr 92 18:03:41 EST
Distribution: comp
Organization: Cornell University

In article <AJC.92Apr2092400@thendara.pa.dec.com>,
ajc@pa.dec.com (AJ Casamento) writes: 
> 
> 	3rd party disks can be a boot disk. Configuring it as such is more
> 	difficult (and for some drive manufacturer's firmware implementations,
> 	virtually unworkable). But, we're willing to work with any disk drive
> 	manufacturer to overcome this (we're working with three of them right
> 	now, but I'd be willing to hear from HP, Fujitsu, IBM, SUN and anybody
> 	else in the disk drive business as well).
> 
So, what exactly is the probvlem?So, what exato get a Fujitsu disk
for the 240 that should be arriving soon, and would definitely
like to be able to boot from the disk. Surely "virtually unworkable"
is different from impossible, and since one doesn't boot often compared
to other uses of the disk, it shouldn't be such a problem. Is it just
entering in the drive parameters in the initial system installation?
Or what?

		Arthur Smith
		(asmith@icose.msd.anl.gov)
From: phil@cs.wwu.EDU (Phil Nelson)
Newsgroups: comp.sys.nsc.32k
Subject: bootstrap program
Date: 7 Apr 92 19:22:05 GMT
Article-I.D.: strawber.9204071922.AA12976
Reply-To: phil@cs.wwu.edu
Organization: Association for the Prevention of Polar Bears and Kangaroos

>I am a little confused about what the current state of the art in rom
>monitors is. We have the original WBC monitor, we have the "autoboot
>monitor" and we have the forth monitor.

Ok, I'll talk about the autoboot monitor.

  Features beyond (added to) the "standard" (OR WBC) monitor of Summer 90.

  A) SCSI tape routines including "backup" and "restore" 
      (Added by Charles Rennolet)

  B) disk partitions, boot images, and autoboot and boot commands.
      (Added by me.)


  For the autoboot monitor, you must have a disk label on your disk.
   The current version uses the BSD disklabel.  One of your partitions
   must be labeled "boot images".  The boot images will contain executables
   of any stand-alone program that you want.  After the BSD disklabel is
   a table of "boot images".  Included in the information is an ascii name,
   the location in ram of where to load the image, the length of the image
   and the run address.  The "boot" command uses the image information to
   execute a "read" command followed by a "run" command.  There is NO knowledge
   of ANY file system format.  Included are commands to list the partition table
   and to list the images.  The number of images you have on your disk is 
   limited only by the size of the image partition and the size of the images.
   I have had up to 8 or 9 images when I was testing new changes to the minix
   kernel.   One image can be identified as the "default" image to boot IF the
   auto feature is enabled and is engaged.  You can boot any image by using
   the boot command.  Even if the autoboot feature is enabled in the rom, you
   can specify that there is no default image and the autoboot code will not
   boot any image.

 There is a program called "hdsetup" that I use under minix to set up my disk for
   the autoboot monitor.  It will setup both the BSD disklabel and the image
   table.  (It may not be complete for BSD, but will currently work for minix.
   Once BSD is working, hdsetup may be useful only for work with the image table.)
   hdsetup can add or delete images from the image partition.

 A typical setup for use with the autoboot monitor is (512 byte sectors):

   partition 0: sectors 0 -> end of the disk
   partition 1: sectors 2 -> 2047  (boot images)
   partition 2-7: sectors 2048 -> and on as you want file systems or swap
	 partitions.


Since I have been using the autoboot monitor I have used the raw read
command only a few times to read a bootable image.  And when I did,
(usually to change some data in the image before running it) I used
the "images" command of the autoboot monitor to help me find the image
and know how many sectors to read.

This "autoboot" method should allow the pc532 to boot ANY OS.  You
could write a small standalone program to put in the image partition
that could read a BSD file system and boot the real OS from off the
BSD file system.


--Phil
Newsgroups: comp.sys.nsc.32k
From: phil@cs.wwu.EDU (Phil Nelson)
Subject: bootstrap program
Reply-To: phil@cs.wwu.edu
Organization: Association for the Prevention of Polar Bears and Kangaroos
Date: Tue, 7 Apr 1992 22:09:20 GMT

> ... I am assuming that
>this new boot code would go where the kernel is now, and the kernel
>would move to /minix or some similar place in the file system.  Seems
>like a good compromise for those people that want it to boot more like
>...

Sounds good to me!  I'd use such a program.
--Phil
Newsgroups: comp.sys.nsc.32k
From: phil@cs.wwu.EDU (Phil Nelson)
Subject: bootstrap program
Reply-To: phil@cs.wwu.edu
Organization: Association for the Prevention of Polar Bears and Kangaroos
Date: Tue, 7 Apr 1992 22:06:49 GMT

I forgot to mention something about the autoboot monitor:

  It is available for anonymous ftp from iceberg.cs.wwu.edu as the
  file pub/pc532/mon.auto.tar.Z.  It contains two precompiled 
  versions, one for 19200 baud console lines and one for 9600 baud
  console lines.  All you should need to use it is a new eprom and
  a programmer.

--Phil
From: jkp@cs.hut.fi (Jyrki Kuoppala)
Newsgroups: comp.sys.nsc.32k
Subject: Re: GNU tools for pc532
Date: 3 Apr 92 19:03:03 GMT
Organization: Helsinki University of Technology, Finland.

In article <9204020432.AA09123@strawberry.cs.wwu.edu> you write:
>gcc-1.40 with Bruce's as/ld/ranlib/....
>
>  A stage2 compiler produced an exact copy of the stage2 compiler.

By the way, if people are using Bruce's as it could make sense to port
gcc 2.1 to use Bruce's as syntax - I guess it wouldn't be that hard,
the rewritten print_operand_address is a lot easier to understand and
modify than in 1.40.

>GNU ar/ld/....
>  ar and ranlib appear to have some real strange problems.  Ranlib
>  complains about bad object files when the libc.a does not have 
>  a __.SYMDEF.  After ranlib adds one, ranlib runs without complaining!

Hmm, I remember something weird about __.SYMDEF also, but not sure of
the details - anyway, it was something you could solve (perhaps a
complaint about bad archive member __.SYMDEF or something).

>gcc-1.40 with GNU as/ranlib/ld ....
>
>  I never did get this version producing working executables.

With what diffs?  If you are using the alignment Bruce is using, there
are some weird problems with gas sometimes coredumping and perhaps
also producing incorrect code.

>gcc-2.1 with GNU as/ranlib/ld ....

>  When this compiler is used to recompile itself, it does get executables
>  for most of the programs.  (GNU ld core dumped on cc1plus when compiled
>  with the gcc-2.1 compiler.)  When the gcc-2.1 compiled compiler tries
>  to do some work, it crashes fast!  (well, it says there is a syntax
>  error at a location where there is no syntax error.)  This did not
>  pass the "stage2" test!

Hmm, are you using libraries compiled with gcc 2.1?  Perhaps you
should, since the alignment is perhaps different (not sure what
exactly people talk about when they are talking about gcc-1.40-wbc).
My libraries are compiled with gcc 1.39 (with diffs which should be
functionally the same as in 2.1, I think they should be available on
nic.funet.fi).

//Jyrki
From: phil@cs.wwu.EDU (Phil Nelson)
Newsgroups: comp.sys.nsc.32k
Subject: bootstrap program
Date: 6 Apr 92 14:35:46 GMT
Article-I.D.: strawber.9204061435.AA11390
Reply-To: phil@cs.wwu.edu
Organization: Association for the Prevention of Polar Bears and Kangaroos

>...
>best choice...  It's nice to have Suns read /vmunix or /usr/stand/foo
>from the ROM, but I've always thought that there should be a better
>way to do that than to bury all sorts of filesystem code in ROM...

Look at how the autoboot monitor does it...  It works with ALL operating
systems!  In fact, since it now uses the BSD disk labels, it will work
with Minix, Mach and BSD.

--Phil
Newsgroups: comp.sys.nsc.32k
From: pp@linkoping.trab.se
Subject: For sale
Organization: Association for the Prevention of Polar Bears and Kangaroos
Date: Mon, 6 Apr 1992 08:56:01 GMT

Dear pc532-fans!

I'm sorry to say this, but I want to sell my PC532. I don't have the
time it requires to keep it going in a way I want.

We are talking about a fully equiped pc532 with 8 MB of RAM, a 180 MB
disk from Fujitsu (M2614SA if my memory is properly refreshed) and a
typical tower-pc-box with a typical powersupply (200W). Please make
me an offer I can't refuse.

	/pp
Newsgroups: comp.sys.nsc.32k
From: rickr@virtech.UUCP (Rick Rodman)
Subject: Re: PC532 & X11 Windowing - Why not do it now with SLIP / KA9Q & a PC ?.
Organization: Association for the Prevention of Polar Bears and Kangaroos
Date: Sun, 5 Apr 1992 02:09:33 GMT

hello:

> First an Idea, then a Question ......

> I guess most of us want windowing on our PC532s ?
> & we've perceived the problem is lack of hardware ?
..
> 	C) If you have an existing [34]86 Unix with SVGA & X windows + SLIP,
> 	   just connect it to the PC532 serially, & port KA9Q to the PC532
> 	   to support SLIP.  Connect perhaps 4 ttys @ 38.4 kbps between the two.
..

Why not just put a cheap SCSI board in the clone?  There are SCSI boards like
those from Corel that have nothing on them but an NCR chip.
From: jonb@altsys.UUCP (Jon Buller)
Newsgroups: comp.sys.nsc.32k
Subject: Re: bootstrap program
Date: 3 Apr 92 14:25:08 GMT
Article-I.D.: .9204031425.AA20460
Organization: Association for the Prevention of Polar Bears and Kangaroos

>In the mean time I am
>working on a "mini" bootstrap program to read a file from a
>minix filesystem and jump to it. It should go something like
>
>boot: /minix partition-start-block [scsi-adr] [scsi-lun]

Sounds interesting.  How big is it?  And are you planning to make
this the program that boots from the monitor, and then it reads the
kernel, or do you envision this going in the EPROM?  It seems that
booting would be friendlier if it were in EPROM, (but not a WHOLE lot
if done correctly) on the other hand, I forsee a BSD system "coming
soon to a pc532 near you" along with whatever filesystems the Mach
people are using.  Therefore, burning it into EPROM may not be the
best choice...  It's nice to have Suns read /vmunix or /usr/stand/foo
from the ROM, but I've always thought that there should be a better
way to do that than to bury all sorts of filesystem code in ROM...

Jon
Newsgroups: comp.sys.nsc.32k