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

On Sun, 19 Jan 2003 20:34:37 -0800, "James J. Weinkam"

Quote:


>> IMO systems where you don't need JCL are better designed for
>> humans to use.  I never had a problem picking up and using JCL
>> myself, but most application programmers did not have two clues
>> about what numbers to plug in for dataset allocation, because
>> they did not (want to) know device track sizes and record
>> overhead counts, numbers of tracks and cylinders.

>Whatever name you call it by, every system has some sort of more or less
>rudimentary language that users employ to get their programs run and to specify
>their input and output datasets.

>Judicious use of cataloged and in stream procedures makes the need to explicitly
>specify the SPACE parameter a rarity.  Moreover, if you don't like to measure
>space in terms of cylinders or tracks, you can always measure it in terms of a
>unit of your own choosing.

>The features of the IBM mainframe operating systems that make a comprehensive
>job control language necessary are the sources of their great strength.  These
>include: 1) an IO system that is a comprehensive data management system which
>includes a spectrum of data organizations and methods of processing instead of a
>system that provides little more than low level transport and the association of
>names with devices and (in the case of direct access devices) a chain of
>allocation units. 2) a uniform, system-wide method of associating every input
>and/or output requirement of a program with a suitable device, access method,
>and data set.

On MVS/JES(2?/3) the first part of 1) (before instead) applies,
but DOS(/VSE)/POWER was more like the second part of 1) (after
instead).
For medium sized shops, running a number of DOS instances under
VM was much cheaper than MVS licences, and you could get a lot
more work done.

Most shops forced applications programmers to use VSAM anyway to
avoid them having to make any critical decisions about files, to
avoid jobs failing because files were not catalogued, or disk I/O
going down the tubes searching the VTOC for files.

Some files were better stored uncatalogued and only in the device
VTOC anyway as that tended to avoid the scrutiny of storage
management.

Quote:
>In contrast, the widely used PC operating systems only provide builtin dynamic
>binding for STDIN, STDOUT, and STDERR.  Moreover instead of looking on the
>default binding as a basic fallback position for use when the user chooses not
>to specify a binding, the default is presented as the standard from which the
>user can choose to deviate by redirection which is described in a manner that
>makes it seem almost magical.  While the net result is the same, this convoluted
>nomenclature tends to produce a distorted mindset.

For most programs users just specifyied explicit filenames: not
many programs required redirection, but many could accept
redirection; as you said: a default binding when filenames are
not specified.

Quote:
>Moreover programmers were left entirely on their own for the remaining I/O
>requirements of their products which has led to a confusing mishmash of
>techniques, some reasonably satisfactory, others entirely unsatisfactory.

The same applied to mainframe application programmers and their
choices: many applications were written as if they were card or
tape processing done on disk, using dozens of sequential files.

Quote:
>Consider the difficulty users have in getting two applications to coexist on the
>same system if each requires a different version of some critical DLL.

That was a stupidity perpetrated by MS in Windows (and NT?) 4.
Other systems support multiple versions of dynamic libraries.

OTOH I don't remember any way of having more than one copy of any
system library code active on MVS: didn't everything have to
reside in sys1.linklib? Whereas DOS(/VSE) supported system entry
point renaming, so it was fairly easy to have a program replace
or augment a system routine, and restore the original afterwards.

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

    fake address                use address above to reply






Fri, 08 Jul 2005 18:28:34 GMT  
 Card Columns (was Why did they make ... ?)

Quote:

> > The 407 manual says that it has 120, not 72, print wheels, so I don't
> > think it can be blamed.  I wonder what they did with all those columns
> > when the cards only held 80 characters apiece.

> Spaces between fields.   The cards only had to be readable by operations
> people, the listings frmo teh 407 by users.

And columns of calculated data.
--
Nick Spalding


Fri, 08 Jul 2005 19:00:50 GMT  
 Card Columns (was Why did they make ... ?)


Quote:


>> I'm not arguing about your algorithm; the others are know
>> more about this stuff than I do.  What I'm trying to point
>> out, and doing it badly, is that there is more to designing
>> a computing task than capacity or speed.

>You're absolutely correct. I couldn't agree more.

>However, this particular discussion happens to be
>about the issues of speed and capacity, which, I
>admit only become important when an application
>is designed that is too limited in capacity, or when
>it runs too slowly to meet the user's expectations.

>Believe me, after 36 years in this business, I've found
>a lot more to worry about than speed and capacity,
>but I can't ignore them either.

>If you find this discussion boring, perhaps you'd prefer
>to read some of the other threads instead.

Perhaps you'll pause long enough to take your head out of your
ass and consider the people who don't know this stuff.  There
isn't any point to these discussions other than handing
what we have learned to the kiddies.

