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

Quote:

> The default for IBM System/360 PL/I was to use columns 2 - 72 for
> the source code but IIRC that could be overridden with a compiler
> option.

> System/360 used the string "/*" in columns 1 & 2 of an input card
> deck to indicate end of file; thus it would not be possible to
> start a comment in column 1.  IIRC, it was possible to substitute
> a different EOF indicator through some option on the "//SYSIN DD *"
> JCL statement, but I never learned it well enough to remember.

//SYSIN DD *,DLM='xx'

but that was a much later innovation.  (2,72,1) was locked in long
before that.

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



Thu, 07 Jul 2005 04:44:38 GMT  
 Card Columns (was Why did they make ... ?)

Quote:

> Punch cards were invented by Hollerith in 1880, but I don't
> believe they were in wide use after the 1890 census: mainly used
> for statistics, so probably large governments only.

Not at all.  Punch-card accounting systems were adopted in the early
20th century just as quickly and enthusiastically as computers were
adopted fifty years later.  IBM was already one of the biggest companies
in the US before WW2, and the famous 1954 consent decree that hobbled
IBM's business practices for so long was based on their 90% control of
that industry, not on the fledgling computer side.

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



Thu, 07 Jul 2005 04:44:43 GMT  
 Card Columns (was Why did they make ... ?)

Quote:
> There were a good many US manufacturers -- Burroughs, Sperry-Rand,
> National Cash Register, Control Data, Honeywell, RCA, General Electric
> (collectively known as the "seven dwarfs") -- even Philco made a stab
> at it at one point, and had a fortran/ALGOL hybrid language called
> ALTAC. But IBM held a commanding presence in the US business world
> almost from the first, partly because they already dominated the
> pre-computer punched-card-accounting business.  (IBM's machines had
> been entirely programmable by the customer; Remington-Rand's machines
> had frequently needed an engineer or even a trip to the factory.)

> When the 360 came out, RCA simply copied its problem-state
> architecture (though they had an incompatible supervisor state,
> requiring their own operating systems), and Honeywell's entire
> advertising campaign, for years, was on the theme, "We can move you
> from an IBM 1401 to a Honeywell system more easily than IBM can move
> you to a 360."

a story i heard that was attributeed to somebody from RCA testifying
during the gov. anti-trust trial ... was that in the late 50s
... every computer manufactor realized that the single, most important
criteria for being succesful in the computer industry was going to be
a single compatible architecture across the computer line.

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

there was some hypothesis that if only a single vendor managed to
achieve that single, most important objective ...  then, in theory,
that vendor could do nearly everything else wrong and still be
succesful.

--

Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm



Thu, 07 Jul 2005 05:34:40 GMT  
 Card Columns (was Why did they make ... ?)

Quote:

>On Sat, 18 Jan 2003 09:11:56 GMT, "glen herrmannsfeldt"



>>(snip)

>>> JCL, what's
>>>that? Why would anyone write a system as limited as that?

>>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.  The
>>ability to write different record formats, for example.  I would
>>say that systems that don't give you the options are limited.

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

Ah, but JCL has two uses:
1) It binds the application software to the actual datasets at execution
time, regardless
    of where the job is submitted from and where it is run. (It's
obvious to me that the
    programs to be run and the input and output files be located where
the job is actually
    run -  but I will admit that concept was "novel" to some programmers.)
2) It allows an application programmer/operations scheduler to specify
how big
    the file might grow to, so that it can be allocated in a place that
has sufficient disk
    space. This avoides the necessity of having to move big files
elsewhere just before
    the job runs. Yes, many systems provide for disk quotas, but in my
experience
    these are established at the application system level, and not at an
individual job level.  

In recent years it has been possible to allocate in terms of bytes, in
addition to records,
blocks and tracks.  It absolutely amazes me how many programmers have
absolutely no
idea how much data they are going to be processing or creating.

