Fred Brooks on OS/360 "JCL is the worst language ever"

[hanc...@bbs.cpcn.com]

The computer history museum has a video of a 2011 lecture by Fred
Brooks on the development of System/360. Very interesting. In it
Brooks talks about JCL and its problems.

http://www.computerhistory.org/revolution/mainframe-computers/7/162/2270

[Peter Flass]

Thanks!

--
Pete

[Ibmekon]

In the talk Fred explains that the creators of JCL declared that there
would only be six verbs - and made this an article of faith.
So that as the complexity of work done by the JCL grew, one of the
verbs - the DD statement - became overly complex.

He describes it as a terrible language - because it was not meant to
be a language.

Although I have fond memories of many years using JCL - it never
occurred to me that it could be described as a language.

It makes me think of the SQL language insisting on one SELECT
statement doing 99% of all the work.
All very well, but it can read like a whole page without any
punctuation !
So I find it hard to consider SQL as a language.

By comparison, many people hated the verbose structure to COBOL.
To me, that is its best design feature.

Of course "MOVE EOQ-TABLE TO MASK2." could be easily written
"MASK2=EOQ-TABLE" - reducing typing.
"WRITE REPREC FROM LINE2 AFTER ADVANCING 3 LINES" could be a function
like WRITE(REPREC,LINE2,AL,3)

But your brain has to re-parse these specialised strings each time you
read the code - making comprehension more difficult.
Languages should be desiged for easy writing and reading by humans.


Carl Goldsworthy

Never keep up with the Joneses, drag them down to your level.

[hanc...@bbs.cpcn.com]

On Oct 19, 6:13 pm, Ibmekon wrote:
> On Fri, 19 Oct 2012 08:25:39 -0700 (PDT),

> In the talk Fred explains that the creators of JCL declared that there
> would only be six verbs - and made this an article of faith.
> So that as the complexity of work done by the JCL grew, one of the
> verbs - the DD statement - became overly complex.

I was curious about that, I wondered what he would've had in its
place. The DD statement has a lot of parameters and sub parameters
(eg "SPACE=(CYL,(40,30),RLSE)"), but they go along with describing the
file. Some of the positional parameters are a little awkward, I think
the LABEL could have a bunch of commas before getting to the meat of
it.

The AS/400 calls its job control "CL", and it's a heck of a lot more
complex than mainframe JCL. I'll take mainframe JCL.

Some of the features of JCL aren't as important today since we don't
use physical punch cards but rather on-line editors. On-line makes it
easier to write stuff up and copy descriptions from step to step.
Also, some places have control software such as CA-7.

> He describes it as a terrible language - because it was not meant to
> be a language.

I don't see it as a language but a set of general specifications of
the environment. I don't think of a JCL stream as a 'program'.

One thing I never liked is that when using VSAM files, we use the
IDCAMS program to define the file specs, as opposed to writing them
out in JCL statements.

[Dan Espen]

hanc...@bbs.cpcn.com writes:

> On Oct 19, 6:13 pm, Ibmekon wrote:
>> On Fri, 19 Oct 2012 08:25:39 -0700 (PDT),
>
>> In the talk Fred explains that the creators of JCL declared that there
>> would only be six verbs - and made this an article of faith.
>> So that as the complexity of work done by the JCL grew, one of the
>> verbs - the DD statement - became overly complex.
>
> I was curious about that, I wondered what he would've had in its
> place. The DD statement has a lot of parameters and sub parameters
> (eg "SPACE=(CYL,(40,30),RLSE)"), but they go along with describing the
> file. Some of the positional parameters are a little awkward, I think
> the LABEL could have a bunch of commas before getting to the meat of
> it.
>
> The AS/400 calls its job control "CL", and it's a heck of a lot more
> complex than mainframe JCL. I'll take mainframe JCL.

Can't imagine what IBM did with CL but I used OCL on the IBM System 34
for a few years and loved it.

> Some of the features of JCL aren't as important today since we don't
> use physical punch cards but rather on-line editors. On-line makes it
> easier to write stuff up and copy descriptions from step to step.
> Also, some places have control software such as CA-7.

So you're saying JCL is okay since we don't use it much and you can add
packages to make it semi-useful.

Sorry, it's a steaming pile crap.

>> He describes it as a terrible language - because it was not meant to
>> be a language.
>
> I don't see it as a language but a set of general specifications of
> the environment. I don't think of a JCL stream as a 'program'.

Of course you think of it that way. It's primitive, barely adequate.
The comparison to OCL made that clear for me.

> One thing I never liked is that when using VSAM files, we use the
> IDCAMS program to define the file specs, as opposed to writing them
> out in JCL statements.

Thought that was "fixed"? If not, that's just one fault.

How about how it being useless for simple things.
IEBCOPY copies files. Why can't we write a proc:

// EXEC COPY,PARM=(DD:FILE1,DD:FILE2)
or
// EXEC COPY,PARM=(DD:FILE1,MYFILE.DATA)

or

// EXEC DELETE,PARM=MYFILE.DATA

The other day I was working on some JCL and thought I would make
the name of the IMS copy a variable:

// SET IMS=XXX

works in DD statements, doesn't work in /*RESOURCE.

Sorry, Fred is right.

--
Dan Espen

[Peter Flass]

On 10/19/2012 10:49 PM, hanc...@bbs.cpcn.com wrote:
> On Oct 19, 6:13 pm, Ibmekon wrote:
>> On Fri, 19 Oct 2012 08:25:39 -0700 (PDT),
>
>> In the talk Fred explains that the creators of JCL declared that there
>> would only be six verbs - and made this an article of faith.
>> So that as the complexity of work done by the JCL grew, one of the
>> verbs - the DD statement - became overly complex.
>
> I was curious about that, I wondered what he would've had in its
> place. The DD statement has a lot of parameters and sub parameters
> (eg "SPACE=(CYL,(40,30),RLSE)"), but they go along with describing the
> file. Some of the positional parameters are a little awkward, I think
> the LABEL could have a bunch of commas before getting to the meat of
> it.

I believe Univac JCL, whatever it's called, is worse. There everything
is positional, so you get lots of commas. JCL has been slightly
improved my making more parameters keyword, as a possible alternative to
positional. DCB subparameters now are mostly real parameters and don't
require the "DCB=(". DCB mad sense if you're coding assembler, but lots
of programmers today don't know what a DCB is.
...