Quote:

>To tell the truth, I'm getting bored with it myself. I've
>come to realize it's now starting to get down to a
>competition to see who has the last word, and that leads
>to an infinite loop.

If you would talk about more than who can sort faster when
designing, you'ld not be bored.

Quote:

>Like many other things in the world, there's no such thing
>as a "perfect" sort algorithm.

EXACTLY!  A little more discussion about the pluses and minuses
might even be useful here.

/BAH

Subtract a hundred and four for e-mail.



Fri, 08 Jul 2005 19:52:00 GMT  
 Card Columns (was Why did they make ... ?)

Quote:


>> I'm not arguing about your algorithm; the others are know
>> more about this stuff than I do.  What I'm trying to point
>> out, and doing it badly, is that there is more to designing
>> a computing task than capacity or speed.  

>And sometimes you have to fight hardware or OS's or a venders
>software library to get a job done.

<GRIN>  Yup.  And taking on all three at the same time is not
for the faint of heart.

/BAH

Subtract a hundred and four for e-mail.



Fri, 08 Jul 2005 19:52:58 GMT  
 Card Columns (was Why did they make ... ?)


Quote:

>> BTW, I do agree with the poster that the 36 bit machine had something
>> to do with the 72 column card limit but I seem to recall the 407 (??)
>> accounting machine only had 72 columns of print out as well and maybe
>> it impacted this limit as well.

>I agree that the 72-column limit was because of the 704's hardware
>limitations.

>The 407 manual says that it has 120, not 72, print wheels, so I don't
>think it can be blamed.  I wonder what they did with all those columns
>when the cards only held 80 characters apiece.

Are you kidding?  One of my jobs was to do cross-charging of
computer usage.  One of the last steps was to print pretty bills
for every department and sub-department...in six-tuple, IIRC.
The forms layout took the full width.  And I'd always get colored
with carbon when I did that job.

/BAH

Subtract a hundred and four for e-mail.



Fri, 08 Jul 2005 20:02:13 GMT  
 Card Columns (was Why did they make ... ?)


Quote:


>> assembly source code via another paper tape. The "T" at the
>> end of the FLIT de{*filter*} name, and the "T" in TECO both
>> originally meant tape, as in paper tape. And "DDT" was the
>> "dynamic debugging tape". IIRC.

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

>DDT *has* to have been a backronym.

I don't know.  But the formula was printed on the margin in the
manual.  I always believed that it was good business practice
to distribute humor.

/BAH

Subtract a hundred and four for e-mail.



Fri, 08 Jul 2005 20:08:57 GMT  
 Card Columns (was Why did they make ... ?)


Quote:
> In 1967 I produced a film in collaboration with Ken Knowlton of
Bell Labs.  We
> used Ken's BEFLIX language whach ran on a 360 pretending it was
a 7090 to
> produce a magnetic tape which was then submitted to a Stromberg
Datagraphics
> 4060 pretending it was a 4020.

I recall hearing a story at about the same time of some office in
the Federal Government in DC, I forget which, that had an
interesting case of "nested emulation".

It seems they started out with some application that ran on a 402
(or maybe a 407) accounting machine. It ran for something like a
week.

Then, they stepped up to an IBM 650, that had a program that
would simulate the 402/7, and the job ran twice as fast. Maybe
2-3 days.

Then, they switched to a 1401, running a 650 simulator, running
the 40x simulator, and it ran about twice as fast. Down to about
24 hours or so.

Then, they switched to a 360/30, running 1401 emulation, running
the 650 simulator, running the 40x simulator, and it ran still
faster.  Down to 12 hours, perhaps.

At each step, the new equipment was apparently justified on the
basis of improving the timeliness of the report it produced.

Finally, an IBM SE offered to code the original 40x application
in Cobol (or maybe RPG), and it ran in a few minutes. Since the
original "program" was a bundle of wires on a plugboard, I can't
imagine it took long to code it, once he figured out what it was
doing.

At least that's the legend I heard from a CE in Washington. If
anyone else has heard the story, I'd love to straighten out the
details. Or maybe it was just an "urban legend" of the '60s.
Also, an object lesson about what can happen when you just follow
an "easy migration" path.



Fri, 08 Jul 2005 21:04:03 GMT  
 Card Columns (was Why did they make ... ?)


Quote:
>Columns 73-80 were for card numbering.

That's true, but I doubt that it is the explanation. I suspect that
the shorter lines were either to make them more readable or to leave
room for quoting.

--
     Shmuel (Seymour J.) Metz, SysProg and JOAT

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain Patriot dot net user shmuel+news to contact me.  Do not



Fri, 08 Jul 2005 02:20:29 GMT  
 Card Columns (was Why did they make ... ?)


