HDTenEightyP/NetNews huggingface dataset:
From: jferreir@dos-lan.cs.up.ac.za (JD Ferreira)
Subject: Re: Dead Seagate 296N
Date: Tue, 8 Sep 1992 09:52:12 GMT
Organization: Computer Science Department, University of Pretoria

In article <1992Aug30.012625.10641@ultb.isc.rit.edu> adw3345@ultb.isc.rit.edu (A.D. Williams) writes:
>From: adw3345@ultb.isc.rit.edu (A.D. Williams)
>Subject: Dead Seagate 296N
>Date: Sun, 30 Aug 1992 01:26:25 GMT
>
> Last week my Seagate 296N decided that it wanted to keel over and die.
>I've had the drive for close to 5 years, and used it nearly every day
>then.
>
> The drive wouldn't spin up, until I turned the platter. I figured the
>lubrication gummed up the heads and was preventing it from spinning. 
>(I spun the platter via the ratchet disk on the bottom of the drive,
>not by opening it up.)
>
> However, when the hard drive spins up, it blinks the drive light
>eight times. My computer reports that it can't find the drive on the
>SCSI port, so I can't re-format it or otherwise salvage it via software
>tools.
>
> I know that hard drives have a limited lifetime, but it's a bummer
>that it only lasted 5 years wheras my other 3 MFM drives (on various
>computers) lasted 8 years and are still going strong.
>
> Is there any hope for this drive, or is it only good for an art
>project?
>
> If I have to buy another SCSI drive, is Seagate a good brand, or should
>I consider a different brand?
>                                                         Thanks,
>                                                             Derrick 
>-------------------------------------------------------------------------
>- Derrick Williams   Rochester Institute of Technology | Insert snappy  -
>- adw3345@ultb.isc.rit.edu     Computer Science        | quotation here -
>-------------------------------------------------------------------------

I have a similar problem with a Seagate ST125N drive - I can't access/
low-level format or anything the drive - The drive light just flashes a lot. 
The problem is that this drive is BRAND NEW (never used although out of the 
guarantee period). I opened up the drive and checked it - the platters spinn 
correctly but the heads just goes up and down the platters - as if looking 
for something but not finding anything.

Could anybody shed some light on the problem ?

Thanks David.
Newsgroups: comp.arch.storage,alt.cd-rom
From: jja@cs.tut.fi (Ahola Jari)
Subject: Jukebox for 1000 CDs minimum - does it exist ?
Originator: jja@kaarne.cs.tut.fi
Organization: Tampere University of Technology
Date: Wed, 9 Sep 1992 10:01:59 GMT

Hello,


	Does anyone know if there exists a jukebox system or any other
	method to manage at least 1000 CDROMs and better yet can be
	expanded ?

	All clues mostly appreciated - thank you.

-jja


-- 
Jari 'jja' Ahola       | Tamfelt Oy
Opiskelijankatu 16A12  | P.O. Box 427, 33101 Tampere, Finland
33720 Tampere, Finland | Tel (intl) 358 31 639375 (work)/358 31 174009 (home)
Puh. 931-174009        | Net address: jja@cs.tut.fi, AHOLA@FINTUTA (BITNET)
--
From: dhd@exnet.co.uk (Damon)
Newsgroups: comp.arch.storage
Subject: Re: Information for mass storage systems.
Date: 5 Sep 92 21:40:45 GMT
Organization: ExNet Systems Ltd Public Access News, London, UK

Fujistu also seem to have something in this area...  The details are in
a different office at the mo...

Damon
-- 
Damon Hart-Davis | Tel/Fax: +44 81 755 0077 |1.24|| Cheap Sun eqpt available.
Internet: dhd@exnet.co.uk | Also: Damon@ed.ac.uk || US high-perf motor groups.
--------------------------+----------------------++ >12 mail&news polls / day.
Public access UNIX (Suns), news and mail for #5 per month.  FIRST MONTH FREE.
From: andrew@alice.att.com (Andrew Hume)
Newsgroups: comp.arch.storage
Subject: Re: R/W Optical Drive file system compatibility
Summary: x3b11.1 update
Date: 7 Sep 92 05:52:31 GMT
Article-I.D.: alice.23638
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <1231@admin.mport.COM>, jack@admin.mport.COM (Jack Craig) writes:
> hi rawn,
> 
> you should be aware that iso x3b11.1 is an optic filesystems architecture
> for spanning all os's, single drives, autochangers, worms, erasable,
> and cd-wo. it has been proposed/approved to ecma this summer and is 
> due to be approved by iso sometime next year. 
> 
> i dont know anyone besides myself that is working toward a commercial
> offering, but ed bayshore(edb@hpgrla.gr.hp.com) can tell you more.
> 
> jack...


	ummm, let me clarify this a little. i am the technical editor