>
> One thing I never liked is that when using VSAM files, we use the
> IDCAMS program to define the file specs, as opposed to writing them
> out in JCL statements.

I believe this hasn't been required for years.

--
Pete

[Peter Flass]

On 10/19/2012 11:42 PM, Dan Espen wrote:
>
> Sorry, it's a steaming pile crap.

Fred mentions the relationship of Assembler to JCL, and that's the
answer. Like Assembler, JCL is immensely powerful but very complex.
These days a lot of the complexity is wasted - who defines
split-cylinder datasets? Who uses 7-track tape?

Burroughs got along fine without (much) JCL, but they didn't have lots
of optional possibilities.

...

>
> How about how it being useless for simple things.
> IEBCOPY copies files. Why can't we write a proc:
>
> // EXEC COPY,PARM=(DD:FILE1,DD:FILE2)
> or
> // EXEC COPY,PARM=(DD:FILE1,MYFILE.DATA)

//EXEC COPY INFILE=FILE1,OUTFILE=FILE2
>
> or
>
> // EXEC DELETE,PARM=MYFILE.DATA

//EXEC DELETE,DSN=MYFILE.DATA

>
> The other day I was working on some JCL and thought I would make
> the name of the IMS copy a variable:
>
> // SET IMS=XXX
>
> works in DD statements, doesn't work in /*RESOURCE.
>
> Sorry, Fred is right.
>

RESOURCE as in PSF? A lot of newer function has munged up JCL even
worse than it was.

--
Pete

[Dan Espen]

Peter Flass <Peter...@Yahoo.com> writes:

> On 10/19/2012 11:42 PM, Dan Espen wrote:
>>
>> Sorry, it's a steaming pile crap.
>
> Fred mentions the relationship of Assembler to JCL, and that's the
> answer. Like Assembler, JCL is immensely powerful but very
> complex. These days a lot of the complexity is wasted - who defines
> split-cylinder datasets? Who uses 7-track tape?
>
> Burroughs got along fine without (much) JCL, but they didn't have lots
> of optional possibilities.
>
> ...
>>
>> How about how it being useless for simple things.
>> IEBCOPY copies files. Why can't we write a proc:
>>
>> // EXEC COPY,PARM=(DD:FILE1,DD:FILE2)
>> or
>> // EXEC COPY,PARM=(DD:FILE1,MYFILE.DATA)
>
> //EXEC COPY INFILE=FILE1,OUTFILE=FILE2
>>
>> or
>>
>> // EXEC DELETE,PARM=MYFILE.DATA
>
> //EXEC DELETE,DSN=MYFILE.DATA

Almost:

// EXEC DELETE,DSN=MYFILE.DATA