Quote:
>for various (non-technical) reasons, tj watson was the only executive
>that managed to get all the different manufactoring lines/plants to
>"toe the line" and maintain compatibility (with 360).

Except, of course, that they didn't. S/7, S/1, 8100, S/3, PC, PC/RT,
S/38; there were huge deviations from the idea of a single product
line.

--
     Shmuel (Seymour J.) Metz, SysProg and JOAT

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain Patriot dot net user shmuel+news to contact me.  Do not



Fri, 08 Jul 2005 02:17:01 GMT  
 Card Columns (was Why did they make ... ?)

Quote:


>>BTW, I do agree with the poster that the 36 bit
>>machine had something to do with the 72 column
>>card limit but I seem to recall the 407 (??) accounting
>>machine only had 72 columns of print out as well
>>and maybe it impacted this limit as well.  This
>>accounting machine preceded the 700/7000 series
>>of IBM computers.  Recall that the UNIVAC cards
>>had 90 columns.
> I think, but I do not know, that the IBM 407 could read all 80 columns;
> at least, the one I used could.

Yes, and it printed 120 characters.  Many 407's ended their lives simply
pre-printing fortran source to check for accuracy before compiling.

Quote:
> The UNIVAC cards had round holes.  Years later, IBM produced a 96 column
> card with smaller round holes.

Rectangular holes are better for brushes.  Round holes are better for
photocells.

--
John W. Kennedy
"The poor have sometimes objected to being governed badly;
the rich have always objected to being governed at all."
   -- G. K. Chesterton, "The Man Who Was Thursday"



Sat, 09 Jul 2005 02:20:25 GMT  
 Card Columns (was Why did they make ... ?)

Quote:

> You bring back fond memories. My very first experience as a programmer
> was on a 16K 1401 at North American Aviation in 1961. We used Autocoder
> but later developed our own assembler because Autocoder took minutes to
> spin through the program tape looking for macros even when our source
> code had none.  For business data processing (decimal arithmetic and
> string processing) the 1401 had (and still has) the best instruction set
> in existence. In addition to the luxury of 16K, we also had 5 tape
> drives, a card-reader/punch and a 300LPM chain printer.

??  The normal rating of the chain-based 1403's was 600LPM.

I'd have to give the 1410/7010 a higher rating than the 1401/1440/1460
line, since it was essentially an extended 1401.  (If you were careful,
you could write neutral Autocoder that would assemble to either
instruction set.)  Of course, they were a lot more expensive!

--
John W. Kennedy
"The poor have sometimes objected to being governed badly;
the rich have always objected to being governed at all."
   -- G. K. Chesterton, "The Man Who Was Thursday"



Sat, 09 Jul 2005 02:28:47 GMT  
 Card Columns (was Why did they make ... ?)

Quote:

> JCL is not user-friendly, but that doesn't make it limited.  It is
> that it gives you so many options that make it hard to learn.
> That, and that many don't have convenient default values.

I've heard the latter stated many times.  I'd love a chance to learn the
basics about JCL at some point.

Quote:
> The ability to write different record formats, for example.  I would
> say that systems that don't give you the options are limited.

True, but shouldn't a record format be handled on the application level
instead of the OS level?

--
 -Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Eden Prairie, MN
                     Written online using slrn 0.9.5.4!
                   The Theorem Theorem: If If, Then Then.



Sat, 09 Jul 2005 02:39:25 GMT  
 Card Columns (was Why did they make ... ?)
John W. Kennedy wrote, in

Quote:

> > You bring back fond memories. My very first experience as a programmer
> > was on a 16K 1401 at North American Aviation in 1961. We used Autocoder
> > but later developed our own assembler because Autocoder took minutes to
> > spin through the program tape looking for macros even when our source
> > code had none.  For business data processing (decimal arithmetic and
> > string processing) the 1401 had (and still has) the best instruction set
> > in existence. In addition to the luxury of 16K, we also had 5 tape
> > drives, a card-reader/punch and a 300LPM chain printer.

> ??  The normal rating of the chain-based 1403's was 600LPM.

> I'd have to give the 1410/7010 a higher rating than the 1401/1440/1460
> line, since it was essentially an extended 1401.  (If you were careful,
> you could write neutral Autocoder that would assemble to either
> instruction set.)  Of course, they were a lot more expensive!

The first machine I ever formally worked on was the 7010.  A splendid
machine.  The only problem with writing Autocoder to run on it and the 1401
was the latter's over-simplified read, punch and print instructions with
fixed areas.  The 1440 had the same M%... type instructions with explicit
addresses, same as the 1410/7010.
--
Nick Spalding


Sat, 09 Jul 2005 02:40:38 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