This is also not a new problem. The first major shop I worked at in the
mid 60's, had a
novel approach, which required programmers to learn stuff like that,
especially those
that want to get more than the "one turn-around a day" seen at many shops.

Systems Support/Operations set the job classes so that you had a
guarenteed 15 min,
 30 min, 1 hr, 2 hr, or more than two hour execution (and turnaround) queues
You also had to estimate the amount of resources that your job was going
to use.
 If during execution, you exceed an estimate, your job was abended
without a dump,
and for the most part, most output was also suppressed. Your account was
charged
for resources used, and no "free" reruns were allowed - unless you could
prove
the job failed because of an operations error. Jobs were selected from
the queues
based upon the estimates provided by the submitter. Jobs with fewer
resources
ran almost immediately, Jobs requiring more resources got delayed. The
scheduler
package also took into consideration how long the long had been waiting,
and how
many jobs got a higher priority. Eventually your job would start, but it
was usually
down to the wire in a guarenteed turnaround period.

The guy who estimates 10,000 lines of output, would wait longer to get
started,
then the person who estimated 9,999.

As a result, most programmers would submit a job the very first time in
the "over 2 hour"
queue and when you got your test back, you examined it to see what you
actually used,
 and revised your estimates accordingly.

End result - over 90% of the batch test jobs were turned around in 15 to
30 minutes, and
when it went into production, you had a very good idea what resources
were actually required.

/s/ bill turner, wb4alm

- Show quoted text -

Quote:
>Thanks. Take care, Brian Inglis     Calgary, Alberta, Canada



Thu, 07 Jul 2005 06:19:50 GMT  
 Card Columns (was Why did they make ... ?)

Quote:
> I suggest that you examine your assumption w.r.t. the newsgroup
> alt.folklore.computers.

Ahh! I hadn't noticed that this thread was cross-posted to both
a.f.c. and the PL/I folks.

Anyway, I said "many" people in the newsgroup, not "most".  I'm
following this via a.f.c., not c.l.pl1 anyway.  The remark was in
reference to those who were using the 72 columns of TTY machines
as the origin of the practice of
reserving 73-80 on punched cards for sequence numbers. I still
hold that the TTY assertion is not the correct  explanation, for
reasons I gave earlier, related to the 704/709/709x card readers
being unable to read more than 72 columns.

In saying this, I'm merely asserting that the conventions
established for punched card source files in programming
languages had a punched-card origin not a TTY origin.

I didn't intend to ruffle any feathers here. Minis have a
venerable tradition, too. It just happens that their systems
reflect their TTY-oriented heritage in just the same way as
mainframes (and most particularly IBM ones) reflect their
punched-card heritage.

With respect to PL/I, I recall that it was developed by a team in
the UK, I also recall that, in the late '60s, anyway, the PL/I
compiler for OS/360 was the only one IBM provided that accepted
variable-length source files in addition to fixed-length files
with 80-byte record lengths.  All the rest supported punched-card
format only.

I'd be interested in hearing some historical background as to why
paper tape was more popular in Europe instead of cards.



Thu, 07 Jul 2005 06:52:44 GMT  
 Card Columns (was Why did they make ... ?)


Quote:

> You're missing a very important point; sort is a dual
operation.
> Without a lot of fussing, you don't compare three things at a
time.

> Size of memory means nothing other than an immediate access to
> the next item to be sorted.

True. You can sort an enormous amount of data with very little
memory
and with external sequential-access devices, by using merge
techniques.

That's how it was possible for an insurance company or bank to
perform all
its accounting using machines with only 16K of memory back in the
'60s.

That method is simple and efficient ... it's always O(n*log(n)),
and with
today's abundance of RAM, can even be done without tapes or
disks, almost
all the time.

What point did I miss, though? I don't follow you.



Thu, 07 Jul 2005 07:15:06 GMT  
 Card Columns (was Why did they make ... ?)

Quote:




>>You're missing a very important point; sort is a dual