No label (in this case stepname except for any the PROC might have,
Then EXEC is the OPCODE then the PARMS to the PROC.

>> The other day I was working on some JCL and thought I would make
>> the name of the IMS copy a variable:
>>
>> // SET IMS=XXX
>>
>> works in DD statements, doesn't work in /*RESOURCE.
>>
>> Sorry, Fred is right.
>
> RESOURCE as in PSF? A lot of newer function has munged up JCL even
> worse than it was.

Nope JES2. As in, this job needs to run on the system that has resource
IMS XXX.

--
Dan Espen

[Jim Haynes]

On 2012-10-20, hanc...@bbs.cpcn.com <hanc...@bbs.cpcn.com> wrote:
>> verbs - the DD statement - became overly complex.
>
> I was curious about that, I wondered what he would've had in its
> place. The DD statement has a lot of parameters and sub parameters
> (eg "SPACE=(CYL,(40,30),RLSE)"), but they go along with describing the
> file. Some of the positional parameters are a little awkward, I think
> the LABEL could have a bunch of commas before getting to the meat of
> it.
>

Seems like the underlying problem is the assumption that the user wants
to control all those parameters when all he really wants to do is get a
file to store things in. It seems like yet another case of IBM solving
the previous generation's problems in the current generation. The previous
generation's problem was very limited capacity of disk storage media, so
the user was allowed to fit data as tightly as possible into the
available space. Other computer companies just let the user call for
some number of blocks of storage, tolerating some waste of space in
the last block. I assume that's what IBM eventually discovered in
"Fixed Block Architecture".

[Peter Flass]

On 10/20/2012 1:11 PM, Jim Haynes wrote:
> On 2012-10-20, hanc...@bbs.cpcn.com <hanc...@bbs.cpcn.com> wrote:
>>> verbs - the DD statement - became overly complex.
>>
>> I was curious about that, I wondered what he would've had in its
>> place. The DD statement has a lot of parameters and sub parameters
>> (eg "SPACE=(CYL,(40,30),RLSE)"), but they go along with describing the
>> file. Some of the positional parameters are a little awkward, I think
>> the LABEL could have a bunch of commas before getting to the meat of
>> it.
>>
> Seems like the underlying problem is the assumption that the user wants
> to control all those parameters when all he really wants to do is get a
> file to store things in. It seems like yet another case of IBM solving
> the previous generation's problems in the current generation.

True.

The previous
> generation's problem was very limited capacity of disk storage media, so
> the user was allowed to fit data as tightly as possible into the
> available space. Other computer companies just let the user call for
> some number of blocks of storage, tolerating some waste of space in
> the last block. I assume that's what IBM eventually discovered in
> "Fixed Block Architecture".
>

FSVO "previous generation." It seems to me that up until about 10-15
years ago disk storage was still a limited resource, and now that I
think about it We still had to migrate stuff out with HSM in order to
have enough space up until I left, a couple of years ago now, and they
probably still do.


--
Pete

[hanc...@bbs.cpcn.com]

On Oct 20, 1:11 pm, Jim Haynes <jhay...@alumni.uark.edu> wrote:
> On 2012-10-20, hanco...@bbs.cpcn.com <hanco...@bbs.cpcn.com> wrote:>> verbs - the DD statement - became overly complex.

Well, many years ago disk space was scarce (at least everywhere I
worked) and we had to define it carefully to avoid waste. Thus all
the parameters (we can define by tracks, if desired).

Today programmers tend to be a lot more sloppy about it. Plus JCL
offers two features that make things easier: BLKSIZE=0, which has the
system determine the optimum blocksize for the device instead of
manually calculating it, and RLSE, which releases unneeded disk space
after the file is created.

Needless to say, all computer resources were expensive and scarce many
years ago, even in the 370 era. The many options of JCL allowed
developers to assign the specific I/O resources that were available
per organization policy and the needs of the application.

Note that many computers had varied devices. Sometimes an output tape
had to be created at 1600 bpi instead of 6250 to accomodate the place
reading it. Sometimes a disk file was to be created on a removable
disk (eg 3330), sometimes on a fixed disk. Sometimes printing was to
go to a specific printer, sometimes it was to go "hot", not spooled.
Modern technology has eliminated the need for much of this stuff
(today we don't mail tapes, we electronically send files).

[hanc...@bbs.cpcn.com]

On Oct 20, 4:02 pm, Peter Flass <Peter_Fl...@Yahoo.com> wrote:

> FSVO "previous generation."  It seems to me that up until about 10-15
> years ago disk storage was still a limited resource, and now that I
> think about it We still had to migrate stuff out with HSM in order to
> have enough space up until I left, a couple of years ago now, and they
> probably still do.

While there is a heck of a lot more disk space than ever, there are
more applications, more transactions, and applications have become
more complex, so the demand for disk space is growing. Further, some
programmers are sloppy these days, such as not bothering to condense
numeric dates into packed-Julian. (On the other hand, modern disk
technology compresses files.)

[Ibmekon]

Yup,

In the late 70's I worked at the Extel company in London, England.

They produced a daily financial analysis of stock, shares currencies
etc.

We created the Focus database during the evening and output it to
Potters tape drives.
These tapes had to go to the merchant banks of the day - Morgan
Grenfell etc
They were individually formatted for each customer - most for non IBM
mainframes.

This was done by JCL and physical switches on the tape drive panels.

The fun bit was calling a taxi (company account) at around six in the
morning.
The driver ferried us around London to the banks.
Some datacenter staff would answer a groundfloor buzzer and come down
to collect the tapes.
Others would just ask us to push them into a mailbox for collection.

At the end of the drops - we could head to Fleet street - which was
very alive at this hour.
The national newspaper first editions would be comming onto the
streets - hot off the presses.

And the cafes were good for a bacon and egg butty.

[Anne & Lynn Wheeler]

Jim Haynes <jha...@alumni.uark.edu> writes:
> Seems like the underlying problem is the assumption that the user
> wants to control all those parameters when all he really wants to do
> is get a file to store things in. It seems like yet another case of
> IBM solving the previous generation's problems in the current
> generation. The previous generation's problem was very limited
> capacity of disk storage media, so the user was allowed to fit data as
> tightly as possible into the available space. Other computer
> companies just let the user call for some number of blocks of storage,
> tolerating some waste of space in the last block. I assume that's
> what IBM eventually discovered in "Fixed Block Architecture".

1960s CKD architecture allowed trade-off with putting lots of structure
and disk and using search commands that burned i/o at savings of real
storage. by mid-70s the search architecture trade-off had started to
invert (real storage becoming plentiful and i/o capacity increasingly
becoming bottleneck resource) ... and by the late 70s aspects of fixed
block architecture was starting to outperform ... in competition of
CKD. the next couple CKD generations were actually low-level fixed-block
cells ... which can be seen in various "space" calculations of how much
data can be placed on track given various record sizes (roundup required
to multiple of cell size). after that all CKD started to be simulated on
industry standard fixec block architecture (i.e. real CKD disks haven't
been manufactured for decades).

lots of past posts about ckd, search operations, dasd vis-a-vis
fixed-block
http://www.garlic.com/~lynn/submain.html#dasd

note that cp67/cms & later vm370/cms was all logical fixed-block
... even when using ckd ... so when real fixed-block was introduced
it was trivial to support.

however, the favorite son mainframe operation system has never supported
fixed-block, being intricately tied to CKD ... even after there has been
no real CKD built for decades. in the early 80s, I once offered them
fixed-block support and was told I needed a $26M business case to cover
the cost of publications and education ... and wasn't able to use total
life-time costs as part of the justification ... just incremental
additional disk sales ... on the order of $300M ... for the profit
margin to cover the $26M publications and education ... and by the way,
customers were supposedly buying CKD as fast as it could be built and
any support for FBA would just result in the same amount of FBA
substituted for CKD ... stacked deck.

recent post mentioning (oft repeated story) of disk division doing (late
80s) presentation that the communication group was going to be
responsible for the demise of the disk division
http://www.garlic.com/~lynn/2012n.html#64

--
virtualization experience starting Jan1968, online at home since Mar1970

[Anne & Lynn Wheeler]

Peter Flass <Peter...@Yahoo.com> writes:
> FSVO "previous generation." It seems to me that up until about 10-15
> years ago disk storage was still a limited resource, and now that I
> think about it We still had to migrate stuff out with HSM in order to
> have enough space up until I left, a couple of years ago now, and they
> probably still do.

late 70s, the system/r (original SQL RDBMS) were being hassled by the
IMS group ... the IMS group claiming that the implicit RDBMS index
doubled the disk storage requirement compared to the same data in IMS
... and could increase numbers of I/Os by 5-6 times for index processing
(again compared to IMS). The system/r retort was that IMS data tended to
be cast in concrete and required enormous manual care&feeding to do
almost anything.

By the early 80s, the significant increase in real storage availability
was allowing caching for indexes and the drop in disk costs was dropping
significantly (mitigating the double disk storage space) ... and the
same time people costs was starting to explode ... when they could be
found. The significant lower people/manual care&feeding (compared to
IMS) coupled with change in hardware economics started see big shift to
RDBMS.

misc. past posts mentioning original relational/sql
http://www.garlic.com/~lynn/submain.html#systemr

[Dan Espen]

IBM discovered FBA then got lost.
The first drive I used of theirs was a 1311. One megabyte of fixed block
100 byte records. Really easy to use without anything more than a
routine that read one or more blocks using a decimal address from 1 to
nnnnn.

When they attached a drive that looked exactly the same to a S/360 they
called it a 2311 and came up with the CKD track format. A huge step
backwards.

--
Dan Espen

[Shmuel Metz]

In <icd30dr...@home.home>, on 10/19/2012
at 11:42 PM, Dan Espen <des...@verizon.net> said:

>Subject: Re: Fred Brooks on OS/360 "JCL is the worst language ever"

TESTRAN.

>How about how it being useless for simple things.
>IEBCOPY copies files. Why can't we write a proc:
>// EXEC COPY,PARM=(DD:FILE1,DD:FILE2)
>or
>// EXEC COPY,PARM=(DD:FILE1,MYFILE.DATA)
>or
>// EXEC DELETE,PARM=MYFILE.DATA

You can, as long as you quote the strings contining the colons.

>doesn't work in /*RESOURCE.

Fred was talking about OS/360.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org

[Shmuel Metz]

In <k5u4m7$v11$1...@dont-email.me>, on 10/20/2012

at 08:23 AM, Peter Flass <Peter...@Yahoo.com> said:

>I believe Univac JCL, whatever it's called, is worse.

That depends on what "it" is. UNIVAC had more than one OS.

>JCL has been slightly improved

JCL has been enhanced. Some of the enhancements were improvements.
Some, e.g., VSAM parameters in AMP=, were shoehorned in.

[Charles Richmond]

"Peter Flass" <Peter...@Yahoo.com> wrote in message
news:k5u4m7$v11$1...@dont-email.me...

> On 10/19/2012 10:49 PM, hanc...@bbs.cpcn.com wrote:
>> On Oct 19, 6:13 pm, Ibmekon wrote:
>>> On Fri, 19 Oct 2012 08:25:39 -0700 (PDT),
>>
>>> In the talk Fred explains that the creators of JCL declared that there
>>> would only be six verbs - and made this an article of faith.
>>> So that as the complexity of work done by the JCL grew, one of the
>>> verbs - the DD statement - became overly complex.
>>
>> I was curious about that, I wondered what he would've had in its
>> place. The DD statement has a lot of parameters and sub parameters
>> (eg "SPACE=(CYL,(40,30),RLSE)"), but they go along with describing the
>> file. Some of the positional parameters are a little awkward, I think
>> the LABEL could have a bunch of commas before getting to the meat of
>> it.
>
> I believe Univac JCL, whatever it's called, is worse. There everything is
> positional, so you get lots of commas. JCL has been slightly improved my
> making more parameters keyword, as a possible alternative to positional.
> DCB subparameters now are mostly real parameters and don't require the
> "DCB=(". DCB mad sense if you're coding assembler, but lots of programmers
> today don't know what a DCB is.
>

I know that DCB stands for "data control block"... but I'm *not* sure of its
function. Is it some sort of disk buffer???

--

numerist at aquaporin4 dot com

[Charles Richmond]

<hanc...@bbs.cpcn.com> wrote in message
news:7f601c8d-1e48-4bd0...@j12g2000vbm.googlegroups.com...

At a PPoE in the 90's, our application had a "time stamp" that was kept in
ASCII. It took 21 bytes, IIRC. However, when the time stamp was stored on
disk, it was in the Oracle database time format... which was fairly
efficient of disk space.

[Charles Richmond]

"Jim Haynes" <jha...@alumni.uark.edu> wrote in message
news:slrnk85mq0....@Frances.localdomain...

Another reason for JCL was that you could allocate a cylinder for your file.
That was supposed to speed disk access by reducing the time used in track
seeks. ISTM that disks used to spin at 1800 or 3600 rpm... instead of the
7200 rpm of 3 1/2 " disks, or 5400 rpm for 2 1/2" disks. Faster rotational
speeds are available, but the two speeds I mentioned are the most common for
Winchester disks.

[Anne & Lynn Wheeler]

"Charles Richmond" <nume...@aquaporin4.com> writes:
> Another reason for JCL was that you could allocate a cylinder for your
> file. That was supposed to speed disk access by reducing the time used
> in track seeks. ISTM that disks used to spin at 1800 or 3600
> rpm... instead of the 7200 rpm of 3 1/2 " disks, or 5400 rpm for 2
> 1/2" disks. Faster rotational speeds are available, but the two
> speeds I mentioned are the most common for Winchester disks.

another reason for JCL (and DCBs and other stuff) was batch processing
paradigm ... "job" was submitted for execution and it might run hrs or
days (in some cases weeks) later ... when the responsible/knowledgeable
person wasn't around.

lots of interactive stuff has responsible person sitting there and any
glitches can be handle in real time. in batch processing ... detailed
JCL specification help increase the probability that application runs to
completion ... for instance, even before starts (hopefully) all the
resource requirements are specified in detail.

[Dan Espen]

Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> writes:

> In <icd30dr...@home.home>, on 10/19/2012
> at 11:42 PM, Dan Espen <des...@verizon.net> said:
>
>>Subject: Re: Fred Brooks on OS/360 "JCL is the worst language ever"
>
> TESTRAN.
>
>>How about how it being useless for simple things.
>>IEBCOPY copies files. Why can't we write a proc:
>>// EXEC COPY,PARM=(DD:FILE1,DD:FILE2)
>>or
>>// EXEC COPY,PARM=(DD:FILE1,MYFILE.DATA)
>>or
>>// EXEC DELETE,PARM=MYFILE.DATA
>
> You can, as long as you quote the strings contining the colons.

I think you're referencing the release that allows variables to affect
instream data? Is that released yet?

>>doesn't work in /*RESOURCE.
>
> Fred was talking about OS/360.

And I was talking about how it still has a long long way to go.
Especially in terms of catching up to OCL from 20 years ago.

--
Dan Espen

[Dan Espen]

DCB is the HLASM macro used to define a file, Ie. you open a DCB.
Unless, of course, it's a VSAM file with an ACB. Or you're using IMS
where all you get is a PCB.

--
Dan Espen

[Ibmekon]

Back in the day I worked on a leased mainframe with CPU time charging.

On the account analysis listing, top of the CPU pops was the IBM sort
- (PGM=??????)
IEBCOPY was also pretty high, considering it did no user oriented
work.

The intelligent allocation of the DD's for SORTIN , SORTOUT, SORTWKnn
was important in reducing both elapsed and CPU time.
IIRC SORTIN & SORTOUT on one pack, SORTWKnn on as many packs as
available - up to 6 max.

Later "Computer Associates" supplied their CA=cascade CAsort program.
This had a dynamic disk load balancing feature - managing IO so as to
reduce the CPU charges.

Another JCL consideration was that many customers submitted their work
to a bureau.
Working at a bureaux I could appreciate that the flexible device
allocation of (LUB to PUBs ?) could be used to quickly update a
customer job submission to run locally.

[hanc...@bbs.cpcn.com]

On Oct 20, 9:38 pm, Dan Espen <des...@verizon.net> wrote:
> Jim Haynes <jhay...@alumni.uark.edu> writes:

> > On 2012-10-20, hanco...@bbs.cpcn.com <hanco...@bbs.cpcn.com> wrote:
> >>> verbs - the DD statement - became overly complex.
>
> >> I was curious about that, I wondered what he would've had in its
> >> place.  The DD statement has a lot of parameters and sub parameters
> >> (eg "SPACE=(CYL,(40,30),RLSE)"), but they go along with describing the
> >> file.  Some of the positional parameters are a little awkward, I think
> >> the LABEL could have a bunch of commas before getting to the meat of
> >> it.
>
> > Seems like the underlying problem is the assumption that the user wants
> > to control all those parameters when all he really wants to do is get a
> > file to store things in.  It seems like yet another case of IBM solving
> > the previous generation's problems in the current generation.  The previous
> > generation's problem was very limited capacity of disk storage media, so
> > the user was allowed to fit data as tightly as possible into the
> > available space.  Other computer companies just let the user call for
> > some number of blocks of storage, tolerating some waste of space in
> > the last block.  I assume that's what IBM eventually discovered in
> > "Fixed Block Architecture".
>
> IBM discovered FBA then got lost.
> The first drive I used of theirs was a 1311.  One megabyte of fixed block
> 100 byte records.  Really easy to use without anything more than a
> routine that read one or more blocks using a decimal address from 1 to
> nnnnn.

But wasn't that wasteful if the desired record size wasn't an even
multiple of 100?

Also, in terms of easy to use, from a high level language like COBOL,
one does not have to worry about how the disk file is physically
organized on disk, except to use a reasonably efficient block size
(any record length can be used). Sequential I/O is very easy, and for
random files, ISAM works well.

> When they attached a drive that looked exactly the same to a S/360 they
> called it a 2311 and came up with the CKD track format.  A huge step
> backwards.

Didn't they also double the capacity size of the disk when they went
to 2311?

[hanc...@bbs.cpcn.com]

On Oct 21, 11:52 am, "Charles Richmond" <numer...@aquaporin4.com>
wrote:

> I know that DCB stands for "data control block"... but I'm *not* sure of its
> function.  Is it some sort of disk buffer???

It describes certain aspects of the file. A common usage would be:

DCB=(RECFM=FB,LRECL=256,BLKSIZE=0)

Recfm=FB means fixed length as opposed to variable length. IIRC, FBA
left the print file carriage control on so the file could be stored
and then printed later.

LRECL=the logical record length of the file, in this example, 256
bytes.

BLKSIZE is the physical length of the block, which is a multiple of
the record size. For tapes and disks, grouping a bunch of records
together in a block saves a great deal of space and time. In our
example, the =0 means we want the system to define for us the optimum
blocksize for the device, which eliminates us manually calculating
it.

[Dan Espen]

No. Don't forget, all we did is read blocks in multiples of 100
characters. Any logical records were figured out in our Autocoder
programs. If we wanted 99 byte records, all you needed was the logic
to take one byte from the end of one block and 98 from the next.

Of course, the simplest thing to do was target the block size and if
your design produced a 247 byte record, allow some room for expansion
and create 250 byte or 275 byte records.

> Also, in terms of easy to use, from a high level language like COBOL,
> one does not have to worry about how the disk file is physically
> organized on disk, except to use a reasonably efficient block size
> (any record length can be used). Sequential I/O is very easy, and for
> random files, ISAM works well.

1311s were on 1400 series machines. No COBOL in sight.

For the few years I did 14xx I did all kinds of file organization on 1311s
including split cylinder.

>> When they attached a drive that looked exactly the same to a S/360 they
>> called it a 2311 and came up with the CKD track format.  A huge step
>> backwards.
>
> Didn't they also double the capacity size of the disk when they went
> to 2311?

Yes, nominally. Of course it depended on physical record size.
The cabinet and pack looked exactly the same.

--
Dan Espen

[Peter Flass]

A DCB is both a collection of information about the file and the name of
the macro that generates it. It stores things like the nname of the
corresponding DD statement (DDNAME), the block size (BLKSIZE), record
length (LRECL), etc. These are also names of parameters of the DCB
macro, so the JCL DCB=() relates almost one-for-one to the macro.
Assembler programmers feel right at home.

--
Pete

[hanc...@bbs.cpcn.com]

On Oct 21, 5:58 pm, Peter Flass <Peter_Fl...@Yahoo.com> wrote:

> These are also names of parameters of the DCB
> macro, so the JCL DCB=() relates almost one-for-one to the macro.
> Assembler programmers feel right at home.

Yes, some of the information can be written in the program instead of
the JCL. IIRC, if in the program it overrides what is in the JCL
(such as the blocksize). But in my opinion, it's better to code the
stuff in the JCL so the program needn't be recompiled if the hardware
changes.

On our 360-DOS machine, we did not have device independence, and had
to code the type of device (eg tape, disk) and blocksize within the
program. To change from tape to disk required a recompile. I don't
know if that is still the case on DOS/VSE.

An example of the usefulness of device independence was when, on our
360-DOS machine, we wanted to get microfiche output instead of hard
copy. We had to recompile the program, changing it from printer to
tape. But on OS, no recompilation was necessary.

[Charlie Gibbs]

In article <m3sj97k...@garlic.com>, ly...@garlic.com

(Anne & Lynn Wheeler) writes:

> lots of interactive stuff has responsible person sitting there and
> any glitches can be handle in real time. in batch processing ...
> detailed JCL specification help increase the probability that
> application runs to completion ... for instance, even before
> starts (hopefully) all the resource requirements are specified
> in detail.

Hence my contention that "interactive" is a synonym for "manual".

--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!

[Gerard Schildberger]

And also for the IBM 1620 computer. _____ Gerard Schildberger

[Peter Flass]

Not DPS on the model 20. The 2311 was formatted with ~270 byte blocks
and a record had to start on a block. Apparently the disk was sectored
- who knew? I believe it had 10 "hidden" sectors per track. I'll have
to check a reference card, but this may be the source of the
computations on how many blocks of whatever size fit on a track. After
50 years I'm still finding stuff out.

--
Pete

[Peter Flass]

On 10/21/2012 6:09 PM, hanc...@bbs.cpcn.com wrote:
> On Oct 21, 5:58 pm, Peter Flass <Peter_Fl...@Yahoo.com> wrote:
>
>> These are also names of parameters of the DCB
>> macro, so the JCL DCB=() relates almost one-for-one to the macro.
>> Assembler programmers feel right at home.
>
> Yes, some of the information can be written in the program instead of
> the JCL. IIRC, if in the program it overrides what is in the JCL
> (such as the blocksize). But in my opinion, it's better to code the
> stuff in the JCL so the program needn't be recompiled if the hardware
> changes.

If you were clever you could control this by reading the JFCB containing
indormation from the DD card, before opening the file and making
whatever tweaks you wanted.

>
> On our 360-DOS machine, we did not have device independence, and had
> to code the type of device (eg tape, disk) and blocksize within the
> program. To change from tape to disk required a recompile. I don't
> know if that is still the case on DOS/VSE.

Wow, that's old! They came out with a DTFDI for device independence by
maybe DOS/360 release 26. It's a sad commentary on the times that this
was seen as a great advance in computer technology.

--
Pete

[Shmuel Metz]

In <icmwzfp...@home.home>, on 10/21/2012

at 01:25 PM, Dan Espen <des...@verizon.net> said:

>I think you're referencing the release that allows variables to
>affect instream data?

No, I was referring to the syntax of the EXEC statements. JCL is what
the name says; a job control language, not a procedural language; it
is intended to control the execution of applications. If the
application is IEBGENER or IEBCOPY, it is trivial to write a copy
procedure that takes the input and output as symbolic parameters.

[Shmuel Metz]

In <k615nf$b5b$1...@dont-email.me>, on 10/21/2012

at 10:52 AM, "Charles Richmond" <nume...@aquaporin4.com> said:

>I know that DCB stands for "data control block"... but I'm *not*
>sure of its function. Is it some sort of disk buffer???

No; a DCB is roughly a file handle. It provides the ddname of an
allocation and some information on how you want to access it, along
with current status.

[Shmuel Metz]

In <iczk3gp...@home.home>, on 10/20/2012

at 09:38 PM, Dan Espen <des...@verizon.net> said:

>When they attached a drive that looked exactly the same to a S/360
>they called it a 2311 and came up with the CKD track format.

You've written the 1301 out of history. It was a deviation from the
RAMAC architecture and preceded the 1311.

[Dan Espen]

Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> writes:

> In <iczk3gp...@home.home>, on 10/20/2012
> at 09:38 PM, Dan Espen <des...@verizon.net> said:
>
>>When they attached a drive that looked exactly the same to a S/360
>>they called it a 2311 and came up with the CKD track format.
>
> You've written the 1301 out of history. It was a deviation from the
> RAMAC architecture and preceded the 1311.

I'm aware of the 1301 and Ramac, never used or saw one.
Just pictures in a book to me.

--
Dan Espen

[Walter Bushell]

In article <743.712T40...@kltpzyxm.invalid>,

"Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:

> In article <m3sj97k...@garlic.com>, ly...@garlic.com
> (Anne & Lynn Wheeler) writes:
>
> > lots of interactive stuff has responsible person sitting there and
> > any glitches can be handle in real time. in batch processing ...
> > detailed JCL specification help increase the probability that
> > application runs to completion ... for instance, even before
> > starts (hopefully) all the resource requirements are specified
> > in detail.
>
> Hence my contention that "interactive" is a synonym for "manual".

I used to work for a Interactive Marketing Systems and that was an oft
repeated joke. Manual Marketing Systems.

--
This space unintentionally left blank.

[Shmuel Metz]

In <ic8vazp...@home.home>, on 10/21/2012

at 05:47 PM, Dan Espen <des...@verizon.net> said:

>1311s were on 1400 series machines. No COBOL in sight.

<http://bitsavers.trailing-edge.com/pdf/ibm/140x/C24-1492-2_1401_tapeCobol.pdf>

[Dan Espen]

Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> writes:

> In <ic8vazp...@home.home>, on 10/21/2012
> at 05:47 PM, Dan Espen <des...@verizon.net> said:
>
>>1311s were on 1400 series machines. No COBOL in sight.
>
> <http://bitsavers.trailing-edge.com/pdf/ibm/140x/C24-1492-2_1401_tapeCobol.pdf>

Always the stickler!

Of course I know there was a COBOL compiler.
Did anyone sane use it?

That's why there was no COBOL in sight.

I never saw it on 1410, but I think I remember you mentioning
a 1410 running COBOL?

There was RPG too.
I took one look and told my boss to forget it.

Was it a separate program that did plug boards or was there
some way to translate plug boards to RPG?

Tape COBOL, that must have been something to behold.
I used both tape Autocoder and disk Autocoder.
Disk was a lot better to work with,

--
Dan Espen

[Dan Espen]

Dan Espen <des...@verizon.net> writes:

> Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> writes:
>
>> In <ic8vazp...@home.home>, on 10/21/2012
>> at 05:47 PM, Dan Espen <des...@verizon.net> said:
>>
>>>1311s were on 1400 series machines. No COBOL in sight.
>>
>> <http://bitsavers.trailing-edge.com/pdf/ibm/140x/C24-1492-2_1401_tapeCobol.pdf>
>
> Always the stickler!
>
> Of course I know there was a COBOL compiler.
> Did anyone sane use it?
>
> That's why there was no COBOL in sight.
>
> I never saw it on 1410, but I think I remember you mentioning
> a 1410 running COBOL?
>
> There was RPG too.
> I took one look and told my boss to forget it.
>
> Was it a separate program that did plug boards or was there
> some way to translate plug boards to RPG?

Ah, got it. FARGO.
Got both manuals at the same time I think. 1965.

[Shmuel Metz]

In <k63c3c$ruv$1...@dont-email.me>, on 10/22/2012

at 08:00 AM, Peter Flass <Peter...@Yahoo.com> said:

>If you were clever you could control this by reading the JFCB
>containing indormation from the DD card, before opening the file
>and making whatever tweaks you wanted.

If you were clever you only used a RDJFCB and OPENJ for the things
that were not easy to do in a DCB exit.

>Wow, that's old! They came out with a DTFDI for device independence
>by maybe DOS/360 release 26.

But note the restrictions on DTFDI.

[Nick Spalding]

Shmuel wrote, in <50860451$13$fuzhry+tra$mr2...@news.patriot.net>
on Mon, 22 Oct 2012 21:43:29 -0500:

> In <ic8vazp...@home.home>, on 10/21/2012
> at 05:47 PM, Dan Espen <des...@verizon.net> said:
>
> >1311s were on 1400 series machines. No COBOL in sight.
>
> <http://bitsavers.trailing-edge.com/pdf/ibm/140x/C24-1492-2_1401_tapeCobol.pdf>

It was a two-stage process. The COBOL compiler produced Autocoder which
then had to be run through the Assembler to get the runnable program.
The 1410/7010 one worked the same way.
--
Nick Spalding

[Joe Morris]

"Dan Espen" <des...@verizon.net> wrote:

[1400 series systems]

> Tape COBOL, that must have been something to behold.

More than once only if you were a masochist. There was a COBOL compiler on
the 1401 at my PPOE (university) but its performance was so retched
(spelling deliberate) that it wasn't used; the accounting majors had to
learn Autocoder. Oh yes...this was on a diskless 8K machine with 7330 tape
drives (200/556 bpi; none of this new-fangled 800 stuff...and at the blazing
speed of 15 ips).

Joe

[Shmuel Metz]

In <ic3916j...@home.home>, on 10/22/2012

at 10:14 PM, Dan Espen <des...@verizon.net> said:

>I never saw it on 1410, but I think I remember you mentioning a 1410
>running COBOL?

I never used it.

>There was RPG too.

And FARGO.

>I took one look and told my boss to forget it.

If you needed to print columns of data and needed subtotals for some
columns, RPG was convenient.

>Was it a separate program that did plug boards or was there some
>way to translate plug boards to RPG?

Not that I'm aware of.

[Walter Bushell]

In article <k676k...@news1.newsguy.com>,

Still better than the programmable calculator on my first job that
worked with a program on paper tape. There was one loop possible by
making the program tape into a physical loop and there were two jump
instructions maximum in a program. The thing took 13 seconds to do a
floating arctangent, and we liked it.

[Shmuel Metz]

In <k676k...@news1.newsguy.com>, on 10/23/2012
at 06:44 PM, "Joe Morris" <j.c.m...@verizon.net> said:

>7330

It's hardly fair to evaluate a compiler based on its performance using
7330 tape drives; real programmers eat 729 tape drives.

We got acceptable performance on a 7070 using 729 drives; I'm not
sure, but I believe that they were model 4, which did not handle 800
BPI.

[jmfbahciv]

Shmuel (Seymour J.) Metz wrote:
> In <k676k...@news1.newsguy.com>, on 10/23/2012
> at 06:44 PM, "Joe Morris" <j.c.m...@verizon.net> said:
>
>>7330
>
> It's hardly fair to evaluate a compiler based on its performance using
> 7330 tape drives; real programmers eat 729 tape drives.

<snort> Our real programmers would have fed the tape drives to the dog
and then be arrested for cruelty. ;-) When TW was trying to write
the contoller and device drivers for the TU70s (which were the best
drives we ever hooked up to a PDP-10) he glared at the drives one
morning after a long debugging sessions and declared, "God never meant
for there to be magtapes."

/BAH

[Joe Morris]

"Shmuel (Seymour J.) Metz" <spam...@library.lspace.org.invalid> wrote:
>"Joe Morris" <j.c.m...@verizon.net> said:

>>7330

> It's hardly fair to evaluate a compiler based on its performance using
> 7330 tape drives; real programmers eat 729 tape drives.

It's perfectly fair if you're talking about a university shop where you
don't have the money to buy the faster drives. (This was the academic
center; the administration computer center also had a 1401 but with much
nicer toys to connect to it.) And in a business environment you (hopefully)
have a production mindset that doesn't need to do multiple compiles for each
student (not "real programmers") in large BA classes.

