HDTenEightyP/NetNews huggingface dataset:
From: pavlov@niktow.canisius.edu (Greg Pavlov)
Newsgroups: comp.sys.dec,comp.unix.ultrix,comp.os.vms
Subject: Re: Patches online, was Re: Unix Review review of Alpha/OSF
Date: 27 Jan 93 06:46:07 GMT
Followup-To: comp.sys.dec,comp.unix.ultrix,comp.os.vms
Organization: Canisius College, Buffalo NY. 14208

In article <1993Jan27.003716.3226@decuac.dec.com>, rye@scmbrd.dco.dec.com (Bill Rye) writes:
> 
> 1) I didn't mean to imply that I or DEC thought users were stupid.  I meant
> to imply (and most people picked up on this) that in my opinion, DEC was
> just being extremely cautious by not having patches available. 
> 
  If DEC's primary concerns are in the areas of technical and user support
  problems, I can understand that.  We provide remote support to a set of 
  users whose total number is miniscule when compared to DEC's installed base
  and the range of problems we encounter that are caused by mistakes and care-
  lessness is still incredible.  So, while I would very much like to see DEC
  make patches available on the net, I do not view it as a trivial commitment,
  as some people in this newsgroup have made it out to be.  

> I propose the following: Send me a mail message (since I've already marked
> most of the news messages as read, and came into this discussion in the
> middle,) containing the following information:
> 

  I have nothing against going through this exercise again.  But someone else
  from DEC did this 2-3 months ago and received a flood of replies.  Does any-
  one at DEC know what transpired after that ?
 
> 	If internet access is refused, what other options might work.

  Posting and/or otherwise distributing lists of known bugs and actions taken
  would sure help.

  If DEC's reluctance to make bug fixes available is linked to software support
  payments, it seems to me that, within this narrow view, it could still make
  them available via internet if it was truly committed to this approach: as-
  sign user logins to software support subscribers.  Yes, it would take work.


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

  Similar debates, tho less vociferous, have been going on in the HP and IBM
  newsgroups as well.  So this is not an attitude held by DEC alone nor an
  outlandish request unique to DEC users.

  greg pavlov
  pavlov@fstrf.org
  
Newsgroups: comp.sys.dec,comp.unix.ultrix,vmsnet.alpha
From: jpt@salama.fno.dec.com (Jari Tavi)
Subject: Re: DEC 3000 AXP delivery times
Reply-To: jpt@rixrax.enet.dec.com (Jari Tavi)
Organization: Digital Equipment Corporation
Date: Thu, 21 Jan 1993 12:10:10 GMT



We have delivered several DEC OSF/1 Alpha AXP systems to different customers.
First customer shipments were in November 92 ! These customers ordered the
systems in Early Shipment Program, customers not requesting this have 
been scheduled to March (as far as I know). 

There seems to be confusion in delivery schedules, and I think we may have not
given information detailed enough to avoid all confusing messages. 

DEC OSF/1 AXP is shipping NOW, next "update" and standard (default, 
Factory Installed Software etc.) shipment starts at March time frame.

regards,

	-jari


--
===============================================================================
Full-Name:      Jari Tavi			
Organization:   DEC Finland                     Dept:           DS/OSG
Tel:            +358-0-434 5252	                Fax:            +358-0-452 1392 
E-mail:         jpt@rixrax.enet.dec.com
Address:        Digital Equipment Corporation Oy
                PL 16
                02201 Espoo
                FINLAND
===============================================================================
* All opinions are my personal, and do not necessarily represent opinions of
* my employer!
Newsgroups: comp.sys.dec
Subject: CMD CRD-5000 controller - multihosts?
From: wykes@decus.org.nz (Nick Wykes, Forestry Corporation of NZ Ltd, Rotorua NZ)
Date: 22 Jan 93 12:47:54 +1300
Organization: DECUS New Zealand

Does anyone use CMD's CRD-5000 disk array controller in a purely VAX SCSI
environment? We are looking at them and would like to hear from anyone who
has any experience of them.

We are particularly interested in how the multi-hosting works. If I read the 
glossy right, the controller can turn your SCSI LAVc into a CI-like cluster, 
with RAID thrown in. Or am I missing something?

