Card Columns (was Why did they make ... ?) 
Author Message
 Card Columns (was Why did they make ... ?)

Ah yes.  A job that did a lot of seeks on a 2311 would cause the whole
unit to vibrate like an out-of-balance washing machine.  I used to work
with a girl who loved to sit on top of the drives when they were seeking
wildly.


Quote:
> > Other pet terms I recall were "Maytag" for the 2311 disk drive,
> > which somewhat resembled a top-loading washing machine,



Mon, 11 Jul 2005 05:50:17 GMT  
 Card Columns (was Why did they make ... ?)


Quote:

> >IIRC, the abbreviation DDT stood for "dynamic debugging technique".

> >DDT *has* to have been a backronym.

> Not to anyone who knows what "Flit" is.  It's more likely a "necessary"
> acronym to which a set of English words had to be found.

Errm, that's what I meant by backronym.  Someone invents the
"abbreviation" first, and then makes up the words to justify it.  (I'm
sure I've recounted the invention of the names TRAP4/5 and [my] TARDIS
in afc before, surely.)

--

    "We can no longer stand apart from Europe if we would.  Yet we are
    untrained to mix with our neighbours, or even talk to them".
                                              George Macaulay Trevelyan, 1919



Mon, 11 Jul 2005 07:35:28 GMT  
 Card Columns (was Why did they make ... ?)

Quote:
> >Burroughs Medium Systems (if my memories are correct).

> I assume that you mean the B2500 et al; it had JCL.

> >        FD  DSKFIL

> And DSKFIL refers to what file? Whatever facility you use to identify
> what DSKFIL is a JCL.

You clipped that line.   The VALUE OF ID "XXXYYZ" identified the
the file.   No JCL needed.

// marc



Mon, 11 Jul 2005 09:08:55 GMT  
 Card Columns (was Why did they make ... ?)


Quote:


>>>DDT *has* to have been a backronym.

>> Not to anyone who knows what "Flit" is.  It's more likely a "necessary"
>> acronym to which a set of English words had to be found.

>That's what a "backronym" is -- one where the alleged "acronym" came
>first with the "source phrase" being made up later to fit.

My project USAGE was definitely a backronym.  The only reason I
matched the letters to words was because JMF said I had to.
He said that people (managers and customers) expected them to
mean something and I'd be saving myself lots of headaches if
I could spit a set of impressive sounding words in my talks.

/BAH

/BAH

Subtract a hundred and four for e-mail.



Mon, 11 Jul 2005 19:11:39 GMT  
 Card Columns

Quote:

>> One of my favorite pet names for a kludgy IBM machine was the
>> term "noodle-picker" for the 2321 Data Cell drive.
>> Also: "noodle-snatcher".

Those names were used when it worked.  When it (all too frequently)
misjudged the relative location of the subcell and the strip that
it wanted to return to its proper location, the phrase often used
to describe the box was "noodle-stuffer".

Quote:
>> Other pet terms I recall were "Maytag" for the 2311 disk drive,
>> which somewhat resembled a top-loading washing machine,

I used the 2311 for many years (IIRC, at 6.6 MB capacity per box, at
full-track blocking!) and never heard it called a "Maytag" -- but
I'll agree that it certainly did look like a washing machine.  OTOH,
while it wasn't a maintenance nightmare like the 2321, neither was
it something that let the CEs emulate the Maytag repairman, who
(for the benefit of our overseas readership) in the adverti{*filter*}ts
are bored out of their skulls for lack of anything to do.