My point was that the compiler wrote huge amounts of data on its
intermediate tapes (IIRC requiring four drives just for the scratch tapes).

Joe

[Joe Morris]

"jmfbahciv" <See....@aol.com> wrote:

> <snort> Our real programmers would have fed the tape drives to the dog
> and then be arrested for cruelty. ;-) When TW was trying to write
> the contoller and device drivers for the TU70s (which were the best
> drives we ever hooked up to a PDP-10) he glared at the drives one
> morning after a long debugging sessions and declared, "God never meant
> for there to be magtapes."

I'm trying to remember: what was the DEC nomenclature for the rebadged
Storage Tech half-inch drives that DEC sold with the -10? These were drives
intended to go on an IBM selector channel and were unmodified by DEC; they
attached through an adapter (D-something-10) that mapped massbus
architecture to a selector channel interface.

My memory of them is that they weren't particularly reliable, not only
because the idjut designers had a motorized front panel that moved *up* and
through the top of the frame, just where one would have placed the next tape
to be mounted.

The STC controller for the drives (again, rebadged) came with the
two-channel-switch feature as a default. I wanted to hang the unused side
of the switch onto our S/360 but DEC's position was that doing so would void
the warranty.

Joe

[Dan Espen]

When I started, I spent 6 months at a Tape Autocoder place, then
went to a 1440 shop for 2 years. Disk Autocoder was a lot nicer.

