Magnetic Drum reservations 1952

[undefined Hancock-4]

This article describes an early airline reservation system using a device
based on magnetic drums.

https://books.google.com/books?id=s3hCAQAAIAAJ&newbks=1&newbks_redir=0&dq=%22morning%20congressional%22%20train%20phone&pg=RA2-PA46#v=onepage&q&f=false

As airline traffic grew it proved to be inadequate, inspiring AA and IBM to
to develop the SABRE computer system.

(Given the experience of developing a massive online host and complex
application software for SABRE, one wonders why they didn't learn
from that when IBM developed OS for S/360 and got so bogged down.)

[John Levine]

Post by undefined Hancock-4
(Given the experience of developing a massive online host and complex
application software for SABRE, one wonders why they didn't learn
from that when IBM developed OS for S/360 and got so bogged down.)

The projects were very different. SABRE was a single application realtime
transaction system. OS was a general purpose system that could run all sorts
of applicatons.

IBM did reimplment SABRE on S/360 as PARS (the airline application)
and ACP (the control program.) ACP has since evolved into TPF which
still runs a lot of high performance transaction systems on zSeries
hardware.

[David Lesher]

Post by John Levine
IBM did reimplment SABRE on S/360 as PARS (the airline application)
and ACP (the control program.) ACP has since evolved into TPF which
still runs a lot of high performance transaction systems on zSeries
hardware.

A Tek serial data test set I used decades ago had not just ASCII
but also some 6-bit code that was used for airline reservation
systems. ?ALPS? maybe?

What's its history?

[chris]

Post by David Lesher

Post by John Levine
IBM did reimplment SABRE on S/360 as PARS (the airline application)
and ACP (the control program.) ACP has since evolved into TPF which
still runs a lot of high performance transaction systems on zSeries
hardware.

A Tek serial data test set I used decades ago had not just ASCII
but also some 6-bit code that was used for airline reservation
systems. ?ALPS? maybe?
What's its history?

Sounds like the Justowriter, a modified Friden Flexowriter for
typesetting work. That used a 5 bit baudot code (rtty), but added
a sixth bit for case shift...

[Scott Lurndal]

Post by chris

Post by David Lesher

Post by John Levine
IBM did reimplment SABRE on S/360 as PARS (the airline application)
and ACP (the control program.) ACP has since evolved into TPF which
still runs a lot of high performance transaction systems on zSeries
hardware.

A Tek serial data test set I used decades ago had not just ASCII
but also some 6-bit code that was used for airline reservation
systems. ?ALPS? maybe?
What's its history?

Sounds like the Justowriter, a modified Friden Flexowriter for
typesetting work. That used a 5 bit baudot code (rtty), but added
a sixth bit for case shift...

Well, EBCDIC was an 2-bit extension to BCDIC which was a 6-bit code.

Burroughs also had 6-bit codes on early machines.

[Andy Burns]

Post by Scott Lurndal
EBCDIC was an 2-bit extension to BCDIC

EBCDIC is awkward enough to pronounce,
I've usually heard it as ebb-suh-dick, so how do you pronounce BCDIC ?

[John Levine]

Post by Andy Burns

Post by Scott Lurndal
EBCDIC was an 2-bit extension to BCDIC

EBCDIC is awkward enough to pronounce,
I've usually heard it as ebb-suh-dick, so how do you pronounce BCDIC ?

Bee-Cee-Dee, of course