for this standard and have slightly more up to date information.

	ECMA-167 is a file system format standard for random access media,
both write-once and rewritable. it is intended for optical media
but will work just fine for magnetic media as well.

	this standard was approved by the ECMA General Assembly on June 26
this year and will be published shortly (i expect the last galley proofs
very soon now). some time after it is published, with a worst case
of December, we expect it to be forwarded by ECMA to ISO for fast track
processing (meaning it becomes a DIS straight away and the 6 mth ISO
ballot starts immediately -- actually 2-3 weeks later).

	the format is designed for interchange amongst a large number of
systems but most attention was paid to PC-DOS and Posix systems
(and to a lesser extent, VMS). It doesn't mention jukeboxes explicitly,
but several members of the developing committee will be using it in
a jukebox environment; the appropriate hooks are there.

	the work was mainly done in the USA in the X3B11.1 committee.
We interacted a lot with ISO SC15 and ECMA TC15 and with teh
Japanese National Committee (which is why we anticpate little trouble
passing the ISO ballot).

	there are at least three othe rimplementation efforts underway;
two, apparently, quite far along. as jack said, ed beshore (the
x3b11.1 committee chair) is the right contact point. his full info is

Edward Beshore
Phone: +1 303-350-4826
FAX: +1 303-350-4675
email: edb@hpgrla.gr.hp.com

	there is a bunch of stuff available about ecma-167.
there is a high-level overview, a programmer's guide and a
very recent draft of teh standard. mail me for details.


			andrew hume
			andrew@research.att.com
From: uncal@talgras.UUCP (Al Amet)
Newsgroups: comp.arch.storage
Subject: Re: Questions on Tape Drives
Date: 14 Sep 92 13:54:53 GMT
Reply-To: uncal@talgras.UUCP (Al Amet (Unc Al))
Organization: Tallgrass Technologies Inc.

In article <44671@ucbvax.BERKELEY.EDU> chiueh@sprite.Berkeley.EDU (Tzi-cker Chiueh) writes:
>Hi, 
>
>I have two questions on tape drives. Hope someone on the net can enlighten me.
>
>1) Although tapes are cheap, but tape drives are more expensive than disk drives.
>    Why is this the case? Also could someone tell me what is the breakdown of a
>   tape drive's cost. For example, the tape transport mechanism, the R/W head, 
>   and the A/D & DSP elctronics.

If disk drives had to track media like tape they would cost more.  If as many
tape drives were made & sold as disk drives they would cost less. 
I don't remember the exact numbers but the figures were like 1000:1 for
quanities manufactured.

>
>2) The "position angle" of a tape head with respect to a tape in 4mm and 8mm 
>   tape drive is 90 and 200+ (?) degrees, but is 0 degree for linear scan tapes.
>   Can someone explain what is the design consideration for this ? 

If you look inside a 4mm or 8mm drive you'll see the head mech is tilted.  This
causes the tracks to be written at ~6 deg. referenced to the bottem edge of the
tape.  The two write heads are placed ~20 deg. positive and negative in
reference to the track angle.  Every other track, written upper edge to lower
edge is at an opposite angle.  This is how azimuth recording is done.  The
track sync signals allow the head positioning mech. to advance or retard the
head speed to allow the head to be centered on the track.  When the head
wanders into the next or past track the deviation of the signal can be used
to calculate exactly how far off track center the head is located.  The linear
tape drives have all the heads fixed to write tracks parallel to the lower
edge of tape.

Several companies have been experimenting with azimuth recording on 1/4"
cartridges.  This will allow 150+ tracks on a 1/4" cartridge.  I doubt we'll
see any of these types of drives until the late 90's when, if I remember
correctly, the patent on azimuth recording runs out.


>   Also, does this mean that for 4mm and 8mm tapes, the head must touch the tape
>   during read/writes?
>

Actually you never want the tape to touch the head with any of them.  The
object is to have just a few molecules of air between the head and the tape.
I use to have a chart that showed objects in reference to a 1/4" cartridge
head.  A human fingerprint was several times the thickness of the distance
between the head and the tape.  Head design is an art.  The object is to
keep the tape wrapped around the head as close as possible without it
touching.

