HDTenEightyP/NetNews huggingface dataset:
From: olin@vger.cheme.cornell.edu (Steve Thompson)
Subject: Re: How are people managing sources?
Reply-To: olin@vger.cheme.cornell.edu
Organization: Chemical Engineering, Cornell University, NY
Date: Sat, 9 Jan 1993 13:22:48 GMT

In article <1993Jan8.191643.1@molbiol.ox.ac.uk>, jasper@molbiol.ox.ac.uk writes:
>In article <1993Jan8.123112.8651@tc.cornell.edu>, olin@vger.cheme.cornell.edu (Steve Thompson) writes:
>> I have a DEC 3000/400 alpha in a cluster with a VAX 4000/500 and a bunch of
>> other VAXes using ethernet for communications. The alpha has its own
>> system disk, but all other files are on the 4000/500, including all
>> user files, rightslist, mail database, batch/print queue database, UAF,
>> etc. 
>This sounds like you ran cluster_config, defined a few logicals and booted....
>Was it really this easy....?  (I wonder what supported will feel like :)

Yes, it was really that easy. I didn't even run cluster_config (I didn't
even look to see if cluster_config was there!); all I did was to edit
sys$system:modparams.dat on the alpha, insert appropriate definitions, run
autogen, copy my sylogicals.com over from the VAX (which defines SYSUAF,
RIGHTSLIST, etc, and mounts the disk that they are on), and booted. The
cluster formed, and that was that. I use all the same startup procedures as
I did on the VAX; no changes were necessary. In my sylogin.com I used
to run an .exe; I had to change this to run it from two different
directories depending on whether it was VAX or Alpha (using the result
of f$getsyi("hw_model").lt.1024). The .exe for the alpha was VESTed from
the VAX version (I have since compiled it natively for a bit more speed).

>> Everything seems to work perfectly!
>Magic!  Well, thats it, I'm off to the cash-n-carry to get one!

I have been using it for production work. It hasn't done anything untoward
yet! Now I am looking forward to seeing what will happen when we get our
4000/610 alpha and I plug in in to the other end of our DSSI bus! (yes, I
do backups).

>> No-one told me that I couldn't tell you, so I did :-)
>Thats 'cos noone thought we would try !

Certainly in our environment it has caused no problems at all. We have
had the alpha CPU pegged for several days now running production stuff.
I ran a large CPU-bound application previously on a set of DECsystem
5000/200's; it's 5.2 times faster on the Alpha (but maybe it could be
speeded up somewhat; all I did was compile and go for now). Incidentally,
the VESTed version of my CPU hog ran at about the same speed as the
4000/500.

Steve

---------------------------------------------------------------------------
Steve Thompson, System Mangler   Internet: thompson@cheme.cornell.edu
School of Chemical Engineering   Bitnet:   thompson@crnlchme
Olin Hall, Cornell University    Phone:    (607) 255 5573
Ithaca NY 14853
---------------------------------------------------------------------------
Newsgroups: vmsnet.alpha
From: hallam@zeus02.desy.de (Phill Hallam-Baker)
Subject: Re: DFS & DQS (was "Re: How are people managing sources?")
Reply-To: Hallam@zeus02.desy.de
Organization: Deutsches Elektronen Synchrotron, Experiment ZEUS bei HERA
Date: Wed, 13 Jan 1993 01:24:51 GMT

In article <1993Jan12.153551.15221@kpc.com>, wheeler@thorn.kpc.com (Lloyd
Wheeler) writes:

|>In article <1993Jan7.195359.1@vax.path.ox.ac.uk>, jasper@vax.path.ox.ac.uk
|>writes:
|>|> In article <4362@mitech.com>, gjc@mitech.com (George J. Carrette) writes:
|>|> > How are people managing their sources now that there are two VMS
|>|> > platforms, VAX and ALPHA?
|>|> > 
|>|> > For example, I would love to be able to access my CMS libraries
|>|> > that are sitting on my VAX directly from my ALPHA machines.
|>|> > However, CMS does not support any network operations, and mixed vms
|>|> > clusters are not something that claim to be supported.
|>|> > 
|>|> o o o
|>|>
|>|> Other options are said to be DFS and DQS. Any comments?
|>
|>DQS (Distributed Queueing Services) would not, per se, provide a shared
|>filesystem, but simply a method for submitting jobs cross-network.
|>
|>DFS (Distributed File System) provides a shared filesystem approach, but at
|>least as of a couple years ago (circa 1990-1991) it did not support shared
|>access to modifiable files (that is, it didn't support record locking).  In
|>the same timeframe, such a modifiable file was at the heart of a CMS library,
|>and hence using DFS would restrict you to a single CMS library access at a
|>time (if memory serves).
|>
|>Things may have changed in either CMS or DFS;  I suggest that you just get 
|>a very clear answer before you buy (although I don't recall a reference to 
|>CMS, the limitations on filesharing were outlined pretty clearly in the DFS 
|>documentation).

My understanding of the CMS docs is that DFS is what you are intended to use for
sharing CMS in that manner. Don't know how though...

Certainly the VMSy bits must have been pruned to get it running on the ULTIX
boxen.

--

Phill Hallam-Baker
From: gjc@mitech.com (George J. Carrette)
Newsgroups: vmsnet.alpha
Subject: Re: real-time
Date: 12 Jan 93 09:58:14 GMT
Distribution: usa
Organization: Mitech Corporation, Concord MA

In article <1993Jan12.023034.126@alw.nih.gov>, rge@helix.nih.gov (roger erickson) writes:
> Will there ever be a simple, SMALL (note emphasis!!!), fast real-time OS
> that will run on Alpha machines? 
> 	I mean something like Rt-11 (NOT Rsx) on the PDP or OS/9 on
> Motorola machines.
> 	I'd buy it in a minute.

Well, my ALPHA has 224 MB of RAM. And a tailored VMS system is
plenty small enough to fit entirely in a ram disk on it. Seriously,
if you need a realtime machine as fast as an ALPHA you are probably going
to be doing a lot of numeric processing for which you do need a lot
of RAM anyway. 

VMS can boot from the network and run without a disk. 
Device drivers are dynamically loadable. Any process can lock down
memory in various ways. The scheduler is reliable. Sure, it is 
a lot more complex than Rt-11, (and if you don't like RSX ...).

There are a few companies that sell and support portable realtime O/S's
for Intel and Motorola microprocessors. Some have even done sparc ports,
although the sparc is in the noise level for imbedded systems when compared
to Intel and Motorola chips. If you really have good reason to use an ALPHA
chipset I'm sure that one of these companies could support you with an O/S.

-gjc
Newsgroups: vmsnet.alpha
From: wheeler@thorn.kpc.com (Lloyd Wheeler)
Subject: DFS & DQS (was "Re: How are people managing sources?")
Organization: Kubota Pacific Computers Inc.
Date: Tue, 12 Jan 1993 15:35:51 GMT

In article <1993Jan7.195359.1@vax.path.ox.ac.uk>, jasper@vax.path.ox.ac.uk writes:
|> In article <4362@mitech.com>, gjc@mitech.com (George J. Carrette) writes:
|> > How are people managing their sources now that there are two VMS
|> > platforms, VAX and ALPHA?
|> > 
|> > For example, I would love to be able to access my CMS libraries
|> > that are sitting on my VAX directly from my ALPHA machines.
|> > However, CMS does not support any network operations, and mixed vms
|> > clusters are not something that claim to be supported.
|> > 
|> o o o
|>
|> Other options are said to be DFS and DQS. Any comments?

DQS (Distributed Queueing Services) would not, per se, provide a shared
filesystem, but simply a method for submitting jobs cross-network.

DFS (Distributed File System) provides a shared filesystem approach, but at
least as of a couple years ago (circa 1990-1991) it did not support shared
access to modifiable files (that is, it didn't support record locking).  In
the same timeframe, such a modifiable file was at the heart of a CMS library,
and hence using DFS would restrict you to a single CMS library access at a
time (if memory serves).

Things may have changed in either CMS or DFS;  I suggest that you just get 
a very clear answer before you buy (although I don't recall a reference to 
CMS, the limitations on filesharing were outlined pretty clearly in the DFS 
documentation).

Lloyd Wheeler
wheeler@kpc.com
Former VAX/VMS dude
Newsgroups: vmsnet.alpha
From: olin@vger.cheme.cornell.edu (Steve Thompson)
Subject: symbol_vector syntax?
Reply-To: olin@vger.cheme.cornell.edu
Organization: Chemical Engineering, Cornell University, NY
Date: Tue, 5 Jan 1993 10:56:37 GMT

Having just begun porting an application to VMS on the Alpha, I have
a question concerning the format of the SYMBOL_VECTOR command in
a linker options file. Of course, I don't have the new linker manual.
I realize that one now replaces macro-coded transfer vectors by
linker options of the form:

	SYMBOL_VECTOR=(routine1=PROCEDURE,routine2=PROCEDURE,...)

etc. What other values are accepted in place of PROCEDURE? For
example, I have a VAX/VMS shareable image that defines a couple of hundred
universal message symbols (ie created in a .MSG file and linked in
with the shareable image). In the linker options file, I have:

	UNIVERSAL=PROG__MSG1
	UNIVERSAL=PROG__MSG2, etc.

What is the appropriate form of SYMBOL_VECTOR command to replace this?
Thanks, one and all.

Steve

---------------------------------------------------------------------------
Steve Thompson, System Mangler   Internet: thompson@cheme.cornell.edu
School of Chemical Engineering   Bitnet:   thompson@crnlchme
Olin Hall, Cornell University    Phone:    (607) 255 5573
Ithaca NY 14853
---------------------------------------------------------------------------
From: jasper@molbiol.ox.ac.uk
Newsgroups: vmsnet.alpha
Subject: Re: How are people managing sources?
Date: 8 Jan 93 18:16:43 GMT
Organization: Oxford University Molecular Biology Data Centre
Nntp-Posting-User: jasper

In article <1993Jan8.123112.8651@tc.cornell.edu>, olin@vger.cheme.cornell.edu (Steve Thompson) writes:
 
> I have a DEC 3000/400 alpha in a cluster with a VAX 4000/500 and a bunch of
> other VAXes using ethernet for communications. The alpha has its own
> system disk, but all other files are on the 4000/500, including all
> user files, rightslist, mail database, batch/print queue database, UAF,
> etc. 

This sounds like you ran cluster_config, defined a few logicals and booted....

Was it really this easy....?  (I wonder what supported will feel like :)

> Everything seems to work perfectly!

Magic!  Well, thats it, I'm off to the cash-n-carry to get one!
 
> No-one told me that I couldn't tell you, so I did :-)

Thats 'cos noone thought we would try !

I wonder though, what will they be shipping extra when it is supported?

regards,  jasper

jasper@molbiol.ox.ac.uk
Newsgroups: vmsnet.alpha
From: larry@eco.twg.com (Lawrence B. Henry III)
Subject: Re: symbol_vector syntax?
Reply-To: larry@eco.twg.com
Organization: The Wollongong Group (East Coast Operations)
Date: Tue, 5 Jan 93 15:53:48 GMT


In article <1993Jan5.105637.25287@tc.cornell.edu> you write:
|>Having just begun porting an application to VMS on the Alpha, I have
|>a question concerning the format of the SYMBOL_VECTOR command in
|>a linker options file. Of course, I don't have the new linker manual.
|>I realize that one now replaces macro-coded transfer vectors by
|>linker options of the form:
|>
|>	SYMBOL_VECTOR=(routine1=PROCEDURE,routine2=PROCEDURE,...)
|>
|>etc. What other values are accepted in place of PROCEDURE? For
|>example, I have a VAX/VMS shareable image that defines a couple of hundred
|>universal message symbols (ie created in a .MSG file and linked in
|>with the shareable image). In the linker options file, I have:
|>
|>	UNIVERSAL=PROG__MSG1
|>	UNIVERSAL=PROG__MSG2, etc.
|>
|>What is the appropriate form of SYMBOL_VECTOR command to replace this?
|>Thanks, one and all.
|>
|>Steve

Steve,
	The SYMBOL_VECTOR linker option has multiple incarnations.. where
in general it is described as:

SYMBOL_VECTOR=([[alias_name/]symbol-name=]symbol-vector-entry-type)

symbol-vector-entry-type may be any of:

DATA		  - symbol vector for data cell
PRIVATE_PROCEDURE - creates enty for a routine that is not propageted to the 
		    GST of the shareable image
PRIVATE_DATA 	  - same as above except is for data
PROCEDURE 	  - vector entry for a routine entry
PSECT		  - create entry for a program section
SPARE		  - reserve space for a future entry

Notice that DEC also allowed for aliasing of symbol names.. I believe for the
replacement of what you have you want..

SYMBOL_VECTOR=(PROG__MSG1=DATA)
SYMBOL_VECTOR=(PROG__MSG2=DATA)

-Larry.
Newsgroups: vmsnet.alpha
From: rge@helix.nih.gov (roger erickson)
Subject: real-time
Organization: National Institutes of Health, Bethesda
Distribution: usa
Date: Tue, 12 Jan 1993 02:30:34 GMT

Will there ever be a simple, SMALL (note emphasis!!!), fast real-time OS
that will run on Alpha machines? 
	I mean something like Rt-11 (NOT Rsx) on the PDP or OS/9 on
Motorola machines.
	I'd buy it in a minute.
From: fredv@abba.acs.uci.edu (Fred Velijanian)
Subject: Re: ALPHA VMS or OSF/1 ?
Newsgroups: vmsnet.alpha
Organization: University of California, Irvine
Date: 8 Jan 93 16:30:54 GMT

In article <1ik7eeINN9tt@umbc5.umbc.edu> themos@umbc3.umbc.edu (Mr. Themos Pentakalos) writes:
>Hello everyone.
>In a few weeks, we will be receiving a 3000 Model 400  but we have not
>specified an operating system for it. Can you please answer these
>questions for me:
>
There are different part numbers for VMS and OSF/1 system. What part
number have you ordered? 

>In chosing between OSF/1 and VMS, what are the benefits/problems, besides
>the obvious differences of the operating systems?
>
VMS AXP 1.0 was officially released in Nov 1992. OSF/1 AXP won't be
released officially until March 1993. It's possible that you'll receive
a VMS system quicker than an OSF/1 system....

>Also, according to our rep, it is very simple and also free for us if we
>chose to change opearting systems on the machine sometime in the future.
>How true is that?
>
As far as VAXes are concerned, you cannot change OS's unless you pay for
an additional OS license fee. All along I believed the same to be true
of AXP as well. Ask your salesrep to double check this, or get this in
writing!

>Why are we getting an Alpha? Well, like the VP said at DECUS:
>"so we can finally run All-in-1..."

If you're serious, I guess you'll need to have VMS, since All-in-1
doesn't run on OSF/1! I would probably get Alpha, since as the VP
said, "Alpha really annoys Scott McNealy" :-)

Fred Velijanian
University of California, Irvine
fredv@uci.edu
From: gjc@mitech.com (George J. Carrette)
Newsgroups: vmsnet.alpha
Subject: Re: SYSGEN - 'internal value'?
Date: 12 Jan 93 10:01:04 GMT
Organization: Mitech Corporation, Concord MA

In article <1993Jan11.172104.1@cudnvr.denver.colorado.edu>, dwing@cudnvr.denver.colorado.edu (Dan Wing) writes:
>   WSINC                     1200       2400         0        -1 Pagelets   D
>    internal value             75        150         0        -1 Pages      D
>   WSINC_SYS                    0          0         0        -1 Pagelets   D

Well, 8192 / 512 = 16. And 75 * 16 is certainly = 1200.

> (I thought it was the page/pagelet conversion based on the page size of
> the box, but some other parameters (SPTREQ, CLISYMTBL) don't show an internal
> value.)
Newsgroups: vmsnet.alpha
Subject: Re: alpha performance question
From: seymour@stein.u.washington.edu (Richard Seymour)
Date: 11 Jan 1993 19:24:28 GMT
Organization: University of Washington, Seattle
NNTP-Posting-Host: stein.u.washington.edu

In article <1993Jan10.232804.1030@qualcomm.com> antonio@qualcomm.com (Franklin Antonio) writes:
>I haven't seen any performance benchmark data on alpha-based machines
>posted by users.  Has someone done some measurements of speed of some
>program you've ported to an alpha-based machine vs same running on some
>model of VAX?  ..or even some other brand?

we managed to borrow an AXP 3000/500 for the two weeks ending Jan 6th.
ooohhhh... although most of our people we gone for the holidays, the few
 who remained reported fifty times faster performand than a VAXstation 3100/38,
 and five to seven times faster than an HP 9000/710.
These were biggy Fortran number-crunch, with lots of transcendental-routine
 calling deep in the loops. (which kills HP's)
The machines in question were: VAXstation 3100/38, 8mb
  Alpha AXP  3000/500, 96mb, dual 400mb disk (the OpSys and Fortran FILLED one)
  HP 9000/710, 48mb, 1Gb disk.
The program which got the most use repetitively runs thru a 50k block file.
 The Alpha showed 30% idle-time , which i assume was waiting for the disk.
Other users also reported the 50x factor over the 3100.
We also tried a program against an 11/780.  Due to an undiscovered bug,
 we had to run it non-optimized on the ALPHA.  it was still 68x faster.

But- if you want an Alpha to reaaaallllyyyy  drag, try WATCH under DEBUG.
They apparently don't have the memory-locking hardware trap a VAX does.
They -trace- every instruction as it executes to see if it modifies the 
 WATCHed locations.  very, very, VERY slow...

We also ran into a Open/Closed VMS difference: the LIB$FIXUP_FLT and its
 kin don't work under OpenVMS AXP (which is explained in HELP.. VERY good
 cross-platform HELP information... kudos to DEC)
We also tried joining it to our cluster (of course!), but LMF got upset.
It -did- manage to join (for a few seconds), and the cluster manager 
complained about differing VMS version numbers (what? OpenVMS V1.0 not 
the same as A5.5-2??)
--dick (i want one (or two, or three...))
From: gavron@spades.aces.com (Ehud Gavron 602-570-2000 x. 2546)
Newsgroups: vmsnet.alpha
Subject: Re: alpha performance question
Date: 12 Jan 93 15:15:00 GMT
Reply-To: gavron@ACES.COM
Organization: ACES Consulting Inc.
News-Software: VAX/VMS VNEWS 1.4-b1

In article <1ishhcINNdhd@shelley.u.washington.edu>, seymour@stein.u.washington.edu (Richard Seymour) writes...
#We also tried joining it to our cluster (of course!), but LMF got upset.

I don't know why.  Ah... ahh... I'm going to sneeze... ahhh ahh...
I'm going to sneeze.... Look out:

$ LICENSE REGISTER VMSCLUSTER -
        /ISSUER=DEC -
        /AUTHORIZATION=MAC-10-AK-47-WOOF -
        /PRODUCER=DEC -
        /UNITS=0 -
        /TERMINATION_DATE=30-JAN-1993 -
        /AVAILABILITY=E -
        /OPTIONS=(ALPHA,MOD_UNITS) -
        /CHECKSUM=2-GCDM-NEAJ-PKAN-FFFL

(CSLG never had it so good)

#It -did- manage to join (for a few seconds), and the cluster manager 
#complained about differing VMS version numbers (what? OpenVMS V1.0 not 
#the same as A5.5-2??)

	Yeah but it will live.  And the queueing system will use
	the old (5.4) format.  but it's just fine.

#--dick (i want one (or two, or three...))

	Ehud

--
Ehud Gavron        (EG76)     
gavron@vesta.sunquest.com
From: themos@umbc3.umbc.edu (Mr. Themos Pentakalos)
Newsgroups: vmsnet.alpha
Subject: ALPHA VMS or OSF/1 ?
Date: 8 Jan 1993 10:43:10 -0500
Organization: Univ. of MD, Baltimore County
NNTP-Posting-Host: umbc5.umbc.edu

Hello everyone.
In a few weeks, we will be receiving a 3000 Model 400  but we have not
specified an operating system for it. Can you please answer these
questions for me:

In chosing between OSF/1 and VMS, what are the benefits/problems, besides
the obvious differences of the operating systems?

Also, according to our rep, it is very simple and also free for us if we
chose to change opearting systems on the machine sometime in the future.
How true is that?

Why are we getting an Alpha? Well, like the VP said at DECUS:
"so we can finally run All-in-1..."

Thanks in advance,

Newsgroups: vmsnet.alpha
From: antonio@qualcomm.com (Franklin Antonio)
Subject: alpha performance question
Organization: Qualcomm, Inc., San Diego, CA
Date: Sun, 10 Jan 1993 23:28:04 GMT

I haven't seen any performance benchmark data on alpha-based machines
posted by users.  Has someone done some measurements of speed of some
program you've ported to an alpha-based machine vs same running on some
model of VAX?  ..or even some other brand?

If you are able to publish same, I would like to see it.
From: murphy@npri6.npri.com (David P. Murphy)
Newsgroups: vmsnet.alpha
Subject: Re: How are people managing sources?
Date: 8 Jan 93 15:27:52 GMT
Distribution: world
Organization: NPRI, Alexandria VA


>> How are people managing their sources now that there are two VMS
>> platforms, VAX and ALPHA?
>> 
>> For example, I would love to be able to access my CMS libraries
>> that are sitting on my VAX directly from my ALPHA machines.
>> However, CMS does not support any network operations, and mixed vms
>> clusters are not something that claim to be supported.
>> 
>>gjc@mitech.com (George J. Carrette)

 >Well, I don't have an Alpha (yet), but the word on the street is that you can
 >cluster VAX and Alpha. 'and anonymous official from our favorite computer
 >company" said that it would work, it just was 'not supported'. 
 >Does anyone have a mixed cluster working?
 >
 >jasper@vax.path.ox.ac.uk (Jasper Rees)

yeah, NPRI has a flamingo clustered in with all the vaxes.  we keep all
of our CMS libraries on one of the vax disks and the reference-directories
are all under one tree on another vax disk, so i just mirrored all of
the [SRC...] directories from the reference disk onto the axp disk,
so we essentially have _two_ reference directories for each CMS library
(one on vax, one on axp).  guess i should mention that we always use
a command procedure i wrote to RESERVE and REPLACE elements, so it was
easy to add a COPY command after the CREATE and REPLACE commands.

it's worked pretty well.  so well, in fact, that i test-build on axp
before building on vax!  loooooove that DECC compiler!!

ok
dpm
-- 
murphy@npri6.npri.com 602 Cameron St. Alexandria, VA 22314 (703) 683-9090

              When every one is dead the Great Game is finished.  Not before.
                              --- Hurree Babu, "Kim"
From: gjc@mitech.com (George J. Carrette)
Newsgroups: vmsnet.alpha
Subject: Re: ALPHA VMS or OSF/1 ?
Date: 11 Jan 93 10:47:03 GMT
Organization: Mitech Corporation, Concord MA

In article <1ik7eeINN9tt@umbc5.umbc.edu>, themos@umbc3.umbc.edu (Mr. Themos Pentakalos) writes:
> In chosing between OSF/1 and VMS, what are the benefits/problems, besides
> the obvious differences of the operating systems?

Take a look at the CD-ROM consolidated software distribution.
Consider that in *.EDU your software license costs are NIL for
most of these products.

Then consider that under Unix you will end up paying real dollars
and/or real local implementation and administration time for many
basic conveniences.

On item that came to mind for me the other day, as I was touring my
old haunts at the MIT labs for AI and computer science:

 * a file and tape archiving system.

In the old days (circa 1980) a place like MIT was a DEC-HARDWARE and
some homebrew or TOPS-20 type house. People actually got used to
the fact that backups and archives were reliable, and that files could be
located and retrieved months or years later with little effort.

But then around 1983 we had the "great leap forward" to Unix. The rest
is a very long story.

Stick with VMS, let the other more famous places eat up their graduate
students and others in low-level, boring, repetitive computer-related tasks.

Anyway the DOMINANT operating system in terms of installed base
on ALPHA could very well be NT. Ask you friendly rep about that.

-gjc
Newsgroups: vmsnet.alpha