Quote:
>> and "Pizza Oven" for the 2314 (a large box with 9 disk drives
>> with removable disk packs). The drives were arranged in an
>> array of drawer-like compartments, with a handle you pulled to
>> open them. (Actually, the 2314 seemed more like a morgue to me
>> than a pizza oven, but that didn't catch on with colleagues.)

The drawers didn't come out very far; at full normal extension they
were opened about as far as they were wide.  "Morgue" might have
caught on as a name if they had come out a bit further.

Quote:
>> I was no longer working in the field when the 3850 Mass Storage
>> System, with it's honeycomb array of phallic-shaped tape
>> cartridges, appeared. There must have been some really choice
>> names for *that* one among CE's.  Anybody heard about that?

>> Today, I work with a guy who wrote some of the microcode for
>> that beast, but I'm sure he doesn't know how CE's might have
>> referred to it.

My shop never had a 3350, but I heard users pronounce "MSS" as "mess".

Quote:
>note also ... that it was an EC to interlock the 3850 robot arm when
>the door was open ... after an unfortunate mishap

One other configuration note for the 3350: you could order the box with
locks for security, but if so there was a mandatory fire-supression
option that had to be installed.

Joe Morris



Mon, 11 Jul 2005 21:50:26 GMT  
 Card Columns

Quote:

> My shop never had a 3350, but I heard users pronounce "MSS" as "mess".

3850 ... was robot arm with honeycomb shaped cartridges and wide
tape. it supported "virtual" 3330 disk packs by staging data to/from
3330. there was a later version that used (faster) 3350 drives for
staging by emulating virtual 3330s.  3850 had two staging modes
... full tape (50mbytes, half 3330-1) and six (3330) cylinders.

several pictures:
http://www.columbia.edu/acis/history/mss.html

including 3350 drives used for staging data

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm



Mon, 11 Jul 2005 23:25:41 GMT  
 Card Columns

Quote:
> I used the 2311 for many years (IIRC, at 6.6 MB capacity per box, at
> full-track blocking!)

7.25 according some old notes I've laying around
The 2314 was some MASSIVE 30 MB !

Nico



Mon, 11 Jul 2005 23:19:14 GMT  
 Card Columns



Quote:
> > I used the 2311 for many years (IIRC, at 6.6 MB capacity per
box, at
> > full-track blocking!)

> 7.25 according some old notes I've laying around
> The 2314 was some MASSIVE 30 MB !

7.25 is correct for the 2311.
3625 bytes/trk x 10 heads * 200 cyls = 7,250,000 bytes.

The figure for 2314 is:
7294 bytes per track x 20 heads + 200 cylinders = 29,176,000
bytes.

Both these require that each and every track be formatted with
one single maximum-size block, which wasn't commonly done. For
one thing, you had to have a VTOC (volume table of contents, sort
of a "directory", which had a certain specified block size, which
I don't recall right now.)

If the blocksize was less than the maximum, and multiple blocks
were written to the disk, a complex formula was used to determine
how many blocks of a certain size you could fit onto a track.
The formula was a function of the block size, a fixed allowance
for inter-block gaps, an additional allowance for "keyed" blocks,
and finally a variable "tolerance factor" that was a function of
the number of blocks on the track. The tolerance factor was some
additional "slop" that had to do with the assumption that the
various blocks on one track might get written independently by
different disk drives spinning at slightly different speeds.

In OS/360, the system API provided access to a table of these
parameters for any given disk drive, called the Device
Characteristics Table.

Files (or "datasets" as they were called) that were written
sequentially were written on a format-as-you-go basis. Quite
different from the approach taken by most disk architectures
today. Space was allocated on a full-track or full-cylinder
basis, and each dataset could be formatted in a different manner,
based on its individual characteristics.

This probably seems bizarre to someone who only knows Unix or
Windows-type file systems, I'm sure. Like anything else, it had
advantages and disadvantages. The advantages were more important
when CPU's were slower relative to what we're accustomed to
today. For one thing, records were usually written directly out
of, and read into, the buffers which the application programs
accessed. No shuffling around of data behind the scenes to fit
odd-sized records into one-size-fits-all disk sectors. On the
other hand, very little opportunity for safely cacheing disk
records, either; at least not in a generalized way.

Still, if you understood the dynamics of this disk architecture,
you could do some pretty cool things that are not possible with
today's fixed-sector disks. And you could do it without violating
the system's security/integrity mechanisms. I kinda miss that.



Tue, 12 Jul 2005 00:57:29 GMT  
 Card Columns

Quote:
> Ah yes.  A job that did a lot of seeks on a 2311 would cause the whole
> unit to vibrate like an out-of-balance washing machine.  I used to work
> with a girl who loved to sit on top of the drives when they were seeking
> wildly.

She sounds like high-maintenence to me.

Cheers,
Rupert



Tue, 12 Jul 2005 01:46:12 GMT  
 Card Columns

Quote:

> Still, if you understood the dynamics of this disk architecture,
> you could do some pretty cool things that are not possible with
> today's fixed-sector disks. And you could do it without violating
> the system's security/integrity mechanisms. I kinda miss that.

part of the CKD design was offloading processing into the disk unit as
opposed to keeping information in storage. it was a storage vis-a-vis
i/o thruput trade-off. for 360s, essentially storage was much more
constrained that i/o capacity. CKD supported record
finding/positioning via search command. the argument for the search
command was in the memory of the processor ... and was referenced for
comparing against each record (as the bits rotated under the r/w
head). as a result during the search command sequence there was a
dedicated path between the device and processor memory (involving
device, controller, and channel).

one use was rather than keeping directories (vtoc was directory for
the whole drive, there was also a library filetype called PDS that had
directory of file members) in real storage .... directories could be
searched on disk for low, equal, high.

starting with 370 (and even some of the larger 360 configurations),
the storage/io trade-off was shifting to being i/o constrained rather
than storage constrained (shift from 360 from being storage
constrained to 370 which started being i/o constrained). as a result,
optimal trade-off had shifting for using bandwidth to search
directories on the device ... to caching directories in storage and
optimizing bandwidth.

i got called in at a very large customer that was periodically
experiencing sever performance degradation during peak-load with large
loosely-coupled, vs2/svs installation. i was brought into class room
that had maybe dozen tables (about 6' long) ... all covered with foot
high print out piles of system activity statistics. They gave me a run
down of the system configuration and all the applications and then let
me start pouring thru the activity data. After a while, for some
reason i started to notice a correlation between poor system thruput
and i/o activity rate on a specific 3330 pack. The activity on this
3330 would peak at about 6.5 i/o operations per second and stay that
way for the duration of the poor performance. Now, normal heavy random
access to 3330 could be expected to have somewhere between 20 to 40
I/Os per second. Eventually tracked it down to a shared program (PDS)
library with a directory that spanned three cylinders. Under heavy
load, applications programs were being constantly (re)loaded from this
particular program library (in part 360s of heritage of looking or no
caching because of design point of severe storage constraints).

Search of the PDS directory was using a "multi-track" search .... the
3330 had 19 tracks per cylinder and spun at 3600 rpm ... that
translates into an unsuccesful multi-track search operation of 19
tracks taking just under 1/3rd second elapsed time. During this period
the drive, the associated control unit, and the associated channel
were busy (and with the control unit being busy, all other drives
belonging to that control unit were unavailable ... and similar with
the channel being busy, all other devices on that channel were
unavailable via that channel path).

CMS, CP/67, VM/370, etc ... all grew up from CTSS heritage .... with
fixed blocks, use of caching of directories, etc (even when using CKD
devices, cms, et al would preformat them to simulated fixed block
design). similarly unix could he considered to have inherited some of
the same characteristics by way of Multics to CTSS (cms, cp/67,
multics were located in 545 tech. sq ... and all projects had people
that had formally worked on ctss).

I had started writing some reports in the late 70s about this dramatic
shift from storage constrained to severe i/o constrained ... w/o some
of the mainstream applications having a similar implementation shift
if their design point. To highlight this ... I made the statement that
dasd system thurput had declined by a factor of between five to ten
times relative to system thruput over a ten to fif{*filter*} year
period. The dasd division got upset about this and assigned their
performance group to refute my claims. By the time they were thru,
they had concluded that I had slightly understated the decline in dasd
relative system thruput (it was actually somewhat worse).

In effect, during the period for a typical configuration, the amount
of real storage and the processing power had increased by a factor of
fifty times while the amount of dasd thruput had only increased by a
factor of five times (dasd got five times faster .... but the amount
of real memory increased by a factor of fifty times and the cpu mip
rate increased by a factor of fifty times). The GPD study morphed into
presentations/reports to guide/share on recommended guidelines
regarding improving i/o thruput.

previous postings on this subject:
http://www.*-*-*.com/ ~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
http://www.*-*-*.com/ ~lynn/95.html#10 Virtual Memory (A return to the past?)
http://www.*-*-*.com/ ~lynn/98.html#46 The god old days(???)
http://www.*-*-*.com/ ~lynn/99.html#4 IBM S/360

http://www.*-*-*.com/ ~lynn/2001l.html#40 MVS History (all parts)
http://www.*-*-*.com/ ~lynn/2001l.html#61 MVS History (all parts)
http://www.*-*-*.com/ ~lynn/2001m.html#23 Smallest Storage Capacity Hard Disk?
http://www.*-*-*.com/ ~lynn/2002.html#5 index searching
http://www.*-*-*.com/ ~lynn/2002b.html#11 Microcode? (& index searching)
http://www.*-*-*.com/ ~lynn/2002e.html#8 What are some impressive page rates?
http://www.*-*-*.com/ ~lynn/2002i.html#16 AS/400 and MVS - clarification please

previous multi-track postings:
http://www.*-*-*.com/ ~lynn/93.html#29 Log Structured filesystems -- think twice
http://www.*-*-*.com/ ~lynn/94.html#35 mainframe CKD disks & PDS files (looong... warning)
http://www.*-*-*.com/ ~lynn/97.html#16 Why Mainframes?
http://www.*-*-*.com/ ~lynn/97.html#29 IA64 Self Virtualizable?
http://www.*-*-*.com/ ~lynn/99.html#75 Read if over 40 and have Mainframe  background
http://www.*-*-*.com/ ~lynn/2000.html#86 Ux's good points.
http://www.*-*-*.com/ ~lynn/2000c.html#34 What level of computer is needed for a computer to Love?
http://www.*-*-*.com/ ~lynn/2000f.html#18 OT?
http://www.*-*-*.com/ ~lynn/2000f.html#19 OT?
http://www.*-*-*.com/ ~lynn/2000f.html#42 IBM 3340 help
http://www.*-*-*.com/ ~lynn/2000g.html#51 > 512 byte disk blocks (was: 4M pages are a bad idea)
http://www.*-*-*.com/ ~lynn/2000g.html#52 > 512 byte disk blocks (was: 4M pages are a bad idea)
http://www.*-*-*.com/ ~lynn/2001c.html#17 database (or b-tree) page sizes
http://www.*-*-*.com/ ~lynn/2001d.html#60 VTOC/VTOC INDEX/VVDS and performance (expansion of VTOC position)
http://www.*-*-*.com/ ~lynn/2001d.html#64 VTOC/VTOC INDEX/VVDS and performance (expansion of VTOC position)
http://www.*-*-*.com/ ~lynn/2001l.html#40 MVS History (all parts)
http://www.*-*-*.com/ ~lynn/2002.html#5 index searching
http://www.*-*-*.com/ ~lynn/2002.html#6 index searching
http://www.*-*-*.com/ ~lynn/2002.html#10 index searching
http://www.*-*-*.com/ ~lynn/2002d.html#22 DASD response times
http://www.*-*-*.com/ ~lynn/2002f.html#8 Is AMD doing an Intel?
http://www.*-*-*.com/ ~lynn/2002g.html#13 Secure Device Drivers
http://www.*-*-*.com/ ~lynn/2002l.html#47 Do any architectures use instruction count instead of timer
http://www.*-*-*.com/ ~lynn/2002l.html#49 Do any architectures use instruction count instead of timer
http://www.*-*-*.com/ ~lynn/2002n.html#50 EXCP
http://www.*-*-*.com/ ~lynn/2002o.html#46 Question about hard disk scheduling algorithms
http://www.*-*-*.com/ ~lynn/2003.html#15 vax6k.openecs.org rebirth

--
Anne & Lynn Wheeler | http://www.*-*-*.com/ ~lynn/
Internet trivia 20th anv http://www.*-*-*.com/ ~lynn/rfcietff.htm



Tue, 12 Jul 2005 02:13:37 GMT  
 
 [ 373 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25]

 Relevant Pages 
 

 
Powered by phpBB® Forum Software