HDTenEightyP/NetNews huggingface dataset:
From: solman@athena.mit.edu (Jason W Solinsky)
Subject: Re: Fujitsu and America
Keywords: Supercomputer, parallel processing, foreign
Organization: Massachusetts Institute of Technology
Distribution: comp.sys.super
Date: Wed, 29 Jul 1992 22:10:17 GMT

In article <1992Jul29.181851.12025@news.eng.convex.com>, jgardner@convex.com (John B. Gardner) writes:
|> This probably belongs in a .politics newsgroup, but since it involves super
|> computing and started here, I'm puting it here...
|> 
|> In article <40173@skye.dcs.ed.ac.uk> gvw@epcc.ed.ac.uk (Greg Wilson) writes:
|> >In article <1992Jul28.152513.27457@athena.mit.edu>, solman@athena.mit.edu (Jason W Solinsky) writes:
|> >> ....I know the USA will
|> >> make sure that its laws (both written and in the works) prevent its profitable
|> >> sale in the US. I'm not unhappy about that, BTW. In fact I rather like it...
|> >                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|> >> Jason W. Solinsky
|> >
|> >Aah, America, the home of free enterprise ... 
|> 
|> 
|> Hold on a minute.  As easy as it would be for me to do flag waving about
|> American jobs and so forth (which I believe in), I believe there's a logical 
|> reason for the U.S. government to mandate U.S. manufactured supercomputers
|> for many installations.
|> 
|> Namely this;  A very large number of supercomputers purchased by the govt.
|> are for military or security operations (note, I don't *know* this, but I'd
|> say it's a pretty safe bet).  Relying on a foreign power for support, parts,
|> maintenance, etc. of a component that would be critical in wartime would be
|> extremely dangerous.

Personally, I prefer using the reason that we built their economy, and the
few parts we didn't build are MITI subsidized (sp?) so they have gotten far
more help than American supercomputing enterprises. Thus the American
companies deserve a little advantage. Especially when the Japanese
corporations discriminate against American electronics manufacturers to the
point of openly ignoring trade agreements.

I'd say that's pretty much the best way to put it without being inflammatory :-).

Jason W. Solinsky
From: solman@athena.mit.edu (Jason W Solinsky)
Newsgroups: comp.sys.super
Subject: Re: Fujitsu Supercomputer Statement of Direction
Keywords: Supercomputer, parallel processing
Date: 28 Jul 92 15:25:13 GMT
Distribution: comp.sys.super
Organization: Massachusetts Institute of Technology

In article <153j3gINN86a@early-bird.think.com>, sandee@Think.COM (Daan Sandee) writes:
|> In article <1992Jul28.125822.17675@athena.mit.edu>, solman@athena.mit.edu (Jason W Solinsky) writes:
|> |> Without getting rid of any facts about the computer or directions of the company
|> |> this should be rewritten as:
|> |> 
|> |>   After experimenting with several parallel technologies, Fujitsu has build a
|> |>   300 GFLOP machine with hundreds of processors.
|> |> 
|> |> The end.
|> 
|> Apparently the hundreds of lines of marketeers' language did its job. They
|> have fooled you.
|> Actually, they say they are *developing* such a system. They didn't say
|> they *have built* it yet. Scheduled for later this year, but they
|> don't say whether that is the 300-GFLOPS system or a smaller one.

Actually I didn't pay attention to that part because I know the USA will
make sure that its laws (both written and in the works) prevent its profitable
sale in the US. I'm not unhappy about that, BTW. In fact I rather like it, but
its the primary consideration when talking about a Japanese supercomputer.

Jason W. Solinsky
Newsgroups: comp.sys.super
From: sandee@Think.COM (Daan Sandee)
Newsgroups: comp.sys.super
Subject: Re: Fujitsu Supercomputer Statement of Direction
Keywords: Supercomputer, parallel processing
Date: 28 Jul 92 13:46:24 GMT
Distribution: comp.sys.super
Organization: TMC
NNTP-Posting-Host: telecaster.think.com