Thanks in advance
Nick
Forestry Corp of NZ Ltd
Nick@fcnz.co.nz
Newsgroups: comp.sys.dec
From: timv@ccad.uiowa.edu (Timothy VanFosson)
Subject: Re: Need alloca which allocates storage IN the stack frame (Ultrix)
Organization: CAD-Research, U. of Iowa, Iowa City, Iowa
Date: Thu, 21 Jan 1993 16:30:51 GMT

From article <9915020@zl2tnm.gen.nz>, by don@zl2tnm.gen.nz (Don Stokes):
> timv@ccad.uiowa.edu (Timothy VanFosson) writes:
>> Does anyone have an implementation of alloca() which actually
>> sets aside storage in the stack frame?  I'm trying to port
>> the NIH Class Library and have everything working except the
>> process classes, and I've narrowed it down to the DEC implementation
>> of alloca() not being what NIH expects.
> 
> You don't say what system you want this for.  It kinda matters, since you
> can't really do an alloca() in C.
> 
> Anyway, since it's short, here's a VAX MACRO alloca() (code filched from GCC,
> comments by me):
> 

Thanks for the response, but (as you point out) I neglected to mention
that this is for a DECStation 5000/200.  Thanks also to those who
have suggested GNU Emacs/GCC alloca(), but it works (doesn't work :-)
in the same manner as the DEC alloca() -- the storage allocated is
not IN the stack.  I had already tried it before I posted.

I am still looking for an (assembly) version of alloca() which
does manipulate the stack to allocate storage.


--tv
-- 
Timothy VanFosson                             E-mail   : timv@ccad.uiowa.edu
Senior Systems Analyst                        US Mail  : CAD-Research
University of Iowa                                       228 ERF
Phone: (319) 335-5728   FAX: (319) 335-6061              Iowa City, Iowa 52242
Newsgroups: comp.sys.dec
From: alh@einoed.in-berlin.de (Adrian Le Hanne)
Subject: CMU/TEK software for Vax
Organization: Einoed Unix & Netzwerke, Berlin (FRG)
Date: Tue, 26 Jan 1993 13:48:28 GMT

Hello,
recently i send mail to the CMU/TEK people asking how to order their
TCP/IP software for VMS. Unfortunately the CM University seem to have
abandoned this project and therefore the software is now in the public 
domain. The CMU/TEK people gave me the address of an ftp server where
i can get the binaries but unfortunately this access was limited up
to the 1/15/93. Can someone tell me, where i can get the binaries now?
The FTP server is 'drycas.club.cc.cmu.edu', our local nameserver does
not recognize this site, maybe someone can send me the decimal internet 
address. 
(There is the possibility to aquire this software through Decus but
this is in germany far too expensive.)

Please reply via e-mail if possible.

thanks,
Adrian
-- 
Adrian S. Le Hanne        Einoed Unix & Netzwerke, Koepenicker Str.154, D-1000
alh@einoed.in-berlin.de   Berlin 36. Tel.: 030/611 31 26,  Fax.: 030/611 32 86
  "On a day such as this you should insist on more than the truth" -Pere Ubu
From: gezelter@rlgsc.com
Newsgroups: comp.sys.dec
Subject: Re: looking for a DECnet primer.
Date: 21 Jan 93 09:53:15 EST
Organization: Robert Gezelter Software Consultant, Flushing, NY

In article <C16Cwz.1Kw@hpwin052.uksr.hp.com>, danielh@hpber199.swiss.hp.com (Daniel Huber) writes:
> Hi there,
> 
> Is there somebody out there who could point me to an online (or ftp'able)
> DECnet primer?
> I have to learn more about DECnet, but have no time to browse trough a bookstore for a DECnet book...
> 
> 
> Thanks a lot...
> 
> Daniel (a TCP/IP guy.. ;-)
-- 
Daniel,
 
There are a variety of documents which can give you introductory 
material on DECnet, however, your POST is not clear on what type 
of information you need. If you can clarify your need, I should 
be able to point you in the correct direction (do you need 
introductory material on architecture, programming interfaces, 
management, performance, troubleshooting, etc.?)
 
I look forward to hearing from you via email or phone.
 
- 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                                                 |
+--------------------------------------------------------------------------+
Newsgroups: comp.sys.dec
From: brune@luther.che.wisc.edu (Douglas A. Brune)
Subject: Re: VMS on ALPHA PC's
Organization: University of Wisconsin - Madison
Date: 26 Jan 93 12:37:08 CST

In article <1k3pqsINNo4r@mojo.eng.umd.edu> and <1k1javINNvb@sol.tis.com>, 
various authors write:

>>>I think DEC is missing market share waiting for NT. Get the boxes out running
>>>VMS and SoftPC now.

>>workstation, too. Waiting for NT is a strategic blunder.

>Count me in for three. It makes no sense (other than intentional marketing BS)
>to limit the low-end machine to NT and only NT.

I disagree. I expect that porting VMS or OSF/1 to the Alpha PC would
involve significantly more effort than porting NT, because the Alpha
PC is intended to support all kinds of industry standard equipment.
With NT, DEC can take advantage of already-written drivers.  With VMS
or OSF/1, they'd have to put in more effort.

Since DEC was already trying to bring up VMS ond OSF/1 on Alpha/
Turbochannel/Futurebus platforms, and since Microsoft had promised NT
for Q4 1992, I can understand why DEC didn't want to take on an
Alpha/EISA port of VMS and OSF/1. They may regret the decision,
however, if NT slips any more.

Doug    brune@luther.che.wisc.edu
Xref: sparky comp.sys.dec:7117 comp.dsp:3097
From: malcolm@Apple.COM (Malcolm Slaney)
Newsgroups: comp.sys.dec,comp.dsp
Subject: Re: "Are DSP Chips Obsolete?" (was re: Alpha fft performance)
Date: 25 Jan 93 23:18:45 GMT
Followup-To: comp.sys.dec
Organization: Apple Computer Inc, Cupertino, CA

In article <1jn4dn$lbf@agate.berkeley.edu> jbuck@forney.berkeley.edu writes:
>If you're after getting the job done with products that are available
>today, contact Motorola, Texas Instruments, Analog Devices, or any of
>a half dozen other companies who understand the DSP market and don't
>go around publishing poorly conceived papers like "Are DSP Chips Obsolete?".

I think you're being a bit harsh on the paper.  It's hard to argue with their
numbers.

I think the essense of the debate is what is DSP?  I remember salivating over
the multiply instruction on the original Intel 2920 data sheets.  Back then
if you wanted a cheap multiplies you had to use DSP chips.  My how things
have changed.

I think that the DEC paper shows two things.  1) You don't have to use a DSP
chip to get fast multiplies any more and 2) as SGI and NeXT have discovered,
DSP chips don't have much work to do in a workstation.