--
Dan Espen

[Shmuel Metz]

In <PM0004CCC...@aca20db2.ipt.aol.com>, on 10/24/2012

at 01:40 PM, jmfbahciv <See....@aol.com> said:

><snort> Our real programmers would have fed the tape drives to the
>dog

Would that be DECtape?

[Shmuel Metz]

In <k6a3o...@news7.newsguy.com>, on 10/24/2012

at 09:13 PM, "Joe Morris" <j.c.m...@verizon.net> said:

>It's perfectly fair if you're talking about a university shop
>where you don't have the money to buy the faster drives.

My 7070 experience was at a university, and there were at least two
university computing centers in Michigan better funded then we were.

[jmfbahciv]

Shmuel (Seymour J.) Metz wrote:

> In <PM0004CCC...@aca20db2.ipt.aol.com>, on 10/24/2012
> at 01:40 PM, jmfbahciv <See....@aol.com> said:
>
>><snort> Our real programmers would have fed the tape drives to the
>>dog
>
> Would that be DECtape?
>

NEVER!!! DECtapes were the best storage media in the world. They
could survive heat, cold, forklifts, kids, dirty fingers, and
years of usage and you could still get the files off those tapes.

/BAH

[jmfbahciv]

Joe Morris wrote:
> "jmfbahciv" <See....@aol.com> wrote:
>
>> <snort> Our real programmers would have fed the tape drives to the dog
>> and then be arrested for cruelty. ;-) When TW was trying to write
>> the contoller and device drivers for the TU70s (which were the best
>> drives we ever hooked up to a PDP-10) he glared at the drives one
>> morning after a long debugging sessions and declared, "God never meant
>> for there to be magtapes."
>
> I'm trying to remember: what was the DEC nomenclature for the rebadged
> Storage Tech half-inch drives that DEC sold with the -10? These were drives
> intended to go on an IBM selector channel and were unmodified by DEC; they
> attached through an adapter (D-something-10) that mapped massbus
> architecture to a selector channel interface.
>
> My memory of them is that they weren't particularly reliable, not only
> because the idjut designers had a motorized front panel that moved *up* and
> through the top of the frame, just where one would have placed the next tape
> to be mounted.