In article <1992Jul28.125822.17675@athena.mit.edu>, solman@athena.mit.edu (Jason W Solinsky) writes:
|> Without getting rid of any facts about the computer or directions of the company
|> this should be rewritten as:
|> 
|>   After experimenting with several parallel technologies, Fujitsu has build a
|>   300 GFLOP machine with hundreds of processors.
|> 
|> The end.

Apparently the hundreds of lines of marketeers' language did its job. They
have fooled you.
Actually, they say they are *developing* such a system. They didn't say
they *have built* it yet. Scheduled for later this year, but they
don't say whether that is the 300-GFLOPS system or a smaller one.

Daan Sandee                                           sandee@think.com
Thinking Machines Corporation
Cambridge, Mass 02142                                 (617) 234-5044
From: fouts@hplmf.hpl.hp.com (Martin Fouts)
Newsgroups: comp.sys.super
Subject: Re: Fujitsu and America
Keywords: Supercomputer, parallel processing, foreign
Date: 29 Jul 92 21:07:43 GMT
Reply-To: fouts@hpl.hp.com
Distribution: comp.sys.super
Organization: Hewlett-Packard Labs

In article <1992Jul29.181851.12025@news.eng.convex.com>,
jgardner@convex.com (John B. Gardner) writes:  
|> [ In response to remarks about the US gov not buying Japanese
     supercomputers]. 
|> 
|> Hold on a minute.  As easy as it would be for me to do flag waving about
|> American jobs and so forth (which I believe in), I believe there's a logical 
|> reason for the U.S. government to mandate U.S. manufactured supercomputers
|> for many installations.
|> 
|> Namely this;  A very large number of supercomputers purchased by the govt.
|> are for military or security operations (note, I don't *know* this, but I'd
|> say it's a pretty safe bet).  Relying on a foreign power for support, parts,
|> maintenance, etc. of a component that would be critical in wartime would be
|> extremely dangerous.
|> 
|> Now i hardly expect we will ever go to war with Japan, but lines of 
|> comunication and shipping capabilities could be seriously hampered if we
|> were at war with _anyone_.
|> 

Sigh.

1) Supercomputers are not widely used in command and control situations
   because they don't have the high mean time to failure.

2) Most US supercomputers are used for research which would probably
   stop in the kind of war being suggested above, and certainly not
   critical to the prosecution of such a war.

3) Not buying supercomputers for command and control does not imply
   not buying supercomputers for research.

Just because the NRO needs to function in a war doesn't mean NASA
can't buy a supercomputer for computational chemistry.
 
-- 
Martin Fouts                  |  M/S 1U-14
Member of Technical Staff     |  HP Laboratories
EMAIL:  fouts@hpl.hp.com      !  MAIL:  P.O. Box 10490
PHONE:  (415) 857-2971        |  SHIP:  1501 Page Mill Road
  FAX:  (415) 857-8526        |  Palo Alto, CA 94304-1126

novae erratae!
From: gvw@epcc.ed.ac.uk (Greg Wilson)
Newsgroups: comp.sys.super
Subject: Re: Fujitsu and America
Keywords: Supercomputer, parallel processing
Date: 29 Jul 92 07:19:29 GMT
Distribution: comp.sys.super
Organization: Edinburgh Parallel Computing Centre

In article <1992Jul28.152513.27457@athena.mit.edu>, solman@athena.mit.edu (Jason W Solinsky) writes:
> ....I know the USA will
> make sure that its laws (both written and in the works) prevent its profitable
> sale in the US. I'm not unhappy about that, BTW. In fact I rather like it...
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Jason W. Solinsky

Aah, America, the home of free enterprise ... 

 ========================================================================
  Gregory V. Wilson                    ||  For in much wisdom is much
  Technical Coordinator                ||  grief; and he that increaseth
  Edinburgh Parallel Computing Centre  ||  knowledge, increaseth sorrow.
  gvw@epcc.edinburgh.ac.uk             ||               - Ecclesiastes
 ========================================================================