Admittedly DEC's ALPHA implementation wasn't optimized for low power (rumor
has it that the clock distribution alone accounts for a large part of the 
power.)    But think what would happen if they did.......

Is there anything inherently power hungry and expensive on the current 
RISC chips?  The RISC chips that I'm familiar with do 64 and 80 bit IEEE
floating point.  That's one item that embedded RISC chips can do away with.
Virtual memory support is another.  Are caches that much more power hungry
than large on-chip memory?  What else is left?  A 32 bit IEEE floating point
multiply has to be the same cost.

Still hoping that someday I don't have to program my DSP algorithms in 
assembly language....

							Malcolm Slaney
							Apple ATG
Xref: sparky comp.sys.dec:7092 comp.os.vms:21817
From: mark@infocomm.com
Newsgroups: comp.sys.dec,comp.os.vms
Subject: Re: Multi-hosting SCSI devices
Date: 22 Jan 93 22:20:10 PST
Organization: INFO COMM - Computer Consulting, Redwood City, Ca

In article <1993Jan19.154520.20736@nessie.mcc.ac.uk>, mzagsaa@v4.cgu.mcc.ac.uk (Tony Arnold) writes:
> 
> I run a LAVC where two of the nodes are a 3600 and a 3400. These nodes each
> have a CMD CQD223TM SCSI adapter on them and there is a 1Gb disk on each
> SCSI bus.
> 
> The CMD controllers support multi-hosting, so it is possible to effectively
> connect both controllers on the same SCSI bus. The disks would then be
> accessible from both nodes which would reduce the impact of one or other
> machines going down.
> 
> One of the disks is currently the system disk for the cluster. My question,
> for anyone who may have done this, is it possible to boot both nodes direct
> from the disk (using separate roots, of course) or do I still have to boot
> one from the disk and the other remotely via a MOP request?

