Card Columns 
Author Message
 Card Columns

On Wed, 22 Jan 2003 21:50:17 GMT, Peter Flass

Quote:


>> > Other pet terms I recall were "Maytag" for the 2311 disk drive,
>> > which somewhat resembled a top-loading washing machine,
>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.

Sounds like she was wildly seeking companionship!

Thanks. Take care, Brian Inglis         Calgary, Alberta, Canada
--

    fake address                use address above to reply






Tue, 12 Jul 2005 03:17:30 GMT  
 Card Columns
On Thu, 23 Jan 2003 09:57:29 -0700, "Russ Holsclaw"

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.)

IIRC (war story from guy at PPOE) VTOC entries were 80 byte
blocks, so could be rebuilt from listings using card reader.

Thanks. Take care, Brian Inglis         Calgary, Alberta, Canada
--

    fake address                use address above to reply






Tue, 12 Jul 2005 03:34:22 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).

True. The design is representative of the tendency in those days
toward
*totally* unbuffered I/O.  The Search-ID CCW operation was
probably the most extreme example of this imaginable.  You'd have
thought that they could have
added a dinky little 5-byte register to hold the ID for
comparison, but
instead required all that extra channel overhead to keep
transmitting the
same little string of bytes over the cable over and over again.
That one
seemed silly to me right from the start.

Quote:
> 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.

<snip lengthy war story>

Right again... Clearly, the design of the Partitioned Data Set
was about the worst thing in the whole architecture of OS/360.
Not only was it an egregiously unscalable misuse of the "Search
Key" function of the CKD architecture, but everything else about
it was also bad, especially it's inability to re-use internal
file space without running a "burp" utility to remove the "gas".

However, I think we're talking mostly about how the CKD
architecture could be misused, rather than something that stands
up as a blanket indictment of CKD architecture itself.  I do
agree, however, that we could have done without the "key" part of
CKD, there being other, better ways of indexing data for rapid
retrieval. And, as mentioned above, the SearchID could have been
done more efficiently without the CCW-looping aspect.

I think that CKD architecture, by and large, made sense for the
times in which it was introduced. As CPU speeds increased,
however, some of its ways of "saving CPU time" are probably no
longer relevant. But, there are still a few things I was able to
do with it that have no direct counterpart in current disk drive
technology, and I miss being able to do them.

For example, around 1974, I discovered a trick for reading an
entire trackful of fixed-length records with almost no rotational
latency. This was done with a channel program consisting of a set
of chained "ReadCKD" commands equal in number to the number of
records/track, and *no* SearchID command and TIC at all. This
would read the entire track, starting with the first block to
pass under the head, regardless of which one it was. The program
then sorted out which block was which by examining the record
numbers in the input buffers. I could read a sequential file
nearly twice as fast that way. This technique, combined with
other tricks I won't go into here, greatly accelerated start-up
of the RETAIN "database"(1) when the system had to be restarted.

(1) ...in quotes because it wasn't a "real" DBMS, just another
one of our "hand-crafted" RETAIN-specific technologies.



Tue, 12 Jul 2005 04:39:33 GMT  
 Card Columns


Quote:

> IIRC (war story from guy at PPOE) VTOC entries were 80 byte
> blocks, so could be rebuilt from listings using card reader.

No. I know *that's* not right. Each record was called a DSCB
(Data Set Control Block).

They were keyed records with a 44-byte key (the dsname, in the
case of the main "format 1" DSCB), plus a data portion of some
90-odd bytes or so.  They definitely were not easily
keypunchable, because most of the fields were binary, not text.
The text fields were EBCDIC, of course, not ASCII.

My first thought was 176 bytes, but that's the size of a Job
Queue record in OS/360.

I'll look it up and tell you later.

You're probably thinking of standard tape labels. They were 80
bytes and all text (still EBCDIC). You could, in principle,
create labeled tapes by copying a card image to the beginning of
a tape, and writing a tapemark. The card started with "VOL1",
followed by the serial number.



Tue, 12 Jul 2005 05:39:26 GMT  
 Card Columns

Quote:

> I'll look it up and tell you later.

Found it.... 140 bytes. 44 for the key, 96 for the data.

Somewhere around the house, I have an old plastic overlay that
you could
use to interpret a VTOC printout, to be used in the early days
when the
IEHLIST program would print DSCB's in hex.  How far we've come,
eh?



Tue, 12 Jul 2005 05:50:41 GMT  
 Card Columns

Quote:
> ... 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.

Hey! You're talking about this in the past tense -- it's still around.
These days CKD disk architectures are emulated by the controllers on, I
believe, sector-oriented disks, but all the rest of this stuff is still
there on almost any OS/390 or  z/OS system.  I believe all or most of
the old channel programs would still work.


Tue, 12 Jul 2005 06:24:31 GMT  
 Card Columns

Quote:

> For example, around 1974, I discovered a trick for reading an
> entire trackful of fixed-length records with almost no rotational
> latency. This was done with a channel program consisting of a set
> of chained "ReadCKD" commands equal in number to the number of
> records/track, and *no* SearchID command and TIC at all. This
> would read the entire track, starting with the first block to
> pass under the head, regardless of which one it was. The program
> then sorted out which block was which by examining the record
> numbers in the input buffers. I could read a sequential file
> nearly twice as fast that way. This technique, combined with
> other tricks I won't go into here, greatly accelerated start-up
> of the RETAIN "database"(1) when the system had to be restarted.

