|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410143 is a reply to message #410131] |
Tue, 20 July 2021 21:46   |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
According to undefined Hancock-4 <hancock4@bbs.cpcn.com>:
> (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.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410180 is a reply to message #410143] |
Thu, 22 July 2021 10:46 |
|
|
Originally posted by: David Lesher
John Levine <johnl@taugh.com> writes:
> 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?
--
A host is a host from coast to coast.................wb8foz@nrk.com
& no one will talk to a host that's close..........................
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410183 is a reply to message #410180] |
Thu, 22 July 2021 12:37 |
chris
Messages: 130
Registered: September 2012
Karma: 0
|
Senior Member |
|
|
On 07/22/21 15:46, David Lesher wrote:
> John Levine<johnl@taugh.com> writes:
>
>
>> 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...
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410184 is a reply to message #410183] |
Thu, 22 July 2021 12:47 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
chris <chris-nospam@tridac.net> writes:
> On 07/22/21 15:46, David Lesher wrote:
>> John Levine<johnl@taugh.com> writes:
>>
>>
>>> 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.
|
|
|
|
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410187 is a reply to message #410185] |
Thu, 22 July 2021 13:10 |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Thu, 22 Jul 2021 17:51:24 +0100
Andy Burns <usenet@andyburns.uk> wrote:
> Scott Lurndal wrote:
>
>> 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!
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
|
|
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410190 is a reply to message #410189] |
Thu, 22 July 2021 15:52 |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Thu, 22 Jul 2021 15:14:55 -0400
Dan Espen <dan1espen@gmail.com> wrote:
> Andy Burns <usenet@andyburns.uk> writes:
>
>> Scott Lurndal wrote:
>>
>>> 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).
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
|
|
|
|
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410194 is a reply to message #410190] |
Thu, 22 July 2021 17:05 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Ahem A Rivet's Shot <steveo@eircom.net> writes:
> On Thu, 22 Jul 2021 15:14:55 -0400
> Dan Espen <dan1espen@gmail.com> wrote:
>
>> Andy Burns <usenet@andyburns.uk> writes:
>>
>>> Scott Lurndal wrote:
>>>
>>>> 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.
--
Dan Espen
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410195 is a reply to message #410193] |
Thu, 22 July 2021 17:08 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Grant Taylor <gtaylor@tnetconsulting.net> writes:
> On 7/22/21 1:14 PM, Dan Espen wrote:
>> 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?
> 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?
--
Dan Espen
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410205 is a reply to message #410187] |
Thu, 22 July 2021 20:13 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2021-07-22, Ahem A Rivet's Shot <steveo@eircom.net> wrote:
> On Thu, 22 Jul 2021 17:51:24 +0100
> Andy Burns <usenet@andyburns.uk> wrote:
>
>> Scott Lurndal wrote:
>>
>>> 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
\ / <cgibbs@kltpzyxm.invalid> | has stolen their car and parked
X I'm really at ac.dekanfrus | a taxi in their driveway.
/ \ if you read it the right way. | -- Mayayana
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410209 is a reply to message #410205] |
Thu, 22 July 2021 22:32 |
bbreynolds
Messages: 18
Registered: July 2013
Karma: 0
|
Junior Member |
|
|
On Thursday, July 22, 2021 at 8:14:02 PM UTC-4, Charlie Gibbs wrote:
> On 2021-07-22, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>
>> On Thu, 22 Jul 2021 17:51:24 +0100
>> Andy Burns <use...@andyburns.uk> wrote:
>>
>>> Scott Lurndal wrote:
>>>
>>>> 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
> \ / <cgi...@kltpzyxm.invalid> | has stolen their car and parked
> X I'm really at ac.dekanfrus | a taxi in their driveway.
> / \ if you read it the right way. | -- Mayayana
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410210 is a reply to message #410183] |
Thu, 22 July 2021 22:43 |
bbreynolds
Messages: 18
Registered: July 2013
Karma: 0
|
Junior Member |
|
|
On Thursday, July 22, 2021 at 12:37:50 PM UTC-4, chris wrote:
> On 07/22/21 15:46, David Lesher wrote:
>> John Levine<jo...@taugh.com> writes:
>>
>>
>>> 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.
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410211 is a reply to message #410205] |
Thu, 22 July 2021 22:44 |
bbreynolds
Messages: 18
Registered: July 2013
Karma: 0
|
Junior Member |
|
|
On Thursday, July 22, 2021 at 8:14:02 PM UTC-4, Charlie Gibbs wrote:
> On 2021-07-22, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>
>> On Thu, 22 Jul 2021 17:51:24 +0100
>> Andy Burns <use...@andyburns.uk> wrote:
>>
>>> Scott Lurndal wrote:
>>>
>>>> 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
> \ / <cgi...@kltpzyxm.invalid> | has stolen their car and parked
> X I'm really at ac.dekanfrus | a taxi in their driveway.
> / \ if you read it the right way. | -- Mayayana
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410212 is a reply to message #410185] |
Thu, 22 July 2021 23:08 |
bbreynolds
Messages: 18
Registered: July 2013
Karma: 0
|
Junior Member |
|
|
On Thursday, July 22, 2021 at 12:51:26 PM UTC-4, Andy Burns wrote:
> Scott Lurndal wrote:
>
>> 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.
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410228 is a reply to message #410194] |
Fri, 23 July 2021 12:13 |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
On Thursday, July 22, 2021 at 3:05:20 PM UTC-6, Dan Espen wrote:
> 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
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410229 is a reply to message #410212] |
Fri, 23 July 2021 12:18 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
TrailingEdgeTechnologies <bbreynolds@aol.com> writes:
> On Thursday, July 22, 2021 at 12:51:26 PM UTC-4, Andy Burns wrote:
>> Scott Lurndal wrote:=20
>> =20
>>> 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 ?
> Retelling old story here:
>
> 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)
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410235 is a reply to message #410210] |
Fri, 23 July 2021 14:46 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Thursday, July 22, 2021 at 10:43:23 PM UTC-4, TrailingEdgeTechnologies wrote:
> On Thursday, July 22, 2021 at 12:37:50 PM UTC-4, chris wrote:
>> On 07/22/21 15:46, David Lesher wrote:
>>> John Levine<jo...@taugh.com> writes:
>>>
>>>
>>>> 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.
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410236 is a reply to message #410194] |
Fri, 23 July 2021 14:48 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Thursday, July 22, 2021 at 5:05:20 PM UTC-4, Dan Espen wrote:
> 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.
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410237 is a reply to message #410143] |
Fri, 23 July 2021 14:56 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Tuesday, July 20, 2021 at 9:46:11 PM UTC-4, John Levine wrote:
> According to undefined Hancock-4 <hanc...@bbs.cpcn.com>:
>> (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.
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410243 is a reply to message #410237] |
Fri, 23 July 2021 19:27 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
undefined Hancock-4 <hancock4@bbs.cpcn.com> wrote:
> On Tuesday, July 20, 2021 at 9:46:11 PM UTC-4, John Levine wrote:
>> According to undefined Hancock-4 <hanc...@bbs.cpcn.com>:
>>> (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.
--
Pete
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410246 is a reply to message #410236] |
Fri, 23 July 2021 23:13 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Saturday, July 24, 2021 at 4:48:54 AM UTC+10, undefined Hancock-4 wrote:
> On Thursday, July 22, 2021 at 5:05:20 PM UTC-4, Dan Espen wrote:
>
>
>> 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)
..
> One could use either keypunch, but would need to know the proper substitution
> which could be tedious.
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410262 is a reply to message #410229] |
Sat, 24 July 2021 13:54 |
Louis Krupp
Messages: 92
Registered: August 2012
Karma: 0
|
Member |
|
|
On 7/23/2021 10:18 AM, Scott Lurndal wrote:
> TrailingEdgeTechnologies <bbreynolds@aol.com> writes:
>> On Thursday, July 22, 2021 at 12:51:26 PM UTC-4, Andy Burns wrote:
>>> Scott Lurndal wrote:=20
>>> =20
>>>> 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 ?
>> Retelling old story here:
>>
>> 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
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410265 is a reply to message #410236] |
Sat, 24 July 2021 17:35 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2021-07-23, undefined Hancock-4 <hancock4@bbs.cpcn.com> wrote:
> On Thursday, July 22, 2021 at 5:05:20 PM UTC-4, Dan Espen wrote:
>
>> 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.
--
/~\ Charlie Gibbs | They don't understand Microsoft
\ / <cgibbs@kltpzyxm.invalid> | has stolen their car and parked
X I'm really at ac.dekanfrus | a taxi in their driveway.
/ \ if you read it the right way. | -- Mayayana
|
|
|
|
|
|
| Re: sixbit, the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410282 is a reply to message #410281] |
Sun, 25 July 2021 17:12 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
According to Vir Campestris <vir.campestris@invalid.invalid>:
> On 22/07/2021 17:47, Scott Lurndal wrote:
>> 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.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: sixbit, the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410287 is a reply to message #410282] |
Mon, 26 July 2021 01:32 |
|
|
Originally posted by: Thomas Koenig
John Levine <johnl@taugh.com> schrieb:
> 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).
> 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.
|
|
|
|
| Re: sixbit, the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410290 is a reply to message #410287] |
Mon, 26 July 2021 04:39 |
|
|
Originally posted by: Bob Eager
On Mon, 26 Jul 2021 05:32:56 +0000, Thomas Koenig wrote:
> John Levine <johnl@taugh.com> schrieb:
>
>> 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.
--
Using UNIX since v6 (1975)...
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
|
|
| Re: sixbit, the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410292 is a reply to message #410287] |
Mon, 26 July 2021 07:21 |
|
|
Originally posted by: gareth evans
On 26/07/2021 06:32, Thomas Koenig wrote:
> John Levine <johnl@taugh.com> schrieb:
>
>> 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).
>
>> 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 " "
|
|
|
|
| Re: sixbit, the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410301 is a reply to message #410292] |
Mon, 26 July 2021 18:45 |
Rich Alderson
Messages: 489
Registered: August 2012
Karma: 0
|
Senior Member |
|
|
gareth evans <headstone255@yahoo.com> writes:
> On 26/07/2021 06:32, Thomas Koenig wrote:
>> John Levine <johnl@taugh.com> schrieb:
>>
>>> 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).
>>
>>> 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.
--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
|
|
|
|
| Re: sixbit, the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410310 is a reply to message #410301] |
Tue, 27 July 2021 06:29 |
|
|
Originally posted by: gareth evans
On 26/07/2021 23:45, Rich Alderson wrote:
> gareth evans <headstone255@yahoo.com> writes:
>
>> On 26/07/2021 06:32, Thomas Koenig wrote:
>>> John Levine <johnl@taugh.com> schrieb:
>>>
>>>> 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).
>>>
>>>> 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 "_"
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410323 is a reply to message #410237] |
Wed, 28 July 2021 00:12 |
Anne & Lynn Wheel
Messages: 3156
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
undefined Hancock-4 <hancock4@bbs.cpcn.com> writes:
> 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.yelavi ch.com/cicshist.htm
https://web.archive.org/web/20071124013919/http://www.yelavi ch.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.
--
virtualization experience starting Jan1968, online at home since Mar1970
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410325 is a reply to message #410323] |
Wed, 28 July 2021 00:49 |
Anne & Lynn Wheel
Messages: 3156
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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
--
virtualization experience starting Jan1968, online at home since Mar1970
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410449 is a reply to message #410243] |
Sat, 07 August 2021 15:38 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Friday, July 23, 2021 at 7:27:56 PM UTC-4, Peter Flass wrote:
> undefined Hancock-4 <hanc...@bbs.cpcn.com> wrote:
>> On Tuesday, July 20, 2021 at 9:46:11 PM UTC-4, John Levine wrote:
>>> According to undefined Hancock-4 <hanc...@bbs.cpcn.com>:
>>>> (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?
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410451 is a reply to message #410449] |
Sat, 07 August 2021 16:04 |
|
|
Originally posted by: Thomas Koenig
undefined Hancock-4 <hancock4@bbs.cpcn.com> schrieb:
[JCL]
> 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.
|
|
|
|
| Re: the wonders of SABRE, was Magnetic Drum reservations 1952 [message #410452 is a reply to message #410451] |
Sat, 07 August 2021 17:24 |
Harry Vaderchi
Messages: 719
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Sat, 7 Aug 2021 20:04:39 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:
> undefined Hancock-4 <hancock4@bbs.cpcn.com> schrieb:
>
> [JCL]
>
>> 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.
--
Bah, and indeed Humbug.
|
|
|
|
Members
Search
Help
Register
Login
Home