Both systems can boot directly as long as you can set BFLAGS on one node to
select an alternate root.  The hardware you have may or may not support this.

Now all sounds peachy, but there are several significant caveats:

	- SCSI cable length is an issue be sure to keep well within the 5
	  meters, and don't try to fill up the SCSI bus with 6 devices.
	- SCSI termination is an issue which implies that even if one node 
	  goes down you can't simply turn it off without removing power
	  on the terminating resistor on one end of the bus.  Doing this will
	  most likely hang the scsi bus or at least make data corruption VERY 
	  likely.
	- If you had more powerful CPU's and had more disks on the bus you'd
	  also have to worry about controller/qbus bandwidth being a serious 
	  limitation (especially if you try to do shadowing).

> Tony Arnold,
> Manchester Computing Centre,
> OpenVMS Systems Manager.
-- 
--
Mark Pizzolato - INFO COMM Computer Consulting, Redwood City, Ca
PHONE:	(415)369-9366	UUCP:  decwrl!infopiz!mark or uunet!lupine!infopiz!mark
DOMAIN:	mark@infocomm.com
Newsgroups: comp.sys.dec
From: jfc@athena.mit.edu (John F Carr)
Subject: VAX 9000 microcode updates?
Organization: Massachusetts Institute of Technology
Date: Fri, 22 Jan 1993 02:46:02 GMT


Are future updates to VAX 9000 microcode planned?

I found what I believe to be a microcode bug, but the person I reported it
to wasn't sure of the plans for future updates.

--
    John Carr (jfc@athena.mit.edu)
Newsgroups: comp.sys.dec
From: toma@db.TC.Cornell.EDU (Rory Toma)
Subject: Vax 11/750, No OS, No tape drive
Organization: Not bloody likely around here!
Distribution: comp.sys.dec
Date: Fri, 22 Jan 1993 22:58:21 GMT

I have the following situation:

I have a Vax 11/750 with a few RA60's. I also have BSD on a few varying
formats of tapes. I have no tape drive. Is there a kind soul out there that
would make a BSD system platter on an RA60 for me?

Thanks
--
toma@tc.cornell.edu	rory@foopub.tucson.az.us
You want me to upgrade to System what?

