Survey

[Craig Jackson drilex1]

In article <7brK02ZFc7RI01 at amdahl.uts.amdahl.com> ikluft at uts.amdahl.com (Ian Kluft) writes:
>In article <1990Sep10.153946.7269 at crl.dec.com> wojcik at crl.dec.com writes:
>>I guess the point I'm trying to make is that there isn't any single attribute
>>that makes an installation "large".  By their very nature, mainframes
>>usually have big user communities and a big farm of disks.  By the same token,
>>large clusters of workstations generally have big user communities and a disk
>>server with a big farm of disks.  It's my feeling that the two styles of
>>computing have more in things in commmon than not.  FWIW.
>
>Point well taken.  I think we have established enough direction to start
>discussions in the topic area.

wojcik does have a good point, but I think in the area of disks there still
is a boundary.  Except for things like the Auspex, few file servers really
support connecting more than about 10 Gigs of disk.  (Also excepting
Amdahls, 3090s, etc running Unix.)

This is a real issue for us--we have a user who would like to keep about
20 GB online at any one time, with convenient access to another 100 GB
of archives.  Right now, even on our mainframe he can only keep about
10 GB up at a time--he pages to tape.  (It's data about international
trade.  I don't know what the current paging scheme is, but at one time
import data was available on even-numbered days, and export data on
odd-numbered days.)

Note that these data don't split real well across multiple boxes--any
give update job will probably go through the whole thing, and any given
access job may access throughout the database.  Given his druthers, the
customer would like to think of it as a single file...  Sure, it's
necessary to break it up for several reasons, but none of them are
natural from the applications standpoint.
-- 
Craig Jackson
dricejb at drilex.dri.mgh.com
{bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}