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

On Mon, 20 Jan 2003 12:35:53 -0500, "Shmuel (Seymour J.) Metz"

Quote:



>>IMO systems where you don't need JCL are better designed for humans
>>to use.

>How do you design a system where you don't need JCL? You can, of
>course, change the nomenclature, and there are a lot of ways that you
>can structure it, but you need some way to specify what functions to
>perform, where the inputs are and where to place the outputs.

JCL is a strict system for predefining all the resources needed
to execute a predetermined collection of programs a fixed number
of times. There's very little flexibility in terms of selecting
inputs, outputs, which programs should be run, how many times
they should be run. A decent OS can allow the user or the program
to make decisions they need to make, or provide useful defaults,
perhaps tailored by the site, the user, the program, or any
combo, for decisions the user doesn't really care about.

Quote:
>There's an old joke, to which the puch line is "We've already settled
>what you are, now we're just haggling over the price." Well, if you
>see a need for a command language of any sort, then you've already
>accepted the need for JCL and you're just haggling over how it should
>look and what functionality it should have.

I would not call JCL a command language by any stretch: REXX is a
command language; just about every other OS command interface
could be called a command language, but JCL is only a bunch of
rigid overrides to rigid program I/O macros controlling data
allocation. Other systems provide the same degree of control over
files as JCL, without requiring every user to repeat a bunch of
redundant information every time they want to use a file.

And I say this from the point of view of a former VM, DOS(/VSE),
MVS and other systems programmer: JCL is a ghastly Byzantine
mess, that may have had a point when systems were small and
resource limited, but should not be required on any system where
the average OS overhead exceeds 30% of the total CPU. I wonder
how much that overhead could be reduced by eliminating JCL and
have the system make decisions smarter than those made by the
programmers and users. Other systems do resource management in
addition to allocation, they do it much better than batch JCL
oriented systems, with much lower overhead, and for much lower
cost.

I suspect the reasons and problems are similar to those that have
resulted in the elimination of SNA from the networking world:
outdated and rigid bad design, based on outdated assumptions,
supported by high marketing budget and margins,  bolstered by
FUD, hacked to keep it from falling apart when interfaced with
more modern devices, until it is obvious even to customer's
managers that just about anything else is more effective.

That was not intended as a flame or rant, but it's time IBM threw
out all their hopelessly outdated software and hardware
architectures, got all their decent designers together and did
something relevant for today's users with today's problems.
I have great respect for the way they treat(ed?) customers, their
many capable and some brilliant staff, but they really need to
let their guys with ideas drive the company, instead of them
fighting the company to allow them to let users at the great
products they come up with that the users are dying to get.
If IBM was run like 3M, they'd probably still own 90% of the
market, but they let corporate management politics get in the way
of what users demanded, and users went with companies that
delivered.

Boy, that feels better! ;^>

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

    fake address                use address above to reply






Sat, 09 Jul 2005 17:16:27 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.

Huh?  Do mean commenting?  I didn't waste card space on comments;
those things went on cards that would be ignored.  You didn't
make short lines for readability purposes.  You need to punch
some cards and design a layout with an 80-character restriction.

/BAH

Subtract a hundred and four for e-mail.



Sat, 09 Jul 2005 18:22:19 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.

<snip>

How did they check?  This is a badly worded question but I
don't know enough to write a good one.

I suppose that there could alphanumeric checks and print
stars around questionable cards.  Or that there were continuation
cards in places that didn't make much sense.

/BAH

Subtract a hundred and four for e-mail.



Sat, 09 Jul 2005 18:32:45 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.
> <snip>

> How did they check?  This is a badly worded question but I
> don't know enough to write a good one.

With the Mk I eyeball.  

Quote:
> I suppose that there could alphanumeric checks and print
> stars around questionable cards.  Or that there were continuation
> cards in places that didn't make much sense.

I don't think any tab could do that sort of checking.
--
Nick Spalding


Sat, 09 Jul 2005 20:58:35 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.
>> <snip>

>> How did they check?  This is a badly worded question but I
>> don't know enough to write a good one.

>With the Mk I eyeball.  

>> I suppose that there could alphanumeric checks and print
>> stars around questionable cards.  Or that there were continuation
>> cards in places that didn't make much sense.

>I don't think any tab could do that sort of checking.