>operation.

>>Without a lot of fussing, you don't compare three things at a

>time.

>>Size of memory means nothing other than an immediate access to
>>the next item to be sorted.

>True. You can sort an enormous amount of data with very little
>memory
>and with external sequential-access devices, by using merge
>techniques.

>That's how it was possible for an insurance company or bank to
>perform all
>its accounting using machines with only 16K of memory back in the
>'60s.

>That method is simple and efficient ... it's always O(n*log(n)),
>*and with
>today's abundance of RAM, can even be done without tapes or
>disks, almost
>all the time.*

Maybe in a "small shop", but It's obvious that you never worked for a
large phone company...
without tapes most of the time:  yes.
without disks most of the time:  not even on a good day and you only
have "one-job" to run...

SyncSort still makes a bunch of bucks, because they can switch the
algorithm used
automatically based upon the amount of data and resources --currently--
available.

/s/ Bill Turner, wb4alm

- Show quoted text -

Quote:

>What point did I miss, though? I don't follow you.



Thu, 07 Jul 2005 07:47:37 GMT  
 Card Columns (was Why did they make ... ?)

Quote:
> There were a good many US manufacturers -- Burroughs, Sperry-Rand,
> National Cash Register, Control Data, Honeywell, RCA, General Electric
> (collectively known as the "seven dwarfs") -- even Philco made a stab at
> it at one point, and had a FORTRAN/ALGOL hybrid language called ALTAC.
> But IBM held a commanding presence in the US business world almost from
> the first, partly because they already dominated the pre-computer
> punched-card-accounting business.  (IBM's machines had been entirely
> programmable by the customer; Remington-Rand's machines had frequently
> needed an engineer or even a trip to the factory.)

> When the 360 came out, RCA simply copied its problem-state architecture
> (though they had an incompatible supervisor state, requiring their own
> operating systems), and Honeywell's entire advertising campaign, for
> years, was on the theme, "We can move you from an IBM 1401 to a
> Honeywell system more easily than IBM can move you to a 360."

Probably false advertising, as didn't IBM have a 1401 emulator for the
/360 ?
Quote:
> --
> John W. Kennedy



Thu, 07 Jul 2005 11:02:10 GMT  
 Card Columns (was Why did they make ... ?)


<snip>

Quote:
>Probably false advertising, as didn't IBM have a 1401 emulator for the
>/360 ?

More of a microcode assist for a simulator.  Mod 30 & 65 I am sure of,
and I think 40 & 50 as well.

I know of someone who rewrote the mod 30 program, so that it could run
two 1401 sessions at once.

--
Arargh (at arargh dot com)    http://www.arargh.com
To reply by email, change the domain name, and remove the garbage.
(Enteract can keep the spam, they are gone anyway)



Thu, 07 Jul 2005 14:20:48 GMT  
 Card Columns (was Why did they make ... ?)



Quote:

> > The default for IBM System/360 PL/I was to use columns 2 - 72
for
> > the source code but IIRC that could be overridden with a
compiler
> > option.

> > System/360 used the string "/*" in columns 1 & 2 of an input
card
> > deck to indicate end of file; thus it would not be possible to
> > start a comment in column 1.  IIRC, it was possible to
substitute
> > a different EOF indicator through some option on the
"file://SYSIN DD *"
> > JCL statement, but I never learned it well enough to remember.

Two other things.

You could have it use column one as the carriage control character
in printing the listing file.  This way you could make nicely
formatted listings.  I even did one once with overprinting (+  CC
character) to darken the
major comment lines.   Also, make each procedure start a new page,
things like that.

Also, since the assembler used a * in column 1 for its comment
character, it was possible to write one file that could be fed
either to PL/I or the assembler, and generate the right output in
both cases.

I believe that the DLM option came much later, probably processed
by JES while spooling.  I thought only
for DD DATA, and not DD *, though.

-- glen