there was work for one of the DBMS that did something similar but for
writing log records. it would garner a full-track worth of logging
information ... and the write would start at the first record the head
encountered after settling/sync'ing.

i had an argument with the 3880-d13/d23 people why didn't they do
something similar with they way they handled full-track caching.

one of the HONE people developed a compare&swap ccw sequence using ckd
... in a multi-cec, loosely-coupled environment ... handle cms
minidisk locking rules across the whole complex. in the late '70s,
hone complex in palo alto was largest single system image operation in
the world; eight multiprocessors sharing common dasd farm ... and with
branch office and field people having online service (and load
balancing rules at front end to direct login).

random hone posts:
http://www.garlic.com/~lynn/subtopic.html#hone

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



Tue, 12 Jul 2005 06:52:04 GMT  
 Card Columns

Quote:

> I think that CKD architecture, by and large, made sense for the
> times in which it was introduced. As CPU speeds increased,
> however, some of its ways of "saving CPU time" are probably no
> longer relevant. But, there are still a few things I was able to
> do with it that have no direct counterpart in current disk drive
> technology, and I miss being able to do them.

Disclaimer: Haven't touched a mainframe in > 12 years. Take model numbers,
technical terms, etc, with grain of salt.

When the 3380 first came out around 1982(?) or so, I took an IBM class in
disk error-recovery. It was taught by an IBM guy who had written some of
the relevant microcode in the 3880 controller; I'm sorry I can't
remember his name. After class I spent some time chatting with him, and he
described some custom channel programming he had done for a government
agency: In order to reduce rotational latency, it threw multiple copies of
each data block onto the track, trading-off capacity for reduced access
time. A nice trick which dramatically improved the throughput of the
application, a search-engine apparently, without requiring any changes in
the application itself.

If I remember right, the instructor sort-of nodded when I said "Sounds
like something the NSA might do". My impression was that this was for
their Harvest system, but I can't remember if that was on IBM hardware.

* Nick Geovanis        Joe Barr: People say Linux is ugly.
| IT Computing Svcs    Linus Torvalds: They'll be the first ones against
| Northwestern Univ              the wall when the revolution comes.

+------------------->



Tue, 12 Jul 2005 07:26:51 GMT  
 Card Columns

Quote:
> If I remember right, the instructor sort-of nodded when I said "Sounds
> like something the NSA might do". My impression was that this was for
> their Harvest system, but I can't remember if that was on IBM hardware.

harvest/stretch ... long ago and far away ...

http://www.ddj.com/documents/s=873/ddj0085b/
http://users.bestweb.net/~collier/sh/arch/index.html
http://www.brouhaha.com/~eric/retrocomputing/ibm/stretch/
http://cyclone.cs.clemson.edu/~mark/stretch.html
http://www.llnl.gov/vcm/interviews/norman_hardy_1.html

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



Tue, 12 Jul 2005 08:29:54 GMT  
 Card Columns

Quote:

> > ... 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.

> Hey! You're talking about this in the past tense -- it's still
around.
> These days CKD disk architectures are emulated by the
controllers on, I
> believe, sector-oriented disks, but all the rest of this stuff
is still
> there on almost any OS/390 or  z/OS system.  I believe all or
most of
> the old channel programs would still work.

That doesn't surprise me much. The question is whether any of the
neat tricks that we did to speed things up still work as well on
emulated hardware, or would they actually make things worse.

By the way, just before I left IBM, I understand that there was a
new type of dataset in MVS called a PDSE (like PDS "Enhanced" or
some such). I never got a chance to play with them because the
project I was working on got cancelled, and the system programmer
hadn't installed the necessary software to make PDSE's work.

So I don't know if they made PDSE's compatible with the old-style
PDS, or if you could use a PDSE to hold any of the old SYS1...
datasets. Know anything about that?



Tue, 12 Jul 2005 08:51:22 GMT  
 Card Columns
I figured that one out in late 1975 or early 1976.


[snip]

Quote:
>For example, around 1974, I discovered a trick for reading an
>entire trackful of fixed-length records with almost no rotational
>latency. This was done with a channel program consisting of a set
>of chained "ReadCKD" commands equal in number to the number of
>records/track, and *no* SearchID command and TIC at all. This
>would read the entire track, starting with the first block to
>pass under the head, regardless of which one it was. The program
>then sorted out which block was which by examining the record
>numbers in the input buffers. I could read a sequential file
>nearly twice as fast that way. This technique, combined with
>other tricks I won't go into here, greatly accelerated start-up
>of the RETAIN "database"(1) when the system had to be restarted.

>(1) ...in quotes because it wasn't a "real" DBMS, just another
>one of our "hand-crafted" RETAIN-specific technologies.

It could make a big difference for sequential reads.  Sometime around
1985 or 1986 I used this little trick to measure the time from
interrupt to redrive on MVS/370 and 3330s.  I found it usually took about
25% of a rotation!  So, instead of taking 2 revolutions to sequentially
read a full track, because you always lost a full rotation between
the 25% lost rotation plus the remainder of the rotation waiting for
R1 to come around again, it took about 1 1/4 rotations.

Of course, all this neat stuff is meaningless with RAID devices and
buffered DASD.  Sigh.

- Steve Myers



Tue, 12 Jul 2005 10:05:56 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