I didn't think so unless you wired it to spit stars if
nonnumeric.  But then, those boards were definitely magic
incantations from my POV.  I always wanted to learn how to
play with them but that was also too ambitious and there
weren't any spares to sneak.

/BAH

Subtract a hundred and four for e-mail.



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

Quote:

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

> Only when printing blank lines.
> For printing alphanumeric stuff, it slowed down a lot.
> It couldn't keep up with the 600 card-per-minute reader.

It depends on which flavor of 1403 you're talking about. The
original machine, as attached to the 1401 computer, had a fixed
character set of 48 characters, repeated 5 times around the
perimeter of the chain.  Its printing speed was fixed, and came
in at 600lpm, regardless of what was being printed.

Other versions of the printer, equipped with "Universal Character
Set" (UCS) support, at attached to a suitably-circuited IBM 2821
integrated control unit (ICU), tied to a 360 channel, had much
more variable speed, depending on what was being printed, and
what print chain/train was used.  I say "train" because the 1403
model N1, among others, had a naturally faster printing speed,
and required a faster magnetic-core print buffer. The "train" was
mechanically distinct from the chain, in that the type-slugs were
not linked together as a chain, but pushed each other around a
closed track, driven by a gear at one end. The chain, used on
slower models, had type slugs attached to a metal band. The 1401
memory was 11 microsecond, and it could only drive a 600 lpm
printer. With a 5-microsecond buffer cycle, the speed could be
upped to 1100 lpm, for the basic 48-character set, and more (or
less) with UCS.  The time required to advance paper between lines
wasn't any quicker, which is why the speedup isn't proportional
to memory cycle time.

With UCS, the printer control unit would signal "print line
complete" whenever it had printed every non-blank character in
the print line, so the average print speed, a 48-character set,
was more like 1200 lpm, instead of 1100.

What would really slow down the printer, though, was attempting
to print non-printable characters; i.e. character codes not found
in the UCS buffer that listed the characters on the installed
type chain/train. In that case, the control unit would wait until
the second occurance of a "home" pulse from the printer before
giving up on finding a suitable type-slug to fire a hammer at.
This slowed printing down to a crawl.

The full EBCDIC character set, containing all the characters used
in the PL/I language, consisted of 60 glyphs. A customer could
choose whether to use a "QN" or "PN" type-train to print
listings.  The QN train was faster at printing non-PL/I
characters and slower if the output contained PL/I-specific
special characters. This was because it had 5 complete sets of
letters, digits, and common special characters, and only 1 each
of PL/I-specific characters. The PN arrangement, on the other
hand, had 4 sets of all 60 characters, and was preferred for
printing PL/I program listings, although slower for other uses.

Slowest of all was the "TN" train, which was used for text
printing. It had full upper- and lower-case letters, numbers,
numeric superscripts, line-drawing characters, and a bunch of
other stuff.  There were 120 glyphs in all, and only two sets on
the train.

On UCS-equipped printers (and control units), "printing" a blank
line was indeed fastest of all, because the all-blank condition
would be detected on the first buffer-scan, and the ICU would
signal Print Line Complete almost immediately.

Some other trivia: The "links" on the train contained 3
type-faces, and there were 80 of them.  On the chain, each link
had only two type-faces, and there were 120 of them. The type
faces were spaced .1505 inches apart, so the total length of the
chain/train was 36.12 inches.

The printer control unit operated so that one character code from
the print-line buffer was compared to a code from the UCS buffer
every 5 microseconds (for train printers). Every third
print-position was "optioned" to print every other type-face on
the train, in the sequence. Thus, each round of print-buffer to
UCS-buffer compare scans was done in three passes, successively
starting at the first, second, and third print positions. When a
match was found, the ICU fired the print hammer magnet, and set a
bit in the buffer indicating that that character had been
printed. When all these bits were found set to 1 on a print scan,
that signalled Print Line Complete.

The 3/2 ratio between UCS and print buffer address increments
echoed the 3/2 ratio between the type-slug spacing and the
1/10-inch spacing between print hammers. The extra .0005 of an
inch between type-faces accounted for the movement of the
type-train during the 5-microsecond interval between
buffer-compares. The type train moved at 200 inches per second.
On the 600 lpm chain printers, all timings proportionately are
the same, scaled to an 11-microsecond buffer cycle-time.