>Thanks.
>
>Tzi-cker


-- 
--------------------------------------------------------------------------
Al Amet (Unc Al)                                    Tallgrass Technologies
uncal@tallgrass.com                                 11100 West 82nd Street
Voice:(913)492-6002                                 Lenexa, KS 66214-3313
Newsgroups: comp.arch.storage
From: infotech@access.digex.com (Dr Sanjay Ranade)
Subject: Re: Information for mass storage systems. 
Keywords: Mass Storage, File Servers 
Organization: Infotech SA Inc
Date: Wed, 9 Sep 1992 06:30:35 GMT

1.Mass Storage Technologies    .........................$49.50
2.State-of-the-Art Report on Mass Storage '92 ..........$195.00

contain lots of information about mass storage systems. (1) is a
book ; (2) is a detailed technical report on the mass storage market,
systems and technologies. Topics covered are : High-Performance File Servers,
LAN File Servers, Backup Servers, Storage Management Software, Helical
Scan Tape, Parallel Disk Arrays, Robotic Storage Libraries,
Comparitive discussions of systems and products from various vendors.


*******************************************************************
Infotech SA Inc.              (301)-989-1785/(301)-989-0838 (Voice)
Silver Spring, MD,            (301)-989-2290 (Fax)
USA                           e-mail : infotech@digex.com
*******************************************************************
  Researching the mass storage market, technologies and systems ...
******************************************************************* 
Newsgroups: comp.arch.storage
From: alvin@netcom.com (Alvin H. White)
Subject: Seeburg or Wurlitzer CD Jukebox?
Date: Thu, 10 Sep 92 18:27:44 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Summary: ? re any application of traditional jukebox to new data.
Keywords: Industrial Strength Traditional Hard Use Reliability

As many of use know over a lifetime or generation of experience
with jukeboxes two of the great names are Wurlitzer, older, and
Seeburg. These were in nightclubs, and got long wear and tear
over years of service.

With that much wear and tear service and durability was important.
I am curious if either of these organizations or remnants of 
their development are involved in current data CD jukeboxes.


alvin@netcom.com

Alvin H. White, Gen. Sect.
G.O.D.S.B.R.A.I.N.
1505 De Rose Way #66 
San Jose, CA 95126 USA

(408) 286-2794
(408) 286-4244

Government Online Database Systems
Bureau for Resource Allocations to Information Networks
[an idea waiting to happen]

120 West 38 North
From: rod@isi.edu (Rodney Doyle Van Meter III)
Newsgroups: comp.arch.storage
Subject: Re: Information for mass storage systems.
Date: 7 Sep 92 01:20:06 GMT
Reply-To: rod@venera.isi.edu (Rodney Doyle Van Meter III)
Organization: Information Sciences Institute, Univ. of So. California


One good source of information is Supernet.  They're accepting
advertising, and a chunk of it is devoted to mass storage.
Since it's a new service, not a lot of vendors are advertising
there yet, but you can pick up a couple of names.

Telnet to supernet.ans.net and follow the directions.

		--Rod
From: kondoff@aspen.NSA.HP.COM (Al Kondoff)
Date: Sat, 12 Sep 1992 19:26:26 GMT
Subject: Re: minimal m/o jukebox system
Organization: HP Networked Systems Architecture - Cupertino, CA
Newsgroups: comp.arch.storage

In comp.arch.storage, mc@emma.la.asu.edu (Mike Caplinger) writes:

    I'm looking for a M/O jukebox of at least 50 GB capacity, *but* I
    don't want an elaborate caching or file migration software package
    with it; I want straight Unix filesystems, one per platter side, and
    some minimal way to change platters.  Anybody know of a vendor?
    Everyone I've found wants to sell me a very expensive "system" and I
    just need the bare bones.  Thanks for any information.

    	Mike Caplinger, Mars Observer Camera
    	mc@msss.com
===============
HP Greeley (Colorado) manufactures M.O. changer mechanisms from 40 to 100 GB
range. Aside from them OEMing these devices to many solution providers, they
have a file system (OSA) that mounts each side of a platter as a UNIX file
system.

HP has several basic products, on their UNIX platforms, which access these
devices in the primitive mode you describe.  The most basic comes gratis with
HP-UX. The next level (optical migration) comes from HP Boebingen (Germany)
where you have to actually pay additional $$.