Newsgroups: comp.sys.super
From: Mike Tighe <tighe@convex.COM>
Subject: Re: Fujitsu and America
Originator: tighe@convex1.convex.com
Keywords: Supercomputer, parallel processing, foreign
Reply-To: tighe@convex.com
Organization: Convex Computer Corporation, Richardson, Texas
Distribution: comp.sys.super
Date: Fri, 31 Jul 1992 05:17:15 GMT
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

fouts@hpl.hp.com writes:

> Sigh.

Sigh.

> 1) Supercomputers are not widely used in command and control situations
>   because they don't have the high mean time to failure.
>
> 2) Most US supercomputers are used for research which would probably
>   stop in the kind of war being suggested above, and certainly not
>   critical to the prosecution of such a war.

I don't mean to sound harsh, but unless you have actually worked in those
[black] areas, you are not really qualified to draw those conclusions, are
you? And if you have worked there (as I have), then you know you have to
keep your mouth shut and smile. :-)

Anyway, there is at least one system that is public knowledge. In fact, it
was the topic of the keynote speech at the Banquet during Supercomputing
91. It was an interesting talk, since it gave a rare public glimpse of how
the US uses supercomputers [for military purposes] to solve real problems.

> 3) Not buying supercomputers for command and control does not imply
>    not buying supercomputers for research.

I agree here.

> Just because the NRO needs to function in a war doesn't mean NASA
> can't buy a supercomputer for computational chemistry.

ditto.

Remember though that any "National Security" argument used to justify
buying domestic computers can also be used by other countries for not
buying US computers, and using their own home-grown product.

And one other point. Content. Many of those chips (except Convex GaAs!),
disk drives, etc. all come from the Land of the Rising Sun. So most of
those domestic computers are not all that home-grown after all.
-- 
Mike Tighe, (214) 497-4206
tighe@convex.com
From: eugene@wilbur.nas.nasa.gov (Eugene N. Miya)
Newsgroups: comp.sys.super
Subject: Re: Fujitsu and America
Keywords: Supercomputer, parallel processing, foreign
Date: 30 Jul 92 16:57:26 GMT
Distribution: comp.sys.super
Organization: NAS, NASA Ames Research Center, Moffett Field, CA

John's disclaimer noted.

