From: jimf@centerline.com (Jim Frost)
Subject: Re: IBM vs. world terminology (was: What does dd stand for?)
Organization: CenterLine Software, Inc.
Date: Tue, 28 Jul 1992 18:52:34 GMT

grog@adagio.UUCP (Greg Lehey) writes:
>In article <jcmorris.712248190@mwunix> jcmorris@mwunix.mitre.org (Joe Morris) writes:
>>ecmtwhk@ccu1.aukuni.ac.nz (Thomas Koenig) writes:
>>>disk		DASD

>I was only briefly exposed to MVS round 15 years ago, and so have been
>able to recover most of my sanity. But my recollection was that we
>called disks disks.

>>
>>>formatting	DASDi
>>
>>DASDI == "DASD Initialization".  This is *not* the same as formatting;

>correct, one of the things you had to tell the system when allocating
>files was what format they should have. *Then* the system would go out
>and format the parts of the disk you had allocated in the form you
>wanted. Great for OLTP.

I'm not sure that's technically correct either, although it may have
appeared so to applications writers.  I may mung a few details and
probably screw up the official IBM terminology but bear with me --
it's been a few years since I wrote a channel program.

The DASD devices had tracks that could be formatted to (for all
practical purposes) any size sector up to the physical capacity of the
track.  Most of the time you set the sector size to the size of the
record for convenience.  The most obvious limitation here is that you
needed to allocate files along track boundaries -- at least one track
per file or piece of file.  This would seem space-inefficient for
small files, and it is -- but not for huge datasets, and it has the
advantages of eliminating rotational delays while reading a dataset
and making it easy to minimize head motion.  Anyway until you wrote
something on that track I don't think it was formatted at all, but
once you wrote one record the DASD device would write the entire track
(it may have only done part of the track, it's kind of hard to tell
from the software vantage point).  At any rate you didn't have to do a
special initialization pass before writing the record -- you said
"write this much data to this record on that track" and viola it was
done.

The technique of creating physical sectors the size of the records
seemed stupid to me (lots of wasted space if the record size wasn't a
nice multiple of the total track capacity) but there was a benefit of
sorts -- the DASD devices were capable of doing keyed record lookup
*in hardware*.  I'll let you decide for yourself whether or not you
think this is a good idea.

After I found out how much work the DASD device did for the OS I was
terribly surprised at how little the OS people did to mask the
hardware, or even to provide a more usable interface -- you're
practically talking directly to the hardware.  Ick.

>>An abend (ABnormal END) is an externally-forced abort of
>>a process (cf. what you get with ^C or CTRL-BREAK).  An abend may or may
>>not generate a core dump, depending on the reason for the abend and
>>whether or not the user has requested that a dump be taken.

>Specifically, you had to have a DD card for either SYSUDUMP or
>SYSABEND - the later gave you a more complete dump (``egad, how shrill
>yon varlet's cry/as sixteen megabytes fly by/in yet another dump'').
>Certainly an external event wasn't the only way to get one of these
>piles of paper: most exceptions would do the same thing. And I could
>have sworn that there was an SVC to abend your program.

Yea, but if most of your sixteen meg was uninitialized it just told
you it was repeated zeros so you didn't get two reams of paper for
every dump.  Most small programs generated "only" twenty or thirty
pages of goo.  I *hated* post-mortem debugging from paper dumps.

jim frost
jimf@centerline.com
Newsgroups: alt.folklore.computers