The only ones I can recall at the moment, whose doors went up, were called
the TU40/41s.

>
> The STC controller for the drives (again, rebadged) came with the
> two-channel-switch feature as a default. I wanted to hang the unused side
> of the switch onto our S/360 but DEC's position was that doing so would void
> the warranty.

I wonder why. I'm not a hardware type so I couldn't guess unless it was
just brainfarts on the part of the local FS.

/BAH

[Walter Banks]

Where can I read DECtapes now? I have a bunch of backup DECtapes
that haven't been read for 30 years whose content from time to time
I could use.

w..

[Al Kossow]

> Where can I read DECtapes now?

What does this have to do with OS/360 JCL?

[hanc...@bbs.cpcn.com]

On Oct 24, 8:15 am, Shmuel (Seymour J.) Metz

<spamt...@library.lspace.org.invalid> wrote:

> It's hardly fair to evaluate a compiler based on its performance using
> 7330 tape drives; real programmers eat 729 tape drives.
>
> We got acceptable performance on a 7070 using 729 drives; I'm not
> sure, but I believe that they were model 4, which did not handle 800
> BPI.

The 2415 were terrible.

[Bill Sudbrink]

In article <50897062...@bytecraft.com> Walter Banks <wal...@bytecraft.com> writes:
>
>Where can I read DECtapes now? I have a bunch of backup DECtapes
>that haven't been read for 30 years whose content from time to time
>I could use.
>