In article <1992Jul29.181851.12025@news.eng.convex.com>
jgardner@convex.com (John B. Gardner) writes:
>Namely this;  A very large number of supercomputers purchased by the govt.
>are for military or security operations (note, I don't *know* this, but I'd
>say it's a pretty safe bet).  Relying on a foreign power for support, parts,
>maintenance, etc. of a component that would be critical in wartime would be
>extremely dangerous.

It's an international world, and the US spends a good deal for foreign
technology for its own military from countries like England, Israel, etc.

>Now i hardly expect we will ever go to war with Japan, but lines of 
>comunication and shipping capabilities could be seriously hampered if we
>were at war with _anyone_.

True.

>Imagine if the JEWC operations center,

I missed that talk.  It sounded like (from the Keynote) like it would be
interesting.

>Get the picture?  We (the U.S.), were in fact
>aided in our war effort by U.S. computer parts (printers) which had been
>shipped to Iraq and covertly modified for just such an occurence.

This story has largely been relegated to an April Fools Day joke.
Not to say it can't happen.

>Yes, I work for a U.S. manufacturer of supercomputers, so my opinion is no
>doubt biased, but the above arguement still has merit, IMHO.

Oh, yes it has some merit.

Disclaimer: I speak for myself and not the Agency.
It's stupid to shoot yourself in the foot for political reasons when
good interesting technology exists in the world and you don't get it
for strictly paper reasons.

If and when these manufacturers come up something interesting, we should
make an effort to evaluate it.  While the up-sized, IBM compatible
architectures produced so far are basically just faster versions of
antiquated architectures, future machines do deserve a look see.
Non-technical posts don't help this argument, and limited resource machines
(single machines) make using them difficult [i.e. we'd all have to share,
as well as obscure OSes or languages, etc.], one or two useful ideas
may result from research.  The argument about US jobs is short term.
Our looking at their technology COULD engender new jobs on our turf if
we make our ground fertile.  A similar situation happened about 40 years ago
with the transistor.

Face it, people who are going to post press releases should be plastered
with all the real simple (then hard) technical questions: like numbers
of processors, cooling, packaging, software, new languages and OS
(maybe THOSE should be the FAQs?).
 
--eugene miya, NASA Ames Research Center, eugene@orville.nas.nasa.gov
  Resident Cynic, Rock of Ages Home for Retired Hackers
  {uunet,mailrus,other gateways}!ames!eugene
Second Favorite email message: Returned mail: Cannot send message for 3 days
A Ref: Mathematics and Plausible Reasoning, vol. 1, G. Polya
From: lpaul@krissy.msi.umn.edu (Paul Morin)
Newsgroups: comp.sys.super
Subject: Looking for Super '92 call for papers
Date: 23 Jul 92 18:04:44 GMT
Reply-To: lpaul@krissy.msi.umn.edu (Paul Morin)
Organization: University of Minnesota

I mistakenly deleted the Supercomputing '92 call for papers.  Could someone  
send me a copy please.

Thanks much,

Paul Morin

Minnesota Supercomputer Institute

lpaul@krissy.msi.umn.edu
Xref: sparky comp.sys.super:872 comp.lang.fortran:2894
From: lionel@quark.enet.dec.com (Steve Lionel)
Newsgroups: comp.sys.super,comp.lang.fortran
Subject: Re: Inner product / AXPY performance
Date: 30 Jul 92 23:36:50 GMT
Organization: Digital Equipment Corporation


In article <l7gi3fINNmsd@utkcs2.cs.utk.edu>, eijkhout@cupid.cs.utk.edu 
(Victor Eijkhout) writes...
> 
>I would like to get an idea of the difference in performance
>between inner products
> 
>       do i=1,n    x = x + a(i)*b(i)
> 
>and axpy operations
> 
>       do i=1,n   x(i) = x(i) + a*b(i)
> 
>which both have the same number of operations, but the inner product
>has an accumulation, which traditionally seems to be an
>unvectorizable idea.
> 

I tried this with VAX FORTRAN-HPO; as long as one uses the 
/ASSUME=NOACCURACY_SENSITIVE qualifier so that the dot product's reduction
transformation can be performed (the default is ACCURACY_SENSITIVE which
disables transformations that could yield different results than scalar
execution), both forms vectorize very nicely.  (The dot product form,
of course, has a final reduction step that the "axpy" form doesn't need.)
The actual vector mul-add sequences are essentially the same between the two.

Of course, one can also use the BLAS SDOT and SAXPY intrinsics, which
VAX FORTRAN-HPO will expand and vectorize (and parallelize, if you like.)

Steve Lionel                    lionel@quark.enet.dec.com
SDT Languages Group
Digital Equipment Corporation
110 Spit Brook Road
Nashua, NH 03062
Newsgroups: comp.sys.super
From: sivbl@win4.vut.EDU.AU (Brett L Sivies)
Subject: Re: Nameservers
Organization: Victoria University Of Technology, Melbourne, Australia
Date: 22 Jul 92 10:31:53 GMT

mohrc@jacobs.CS.ORST.EDU writes:

>>I am trying to set up a nameserver for a Sequent S81 running Dynix/Ptx
>>(sys5) and am looking for some information/general help on how to do it.
>>where can a good namesever program be found?

I have an S27 and the OS's are the same.. I have PTX 1.3.0

The way I installed the name server on my machine is by simply following
the instructions set out in the admin handbook.

I can mail anyone the named.boot etc files if they would like an example
of the name server files... it is VERY easy to setup..

bye
--
Brett Sivies			e-mail: brett@win4.vut.edu.au (IRC: Supreme)
Systems Programmer		Phone:  61 03 366 2112
Victoria University of Tech.	Fax:    61 03 366 8285
St. Albans			Post:   P.O Box 11428, Melbourne Mail Centre,
From: ccx009@cch.coventry.ac.uk (Adam Bentley)
Newsgroups: comp.sys.sequent
Subject: RPC
Date: 29 Jul 92 10:37:29 GMT
Organization: Coventry University


Has anyone ported the Sun version of rpcgen to Dynix 3.1.2 and the
associated libraries etc. The source version we obtained was from
gatekeeper.dec.com and was /pub/net/rpc/sun/rpc_40* 
We built rpcgen from this source without too many problems but as 
usual sequent have changed their rpc interface so that it differs 
from Sun's....so much for open systems, :-(

We would like this or anything similar that runs on Sequents under
Dynix.......

can anyone help.

(Any replies via email please, or email and comp.sys.sequent).

thanks.


-- 
						_
					       /-\dam

FLESH: Adam Bentley (Fraggle), Systems/Networking, Coventry University. UK
Newsgroups: comp.sys.sequent
From: stevew@majestix.cs.uoregon.edu (Stephen M. Wynne)
Subject: GNU Emacs for DYNIX/ptx?
Organization: /home/users/stevew/.organization
Distribution: comp.sys.sequent
Date: Fri, 31 Jul 1992 11:02:22 GMT

Anybody got GNU Emacs up and running on ptx? I'd like to hear from you if so.

Thanks!
Newsgroups: comp.sys.sequent
From: srikant@skorpio.usask.ca (Srikant Subramaniam)
Subject: Help with Sequent makefile ...
Organization: University of Saskatchewan, Saskatoon, Canada
Date: Tue, 28 Jul 1992 17:17:05 GMT

Hi:

Could somebody out there help me with this problem?

I need to know what exactly are the -Y and -Z options in the Sequent linker?
Does there exist an equivalent on the SGI multiprocessor?

Thanks for helping me out,
-- 
----- 
 |\/\/\/|      Srikant Subramaniam.
 |      |      srikant@cs.usask.ca 
 |	|
 |      |      Disclaimer: This is not what really I look like. 	
 | (o)(o)      Disclaimer: I didn't do it, nobody saw me do it, 
 C      _)                  can't prove anything. 
  | ,___|             
  |   /     
  /---\    
Xref: sparky comp.sys.sequent:462 comp.sys.unisys:419
From: "stuart irving" <stuart.irving@canrem.com>
Newsgroups: comp.sys.sequent
Subject: fax modem available?
Date: 30 Jul 92 21:59:13 EST
Reply-To: "stuart irving" <stuart.irving@canrem.com>
Distribution: comp
Organization: Canada Remote Systems

I have a requirment to be able to fax text documents from our Sequent
which is an S81 running dynix 3.0.19.   Is there such a beast available
to allow me to do this?  We also have terminal servers on the ethernet
so we could also do this by connecting the device to the terminal
server if we could find the fax device and software.

Could someone give me some leads in the Toronto, Canada area?



-------------------------------------------------------------
stuart.irving@canrem.UUCP            -   UUCP
stuart.irving@canrem.com             -   Internet
sirving%corpsqnt@elegant.com         -   Preferred mail feed
---
  DeLuxe/386 1.25 #163  Excuse me. You are standing on my girlfriend!
--
Canada Remote Systems  - Toronto, Ontario/Detroit, MI
World's Largest PCBOARD System - 416-629-7000/629-7044
From: tony@hacgate.SCG.HAC.COM (Tony Reeves)
Newsgroups: comp.sys.sequent
Subject: scsi this...
Date: 23 Jul 92 21:21:57 GMT
Reply-To: tony@hacgate.UUCP (Tony Reeves)
Distribution: usa
Organization: Hughes Aircraft Co., El Segundo, CA

We have a Sequent S81 running the sequent drive controllers running swallow,
super swallows and NEC drives. 

We would like to use any standard scsi drives on our system. Is anyone using
standard scsi drives (like a Maxtor P1-17s?) on a sequent? If so can you use
any scsi drives? what controller do you use? can you format drives while in
multi-user mode?

any answers would be great.

-- 
Why did the Roman Empire Collapse? What is latin for Office Automation?
---- The opitions expressed here are mine and have nothing to do with Hughes
Aircraft Co. -- So there! tony@hacgate.hac.com
Newsgroups: comp.sys.sequent,comp.sys.unisys
From: pete@wvus.org (Pete Gregory)
Subject: multiple SCEDs on one LAN
Organization: World Vision U.S.
Date: Wed, 22 Jul 92 14:03:52 GMT

Hi - PTX 1.1.1 here on 3xS27's + 2xS81's...

One of our S81's has enough tcp connections that we've had to buy a second
SCED card (each SCED card will carry up to 256 tcp connections, a hard
limit).  We want to put it on the same LAN as the first, as our entire
organization operates on one big LAN (composed of 400 PC's, 30 UNIX
workstations, 6 UNIX mainframes, and numerous printer servers).  The idea
here is that some people would telnet to the first SCED card, and others to
the second SCED card, thereby distributing the tcp-connections load evenly
among the two SCED cards and avoiding problems by overflowing one or the
other.

When the two SCED cards' IP addresses are set to be 89.0.0.5 and 89.0.0.40,
the second SCED card end up transmitting ALL outbound packets; netstat -i
looks like this:

Name  Mtu   Network     Address            Ipkts    Opkts    Odrop
loop  1536  loopback-ne loopback               0        0        0
se1   1500  89.0.0.5    john2             664420  1480083        0
se0   1500  89.0.0.40   john             1347890        0        0

...as you can see, the first SCED card sends no outbound packets; hence,
the second SCED card ends up trying to carry > 255 tcp connections.

Something else I've tried: using IP addresses on different network numbers
(ie. 89.0.0.5 and 88.0.0.40), but we can't reach the 2nd SCED card, even
when I manually put entries for the 2nd SCED card in all machines' ARP
tables.

Bottom line question: how does one configure 2-SCEDs-on-1-LAN system ???  
Unisys (our OEM vendor) hasn't been much help.
-- 

Pete Gregory       |  Internet: pete@wvus.org
UNIX SA            |  Bangpath: ames!elroy!wvus!pete
World Vision U.S.  |  Slowpath: 919 W. Huntington Dr., Monrovia, CA 91016
Newsgroups: comp.sys.sequent
From: rick@sjsumcs.sjsu.edu (Richard M. Warner)
Subject: gopher
Organization: San Jose State University, Math & CS
Date: Wed, 29 Jul 1992 18:47:34 GMT

I am attempting to install a gopher system here.  We would like to
allow the users on our S27 (Dynix 3.0.17.9) access.  I have tried
to compile the U. of Minnesota gopher client, and keep hitting 
hurdles.  First, 'make' did not like the UMN Makefile, so I went to
GNU make.  Then the ever present 'string.h' is referenced throughout
the source tree, and I globally changed that to 'strings.h'.  Now
it is complaining because it cannot find 'strchr()'.  

Has anyone made the UMN gopher client?  If so, I would be interested in
your comments or a diff file, if possible.  I would prefer to use
wais, but without is fine for now.

- rick warner -
  rick@sjsumcs.sjsu.edu
Newsgroups: comp.sys.sequent
From: sjn@crayamid.cray.com (Scott Narveson)
Subject: Re: psroff - is there a free version available
Date: 30 Jul 92 14:31:16 CDT

clewis@ferret.ocunix.on.ca (Chris Lewis) writes:
: 
: [...]
: 
: Incidentally, since you're cross-posting to comp.sys.sequent - I assume
: you have a sequent, sequents come with old troff (I think).  In which
: case, the "free" options (aside from groff - you'll need GNU g++ too) are
: thack and my psroff.
: 
: [...]

If the Sequent involved is running some flavor of Dynix 3.x that
includes Sequent's System V Application Environment (meaning you're
living with those wonderful dual universes :-( ), your system does have
a DWB troff (2.0, I think) installed as the "att universe" troff (and
thus has both troffs, since "ucb universe" troff is old troff).  So,
Transcript is an option in that case, although the installation of the
package requires some hands-on tinkering.  But then, few ports of
anything to Dynix 3.x don't involve at least some tinkering...

--

 Scott Narveson                         (612) 683-5803
 Cray Research, Inc.                    sjn@cray.com
 Eagan, MN  55121                       ...!uunet!cray!sjn
Newsgroups: comp.sys.sequent