Either call a HP sales rep, or I can get you the name of a product marketing
type in Greeley. My project is only a user of the MO Jukebox; I don't know
how to get you info on it. Sorry.

- Al Kondoff, HP NSA, Cupertino, CA
From: lupe@ukw.uucp (Lupe Christoph)
Newsgroups: comp.arch.storage
Subject: Re: R/W Optical Drive file system compatibility
Date: 6 Sep 92 10:45:41 GMT
Organization: cic

rawn@manduca.neurobio.arizona.edu (Rawn Shah) writes:


>    One problem we came across immediately is that even if the drives were
>compatible (same disk size & conforming to ISO), the actual file system on 
>the disk as saved by the driver software differs; on the Sun its a SunOS 
>file system and on the DOS-based 486, it uses the FAT tables and such.
>So data stored on a disk on the DOS system cannot be read by the MO drive
>on the Sun and vice versa.

>    I had the idea that I might stick a DOS emulator on the Sun and have
>it read the disks in DOS format. BUT as far as I know the DOS emulator
>I looked up (SoftPC for SunOS 4) does not have any drivers for r/w optical
>drives and even if I did NFS-mount the drive (the other option given by
>SoftPC) the actual file format is still SunOS and so the disks wouldn't
>be readable by the DOS machine.

>    As far as I know so far there are no compatibility measures on such
>kinds of drives. Now there're phase change r/w optical drives but I still
>haven't heard of any compatibility between systems either.

I have two solutions for you. One is hacking the mtools a bit. The mtools
implement the DOS file system portably.

The other is using FILEdriver from OSS. This is a WORM filesystem that
has been implemented on DOS, Novell, and SunOS. Of course the file system
has the same structure on all three platforms; even the code derives from
a common source.

The drawback is that while you can run a WORM filesystem on any random
access media, it will assume WORM behaviour: any sector can be written
at most one time. This seems to be OK with your application, though.
Of course, for MOs FILEdriver offers a "wipe" utility to erase the disk.

If you are interested in FILEdriver, call OSS:

	Optical Software Solutions, Inc.
	Keith Ragsdale
	1956 Marion Court
	Lafayette, CA 94549
	Tel (510) 256-1066
	FAX (510) 256-6461
	Email uunet!ossi.com!ossie!keith
-- 
| ...!unido!ukw!lupe  (German EUNet, "bang")     |  Disclaimer:            |
| lupe@ukw.UUCP       (German EUNet, domain)     |  As I am self-employed, |
| suninfo!alanya!lupe (Sun Germany)              |  this *is* the opinion  |
| Res non sunt complicanda praeter necessitatem. |  of my employer.        |
From: rawn@manduca..neurobio.arizona.edu (Rawn Shah)
Newsgroups: comp.arch.storage
Subject: Re: R/W Optical Drive file system compatibility
Date: 5 Sep 92 19:18:58 GMT
Organization: University of Arizona UNIX Users Group

From article <1231@admin.mport.COM>, by jack@admin.mport.COM (Jack Craig):
> hi rawn,
> 
> you should be aware that iso x3b11.1 is an optic filesystems architecture
> for spanning all os's, single drives, autochangers, worms, erasable,
> and cd-wo. it has been proposed/approved to ecma this summer and is 
> due to be approved by iso sometime next year. 

    So can we get a little more detail as to this proposed standard? And
would it mean hardware changes (either simple changes or a complete overhaul
of the technology)??

> 
> i dont know anyone besides myself that is working toward a commercial
> offering, but ed bayshore(edb@hpgrla.gr.hp.com) can tell you more.
> 
> jack...
> =============================================================================
>  Jack Craig  Microport         SVR4 408-438-UNIX   uunet!mport.com!jack
>              Software Horizons SVR3 408-684-1375   uunet!sco.com!blznrzn!jack
> =============================================================================

Rawn Shah
rawn@neurobio.arizona.edu
From: torbenm@diku.dk (Torben AEgidius Mogensen)
Newsgroups: comp.arch
Subject: Re: CPU and speed question.
Keywords: CPU's,speed, pc's workstations.
Date: 8 Sep 92 10:46:02 GMT
Organization: Department of Computer Science, U of Copenhagen

phd85@seq1.keele.ac.uk (D.H. Holden) writes:


> Hi,
>    I was wondering if any one could resolve my confusion,
>    what is it that makes a workstation faster than a PC
>    apart from the operating system.
>    Because I've just read a article about a PC with a
>    50Mhz clock, would this be faster than say a sun 
>    workstation with 25mhz clock?
>    I also read that dec are bringing out a new chip
>    that can manage 200Mhz, is'nt this a massive jump
>    from current chips, I thought the fastest intel chip
>    only did 66Mhz.

>    Hope this is the right group to post this, comp.arch
>    sounded right,
>    cheers, 
>		Dave

If anything, the operating systems on workstations would tend to make
them slower than PCs, as they are geared towards multi-user systems
with the corresponding larger overhead. Try comparing the speed of an
386 running Unix and X windows with the same machine running Windows.

There are several factors to take into account when explaining the
apparent better speed of workstations:

1) Cycles per instruction. Most workstations nowadays use RISC
processors where most instructions execute in a single cycle. An x86
will generally need several cycles for similar instructions (though
some instructions on the 486 execute in a single cycle). Some of the
newer RISC processors can execute several instructions in parallel and
thus get below one cycle per instruction (on average).

2) Floating point performance. Many workstations have faster floating
point units than PCs, even at comparable clock rates (see above).

3) Registers. The x86 processors have relatively few registers (many
of which are special purpose). This makes it more likely that you will
need to have values in memory, which is slower.

4) Compiler technology. RISC processors generally have a more regular
instruction set and memory model than x86 processors, making it easier
for the compiler to optimize the code. Also, on different generations
of x86 processors (286, 386 and 486) different code is optimal. Many
compilers for PC's still generate code for 286's.

5) Disc speed. The hard discs used on workstations are generally much
faster than on PCs, making many applications run faster, especially if
virtual memory is required.

Even so, some jobs actually are faster on a good PC than on a small
workstation.

The 200MHz of the DEC Alpha is indeed a large leap forwards, even
larger when you consider that it can execute several instructions in
parallel. However, as far as I know, no Alpha based systems are yet on
the market. Also, other manufacturers are beginning to release
processors with 100+ MHz clock speed.

	Torben Mogensen (torbenm@diku.dk)
From: zeke@fasttech.uucp (Bohdan Tashchuk)
Newsgroups: comp.arch
Subject: Computer architects forced to change careers. NOT!
Date: 9 Sep 92 21:33:19 GMT
Article-I.D.: fasttech.1992Sep9.213319.7894
Organization: Fast Technology

In <1992Sep9.061933.28304@news.eng.convex.com> culter@convex.com (Brad Culter) writes:

>	I.M. Pei is a world-renowned architect who also has
>	a reputation for designing buildings that nearly can't
>	be built, often requiring new technology to be invented
>	on the spot by the construction engineers. I think if
>	a computer architect did this, she or he would be forced
>	to change careers.

Not that I can tell.

Take a look at the history of the Intel 432. Was there ever a computer
architecture that was a worse disaster?

And yet, those most directly responsible were (at least initially) allowed an
almost completely free hand to architect what eventually became the Intel 960.
The proprietary crud that was left in the 960 after some sanity prevailed
became the cornerstone of BiiN's non-contribution to the computer industry.

Probably $100e6 down the drain between the 432 and BiiN. Not even taking into
account whether or not the 960 is a financial success or exists simply to
salvage SOMETHING from this whole fiasco.

Since this is ancient history, I mention it because:

	The concept of reward for a job well done and punishment for an abject
	failure doesn't exist in many high-technology companies.

	The 432 should be studied in all engineering schools as an example of
	how NOT to design and implement a computer architecture.

	When screwups like this happen, a LOT of people get hurt in the
	resulting layoffs that endear the company to Wall Street.

The concepts behind RISC have helped bring some sanity back into the field.
Xref: sparky comp.arch:9432 comp.lang.misc:3087 comp.compilers:1554
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch,comp.lang.misc,comp.compilers
Subject: Re: Are 64 Int or FP registers useful?
Keywords: registers, optimize, comment
Date: 14 Sep 92 12:58:06 GMT
Reply-To: hrubin@pop.stat.purdue.edu (Herman Rubin)
Organization: Purdue University Statistics Department

neideck@nestvx.enet.dec.com (Burkhard Neidecker-Lutz) writes:
>Most compilers couldn't deal with that many registers. A good paper about
>a compiler system that could is:

		[References to WRL technical reports deleted.]

With all these claims about how tremendous a job compilers are doing, this
is certainly a counterexample.  

-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054, hrubin@pop.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!pop.stat!hrubin(UUCP)
[So how good are human programmers at using zillions of registers? -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.