There was a certain pattern of characters that would cause all
132 print hammers to fire during one full buffer-scan. If you hit
the printer with this same pattern on about a half-dozen
successive print lines (with a print-no-space command), it would
severely stress the mechanism, and would probably break the chain
on a chain printer.  The train couldn't be broken that way, of
course, but the "chain-break" pattern would cause a "sync-check"
error, signalling that the control unit had lost sync with the
type-train. You could tear a hole in the ribbon, too, if the
sync-check didn't stop the printer. Fortunately, this pattern was
unlikely, unless it was done deliberately. It was kept a secret
from college students whenever possible.

By the way, I was ranked first in my 1403/2540/2821 class in CE
school back in '66, and I still remember a lot of that stuff.
It's kinda fun to dredge it back up. :-)



Sun, 10 Jul 2005 01:11:48 GMT  
 Card Columns (was Why did they make ... ?)


Quote:
>JCL is a strict system for predefining all the resources needed to
>execute a predetermined collection of programs a fixed number of
>times.

No. Not in general and not in OS/360 JCL either.

Quote:
>A decent OS can allow the user

JCL is the means by which the user communicates that.

Quote:
>I would not call JCL a command language by any stretch:

Which JCL? A command language is a JCL; not every JCL is a command
language.

Quote:
>REXX is a command language;

No it is not; REXX is a scripting language, and relies on an
underlying command language to pass requests to the operating system.
In fact, an application is free to support REXX in a manner that
provides no command environment.

Quote:
>JCL is only a bunch of rigid overrides

Again, you are confusing "JCL" with "OS/360" JCL, and are wrong even
about the latter.

Quote:
>And I say this from the point of view of a former VM, DOS(/VSE),
>MVS

You've used DOS and you've used MVS, and you've never noticed that
they don't have the same JCL? You should have; it would have given you
a clue that JCL is a generic term.

Quote:
>average OS overhead

Most of which has nothing to do with handling the JCL.

Quote:
>I wonder
>how much that overhead could be reduced by eliminating JCL and have
>the system make decisions smarter than those made by the programmers
>and users.

None. But the failed attempt would undoubtedly make life harder for
the users.

Quote:
>Other systems do resource management in
>addition to allocation, they do it much better than batch JCL
>oriented systems, with much lower overhead, and for much lower cost.

Most resource management has nothing to do with JCL. Other systems may
have more overhead, or less, to, e.g., schedule an I/O, or less, but
that has nothing to do with the nature of their user interfaces.

Quote:
>I suspect the reasons and problems are similar to those that have
>resulted in the elimination of SNA from the networking world:

The use of TCP/IP on the ARPA net has a lot more to do with it than
any characteristics of SNA.

Quote:
>I have great respect for the way they treat(ed?) customers,

It's a dirty job, but somebody has to do it.

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



Sun, 10 Jul 2005 00:36:55 GMT  
 Card Columns (was Why did they make ... ?)


Quote:
>We are talking about different machines.

I doubt it.

Quote:
>I was referring to the
>teletypewriters used by Western Union 40's, 50's and 60's.

Which used Baudot, not ASCII.

Quote:
>They only had three rows of keys which explains why all the  digits
>and specials characters were accessed in FIGS mode.

The figures and letters key didn't just switch modes; they also
generated characters. If you were punching paper tape, you puched
those characters when you hit the keys. without them you wouldn't have
been able to read the tape back correctly.

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



Sun, 10 Jul 2005 00:15:50 GMT  
 Card Columns (was Why did they make ... ?)


Quote:
>Burroughs Medium Systems (if my memories are correct).

I assume that you mean the B2500 et al; it had JCL.

Quote:
>        FD  DSKFIL

And DSKFIL refers to what file? Whatever facility you use to identify
what DSKFIL is a JCL.

Quote:
>We don't need no stinkin' JCL :-)

See above.

Quote:
>Admittedly, on large systems WFL does the JCL functions

"The story you are about to see is true. Only the names have been
changed to protect the innocent."

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



Sun, 10 Jul 2005 00:09:18 GMT  
 Card Columns (was Why did they make ... ?)


Quote:
>they weren't suppose to be compatible ... it was every model in the
>360 line that was suppose to be compatible.

That wasn't what IBM told the general public. Having a new line of
compatible processors net to other lines of compatible processors
incompatible with the first was nothing new.

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



Sun, 10 Jul 2005 00:03:39 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