Thu, 07 Jul 2005 17:00:31 GMT  
 Card Columns (was Why did they make ... ?)
On later IBM sorters, it was possible to alphasort a file with only three
passes per column. The trick was that the sorter would be set to sort
12-punch cards (A-I) into nine columns of the sorter. 11-punch cards (J-R)
were all sorted into another pocket; 0-punch cards (S-Z) were sorted into
yet another pocket.

Pull out the A-I cards in order from 1-9, then sort the J-R cards on their
numeric values and remove them in order; finally, sort the S-Z cards  into
order and create one big deck.

Some professional (full-time) operators did not use the trick because it was
too complicated! I do not remember which model sorter was the first to have
this feature. I believe I remember doing it prior to 1963.


Quote:

> > What are you sorting if not alphanumeric data?
> > Do you mean only numeric data, or only enough codes to fit in the
> > pockets?
> > And we are talking about a card sorter, right?

> Right.

> If a key column may only contain a digit from 0 to 9 there is a single
hole in
> that column.  If it may contain any alphanumeric character, there are two
holes
> for the letters but still only the one for a digit.  Any cards with two
holes in
> the column being sorted on normally go into the reject or multipunch
pocket.  It
> is possible to set up the sorter to look at either the digits (1-9) only
or the
> zones only (0,11,12).  First do the digits.  Then do zones for the reject
deck,
> then do the zones for the 1-9 decks combined in that order, then put the
pieces
> together.  If special characters are involved some characters require
three
> holes and sorting gets trickier.



Thu, 07 Jul 2005 17:37:46 GMT  
 Card Columns (was Why did they make ... ?)
My memory is that the really embarrassing thing about qsort's worst case was
that it was an already sorted file.
The typical implementation would stop partitioning when the partition size
was small (5-7 items as I remember) and so a simple sort of the last items.
This would result in one item placed in its proper place in the array, with
all earlier items smaller in value, and all later items larger in value
(thus, "partitioned").
With an already sorted array, it would sort things fine, but would be all
overhead and no sorting. With everything already in place, there was nothing
to do.
Selecting the middle item in the unsorted partition could reduce the
problem, but you would still work all the way down proving that it was also
the middle item in the remaining sorted array. Stack depth did not run away,
but run time did.
User's attempting to use qsort to check that a card deck was indeed still in
sequence (hadn't been dropped, etc.) were unhappy with times they noticed
were rather slow.



Quote:

> > Well... I did a little research on this one.  It seems that you
> > have a
> > trade-off between explosive stack use or occasional very-slow
> > sorts with
> > Quick-sort. Or both. Not worth it.

> There is no known general method to eliminate the occasional very slow
(i.e.,
> n*2) performance in Quicksort; however there is a sure fire way to
guarantee
> that the stack depth never exceeds log2 n, and that is always to stack the
large
> piece and go on to process the small piece.  This has no effect on the
time
> performance since both pieces must be processed eventually and it makes no
> difference in which order you process them.



Thu, 07 Jul 2005 18:00:56 GMT  
 Card Columns (was Why did they make ... ?)

Quote:

>I'd be interested in hearing some historical background as to why
>paper tape was more popular in Europe instead of cards.

I wasn't around at the time, but I suspect that as tape was used extensively
in the communications sphere, when they were developing Collosus[1] and the
early computers it was natural for them to use the machinery they already
had available.  With EDSAC program tapes were punched using standard Telex-
type perforators[2].   Later computers probably just followed established
practice.

[1] Tommy Flowers, who developed much of the Collosus hardware actually
    worked for the Post Office so would have been more familiar with punched
    tape than cards.   Tape was also used on the FISH bombe which preceded
    Collosus.

[2] You can see a photo of one on page 24 of the EDSAC simulator manual.
    http://www.dcs.warwick.ac.uk/~edsac/
--
Cheers,

**Remove the digits from email address**

The future was never like this!



Thu, 07 Jul 2005 18:48:32 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