Ask on the cctalk mailing list:

cctalk <at> classiccmp <dot> org

Lots of members with operating classic dec hardware.

[Peter Flass]

We got a lot of work out of them. My first exposure to a 3420 a bearing
went on the drive and the hub came completely off with the reel still
attached.

--
Pete

[Scott Lurndal]

jmfbahciv <See....@aol.com> writes:
>Joe Morris wrote:
>> "jmfbahciv" <See....@aol.com> wrote:
>>
>>> <snort> Our real programmers would have fed the tape drives to the dog
>>> and then be arrested for cruelty. ;-) When TW was trying to write
>>> the contoller and device drivers for the TU70s (which were the best
>>> drives we ever hooked up to a PDP-10) he glared at the drives one
>>> morning after a long debugging sessions and declared, "God never meant
>>> for there to be magtapes."
>>
>> I'm trying to remember: what was the DEC nomenclature for the rebadged
>> Storage Tech half-inch drives that DEC sold with the -10? These were drives
>> intended to go on an IBM selector channel and were unmodified by DEC; they
>> attached through an adapter (D-something-10) that mapped massbus
>> architecture to a selector channel interface.
>>
>> My memory of them is that they weren't particularly reliable, not only
>> because the idjut designers had a motorized front panel that moved *up* and
>> through the top of the frame, just where one would have placed the next tape
>> to be mounted.
>
>The only ones I can recall at the moment, whose doors went up, were called
>the TU40/41s.