[Ahem A Rivet's Shot]

On Thu, 22 Jul 2021 17:51:24 +0100

Post by Andy Burns

Post by Scott Lurndal
EBCDIC was an 2-bit extension to BCDIC

EBCDIC is awkward enough to pronounce,
I've usually heard it as ebb-suh-dick, so how do you pronounce BCDIC ?

I've also heard EBCDIC pronounced ebb-kuh-dick which would make
BCDIC come out as bic-dick.
____________________^ That's a C see!

[Charlie Gibbs]

Post by Ahem A Rivet's Shot
On Thu, 22 Jul 2021 17:51:24 +0100

Post by Andy Burns

Post by Scott Lurndal
EBCDIC was an 2-bit extension to BCDIC

EBCDIC is awkward enough to pronounce,
I've usually heard it as ebb-suh-dick, so how do you pronounce BCDIC ?

I've also heard EBCDIC pronounced ebb-kuh-dick which would make
BCDIC come out as bic-dick.
____________________^ That's a C see!

A TA in a computer science class I once took pronounced EBCDIC
"ee-biddy-dick".

As for BCDIC, maybe it's a back-formation.

[TrailingEdgeTechnologies]

Post by Charlie Gibbs

Post by Ahem A Rivet's Shot
On Thu, 22 Jul 2021 17:51:24 +0100

Post by Andy Burns

Post by Scott Lurndal
EBCDIC was an 2-bit extension to BCDIC

EBCDIC is awkward enough to pronounce,
I've usually heard it as ebb-suh-dick, so how do you pronounce BCDIC ?

I've also heard EBCDIC pronounced ebb-kuh-dick which would make
BCDIC come out as bic-dick.
____________________^ That's a C see!

A TA in a computer science class I once took pronounced EBCDIC
"ee-biddy-dick".
As for BCDIC, maybe it's a back-formation.
--
/~\ Charlie Gibbs | They don't understand Microsoft
X I'm really at ac.dekanfrus | a taxi in their driveway.
/ \ if you read it the right way. | -- Mayayana

[TrailingEdgeTechnologies]

Post by Charlie Gibbs

Post by Ahem A Rivet's Shot
On Thu, 22 Jul 2021 17:51:24 +0100

Post by Andy Burns

Post by Scott Lurndal
EBCDIC was an 2-bit extension to BCDIC

EBCDIC is awkward enough to pronounce,
I've usually heard it as ebb-suh-dick, so how do you pronounce BCDIC ?

I've also heard EBCDIC pronounced ebb-kuh-dick which would make
BCDIC come out as bic-dick.
____________________^ That's a C see!

A TA in a computer science class I once took pronounced EBCDIC
"ee-biddy-dick".
As for BCDIC, maybe it's a back-formation.
--
/~\ Charlie Gibbs | They don't understand Microsoft
X I'm really at ac.dekanfrus | a taxi in their driveway.
/ \ if you read it the right way. | -- Mayayana

[Dan Espen]

Post by Andy Burns

Post by Scott Lurndal
EBCDIC was an 2-bit extension to BCDIC

EBCDIC is awkward enough to pronounce,
I've usually heard it as ebb-suh-dick, so how do you pronounce BCDIC ?

Never saw a reference to BCDIC, it was BCD. Pronounced B-C-D.

[Ahem A Rivet's Shot]

On Thu, 22 Jul 2021 15:14:55 -0400

Post by Dan Espen

Post by Andy Burns

Post by Scott Lurndal
EBCDIC was an 2-bit extension to BCDIC

EBCDIC is awkward enough to pronounce,
I've usually heard it as ebb-suh-dick, so how do you pronounce BCDIC ?

Never saw a reference to BCDIC, it was BCD. Pronounced B-C-D.

The term was used, I think to differentiate the six bit
alphanumeric codes from the four bit numeric 'code' (simply binary for 0-9
in four bit groups) known as BCD to hardware types and occasionally in
instruction sets eg 68K has ABCD (Add Binary Coded Decimal).

[Dan Espen]

Post by Ahem A Rivet's Shot
On Thu, 22 Jul 2021 15:14:55 -0400

Post by Dan Espen

Post by Andy Burns

Post by Scott Lurndal
EBCDIC was an 2-bit extension to BCDIC

EBCDIC is awkward enough to pronounce,
I've usually heard it as ebb-suh-dick, so how do you pronounce BCDIC ?

Never saw a reference to BCDIC, it was BCD. Pronounced B-C-D.

The term was used, I think to differentiate the six bit
alphanumeric codes from the four bit numeric 'code' (simply binary for 0-9
in four bit groups) known as BCD to hardware types and occasionally in
instruction sets eg 68K has ABCD (Add Binary Coded Decimal).

I suspect that term appeared AFTER the term EBCDIC was invented.
Before S/360 was announced the only term I remember was BCD.
There were never any pretensions that BCD was an "interchange" code.
I believe IBM snuck that term "interchange" in there to justify not
using ASCII.

[Quadibloc]

Post by Dan Espen
I suspect that term appeared AFTER the term EBCDIC was invented.
Before S/360 was announced the only term I remember was BCD.
There were never any pretensions that BCD was an "interchange" code.
I believe IBM snuck that term "interchange" in there to justify not
using ASCII.

I checked this, and indeed, the six bit codes for alphanumerics
were referred to as "BCD code" in a 1401 manual predating the 1401.

So the four-bit numeric code would just be binary-coded decimal,
while the six-bit alphanumeric code is BCD code, later changed to
BCD interchange code by analogy with ASCII.

John Savard

[undefined Hancock-4]

Post by Dan Espen
I suspect that term appeared AFTER the term EBCDIC was invented.
Before S/360 was announced the only term I remember was BCD.
There were never any pretensions that BCD was an "interchange" code.
I believe IBM snuck that term "interchange" in there to justify not
using ASCII.

+ 1

It got confusing in data centers with multiple types of computers, one EBCDIC,
one BCD. Often such sites had an 026 and 029 keypunches. The basic
characters were the same, but certain special characters were different.

One could use either keypunch, but would need to know the proper substitution
which could be tedious.

[Robin Vowels]

Post by undefined Hancock-4

Post by Dan Espen
I suspect that term appeared AFTER the term EBCDIC was invented.
Before S/360 was announced the only term I remember was BCD.
There were never any pretensions that BCD was an "interchange" code.
I believe IBM snuck that term "interchange" in there to justify not
using ASCII.

+ 1
It got confusing in data centers with multiple types of computers, one EBCDIC,
one BCD. Often such sites had an 026 and 029 keypunches. The basic
characters were the same, but certain special characters were different.

.
Irritatingly, the Plus sign was different. (Y vs Y-5-8)
.

Post by undefined Hancock-4
One could use either keypunch, but would need to know the proper substitution
which could be tedious.

[Charlie Gibbs]

Post by undefined Hancock-4

Post by Dan Espen
I suspect that term appeared AFTER the term EBCDIC was invented.
Before S/360 was announced the only term I remember was BCD.
There were never any pretensions that BCD was an "interchange" code.
I believe IBM snuck that term "interchange" in there to justify not
using ASCII.

+ 1
It got confusing in data centers with multiple types of computers, one EBCDIC,
one BCD. Often such sites had an 026 and 029 keypunches. The basic
characters were the same, but certain special characters were different.
One could use either keypunch, but would need to know the proper substitution
which could be tedious.

The fun thing I discovered was that although the glyphs were different,
the key at any given location on the keyboard punched the same combination
of holes regardless of whether it had a BCD or an EBCDIC code plate.
Thus, if you could touch-type the BCD keyboard, you could sit down at
an EBCDIC machine and create your card deck (and vice versa with a few
gotchas, see below). The special characters printed on the cards would
be wrong, but the computer would see exactly what you wanted. That came
in handy at university, where there would often be a line-up for one
flavour of keypunch while the other ones stood empty.

The one catch was the the 026 couldn't punch everything that a 029
could; you'd have to resort to the multi-punch key for the less-used
characters.

[Andy Burns]

Post by Dan Espen
Never saw a reference to BCDIC,

Me neither, but wikilies claims it was a thing, even has an
Addison-Wesley reference

Post by Dan Espen
it was BCD. Pronounced B-C-D.

[Grant Taylor]

Post by Dan Espen
Never saw a reference to BCDIC, it was BCD. Pronounced B-C-D.

I've seen reference to non-Extended BCDIC in IBM documentation.

It also seems reasonable to me that for there to be an extended form of
something there usually needs to be a non-extended (proceeding) form.

[Dan Espen]

Post by Grant Taylor

Post by Dan Espen
Never saw a reference to BCDIC, it was BCD. Pronounced B-C-D.

I've seen reference to non-Extended BCDIC in IBM documentation.

Before or after S/360 and EBCDIC were invented?

Post by Grant Taylor
It also seems reasonable to me that for there to be an extended form
of something there usually needs to be a non-extended (proceeding)
form.

You get the extended form and the non-extended form, after the extended
form is invented?

[TrailingEdgeTechnologies]

Post by Andy Burns

Post by Scott Lurndal
EBCDIC was an 2-bit extension to BCDIC

EBCDIC is awkward enough to pronounce,
I've usually heard it as ebb-suh-dick, so how do you pronounce BCDIC ?

Retelling old story here:

Had full exposure to IBM systems from 1620 forward while in college; in 1967, Rutgers acquired one of the first 360/67s, and then spouse moved into systems programmer slot working to iron out TSS (don't ask); spent a lot of time moving older FORTRAN code from 7044 to S/360. Three years later, I had just gotten off a flight from McGuire to Bien Hoa, Vietnam, expecting to be a radio operator for the Americal division. First sit down after debarking: guy up front asks "does anybody have the wrong MOS on their orders"? Well, I was sent to be a radio operator, but I had stayed over at Fort Dix as a court martial clerk and tuba player, so I raised my hand, looking for the guy who was checking MOS problems. Another question: "does anybody here have an Master's degree"? Now, this was an interesting question: were too many people with Master's degrees being killed in Vietnam, or were not enough people with Master's degrees being killed in Vietnam? This seemed like a 50/50 chance, which is rare in the Army, so I put my other hand up, and made eye contact with the guy looking for Master's degrees. So, I'm sitting there, with two hands up, looking like I'm in second grade, and need to go to the bathroom, and after droning on the guy up front goes "does anybody here know what (and I'm going to spell this out, 'cause I don't think it is a word), does anybody here know what EEE-BEE-CEE-DEE-EYE-CEE is?". I put my foot into the air, and I spent the last ten months of my two years in the Army working on a Burroughs 3500 at the Data Service Center in Long Binh, Vietnam.

[Scott Lurndal]

Scott Lurndal wrote:=20
=20

Post by Scott Lurndal
EBCDIC was an 2-bit extension to BCDIC

EBCDIC is awkward enough to pronounce,=20
I've usually heard it as ebb-suh-dick, so how do you pronounce BCDIC ?

Had full exposure to IBM systems from 1620 forward while in college; in 196=
7, Rutgers acquired one of the first 360/67s, and then spouse moved into sy=
stems programmer slot working to iron out TSS (don't ask); spent a lot of t=
ime moving older FORTRAN code from 7044 to S/360. Three years later, I had =
just gotten off a flight from McGuire to Bien Hoa, Vietnam, expecting to be=
a radio operator for the Americal division. First sit down after debarking=
: guy up front asks "does anybody have the wrong MOS on their orders"? Well=
, I was sent to be a radio operator, but I had stayed over at Fort Dix as a=
court martial clerk and tuba player, so I raised my hand, looking for the =
guy who was checking MOS problems. Another question: "does anybody here hav=
e an Master's degree"? Now, this was an interesting question: were too many=
people with Master's degrees being killed in Vietnam, or were not enough p=
eople with Master's degrees being killed in Vietnam? This seemed like a 50/=
50 chance, which is rare in the Army, so I put my other hand up, and made e=
ye contact with the guy looking for Master's degrees. So, I'm sitting there=
, with two hands up, looking like I'm in second grade, and need to go to th=
e bathroom, and after droning on the guy up front goes "does anybody here k=
now what (and I'm going to spell this out, 'cause I don't think it is a wor=
d), does anybody here know what EEE-BEE-CEE-DEE-EYE-CEE is?". I put my foot=
into the air, and I spent the last ten months of my two years in the Army =
working on a Burroughs 3500 at the Data Service Center in Long Binh, Vietna=
m.

It was at Burroughs (working on the successors to the B3500) that I ran
across the term BCDIC - which as someone pointed out, distinguishes
between BCD 4-bit digits (as implemented on the B3500 et alia) and
the interchange code used between older burroughs machines (Burroughs
called their 6-bit code BCL - which may have been an acronym/backronym for
Burroughs Common Language)

[Louis Krupp]

Post by Scott Lurndal

Scott Lurndal wrote:=20
=20

Post by Scott Lurndal
EBCDIC was an 2-bit extension to BCDIC

EBCDIC is awkward enough to pronounce,=20
I've usually heard it as ebb-suh-dick, so how do you pronounce BCDIC ?

Had full exposure to IBM systems from 1620 forward while in college; in 196=
7, Rutgers acquired one of the first 360/67s, and then spouse moved into sy=
stems programmer slot working to iron out TSS (don't ask); spent a lot of t=
ime moving older FORTRAN code from 7044 to S/360. Three years later, I had =
just gotten off a flight from McGuire to Bien Hoa, Vietnam, expecting to be=
a radio operator for the Americal division. First sit down after debarking=
: guy up front asks "does anybody have the wrong MOS on their orders"? Well=
, I was sent to be a radio operator, but I had stayed over at Fort Dix as a=
court martial clerk and tuba player, so I raised my hand, looking for the =
guy who was checking MOS problems. Another question: "does anybody here hav=
e an Master's degree"? Now, this was an interesting question: were too many=
people with Master's degrees being killed in Vietnam, or were not enough p=
eople with Master's degrees being killed in Vietnam? This seemed like a 50/=
50 chance, which is rare in the Army, so I put my other hand up, and made e=
ye contact with the guy looking for Master's degrees. So, I'm sitting there=
, with two hands up, looking like I'm in second grade, and need to go to th=
e bathroom, and after droning on the guy up front goes "does anybody here k=
now what (and I'm going to spell this out, 'cause I don't think it is a wor=
d), does anybody here know what EEE-BEE-CEE-DEE-EYE-CEE is?". I put my foot=
into the air, and I spent the last ten months of my two years in the Army =
working on a Burroughs 3500 at the Data Service Center in Long Binh, Vietna=
m.

It was at Burroughs (working on the successors to the B3500) that I ran
across the term BCDIC - which as someone pointed out, distinguishes
between BCD 4-bit digits (as implemented on the B3500 et alia) and
the interchange code used between older burroughs machines (Burroughs
called their 6-bit code BCL - which may have been an acronym/backronym for
Burroughs Common Language)

You're correct. BCL was Burroughs Common Language.

Louis

[Vir Campestris]

Post by Scott Lurndal
Burroughs also had 6-bit codes on early machines.

As did DEC - the DECSystem10 had a native 36 bit word size. A filename
was one word, giving 6 characters of 6 bits (plus another half word for
the file type, such as TXT)

Andy

[John Levine]

Post by Vir Campestris

Post by Scott Lurndal
Burroughs also had 6-bit codes on early machines.

As did DEC - the DECSystem10 had a native 36 bit word size. A filename
was one word, giving 6 characters of 6 bits (plus another half word for
the file type, such as TXT)

That was just a sixbit subset of ASCII, subtract 040 from the ASCII value. They used it
on the earlier PDP-6 and some of their 12 and 18 bit machines.

The DEC assemblers used an even more compressed encoding known as
RADIX50 or SQUOZE, which had six characters from a 40 character (50
octal) set encoded into 32 bits with four left over for flags. I
gather there was a BCD-based SQUOZE used on IBM machines in the 1950s.

[Thomas Koenig]

Post by John Levine
The DEC assemblers used an even more compressed encoding known as
RADIX50 or SQUOZE, which had six characters from a 40 character (50
octal) set encoded into 32 bits with four left over for flags.

Wow, division for accessing text..., on the other hand, not worse
than formatting a decimal number. Tt seems they carried it over
to 16-bit words containing three characters each to the PDP-11 and
the VAX, too, from what https://en.wikipedia.org/wiki/DEC_RADIX_50
tells us. Still 1536 values left over as flags even in that case
(a bit more than 10 bits).

Post by John Levine
I
gather there was a BCD-based SQUOZE used on IBM machines in the 1950s.

Yep, for the 36-bit machines, but it appears they didn't carry
over the system to the /360 series.

[Bob Eager]

Post by John Levine
The DEC assemblers used an even more compressed encoding known as
RADIX50 or SQUOZE, which had six characters from a 40 character (50
octal) set encoded into 32 bits with four left over for flags.

Wow, division for accessing text..., on the other hand, not worse than
formatting a decimal number. Tt seems they carried it over to 16-bit
words containing three characters each to the PDP-11 and the VAX, too,
from what https://en.wikipedia.org/wiki/DEC_RADIX_50 tells us. Still
1536 values left over as flags even in that case (a bit more than 10
bits).

And on the PDP-8 - two in a 12-bit word.

[gareth evans]

Post by Thomas Koenig

Post by John Levine
The DEC assemblers used an even more compressed encoding known as
RADIX50 or SQUOZE, which had six characters from a 40 character (50
octal) set encoded into 32 bits with four left over for flags.

Wow, division for accessing text..., on the other hand, not worse
than formatting a decimal number. Tt seems they carried it over
to 16-bit words containing three characters each to the PDP-11 and
the VAX, too, from what https://en.wikipedia.org/wiki/DEC_RADIX_50
tells us. Still 1536 values left over as flags even in that case
(a bit more than 10 bits).

Post by John Levine
I
gather there was a BCD-based SQUOZE used on IBM machines in the 1950s.

Yep, for the 36-bit machines, but it appears they didn't carry
over the system to the /360 series.

For the PDP11, it was .RAD40, up to 6 characters in 32 bits
(or 3 in 16 bits), A-Z, 0-9, ".", "$" and " "

[Rich Alderson]

Post by gareth evans

Post by Thomas Koenig

Post by John Levine
The DEC assemblers used an even more compressed encoding known as
RADIX50 or SQUOZE, which had six characters from a 40 character (50
octal) set encoded into 32 bits with four left over for flags.

Wow, division for accessing text..., on the other hand, not worse
than formatting a decimal number. Tt seems they carried it over
to 16-bit words containing three characters each to the PDP-11 and
the VAX, too, from what https://en.wikipedia.org/wiki/DEC_RADIX_50
tells us. Still 1536 values left over as flags even in that case
(a bit more than 10 bits).

Post by John Levine
I
gather there was a BCD-based SQUOZE used on IBM machines in the 1950s.

Yep, for the 36-bit machines, but it appears they didn't carry
over the system to the /360 series.

For the PDP11, it was .RAD40, up to 6 characters in 32 bits
(or 3 in 16 bits), A-Z, 0-9, ".", "$" and " "

As Mr. Levine noted, 40_10 = 50_8. It's the same thing, under different names.

[gareth evans]

Post by Rich Alderson

Post by gareth evans

Post by Thomas Koenig

Post by John Levine
The DEC assemblers used an even more compressed encoding known as
RADIX50 or SQUOZE, which had six characters from a 40 character (50
octal) set encoded into 32 bits with four left over for flags.

Wow, division for accessing text..., on the other hand, not worse
than formatting a decimal number. Tt seems they carried it over
to 16-bit words containing three characters each to the PDP-11 and
the VAX, too, from what https://en.wikipedia.org/wiki/DEC_RADIX_50
tells us. Still 1536 values left over as flags even in that case
(a bit more than 10 bits).

Post by John Levine
I
gather there was a BCD-based SQUOZE used on IBM machines in the 1950s.

Yep, for the 36-bit machines, but it appears they didn't carry
over the system to the /360 series.

For the PDP11, it was .RAD40, up to 6 characters in 32 bits
(or 3 in 16 bits), A-Z, 0-9, ".", "$" and " "

As Mr. Levine noted, 40_10 = 50_8. It's the same thing, under different names.

Sorry, it wasn't ".", "$" and " " but ".", "$" and "_"

[TrailingEdgeTechnologies]

Post by chris

Post by David Lesher

Post by John Levine
IBM did reimplment SABRE on S/360 as PARS (the airline application)
and ACP (the control program.) ACP has since evolved into TPF which
still runs a lot of high performance transaction systems on zSeries
hardware.

A Tek serial data test set I used decades ago had not just ASCII
but also some 6-bit code that was used for airline reservation
systems. ?ALPS? maybe?
What's its history?

Sounds like the Justowriter, a modified Friden Flexowriter for
typesetting work. That used a 5 bit baudot code (rtty), but added
a sixth bit for case shift...

The code used on the modified Selectric typewriters of the SABRE system was PTTC/BCD (Paper Tape Transmission Code/Binary Coded Decimal) which was standard for IBM communications systems of the time, such as the 1050 series. A Selectric typewriter ball was designed with the printable characters arranged to match the bit patterns of PTTC code, so that the Selectric mechanism would move its multitude of parts according to the bit pattern. The odd bit rate of 134.5 bits/per/second matched the speed at which the "rugged" version of the Selectric mechanism (as used in the 1050) could operate without exploding. Working low-mileage 1053 "typers" were a hot commodity item among the surviving 1800 systems users well into the middle 1990s.

[undefined Hancock-4]

Post by TrailingEdgeTechnologies

Post by chris

Post by David Lesher

Post by John Levine
IBM did reimplment SABRE on S/360 as PARS (the airline application)
and ACP (the control program.) ACP has since evolved into TPF which
still runs a lot of high performance transaction systems on zSeries
hardware.

A Tek serial data test set I used decades ago had not just ASCII
but also some 6-bit code that was used for airline reservation
systems. ?ALPS? maybe?
What's its history?

Sounds like the Justowriter, a modified Friden Flexowriter for
typesetting work. That used a 5 bit baudot code (rtty), but added
a sixth bit for case shift...

The code used on the modified Selectric typewriters of the SABRE system was PTTC/BCD (Paper Tape Transmission Code/Binary Coded Decimal) which was standard for IBM communications systems of the time, such as the 1050 series. A Selectric typewriter ball was designed with the printable characters arranged to match the bit patterns of PTTC code, so that the Selectric mechanism would move its multitude of parts according to the bit pattern. The odd bit rate of 134.5 bits/per/second matched the speed at which the "rugged" version of the Selectric mechanism (as used in the 1050) could operate without exploding. Working low-mileage 1053 "typers" were a hot commodity item among the surviving 1800 systems users well into the middle 1990s.

In the SABRE history, there is mention that the original terminals also used reference cards and an extra button panel.
The agent inserted a reference card into the machine that apparently was read and provided additional information.
They might have had a card for each flight.

How this information was transmitted to the computer was not explained.

[undefined Hancock-4]

Post by undefined Hancock-4
(Given the experience of developing a massive online host and complex
application software for SABRE, one wonders why they didn't learn
from that when IBM developed OS for S/360 and got so bogged down.)

The projects were very different. SABRE was a single application realtime
transaction system. OS was a general purpose system that could run all sorts
of applicatons.

I see your point, but I think there are still some common aspects. First,
both were massive programming efforts, pushing the state of the art
at the time, using new, large, powerful computers. Both programming
groups were venturing into new areas (though SABRE had some influence
from SAGE).

Second, both the SABRE host and S/360-OS had to load in various
modules on demand, execute them, and then release them. Both had
to handle multiple modules running simultaneous, with protection
and control against overlapping memory and I/O demands. All
this is complex as well as new.

Third, given the nature of both projects, all the programmers were
somewhat inexperienced since it was cutting edge work. Further,
given the size, I suspect some of the programmers were inexperienced
altogether (there weren't that many programmers out there at the time.)

I can't help but think programmers had to do some experimentation,
which costs time. Some modules probably didn't work out very
well in testing and had to be abandoned or rewritten, wasting
calendar time.

We know the S/360-OS programmers were under an enormous
time pressure. But I suspect the SABRE people were as well.

[Peter Flass]

Post by undefined Hancock-4

Post by undefined Hancock-4
(Given the experience of developing a massive online host and complex
application software for SABRE, one wonders why they didn't learn
from that when IBM developed OS for S/360 and got so bogged down.)

The projects were very different. SABRE was a single application realtime
transaction system. OS was a general purpose system that could run all sorts
of applicatons.

I see your point, but I think there are still some common aspects. First,
both were massive programming efforts, pushing the state of the art
at the time, using new, large, powerful computers. Both programming
groups were venturing into new areas (though SABRE had some influence
from SAGE).
Second, both the SABRE host and S/360-OS had to load in various
modules on demand, execute them, and then release them. Both had
to handle multiple modules running simultaneous, with protection
and control against overlapping memory and I/O demands. All
this is complex as well as new.
Third, given the nature of both projects, all the programmers were
somewhat inexperienced since it was cutting edge work. Further,
given the size, I suspect some of the programmers were inexperienced
altogether (there weren't that many programmers out there at the time.)
I can't help but think programmers had to do some experimentation,
which costs time. Some modules probably didn't work out very
well in testing and had to be abandoned or rewritten, wasting
calendar time.
We know the S/360-OS programmers were under an enormous
time pressure. But I suspect the SABRE people were as well.

SABRE was designed to do one thing very well. OS was expected to do
everything, and therefore wasn’t very good at anything. The Burroughs large
systems MCP could run rings around OS/360. It didn’t do everything OS did,
but did what had to be done.

[undefined Hancock-4]

Post by Peter Flass

Post by undefined Hancock-4
(Given the experience of developing a massive online host and complex
application software for SABRE, one wonders why they didn't learn
from that when IBM developed OS for S/360 and got so bogged down.)

The projects were very different. SABRE was a single application realtime
transaction system. OS was a general purpose system that could run all sorts
of applicatons.

I see your point, but I think there are still some common aspects. First,
both were massive programming efforts, pushing the state of the art
at the time, using new, large, powerful computers. Both programming
groups were venturing into new areas (though SABRE had some influence
from SAGE).
Second, both the SABRE host and S/360-OS had to load in various
modules on demand, execute them, and then release them. Both had
to handle multiple modules running simultaneous, with protection
and control against overlapping memory and I/O demands. All
this is complex as well as new.
Third, given the nature of both projects, all the programmers were
somewhat inexperienced since it was cutting edge work. Further,
given the size, I suspect some of the programmers were inexperienced
altogether (there weren't that many programmers out there at the time.)
I can't help but think programmers had to do some experimentation,
which costs time. Some modules probably didn't work out very
well in testing and had to be abandoned or rewritten, wasting
calendar time.
We know the S/360-OS programmers were under an enormous
time pressure. But I suspect the SABRE people were as well.

SABRE was designed to do one thing very well. OS was expected to do
everything, and therefore wasn’t very good at anything. The Burroughs large
systems MCP could run rings around OS/360. It didn’t do everything OS did,
but did what had to be done.

OS was developed to control resources of a large computer system. In the old
days when memory, peripherals, and CPU speed were scarce yet workloads
large this was critical. There wasn't a lot of room on a 2-meg 2311 or an
800 bpi tape. So we could specify exactly the parameters of the file we were
creating, including how many tracks it would take up. Not necessary today, but
important back then. We had different kinds of files, such as library files (PDS).

In looking over JCL, we see a million options. But they were necessary to handle
many different I/O situations.

For instance, we did things like store multiple independent files on a single reel
of tape. We produced tapes of many different formats for export to other data
centers, and likewise we would read such tapes. JCL handled all the options.

We could specify a particular peripheral unit or let the system assign it to us.
We could utilize spooling for printing, or print hot.

Many times we output to a specialty device that needed special formatting.

There were convenience features, like stored procedures which were great for
compilations. Within a job, we could refer backwards to files created in an
earlier job step. We could direct the job to quit if an earlier step failed, or run
a special step. Output files could be automatically sequenced and old files
rolled off (generation data group). The location and format of an input file
could be stored in a catalog, or specified afresh.

I remember a large university data center and the numerous requests to mount
disk and tapes for specific jobs. The system had to track all that stuff.

This is just scratching the surface.

How did this compare to the JCL of other large scale computer systems?

[Thomas Koenig]

undefined Hancock-4 <***@bbs.cpcn.com> schrieb:

[JCL]

Post by undefined Hancock-4
There were convenience features, like stored procedures which were great for
compilations. Within a job, we could refer backwards to files created in an
earlier job step. We could direct the job to quit if an earlier step failed, or run
a special step.

Ah yes, the fabled COND parameter, a wonder of interface design and user
experience unrivalled since then.

I wrote JCL containing a hundred lines or so once, compiling a
Fortran job on a 3090 to see if there were syntax errors, then
sending it across to a Fujutsu vector computer which also ran MVS
or a copy thereof, running the program and then getting back the
output from there.

[Kerr-Mudd, John]

On Sat, 7 Aug 2021 20:04:39 -0000 (UTC)

Post by Thomas Koenig
[JCL]

Post by undefined Hancock-4
There were convenience features, like stored procedures which were great for
compilations. Within a job, we could refer backwards to files created in an
earlier job step. We could direct the job to quit if an earlier step failed, or run
a special step.

Ah yes, the fabled COND parameter, a wonder of interface design and user
experience unrivalled since then.
I wrote JCL containing a hundred lines or so once, compiling a
Fortran job on a 3090 to see if there were syntax errors, then
sending it across to a Fujutsu vector computer which also ran MVS
or a copy thereof, running the program and then getting back the
output from there.

[Kerr-Mudd, John]

On Sat, 7 Aug 2021 20:04:39 -0000 (UTC)

Post by Thomas Koenig
[JCL]

Post by undefined Hancock-4
There were convenience features, like stored procedures which were great for
compilations. Within a job, we could refer backwards to files created in an
earlier job step. We could direct the job to quit if an earlier step failed, or run
a special step.

Ah yes, the fabled COND parameter, a wonder of interface design and user
experience unrivalled since then.

Urgh indeed. I was quite taken aback to be told ICL had (George III?) a JCL that was just
simple If Else conditionals.

Post by Thomas Koenig
I wrote JCL containing a hundred lines or so once, compiling a
Fortran job on a 3090 to see if there were syntax errors, then
sending it across to a Fujutsu vector computer which also ran MVS
or a copy thereof, running the program and then getting back the
output from there.

[undefined Hancock-4]

Post by Thomas Koenig
[JCL]

Post by undefined Hancock-4
There were convenience features, like stored procedures which were great for
compilations. Within a job, we could refer backwards to files created in an
earlier job step. We could direct the job to quit if an earlier step failed, or run
a special step.

Ah yes, the fabled COND parameter, a wonder of interface design and user
experience unrivalled since then.

Yes, the COND parameter was counter-intuitive. Saying COND=(0,NE) meant
to run the step, not ignore the step. Even the developer, Fred Brooks, said
it was a lousy design.

But it was a powerful tool to handle a multitude of trouble situations. A program
could set the condition code. There was an option to write a message to the
operator. In more recent years, one could issue an email from the job in case
of a problem, and various emails depending on the problem. Or, upon successful completion.

[J. Clarke]

On Tue, 10 Aug 2021 11:49:07 -0700 (PDT), undefined Hancock-4

Post by undefined Hancock-4

Post by Thomas Koenig
[JCL]

Post by undefined Hancock-4
There were convenience features, like stored procedures which were great for
compilations. Within a job, we could refer backwards to files created in an
earlier job step. We could direct the job to quit if an earlier step failed, or run
a special step.

Ah yes, the fabled COND parameter, a wonder of interface design and user
experience unrivalled since then.

Yes, the COND parameter was counter-intuitive. Saying COND=(0,NE) meant
to run the step, not ignore the step. Even the developer, Fred Brooks, said
it was a lousy design.
But it was a powerful tool to handle a multitude of trouble situations. A program
could set the condition code. There was an option to write a message to the
operator. In more recent years, one could issue an email from the job in case
of a problem, and various emails depending on the problem. Or, upon successful completion.

There's a particular job where one of these days I'm going to set it
up to send me an email, and on receipt of the email have Windows
retrieve and do stuff with the output.

[Robin Vowels]

Post by Peter Flass

Post by undefined Hancock-4
(Given the experience of developing a massive online host and complex
application software for SABRE, one wonders why they didn't learn
from that when IBM developed OS for S/360 and got so bogged down.)

The projects were very different. SABRE was a single application realtime
transaction system. OS was a general purpose system that could run all sorts
of applicatons.

I see your point, but I think there are still some common aspects. First,
both were massive programming efforts, pushing the state of the art
at the time, using new, large, powerful computers. Both programming
groups were venturing into new areas (though SABRE had some influence
from SAGE).
Second, both the SABRE host and S/360-OS had to load in various
modules on demand, execute them, and then release them. Both had
to handle multiple modules running simultaneous, with protection
and control against overlapping memory and I/O demands. All
this is complex as well as new.
Third, given the nature of both projects, all the programmers were
somewhat inexperienced since it was cutting edge work. Further,
given the size, I suspect some of the programmers were inexperienced
altogether (there weren't that many programmers out there at the time.)
I can't help but think programmers had to do some experimentation,
which costs time. Some modules probably didn't work out very
well in testing and had to be abandoned or rewritten, wasting
calendar time.
We know the S/360-OS programmers were under an enormous
time pressure. But I suspect the SABRE people were as well.

SABRE was designed to do one thing very well. OS was expected to do
everything, and therefore wasn’t very good at anything. The Burroughs large
systems MCP could run rings around OS/360. It didn’t do everything OS did,
but did what had to be done.

OS was developed to control resources of a large computer system. In the old
days when memory, peripherals, and CPU speed were scarce yet workloads
large this was critical. There wasn't a lot of room on a 2-meg 2311 or an
800 bpi tape. So we could specify exactly the parameters of the file we were
creating, including how many tracks it would take up. Not necessary today, but
important back then. We had different kinds of files, such as library files (PDS).
In looking over JCL, we see a million options. But they were necessary to handle
many different I/O situations.
For instance, we did things like store multiple independent files on a single reel
of tape. We produced tapes of many different formats for export to other data
centers, and likewise we would read such tapes. JCL handled all the options.
We could specify a particular peripheral unit or let the system assign it to us.
We could utilize spooling for printing, or print hot.
Many times we output to a specialty device that needed special formatting.
There were convenience features, like stored procedures which were great for
compilations. Within a job, we could refer backwards to files created in an
earlier job step. We could direct the job to quit if an earlier step failed, or run
a special step. Output files could be automatically sequenced and old files
rolled off (generation data group). The location and format of an input file
could be stored in a catalog, or specified afresh.
I remember a large university data center and the numerous requests to mount
disk and tapes for specific jobs. The system had to track all that stuff.
This is just scratching the surface.
How did this compare to the JCL of other large scale computer systems?

.
It was overly complex. No need to specify block size and record length
on CDC's Cyber 70 series.

[undefined Hancock-4]

Post by Peter Flass

Post by undefined Hancock-4
(Given the experience of developing a massive online host and complex
application software for SABRE, one wonders why they didn't learn
from that when IBM developed OS for S/360 and got so bogged down.)

The projects were very different. SABRE was a single application realtime
transaction system. OS was a general purpose system that could run all sorts
of applicatons.

I see your point, but I think there are still some common aspects. First,
both were massive programming efforts, pushing the state of the art
at the time, using new, large, powerful computers. Both programming
groups were venturing into new areas (though SABRE had some influence
from SAGE).
Second, both the SABRE host and S/360-OS had to load in various
modules on demand, execute them, and then release them. Both had
to handle multiple modules running simultaneous, with protection
and control against overlapping memory and I/O demands. All
this is complex as well as new.
Third, given the nature of both projects, all the programmers were
somewhat inexperienced since it was cutting edge work. Further,
given the size, I suspect some of the programmers were inexperienced
altogether (there weren't that many programmers out there at the time.)
I can't help but think programmers had to do some experimentation,
which costs time. Some modules probably didn't work out very
well in testing and had to be abandoned or rewritten, wasting
calendar time.
We know the S/360-OS programmers were under an enormous
time pressure. But I suspect the SABRE people were as well.

SABRE was designed to do one thing very well. OS was expected to do
everything, and therefore wasn’t very good at anything. The Burroughs large
systems MCP could run rings around OS/360. It didn’t do everything OS did,
but did what had to be done.

OS was developed to control resources of a large computer system. In the old
days when memory, peripherals, and CPU speed were scarce yet workloads
large this was critical. There wasn't a lot of room on a 2-meg 2311 or an
800 bpi tape. So we could specify exactly the parameters of the file we were
creating, including how many tracks it would take up. Not necessary today, but
important back then. We had different kinds of files, such as library files (PDS).
In looking over JCL, we see a million options. But they were necessary to handle
many different I/O situations.
For instance, we did things like store multiple independent files on a single reel
of tape. We produced tapes of many different formats for export to other data
centers, and likewise we would read such tapes. JCL handled all the options.
We could specify a particular peripheral unit or let the system assign it to us.
We could utilize spooling for printing, or print hot.
Many times we output to a specialty device that needed special formatting.
There were convenience features, like stored procedures which were great for
compilations. Within a job, we could refer backwards to files created in an
earlier job step. We could direct the job to quit if an earlier step failed, or run
a special step. Output files could be automatically sequenced and old files
rolled off (generation data group). The location and format of an input file
could be stored in a catalog, or specified afresh.
I remember a large university data center and the numerous requests to mount
disk and tapes for specific jobs. The system had to track all that stuff.
This is just scratching the surface.
How did this compare to the JCL of other large scale computer systems?

.
It was overly complex. No need to specify block size and record length
on CDC's Cyber 70 series.

It appeared that the Cyber 70 was about ten years newer than S/360, so perhaps
disk blocking and usage was more efficient. But blocking is important, be it
handled automatically by software (as Z series does now) or by the programmer.

[Robin Vowels]

Post by undefined Hancock-4

Post by Peter Flass

Post by undefined Hancock-4
(Given the experience of developing a massive online host and complex
application software for SABRE, one wonders why they didn't learn
from that when IBM developed OS for S/360 and got so bogged down.)

The projects were very different. SABRE was a single application realtime
transaction system. OS was a general purpose system that could run all sorts
of applicatons.

I see your point, but I think there are still some common aspects. First,
both were massive programming efforts, pushing the state of the art
at the time, using new, large, powerful computers. Both programming
groups were venturing into new areas (though SABRE had some influence
from SAGE).
Second, both the SABRE host and S/360-OS had to load in various
modules on demand, execute them, and then release them. Both had
to handle multiple modules running simultaneous, with protection
and control against overlapping memory and I/O demands. All
this is complex as well as new.
Third, given the nature of both projects, all the programmers were
somewhat inexperienced since it was cutting edge work. Further,
given the size, I suspect some of the programmers were inexperienced
altogether (there weren't that many programmers out there at the time.)
I can't help but think programmers had to do some experimentation,
which costs time. Some modules probably didn't work out very
well in testing and had to be abandoned or rewritten, wasting
calendar time.
We know the S/360-OS programmers were under an enormous
time pressure. But I suspect the SABRE people were as well.

SABRE was designed to do one thing very well. OS was expected to do
everything, and therefore wasn’t very good at anything. The Burroughs large
systems MCP could run rings around OS/360. It didn’t do everything OS did,
but did what had to be done.

OS was developed to control resources of a large computer system. In the old
days when memory, peripherals, and CPU speed were scarce yet workloads
large this was critical. There wasn't a lot of room on a 2-meg 2311 or an
800 bpi tape. So we could specify exactly the parameters of the file we were
creating, including how many tracks it would take up. Not necessary today, but
important back then. We had different kinds of files, such as library files (PDS).
In looking over JCL, we see a million options. But they were necessary to handle
many different I/O situations.
For instance, we did things like store multiple independent files on a single reel
of tape. We produced tapes of many different formats for export to other data
centers, and likewise we would read such tapes. JCL handled all the options.
We could specify a particular peripheral unit or let the system assign it to us.
We could utilize spooling for printing, or print hot.
Many times we output to a specialty device that needed special formatting.
There were convenience features, like stored procedures which were great for
compilations. Within a job, we could refer backwards to files created in an
earlier job step. We could direct the job to quit if an earlier step failed, or run
a special step. Output files could be automatically sequenced and old files
rolled off (generation data group). The location and format of an input file
could be stored in a catalog, or specified afresh.
I remember a large university data center and the numerous requests to mount
disk and tapes for specific jobs. The system had to track all that stuff.
This is just scratching the surface.
How did this compare to the JCL of other large scale computer systems?

.
It was overly complex. No need to specify block size and record length
on CDC's Cyber 70 series.

.

Post by undefined Hancock-4
It appeared that the Cyber 70 was about ten years newer than S/360, so perhaps
disk blocking and usage was more efficient. But blocking is important, be it
handled automatically by software (as Z series does now) or by the programmer.

.
The operating system Kronos on the Cyber 70 series was derived from
that on the earlier 6600 series, predating the S/360.

[Peter Flass]

Post by Robin Vowels

Post by undefined Hancock-4

Post by Peter Flass

Post by undefined Hancock-4
(Given the experience of developing a massive online host and complex
application software for SABRE, one wonders why they didn't learn
from that when IBM developed OS for S/360 and got so bogged down.)

The projects were very different. SABRE was a single application realtime
transaction system. OS was a general purpose system that could run all sorts
of applicatons.

I see your point, but I think there are still some common aspects. First,
both were massive programming efforts, pushing the state of the art
at the time, using new, large, powerful computers. Both programming
groups were venturing into new areas (though SABRE had some influence
from SAGE).
Second, both the SABRE host and S/360-OS had to load in various
modules on demand, execute them, and then release them. Both had
to handle multiple modules running simultaneous, with protection
and control against overlapping memory and I/O demands. All
this is complex as well as new.
Third, given the nature of both projects, all the programmers were
somewhat inexperienced since it was cutting edge work. Further,
given the size, I suspect some of the programmers were inexperienced
altogether (there weren't that many programmers out there at the time.)
I can't help but think programmers had to do some experimentation,
which costs time. Some modules probably didn't work out very
well in testing and had to be abandoned or rewritten, wasting
calendar time.
We know the S/360-OS programmers were under an enormous
time pressure. But I suspect the SABRE people were as well.

SABRE was designed to do one thing very well. OS was expected to do
everything, and therefore wasn’t very good at anything. The Burroughs large
systems MCP could run rings around OS/360. It didn’t do everything OS did,
but did what had to be done.

OS was developed to control resources of a large computer system. In the old
days when memory, peripherals, and CPU speed were scarce yet workloads
large this was critical. There wasn't a lot of room on a 2-meg 2311 or an
800 bpi tape. So we could specify exactly the parameters of the file we were
creating, including how many tracks it would take up. Not necessary today, but
important back then. We had different kinds of files, such as library files (PDS).
In looking over JCL, we see a million options. But they were necessary to handle
many different I/O situations.
For instance, we did things like store multiple independent files on a single reel
of tape. We produced tapes of many different formats for export to other data
centers, and likewise we would read such tapes. JCL handled all the options.
We could specify a particular peripheral unit or let the system assign it to us.
We could utilize spooling for printing, or print hot.
Many times we output to a specialty device that needed special formatting.
There were convenience features, like stored procedures which were great for
compilations. Within a job, we could refer backwards to files created in an
earlier job step. We could direct the job to quit if an earlier step failed, or run
a special step. Output files could be automatically sequenced and old files
rolled off (generation data group). The location and format of an input file
could be stored in a catalog, or specified afresh.
I remember a large university data center and the numerous requests to mount
disk and tapes for specific jobs. The system had to track all that stuff.
This is just scratching the surface.
How did this compare to the JCL of other large scale computer systems?

.
It was overly complex. No need to specify block size and record length
on CDC's Cyber 70 series.

.

Post by undefined Hancock-4
It appeared that the Cyber 70 was about ten years newer than S/360, so perhaps
disk blocking and usage was more efficient. But blocking is important, be it
handled automatically by software (as Z series does now) or by the programmer.

.
The operating system Kronos on the Cyber 70 series was derived from
that on the earlier 6600 series, predating the S/360.

I never thought of CDC operating systems as particularly advanced, though.
It seems like they got the job done, but without a lot of frills. Sort of
like the hardware.

[Peter Flass]

Post by undefined Hancock-4

Post by Peter Flass

Post by undefined Hancock-4
(Given the experience of developing a massive online host and complex
application software for SABRE, one wonders why they didn't learn
from that when IBM developed OS for S/360 and got so bogged down.)

The projects were very different. SABRE was a single application realtime
transaction system. OS was a general purpose system that could run all sorts
of applicatons.

I see your point, but I think there are still some common aspects. First,
both were massive programming efforts, pushing the state of the art
at the time, using new, large, powerful computers. Both programming
groups were venturing into new areas (though SABRE had some influence
from SAGE).
Second, both the SABRE host and S/360-OS had to load in various
modules on demand, execute them, and then release them. Both had
to handle multiple modules running simultaneous, with protection
and control against overlapping memory and I/O demands. All
this is complex as well as new.
Third, given the nature of both projects, all the programmers were
somewhat inexperienced since it was cutting edge work. Further,
given the size, I suspect some of the programmers were inexperienced
altogether (there weren't that many programmers out there at the time.)
I can't help but think programmers had to do some experimentation,
which costs time. Some modules probably didn't work out very
well in testing and had to be abandoned or rewritten, wasting
calendar time.
We know the S/360-OS programmers were under an enormous
time pressure. But I suspect the SABRE people were as well.

SABRE was designed to do one thing very well. OS was expected to do
everything, and therefore wasn’t very good at anything. The Burroughs large
systems MCP could run rings around OS/360. It didn’t do everything OS did,
but did what had to be done.

OS was developed to control resources of a large computer system. In the old
days when memory, peripherals, and CPU speed were scarce yet workloads
large this was critical. There wasn't a lot of room on a 2-meg 2311 or an
800 bpi tape. So we could specify exactly the parameters of the file we were
creating, including how many tracks it would take up. Not necessary today, but
important back then. We had different kinds of files, such as library files (PDS).
In looking over JCL, we see a million options. But they were necessary to handle
many different I/O situations.
For instance, we did things like store multiple independent files on a single reel
of tape. We produced tapes of many different formats for export to other data
centers, and likewise we would read such tapes. JCL handled all the options.
We could specify a particular peripheral unit or let the system assign it to us.
We could utilize spooling for printing, or print hot.
Many times we output to a specialty device that needed special formatting.
There were convenience features, like stored procedures which were great for
compilations. Within a job, we could refer backwards to files created in an
earlier job step. We could direct the job to quit if an earlier step failed, or run
a special step. Output files could be automatically sequenced and old files
rolled off (generation data group). The location and format of an input file
could be stored in a catalog, or specified afresh.
I remember a large university data center and the numerous requests to mount
disk and tapes for specific jobs. The system had to track all that stuff.
This is just scratching the surface.
How did this compare to the JCL of other large scale computer systems?

You could do 90% of the stuff with 20% of the complexity. Burroughs large
system MCP had some JCL (WFL?) but as I recall we rarely needed it. A job
card and an execute card was about it. Things like DSNs were coded in the
program, although they could be overridden in exceptional cases. I don’t
think the systems supported a lot of exotic peripherals or options.

[Charlie Gibbs]

Post by Peter Flass

Post by undefined Hancock-4
In looking over JCL, we see a million options. But they were necessary
to handle many different I/O situations.

<snip>

Post by Peter Flass

Post by undefined Hancock-4
How did this compare to the JCL of other large scale computer systems?

You could do 90% of the stuff with 20% of the complexity. Burroughs large
system MCP had some JCL (WFL?) but as I recall we rarely needed it. A job
card and an execute card was about it. Things like DSNs were coded in the
program, although they could be overridden in exceptional cases. I don’t
think the systems supported a lot of exotic peripherals or options.

A friend worked in a small Burroughs shop (1700). I think it wasn't
so much that not many peripherals were supported, but that the system
had a lot of device independence. You didn't need a special procedure
for each device, but just pointed your program at whatever device you
wanted to use and let the MCP sort it out. Also, there wasn't such a
plethora of file formats. I always hated the amount of work you had
to do to access a program module (source or binary) on a traditional
mainframe system. Mind you, given the overhead of each file (look
at the VTOC layout, for instance), storing each program module in
a separate file was simply not feasible in that environment.

[undefined Hancock-4]

Post by Peter Flass
You could do 90% of the stuff with 20% of the complexity. Burroughs large
system MCP had some JCL (WFL?) but as I recall we rarely needed it. A job
card and an execute card was about it. Things like DSNs were coded in the
program, although they could be overridden in exceptional cases. I don’t
think the systems supported a lot of exotic peripherals or options.

It wasn't every day, but periodically we had to write special JCL to handle
a special imported or exported file. We'd have to look up options in the JCL
manual, like bypassing standard label records, getting to multiple files on
a tape, or special formatting. For instance, almost all files were in standard
format, but every so often we'd use option U. All those commas for
positional parameters!

[Scott Lurndal]

Post by Peter Flass

Post by undefined Hancock-4
I remember a large university data center and the numerous requests to mount
disk and tapes for specific jobs. The system had to track all that stuff.
This is just scratching the surface.
How did this compare to the JCL of other large scale computer systems?

You could do 90% of the stuff with 20% of the complexity. Burroughs large
system MCP had some JCL (WFL?) but as I recall we rarely needed it. A job
card and an execute card was about it. Things like DSNs were coded in the
program, although they could be overridden in exceptional cases. I don’t
think the systems supported a lot of exotic peripherals or options.

Actually, there were a fair number of peripherals supported, including
MICR reader/sorters, various types of tape drives, 100-byte and
180-byte sector media (disk vs. pack), tape listers (finance),
high-speed host interconnects, terminal controllers, etc et al.

The command language was simple. The filesystems (both disk and pack)
were extent-based and normally the MCP was responsible for allocation,
the application specified record size, block size, etc in the file
information block (FIB) in the application.

?EX PROGRAM; MEM + 300
?FILE INPUT = FRED CRD
?FILE OUTPUT = FREDOT PBK
?FILE ARCHIVE = FREDTP MTP

which would direct the internal file INPUT to a card deck
named 'FRED' (either from a real reader or a pseudo-card reader that reads disk files).
The output listing would go to printer backup (i.e. on disk); specify PRN instead and the
output would go to a printer named FREDOT automatically if the printer is ready (all printers
could be named).

If PROGRAM opened ARCHIVE, the MCP would look for a mounted tape named
FREDTP, and if not found, would suspend the program until the operator
mounted the tape and made the unit ready, or if the program opened the
tape OUTPUT, then the MCP would look for a mounted scratch tape, or suspend
the program until a scratch tape was ready on any drive (assigned by
the operator if necessary).

[undefined Hancock-4]

Post by Scott Lurndal

Post by Peter Flass
You could do 90% of the stuff with 20% of the complexity. Burroughs large
system MCP had some JCL (WFL?) but as I recall we rarely needed it. A job
card and an execute card was about it. Things like DSNs were coded in the
program, although they could be overridden in exceptional cases. I don’t
think the systems supported a lot of exotic peripherals or options.

Actually, there were a fair number of peripherals supported, including
MICR reader/sorters, various types of tape drives, 100-byte and
180-byte sector media (disk vs. pack), tape listers (finance),
high-speed host interconnects, terminal controllers, etc et al.

Interestingly, one of the 'non standard' peripherals we attached was a Burroughs
microfiche printer. On 360-OS, it was very easy, just changed one parameter on the
JCL. OS had device independence, so program changes and recompilations were
not necessary to change devices. Major advantage.

However, on 360-DOS, it was necessary to recompile the program since the device
was specified in the program code.

As an aside, those microfiche printers were slick machines. Produced very high quality
cards. Automatically produced the appropriate visible index at the top or with minimal
setup. Saved a huge volume of paper, big savings in storage space and the visible index
was faster to locate data.

[Anne & Lynn Wheeler]

Post by undefined Hancock-4
Interestingly, one of the 'non standard' peripherals we attached was a Burroughs
microfiche printer. On 360-OS, it was very easy, just changed one parameter on the
JCL. OS had device independence, so program changes and recompilations were
not necessary to change devices. Major advantage.
However, on 360-DOS, it was necessary to recompile the program since the device
was specified in the program code.
As an aside, those microfiche printers were slick machines. Produced very high quality
cards. Automatically produced the appropriate visible index at the top or with minimal
setup. Saved a huge volume of paper, big savings in storage space and the visible index
was faster to locate data.

home office 1977/1978, cdi miniterm, ibm tieline, and compact microfiche
viewer. plant site had microfiche printer and could get 24hr turn around
... had couple hundred microfiche at home, source listings,
documentation, etc.
Loading Image...

[undefined Hancock-4]

Post by Anne & Lynn Wheeler

As an aside, those microfiche printers were slick machines. Produced very high quality
cards. Automatically produced the appropriate visible index at the top or with minimal
setup. Saved a huge volume of paper, big savings in storage space and the visible index
was faster to locate data.

home office 1977/1978, cdi miniterm, ibm tieline, and compact microfiche
viewer. plant site had microfiche printer and could get 24hr turn around
... had couple hundred microfiche at home, source listings,
documentation, etc.

Someone somehow hacked into the microfiche system and printed a bunch of pictures.
When my boss retired he gave me an envelope, "here, you might like this". It wasn't source code.

In the old days, people printed pictures from the line printer, which were very coarse. Some
had some shading to them by using different characters and overprinting. Can't imagine
anyone doing that today, let alone hanging them up in their cube.

[Scott Lurndal]

Post by undefined Hancock-4

Post by Anne & Lynn Wheeler

As an aside, those microfiche printers were slick machines. Produced very high quality
cards. Automatically produced the appropriate visible index at the top or with minimal
setup. Saved a huge volume of paper, big savings in storage space and the visible index
was faster to locate data.

home office 1977/1978, cdi miniterm, ibm tieline, and compact microfiche
viewer. plant site had microfiche printer and could get 24hr turn around
... had couple hundred microfiche at home, source listings,
documentation, etc.

Someone somehow hacked into the microfiche system and printed a bunch of pictures.
When my boss retired he gave me an envelope, "here, you might like this". It wasn't source code.
In the old days, people printed pictures from the line printer, which were very coarse. Some
had some shading to them by using different characters and overprinting. Can't imagine
anyone doing that today, let alone hanging them up in their cube.

I've got one of those of myself (done with a 256-gray-scale capture system
in 1981).

I still have a copy of the 9track poster tape that was handed around in those
days - there's a poster of a 727 going over the golden gate bridge that required
taping several full-width listing side by each, and a really nice on
of the moon (the finished moon was about 2' in diameter when all the pieces
were taped together), and a handful of tame (by modern standards) topless
models.

[Charlie Gibbs]

Post by Scott Lurndal

Post by undefined Hancock-4
In the old days, people printed pictures from the line printer, which
were very coarse. Some had some shading to them by using different
characters and overprinting. Can't imagine anyone doing that today,
let alone hanging them up in their cube.

I've got one of those of myself (done with a 256-gray-scale capture
system in 1981).
I still have a copy of the 9track poster tape that was handed around
in those days - there's a poster of a 727 going over the golden gate
bridge that required taping several full-width listing side by each,
and a really nice on of the moon (the finished moon was about 2' in
diameter when all the pieces were taped together), and a handful of
tame (by modern standards) topless models.

I have one of those tapes myself. On mine the moon is about 5 feet
across. Another nice one was of Spock holding a model of the Enterprise.

[Scott Lurndal]

Post by Charlie Gibbs

Post by Scott Lurndal

Post by undefined Hancock-4
In the old days, people printed pictures from the line printer, which
were very coarse. Some had some shading to them by using different
characters and overprinting. Can't imagine anyone doing that today,
let alone hanging them up in their cube.

I've got one of those of myself (done with a 256-gray-scale capture
system in 1981).
I still have a copy of the 9track poster tape that was handed around
in those days - there's a poster of a 727 going over the golden gate
bridge that required taping several full-width listing side by each,
and a really nice on of the moon (the finished moon was about 2' in
diameter when all the pieces were taped together), and a handful of
tame (by modern standards) topless models.

I have one of those tapes myself. On mine the moon is about 5 feet
across. Another nice one was of Spock holding a model of the Enterprise.

Yeah, 5' sounds right. I haven't seen my copy of the poster in
decades, it may still be in a box in storage. The enterprise poster
is on that tape.


I did read the tape yesterday on the Burroughs Simulator (it is
an ANSI labeled EBCDIC tape); I should get the old dot matrix epson
132-column printer out of storage and (if I can find a parallel
port and new ribbon anywhere :-) see if I can't print a couple of the posters.

[Scott Lurndal]

Post by Scott Lurndal

Post by Charlie Gibbs
I have one of those tapes myself. On mine the moon is about 5 feet
across. Another nice one was of Spock holding a model of the Enterprise.

I did read the tape yesterday on the Burroughs Simulator (it is
an ANSI labeled EBCDIC tape); I should get the old dot matrix epson
132-column printer out of storage and (if I can find a parallel
port and new ribbon anywhere :-) see if I can't print a couple of the posters.

$ (cd /work/4mmtapes/chm/; dd if=poster_890825_1600.tap conv=ascii | strings | grep -i hdr1)
HDR1SMALL.CAT POSTER00010001 77051 000000000000
HDR1LARGE.CAT POSTER00010002 77051 000000000000
HDR1SMALL.DOG POSTER00010003 77051 000000000000
HDR1LARGE.DOG POSTER00010004 77051 000000000000
HDR1SMALL.NUDE POSTER00010005 77051 000000000000
HDR1LARGE.NUDE POSTER00010006 77051 000000000000
HDR1PICASSO.SYLVETTE POSTER00010007 77051 000000000000
HDR1EINSTEIN POSTER00010008 77051 000000000000
HDR1MOUTN.CLIMBER POSTER00010009 77051 000000000000
HDR1MR.SPOCK POSTER00010010 77051 000000000000
HDR1ARMSTRNG.ON.MOON POSTER00010011 77051 000000000000
HDR1DEAN.AND.NIXON POSTER00010012 77051 000000000000
HDR1MOON POSTER00010013 77051 000000000000
HDR1BEETHOVN POSTER00010014 77051 000000000000
HDR1PLANE.B727 POSTER00010015 77051 000000000000
HDR1ISU.CY POSTER00010016 77054 000000000000
HDR1CLIPPER.SHIP POSTER00010017 77054 000000000000
HDR1MONA.LISA POSTER00010018 77054 000000000000
HDR1PIECE.OF.PI POSTER00010019 77054 000000000000
HDR1CAPN.ANDY POSTER00010020 77054 000000000000
HDR1DOG POSTER00010021 77054 000000000000
HDR1ECOLOGY POSTER00010022 77054 000000000000
HDR1PEACE.SYMBOL POSTER00010023 77054 000000000000
HDR1ALFRED POSTER00010024 77054 000000000000
HDR1EDITH POSTER00010025 77054 000000000000
HDR1RAQUEL.WELCH POSTER00010026 77054 000000000000
HDR1JFK POSTER00010027 77054 000000000000
HDR1JFK POSTER00010028 77054 000000000000
HDR1ROAD.RUNNER POSTER00010029 77054 000000000000
HDR1ROAD.RUNNER POSTER00010030 77054 000000000000
HDR1GOOD.GRIEF POSTER00010031 77054 000000000000
HDR1CHARLIE.BROWN POSTER00010032 77054 000000000000
HDR1LINUS POSTER00010033 77054 000000000000
HDR1LUCY POSTER00010034 77054 000000000000
HDR1SCHROEDR POSTER00010035 77054 000000000000
HDR1SNOOPY POSTER00010036 77054 000000000000
HDR1SNOOPY POSTER00010037 77054 000000000000
HDR1SNOOPY POSTER00010038 77054 000000000000
HDR1SNOOPY.ACE POSTER00010039 77054 000000000000
HDR1SNOOPY.CURSE POSTER00010040 77054 000000000000
HDR1SNOOPY.DISH POSTER00010041 77054 000000000000
HDR1SNOOPY.HANG POSTER00010042 77054 000000000000
HDR1SNOOPY.HANG.ON POSTER00010043 77054 000000000000
HDR1SNOOPY.HUG POSTER00010044 77054 000000000000
HDR1SNOOPY.PUNT POSTER00010045 77054 000000000000
HDR1PLAYBOY.RABBIT POSTER00010046 77054 000000000000
HDR1PLAYBOY.RABBIT POSTER00010047 77054 000000000000
HDR1PLAYBOY.RABBIT POSTER00010048 77054 000000000000
HDR1PLAYBOY.RABBIT POSTER00010049 77054 000000000000
HDR1PLAYBOY.RABBIT POSTER00010050 77054 000000000000
HDR1PLAYBOY.RABBIT POSTER00010051 77054 000000000000
HDR1NUDE POSTER00010052 77054 000000000000
HDR1NUDE POSTER00010053 77054 000000000000
HDR1NUDE POSTER00010054 77054 000000000000
HDR1NUDE.DOT POSTER00010055 77054 000000000000
HDR1NUDE.MIRROR POSTER00010056 77054 000000000000
HDR1NUDE.MISS.JUNE POSTER00010057 77054 000000000000
HDR1NUDE.RECLING POSTER00010058 77054 000000000000
HDR1NUDE.RECLING POSTER00010059 77054 000000000000
HDR1NUDE.STOOL POSTER00010060 77054 000000000000
HDR1NUDE.STOOL POSTER00010061 77054 000000000000
HDR1NUDE.STOOL POSTER00010062 77054 000000000000
HDR1NUDE.STOOL POSTER00010063 77054 000000000000
HDR1NUDE.STOOL POSTER00010064 77054 000000000000
HDR1NUDE.STOOL POSTER00010065 77054 000000000000
HDR1NUDE.STOOL POSTER00010066 77054 000000000000
HDR1LBJ POSTER00010067 77054 000000000000
HDR1XMAS.VIRGIN.MARY POSTER00010068 77054 000000000000
HDR1XMAS.WREATH POSTER00010069 77054 000000000000
HDR1XMAS.WREATH.MCHNYPOSTER00010070 77054 000000000000
HDR1XMAS.SANTA POSTER00010071 77055 000000000000
HDR1XMAS.SOLTICE POSTER00010072 77055 000000000000
HDR1XMAS.JOY POSTER00010073 77055 000000000000
HDR1XMAS.WISE.MEN POSTER00010074 77055 000000000000
HDR1XMAS.MERRY.XMAS POSTER00010075 77055 000000000000
HDR1XMAS.MERRY.XMAS POSTER00010076 77055 000000000000
HDR1XMAS.RAINDEER POSTER00010077 77055 000000000000
HDR1XMAS.RAINDEER POSTER00010078 77055 000000000000
HDR1XMAS.RAINDEER POSTER00010079 77060 000000000000
HDR1PLI.UNCOBOL POSTER00010080 77335 000000000000
HDR1SNOOPY.RUDE POSTER00010081 77343 000000000000
HDR1LINUS.PEACE POSTER00010082 77343 000000000000
HDR1SNOOPY.HOP POSTER00010083 77343 000000000000
HDR1STARSHIP POSTER00010084 80034 000000000000IBM OS/VS 370382 &
HDR1STARWARS POSTER00010085 81199 000000000000IBM OS/VS 370383 &

[Kerr-Mudd, John]

On Wed, 18 Aug 2021 16:38:21 GMT

Post by Scott Lurndal

Post by Scott Lurndal

Post by Charlie Gibbs
I have one of those tapes myself. On mine the moon is about 5 feet
across. Another nice one was of Spock holding a model of the Enterprise.

I did read the tape yesterday on the Burroughs Simulator (it is
an ANSI labeled EBCDIC tape); I should get the old dot matrix epson
132-column printer out of storage and (if I can find a parallel
port and new ribbon anywhere :-) see if I can't print a couple of the posters.

$ (cd /work/4mmtapes/chm/; dd if=poster_890825_1600.tap conv=ascii | strings | grep -i hdr1)
HDR1SMALL.CAT POSTER00010001 77051 000000000000
HDR1LARGE.CAT POSTER00010002 77051 000000000000
HDR1SMALL.DOG POSTER00010003 77051 000000000000
HDR1LARGE.DOG POSTER00010004 77051 000000000000
HDR1SMALL.NUDE POSTER00010005 77051 000000000000
HDR1LARGE.NUDE POSTER00010006 77051 000000000000
HDR1PICASSO.SYLVETTE POSTER00010007 77051 000000000000
HDR1EINSTEIN POSTER00010008 77051 000000000000
HDR1MOUTN.CLIMBER POSTER00010009 77051 000000000000
HDR1MR.SPOCK POSTER00010010 77051 000000000000
HDR1ARMSTRNG.ON.MOON POSTER00010011 77051 000000000000
HDR1DEAN.AND.NIXON POSTER00010012 77051 000000000000
HDR1MOON POSTER00010013 77051 000000000000
HDR1BEETHOVN POSTER00010014 77051 000000000000
HDR1PLANE.B727 POSTER00010015 77051 000000000000
HDR1ISU.CY POSTER00010016 77054 000000000000
HDR1CLIPPER.SHIP POSTER00010017 77054 000000000000
HDR1MONA.LISA POSTER00010018 77054 000000000000
HDR1PIECE.OF.PI POSTER00010019 77054 000000000000
HDR1CAPN.ANDY POSTER00010020 77054 000000000000
HDR1DOG POSTER00010021 77054 000000000000
HDR1ECOLOGY POSTER00010022 77054 000000000000
HDR1PEACE.SYMBOL POSTER00010023 77054 000000000000
HDR1ALFRED POSTER00010024 77054 000000000000
HDR1EDITH POSTER00010025 77054 000000000000
HDR1RAQUEL.WELCH POSTER00010026 77054 000000000000
HDR1JFK POSTER00010027 77054 000000000000
HDR1JFK POSTER00010028 77054 000000000000
HDR1ROAD.RUNNER POSTER00010029 77054 000000000000
HDR1ROAD.RUNNER POSTER00010030 77054 000000000000
HDR1GOOD.GRIEF POSTER00010031 77054 000000000000
HDR1CHARLIE.BROWN POSTER00010032 77054 000000000000
HDR1LINUS POSTER00010033 77054 000000000000
HDR1LUCY POSTER00010034 77054 000000000000
HDR1SCHROEDR POSTER00010035 77054 000000000000
HDR1SNOOPY POSTER00010036 77054 000000000000
HDR1SNOOPY POSTER00010037 77054 000000000000
HDR1SNOOPY POSTER00010038 77054 000000000000
HDR1SNOOPY.ACE POSTER00010039 77054 000000000000
HDR1SNOOPY.CURSE POSTER00010040 77054 000000000000
HDR1SNOOPY.DISH POSTER00010041 77054 000000000000
HDR1SNOOPY.HANG POSTER00010042 77054 000000000000
HDR1SNOOPY.HANG.ON POSTER00010043 77054 000000000000
HDR1SNOOPY.HUG POSTER00010044 77054 000000000000
HDR1SNOOPY.PUNT POSTER00010045 77054 000000000000
HDR1PLAYBOY.RABBIT POSTER00010046 77054 000000000000
HDR1PLAYBOY.RABBIT POSTER00010047 77054 000000000000
HDR1PLAYBOY.RABBIT POSTER00010048 77054 000000000000
HDR1PLAYBOY.RABBIT POSTER00010049 77054 000000000000
HDR1PLAYBOY.RABBIT POSTER00010050 77054 000000000000
HDR1PLAYBOY.RABBIT POSTER00010051 77054 000000000000
HDR1NUDE POSTER00010052 77054 000000000000
HDR1NUDE POSTER00010053 77054 000000000000
HDR1NUDE POSTER00010054 77054 000000000000
HDR1NUDE.DOT POSTER00010055 77054 000000000000
HDR1NUDE.MIRROR POSTER00010056 77054 000000000000
HDR1NUDE.MISS.JUNE POSTER00010057 77054 000000000000
HDR1NUDE.RECLING POSTER00010058 77054 000000000000
HDR1NUDE.RECLING POSTER00010059 77054 000000000000
HDR1NUDE.STOOL POSTER00010060 77054 000000000000
HDR1NUDE.STOOL POSTER00010061 77054 000000000000
HDR1NUDE.STOOL POSTER00010062 77054 000000000000
HDR1NUDE.STOOL POSTER00010063 77054 000000000000
HDR1NUDE.STOOL POSTER00010064 77054 000000000000
HDR1NUDE.STOOL POSTER00010065 77054 000000000000
HDR1NUDE.STOOL POSTER00010066 77054 000000000000
HDR1LBJ POSTER00010067 77054 000000000000
HDR1XMAS.VIRGIN.MARY POSTER00010068 77054 000000000000
HDR1XMAS.WREATH POSTER00010069 77054 000000000000
HDR1XMAS.WREATH.MCHNYPOSTER00010070 77054 000000000000
HDR1XMAS.SANTA POSTER00010071 77055 000000000000
HDR1XMAS.SOLTICE POSTER00010072 77055 000000000000
HDR1XMAS.JOY POSTER00010073 77055 000000000000
HDR1XMAS.WISE.MEN POSTER00010074 77055 000000000000
HDR1XMAS.MERRY.XMAS POSTER00010075 77055 000000000000
HDR1XMAS.MERRY.XMAS POSTER00010076 77055 000000000000
HDR1XMAS.RAINDEER POSTER00010077 77055 000000000000
HDR1XMAS.RAINDEER POSTER00010078 77055 000000000000
HDR1XMAS.RAINDEER POSTER00010079 77060 000000000000
HDR1PLI.UNCOBOL POSTER00010080 77335 000000000000
HDR1SNOOPY.RUDE POSTER00010081 77343 000000000000
HDR1LINUS.PEACE POSTER00010082 77343 000000000000
HDR1SNOOPY.HOP POSTER00010083 77343 000000000000
HDR1STARSHIP POSTER00010084 80034 000000000000IBM OS/VS 370382 &
HDR1STARWARS POSTER00010085 81199 000000000000IBM OS/VS 370383 &

I recall a Snoopy (calendar, IIRC) but the porn passed me by; please repost! (smiley)

[Anne & Lynn Wheeler]

Post by undefined Hancock-4
Second, both the SABRE host and S/360-OS had to load in various
modules on demand, execute them, and then release them. Both had
to handle multiple modules running simultaneous, with protection
and control against overlapping memory and I/O demands. All
this is complex as well as new.

Lots of OS/360 had multiple module loads for functions (pieces split
into little tiny pieces in order to operate on smaller machienes)
... some of the absolute worst was file open/close SVCs which was
fragmened into 2k modules. It was one of the reasons the CICS (fast
transaction processing) did a whole lot of work at startup, obtaining
resources and doing file opens ... and then while running ... making use
of as little of os/360 services as possible. This included storage
allocation ... this old post (originally bit.listserv.ibm-main) where I
had been asked to track down the decision to move all 370s to virtual
memory ... aka OS/360 storage management was so horrible that region
requests typically had to be four times larger than actually used (and
for longer running applications, like CICS, things like storage
fragmentation increased the longer they were running).
http://www.garlic.com/~lynn/2011d.html#73

from response (included in the above):

Note to Lynn - I have always given zzzzz the credit for turning Bob
Evans around. For reasons unknown to me, the TSO group had the flip
charts and wallboard zzzzz used. The clincher was the ability to run 16
initiators simultaneously on a 1 megabyte system, taking advantage of
the fact that MVT normally used only 25% of the memory in a
partition. The resulting throughput gain (compared to real hardware) was
substantial enough to convince Bob. It helped that Tom Simpson and Bob
Crabtree had hosted an MFT II system TSS-Style and shown similar
performance gains. Of course, since CP67 was a pickup group they weren't
considered and we had the OS/VS adventure instead.

... snip ...

trivia: within year after taking two semester hr intro to
computers/fortran, the univ. hired me responsible for os/360 systems.
Sometime later, univ. library got an ONR (office of naval research) grant
to do online catalog ... part of the money went for a IBM 2321
(datacell) ... the univ. library was also selected to beta test site for
original CICS product ... one of the early bugs I had to diagnose
... was there were some (undocumented) hardcoded BDAM file operations
and the univ had created BDAM files with different options ... and CICS
would fail on startup.

past CICS/BDAM posts
http://www.garlic.com/~lynn/submain.html#cics

more CICS lore ... gone 404, but still lives on at wayback michine
https://web.archive.org/web/20050409124902/http://www.yelavich.com/cicshist.htm
https://web.archive.org/web/20071124013919/http://www.yelavich.com/history/toc.htm

OS/360 was enormously disk intensive ... with all the fragmented module
loads ... that I did very careful system generations ... arranging
sysgen statements to carefully place files&modules to optimize disk arm
seek and PDS directory multi-track search. I've frequently mentioned
that student fortran programs ran less than second on 709 tape->tape
... but initial move to OS/360 (360/67 running as 360/65) student
fortran took over a minute, installing HASP ... cut that in half.
Initial careful sysgens cut it almost by 2/3rds (most of it still
furious disk activity). Didn't get to better than 709 until single step
WATFOR montor (batched multiple jobs in single execution). Single step
startup overhead was still over 4secs ... but batching 40-60 student
jobs running at (watfor) 20,000 cards/min (333 cards/sec) ... student
jobs 30-60 cards, so 4sec startup/shutdown spread over 50 batched jobs
4sec/50=.08sec/job plus 50cards/333=.15sec/job ... avg .23sec.

... note that ACP/TPF was highly optimized code and was really difficult
to add hardware multiprocessor support. 3081 was originally going to be
multiprocessor only machine and IBM was afraid that the whole ACP/TPF
market would move to clone mainframe makers ... that were coming out
with new, faster single processor machines (high-end single proceessor
amdahl had nearly the same processing as two processor 3081k ... and two
processor high-end amdahl was twice that ... better than the four
processor 3084). Eventually IBM did come out with 3083 ... a 3081 with
one of the processors removed (initially for the ACP/TPF market). It
took a while longer and whole lot of effort before had ACP/TPF
supporting real multiprocessor operation.

past SMP, multiprocessor, compare&swap, etc posts
http://www.garlic.com/~lynn/subtopic.html#smp

... trivia: problem for CICS was even worse ... above referenced cics
history table of contents ... doesn't have multiprocessor exploitation
until 2004.

... other CICS trivia: CICS had a slight of hand work around, running
multiple instances with workload partitioned across the different
instances. I visited a datacenter around the turn of the century that
claimed it was concurrently running 120-130 CICS instances on their
system.

[Anne & Lynn Wheeler]

other ACP/TPF trivia ... while ACP/TPF didn't have (tightly-coupled)
multiprocessor support ... it had done a lot of work for loosely-coupled
multiprocessor (shared dasd, cluster). Standard OS/360 mechanism was
reserve/release whole device ... ACP/TPF improved on that by putting a
logical "symbolic" lock manager in the 3830 disk controller (for 3330
disks) ... which supported four channel interface connecting to four
different systems.

old email from jim gray looking for ACP/TPF locking experience ... for
input to (original sql/relational) system/r
http://www.garlic.com/~lynn/2008i.html#email800325

past posts
http://www.garlic.com/~lynn/2018e.html#94 It's 1983: What computer would you buy?
http://www.garlic.com/~lynn/2017d.html#42 What are mainframes
http://www.garlic.com/~lynn/2016c.html#9 You count as an old-timer if (was Re: Origin of the phrase "XYZZY")
http://www.garlic.com/~lynn/2011p.html#76 Has anyone successfully migrated off mainframes?
http://www.garlic.com/~lynn/2011l.html#33 Selectric Typewriter--50th Anniversary
http://www.garlic.com/~lynn/2011j.html#0 program coding pads
http://www.garlic.com/~lynn/2011i.html#77 program coding pads
http://www.garlic.com/~lynn/2008i.html#39 Amercian Airlines
http://www.garlic.com/~lynn/2001.html#26 Disk caching and file systems. Disk history...people forget

disk division later tried to have them move away ... since the strategic
direction was string switch ... allowing two 3830 controllers for string
of 3330 disks ... each with four system connect for total eight systems
total ... the problem was that controller based logical lock manager
didn't work across multiple (3830) controllers.

loosely-coupled/cluster HONE trivia: One of my hobbies after joining IBM
was enhanced production operating systems for internal datacenters
... and HONE was long-time customer ... online world-wide
sales&marketing support system. In the mid-70s, the US HONE datacenters
were consildated in Palo Alto (later when FACEBOOK 1st moves into
silicon valley, it is into a new bldg built next door to the former HONE
datacenter) ... and system enhanced for 8-way loosely-coupled operation
(eight indendent systems sharing same disk farm with load-balancing and
fall-over).

since it was 8-way ... needing two controllers ... so couldn't use
the ACP/TPF controllere logical locking ... put it needed something
significantly better than the standard (os/360) device reserve/release.
The implmentation used was a channel-program sequence that did search
data equal ... and if matched ... would do update ... basically
simulating the (SMP) 370 "compare&swap" instruction (charlie had
invented compare&swap when he was doing fine-grain CP67 multiprocessor
kernel locking at the science center, CAS originally chosen because
they are charlie's initials, which got added to 370).

In the morph of CP67->VM370 product, they simplified and/or dropped a
lot of stuff (including a bunch of my stuff as well as the CP67
tightly-coupled multiprocessor support). HONE applications were heavily
APL-based and even with eight 168-3s for US HONE, it was still CPU
limited. I had gotten around to significantly enhanced VM370
... including a lot of stuff from CP67. I then got around to putting in
the CP67 (tightly coupled) multiprocessor support ... so HONE could add
a 2nd CPU to each system for 16 processors

HONE (&/or APL) posts
http://www.garlic.com/~lynn/subtopic.html#hone
SMP, tightly-coupled, and/or compare&swap posts
http://www.garlic.com/~lynn/subtopic.html#smp
cambridge science center (4th flr, 545tech sq) posts
http://www.garlic.com/~lynn/subtopic.html#545tech
system/r posts
http://www.garlic.com/~lynn/submain.html#systemr