Newsgroups: comp.sys.dec
From: merz@ips.id.ethz.ch (Andreas Merz)
Subject: UNIBUS and/or QBUS interface description?
Organization: ETH Zurich (Swiss Federal Institute of Technology
Date: Mon, 25 Jan 1993 17:58:02 GMT

I am looking for documentation for the UNIBUS and the QBUS interfaces.
Where can i find something? (books, files, etc.)

Any help is much appreciated!
-- 
 ---------------> Andreas Merz  /  Internet: merz@ips.ethz.ch <----------------
 ------> Interdisciplinary  Project  Center  for  Supercomputing  (IPS) <------
 <-------- *THE* ultimate computer virus:  MSDOS - even with updates! -------->
Newsgroups: comp.sys.dec
From: epeisach@athena.mit.edu (Ezra Peisach)
Subject: Re: Unknown console password on DECstation 5000/33
Keywords: DECstation, console password
Organization: Massachusetts Institute of Technology
Date: Thu, 21 Jan 1993 23:34:19 GMT

Well, if you are daring you could open your machine and pull the battery
(or short out the NVRAM - I forget which). Once the NVRAM is cleared,
there shouldn't be a password. Of course this may void your DEC service
agreement. Check in the manual that comes with your beast and see if
they show you where the NVRAM is.....

I've never had to do this with DEC equipment, but have successfully on
IBM hardware....

	Ezra



Newsgroups: comp.sys.dec
From: beutel@chdasic.sps.mot.com (Jim Beutel)
Subject: Backups with NSR, experience...?
Reply-To: beutel@chdasic.sps.mot.com
Organization: Motorola SPS ASIC, Chandler, AZ
Date: Tue, 26 Jan 1993 20:00:43 GMT


Does anybody out there have any practical experience
with the network backup product called NSR from Digital?


Am presently using a combination of BRU, BudTools, and 
dump. Major pain for multi vendor, multi network config.


Saw a short demo on the product at DEC. Sounds like the 
OSF answer to backup. Want to hear from REAL users of the 
product.....


Regards,

---
-------------------------------------------------------
Jim Beutel	

Motorola SPS ASIC            beutel@chdasic.sps.mot.com
1300 N. Alma School Rd       Computer Operations 
M/S CH290  AZ50              office:  (602) 821-4967
Chandler, Arizona 85224	     telefax: (602) 821-4963
-------------------------------------------------------

The Surgeon General has determined that Skydiving is Extremely addicting.
From: pavlov@niktow.canisius.edu (Greg Pavlov)
Newsgroups: comp.sys.dec
Subject: Re: VMS on ALPHA PC's
Date: 28 Jan 93 09:41:11 GMT
Organization: Canisius College, Buffalo NY. 14208

In article <1993Jan28.121135.1@stimpy.enet.dec.com>, quodling@stimpy.enet.dec.com writes:
> > I, too, would trade the effort required to write VMS drivers for Alpha PC
> > hardware in exchange for an Alpha PC. And I have written drivers for Alpha/VMS.
> 
> There are more than enough people in DEC that will trade effort for hardware.
> Go to the end of the Queue...
> 
> :-)
> 
  Aye, maybe there's the rub:  lot's of people willing to work for hardware
  but not-yet-quite-enough-Alpha-hardware produced to go around ??  :-)  :-)




  greg pavlov
  pavlov@fstrf.org
From: sybertz@brsux0.bro.dec.com (Sybertz Marc)
Newsgroups: comp.sys.dec
Subject: Re: Question on DEC's NSR and what it supports...
Date: 25 Jan 93 14:12:36 GMT
Reply-To: sybertz@ketje.enet.dec.com
Organization: Digital Equipment Corporation, Brussels


In article <1993Jan16.013706.332@wsm.com>, root@wsm.com (System Manager) writes:
>Newsgroups: comp.sys.dec
>From: root@wsm.com (System Manager)
>Subject: Question on DEC's NSR and what it supports...
>
>
>Hello All,
>
>  Does DEC's NSR Network Backup Software (Private Labeled Legato Networker)
>
>have any 3rd party device support in it like the Legato Networker you find
>on the street? SPecifically does anyone knwo if NSR supports SCSI controlled
>jukeboxes or autochangers like the ADIC 12 tape 4mm DAT jukebox or Exabyte
>10i.
>
>
>Thanks...
>
>Jeff Johnson
>jeff@wsm.com
>
>(I know the Legato standard version supports them, but you know DEC....)
>

DECnsr supports at least: 	DEC TZ85/TZ857
				DEC TA90/91
				IGM Models ATL-2300 & ATL-5000

Contact your local sales representative for more infos.

Regards,
Marc Sybertz.

+------------------------------------------+
| From : Marc Sybertz                      |
| Dept : EIS - Unix Service Center         |
| Func : Unix System Management Specialist |
| Mail : sybertz@ketje.enet.dec.com        |
| Loc  : DIGITAL - BRO (Brussels, Belgium) |
+------------------------------------------+
Xref: sparky comp.sys.dec:7182 comp.unix.ultrix:9565 comp.os.vms:22245
From: lionel@quark.enet.dec.com (Steve Lionel)
Newsgroups: comp.sys.dec,comp.unix.ultrix,comp.os.vms
Subject: Re: Patches online, was Re: Unix Review review of Alpha/OSF
Date: 28 Jan 93 19:05:54 GMT
Reply-To: lionel@quark.enet.dec.com (Steve Lionel)
Organization: Digital Equipment Corporation, Nashua NH