I gave a TU58 drive and carts to the CHM a while back, I don't know if they've
used them.

scott

[Charles Richmond]

"Walter Banks" <wal...@bytecraft.com> wrote in message
news:50897062...@bytecraft.com...

Get yourself some of that there mag tape liquid and a magnifying glass...
;-)

Perhaps you should try and contact Mark Crispin... he may have or know
someone who has a TU-56 drive.

--

numerist at aquaporin4 dot com

[Walter Banks]

Charles Richmond wrote:

> Get yourself some of that there mag tape liquid and a magnifying glass...
> ;-)
>

I forgot about that stuff. My eyes are not as good as they were when I last
used it 40 + years ago. :)
It would work, should get the first tape read by the end of the decade.

:D w..

[Shmuel Metz]

In <k6bvip$c6o$3...@dont-email.me>, on 10/25/2012

at 02:26 PM, Peter Flass <Peter...@Yahoo.com> said:

>We got a lot of work out of them. My first exposure to a 3420 a
>bearing went on the drive and the hub came completely off with the
>reel still attached.

Oddly enough, I found the 3420 to be reasonably reliable; certainly
better than the Potter[1] tape drives I once had the "pleasure" of
working with.

[1] I was tempted to inadvertently type Potty, although I understand
that Potter once made reliable hardware.

[capek@ieee.org <Peter Capek>]

On Friday, October 19, 2012 11:25:40 AM UTC-4, hanc...@bbs.cpcn.com wrote:

> The computer history museum has a video of a 2011 lecture by Fred
>
> Brooks on the development of System/360. Very interesting. In it
> Brooks talks about JCL and its problems.
>
> http://www.computerhistory.org/revolution/mainframe-computers/7/162/2270

Very interesting. But one small point: In this excerpt, Fred mentions how
special column 73 was in JCL, explaining that it was related to the historical
way in which the IBM 701 punched 2 36-bit words per row in a card, leaving column 73 for some unstated purpose.

Wasn't it column 72 that was special in JCL (and, incidentally, in assembler)?
The need was eliminated at some point, but column 72 was used to indicate that the JCL statement was (almost always...) continued on the next card when column 72 was not blank. Or do I have this wrong?