In article <1k8qmhINN9jd@sol.tis.com>, mjr@tis.com (Marcus J Ranum) writes...
|>
|>>	Bill, your heart is in the right place, but your horse is dead,
|>>and maybe it's cruelty to animals to flog it further. Gail Grant has
|>>already tried exactly what you're suggesting. Before Gail tried it, I
|>>tried it informally. Gail managed to get the input up to a VP level I
|>>believe before it got stonewalled/sidetracked/ignored/bitbucketted.
|>
|>This is venturing into an area that many groups within DEC are involved.
|>Starting small is the key.  Show that it works and helps, then move onto
|>the next level.
|>
|>Anyone who wants patches online today will be waiting a while, IMHO.
|>

Gail did not get stonewalled, sidetracked, ignored nor bitbucketed.   (Or if
she did, it was not permanent.)  I've just recently authorized DEC Fortran
updates and change notices to appear on such a service which I have every
reason to believe is "coming soon".  I'm sure Gail will make an announcement
when the time comes; I have no further details.
--

Steve Lionel                    lionel@quark.enet.dec.com
SDT Languages Group
Digital Equipment Corporation
110 Spit Brook Road
Nashua, NH 03062
Newsgroups: comp.sys.dec
From: dierick@brsux0.bro.dec.com (Dierick Dominique)
Subject: Re: VMS on ALPHA PC's
Reply-To: dierick@ketje.enet.dec.com
Organization: Digital Equipment Corporation, Brussels
Date: Thu, 28 Jan 1993 08:45:06 GMT


In article <1993Jan28.121135.1@stimpy.enet.dec.com>, quodling@stimpy.enet.dec.com writes:
>Newsgroups: comp.sys.dec
>From: quodling@stimpy.enet.dec.com
>Subject: Re: VMS on ALPHA PC's
>
>In article <1993Jan27.203213.6154@eco.twg.com>, reece@eco.twg.com (Reece R. Pollack) writes:
>> 
>> In article <1993Jan27.121405.27694@infodev.cam.ac.uk>, rf@cl.cam.ac.uk (Robin Fairbairns) writes:
>> I, too, would trade the effort required to write VMS drivers for Alpha PC
>> hardware in exchange for an Alpha PC. And I have written drivers for Alpha/VMS.
>
>There are more than enough people in DEC that will trade effort for hardware.
>Go to the end of the Queue...
>
>:-)

Since there are allready enough volunteers to write EISA device drivers
for VMS, I volunteer for AXP PC OSF/1 ( same conditions : hw for sw )...
Imagine a big specmark PC at home with 3 disks...what OS shall I have
tonight ?

8-)


Dominique
Newsgroups: comp.sys.dec
From: zrepachol@cc.curtin.edu.au
Subject: Re: Unix Review review of Alpha/OSF
Organization: Curtin University of Technology
Date: Sat, 23 Jan 1993 21:39:50 GMT

In article <1993Jan22.091555.19314@rdg.dec.com>, jpt@salama.fno.dec.com (Jari Tavi) writes:
> Umh ;-) Yes, I fully agree that we need net-dist for patches. Don't shoot us
> yet ;-) 
> Still we have to solve the problems with lawyers and regulations, but that
> shouldn't be a problem ... that's what the lawyers exists anyway...
> 
> We need only good, documented and accepted way of distributing patches. This
> shoudl take care of at least following things:
>  - patch history
>  - version compatibilities and incompatibilies
>  - "easy to use interface" to minimize risk for human errors
>  - other things I haven't even thought yet...
> 

You might start by dragging out the old 10/20 software dispatch! Not only were
fixes published, but also fixes to fixes :-) AND SPRs with no fix. Them you
knew where to not put your feet! Not quite as good as removing the mine field,
but at least you knew to be carefull. It also allerted people to look out for
the bug, and generate more info on it to the developers.

~Paul

Newsgroups: comp.sys.dec
From: sjh@Franz.COM (Steve Huey)
Subject: DecStation
Organization: Franz Inc., Berkeley, CA
Distribution: comp.sys.dec
Date: Fri, 22 Jan 1993 23:58:16 GMT


looking for a used DecStation 3100.


--
Steve Huey, Franz Inc.          1995 University Avenue, Suite 275
sjh@Franz.COM (internet)        Berkeley, CA  94704
                                Phone: (510) 548-3600; FAX: (510) 548-8253