Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.folklore.computers > #218482 > unrolled thread
| Started by | undefined Hancock-4 <hancock4@bbs.cpcn.com> |
|---|---|
| First post | 2021-07-20 12:14 -0700 |
| Last post | 2021-07-27 18:49 -1000 |
| Articles | 20 on this page of 59 — 23 participants |
Back to article view | Back to alt.folklore.computers
Magnetic Drum reservations 1952 undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-07-20 12:14 -0700
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 John Levine <johnl@taugh.com> - 2021-07-21 01:46 +0000
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 David Lesher <wb8foz@panix.com> - 2021-07-22 14:46 +0000
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 chris <chris-nospam@tridac.net> - 2021-07-22 17:37 +0100
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 scott@slp53.sl.home (Scott Lurndal) - 2021-07-22 16:47 +0000
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 Andy Burns <usenet@andyburns.uk> - 2021-07-22 17:51 +0100
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 John Levine <johnl@taugh.com> - 2021-07-22 17:25 +0000
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 Ahem A Rivet's Shot <steveo@eircom.net> - 2021-07-22 18:10 +0100
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-07-23 00:13 +0000
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 TrailingEdgeTechnologies <bbreynolds@aol.com> - 2021-07-22 19:32 -0700
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 TrailingEdgeTechnologies <bbreynolds@aol.com> - 2021-07-22 19:44 -0700
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 Dan Espen <dan1espen@gmail.com> - 2021-07-22 15:14 -0400
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 Ahem A Rivet's Shot <steveo@eircom.net> - 2021-07-22 20:52 +0100
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 Dan Espen <dan1espen@gmail.com> - 2021-07-22 17:05 -0400
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 Quadibloc <jsavard@ecn.ab.ca> - 2021-07-23 09:13 -0700
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-07-23 11:48 -0700
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 Robin Vowels <robin.vowels@gmail.com> - 2021-07-23 20:13 -0700
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-07-24 21:35 +0000
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 Andy Burns <usenet@andyburns.uk> - 2021-07-22 21:10 +0100
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 Grant Taylor <gtaylor@tnetconsulting.net> - 2021-07-22 14:16 -0600
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 Dan Espen <dan1espen@gmail.com> - 2021-07-22 17:08 -0400
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 TrailingEdgeTechnologies <bbreynolds@aol.com> - 2021-07-22 20:08 -0700
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 scott@slp53.sl.home (Scott Lurndal) - 2021-07-23 16:18 +0000
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 Louis Krupp <lkrupp@invalid.pssw.com.invalid> - 2021-07-24 11:54 -0600
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 Vir Campestris <vir.campestris@invalid.invalid> - 2021-07-25 21:51 +0100
Re: sixbit, the wonders of SABRE, was Magnetic Drum reservations 1952 John Levine <johnl@taugh.com> - 2021-07-25 21:12 +0000
Re: sixbit, the wonders of SABRE, was Magnetic Drum reservations 1952 Thomas Koenig <tkoenig@netcologne.de> - 2021-07-26 05:32 +0000
Re: sixbit, the wonders of SABRE, was Magnetic Drum reservations 1952 Bob Eager <news0009@eager.cx> - 2021-07-26 08:39 +0000
Re: sixbit, the wonders of SABRE, was Magnetic Drum reservations 1952 gareth evans <headstone255@yahoo.com> - 2021-07-26 12:21 +0100
Re: sixbit, the wonders of SABRE, was Magnetic Drum reservations 1952 Rich Alderson <news@alderson.users.panix.com> - 2021-07-26 18:45 -0400
Re: sixbit, the wonders of SABRE, was Magnetic Drum reservations 1952 gareth evans <headstone255@yahoo.com> - 2021-07-27 11:29 +0100
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 TrailingEdgeTechnologies <bbreynolds@aol.com> - 2021-07-22 19:43 -0700
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-07-23 11:46 -0700
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-07-23 11:56 -0700
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 Peter Flass <peter_flass@yahoo.com> - 2021-07-23 16:27 -0700
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-08-07 12:38 -0700
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 Thomas Koenig <tkoenig@netcologne.de> - 2021-08-07 20:04 +0000
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 "Kerr-Mudd, John" <admin@127.0.0.1> - 2021-08-07 22:24 +0100
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 "Kerr-Mudd, John" <admin@127.0.0.1> - 2021-08-07 22:27 +0100
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-08-10 11:49 -0700
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 J. Clarke <jclarke.873638@gmail.com> - 2021-08-10 15:34 -0400
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 Robin Vowels <robin.vowels@gmail.com> - 2021-08-07 18:13 -0700
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-08-10 11:45 -0700
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 Robin Vowels <robin.vowels@gmail.com> - 2021-08-11 06:36 -0700
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 Peter Flass <peter_flass@yahoo.com> - 2021-08-11 08:00 -0700
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 Peter Flass <peter_flass@yahoo.com> - 2021-08-10 10:57 -0700
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-08-10 18:29 +0000
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-08-10 11:54 -0700
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 scott@slp53.sl.home (Scott Lurndal) - 2021-08-10 19:44 +0000
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-08-13 12:26 -0700
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 Anne & Lynn Wheeler <lynn@garlic.com> - 2021-08-13 09:49 -1000
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-08-16 12:52 -0700
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 scott@slp53.sl.home (Scott Lurndal) - 2021-08-16 20:06 +0000
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-08-16 23:31 +0000
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 scott@slp53.sl.home (Scott Lurndal) - 2021-08-17 15:41 +0000
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 scott@slp53.sl.home (Scott Lurndal) - 2021-08-18 16:38 +0000
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 "Kerr-Mudd, John" <admin@127.0.0.1> - 2021-08-18 18:29 +0100
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 Anne & Lynn Wheeler <lynn@garlic.com> - 2021-07-27 18:12 -1000
Re: the wonders of SABRE, was Magnetic Drum reservations 1952 Anne & Lynn Wheeler <lynn@garlic.com> - 2021-07-27 18:49 -1000
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
| From | Dan Espen <dan1espen@gmail.com> |
|---|---|
| Date | 2021-07-22 17:08 -0400 |
| Subject | Re: the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <sdcmni$797$2@dont-email.me> |
| In reply to | #218509 |
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
[toc] | [prev] | [next] | [standalone]
| From | TrailingEdgeTechnologies <bbreynolds@aol.com> |
|---|---|
| Date | 2021-07-22 20:08 -0700 |
| Subject | Re: the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <6209fb4c-4e5c-4d8c-823f-7245789b92a4n@googlegroups.com> |
| In reply to | #218503 |
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.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-07-23 16:18 +0000 |
| Subject | Re: the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <gZBKI.7893$Pn7.891@fx16.iad> |
| In reply to | #218517 |
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)
[toc] | [prev] | [next] | [standalone]
| From | Louis Krupp <lkrupp@invalid.pssw.com.invalid> |
|---|---|
| Date | 2021-07-24 11:54 -0600 |
| Subject | Re: the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <6tYKI.22836$uj5.19317@fx03.iad> |
| In reply to | #218519 |
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
[toc] | [prev] | [next] | [standalone]
| From | Vir Campestris <vir.campestris@invalid.invalid> |
|---|---|
| Date | 2021-07-25 21:51 +0100 |
| Subject | Re: the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <sdkis8$u3r$4@dont-email.me> |
| In reply to | #218502 |
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) Andy
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2021-07-25 21:12 +0000 |
| Subject | Re: sixbit, the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <sdkk34$f3a$1@gal.iecc.com> |
| In reply to | #218536 |
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
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2021-07-26 05:32 +0000 |
| Subject | Re: sixbit, the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <sdlhe8$ho3$1@newsreader4.netcologne.de> |
| In reply to | #218537 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Bob Eager <news0009@eager.cx> |
|---|---|
| Date | 2021-07-26 08:39 +0000 |
| Subject | Re: sixbit, the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <im7allF6u5uU3@mid.individual.net> |
| In reply to | #218538 |
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
[toc] | [prev] | [next] | [standalone]
| From | gareth evans <headstone255@yahoo.com> |
|---|---|
| Date | 2021-07-26 12:21 +0100 |
| Subject | Re: sixbit, the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <sdm5rv$cn7$1@dont-email.me> |
| In reply to | #218538 |
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 " "
[toc] | [prev] | [next] | [standalone]
| From | Rich Alderson <news@alderson.users.panix.com> |
|---|---|
| Date | 2021-07-26 18:45 -0400 |
| Subject | Re: sixbit, the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <mdd1r7ku21u.fsf@panix5.panix.com> |
| In reply to | #218540 |
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
[toc] | [prev] | [next] | [standalone]
| From | gareth evans <headstone255@yahoo.com> |
|---|---|
| Date | 2021-07-27 11:29 +0100 |
| Subject | Re: sixbit, the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <sdon6u$rse$1@dont-email.me> |
| In reply to | #218543 |
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 "_"
[toc] | [prev] | [next] | [standalone]
| From | TrailingEdgeTechnologies <bbreynolds@aol.com> |
|---|---|
| Date | 2021-07-22 19:43 -0700 |
| Subject | Re: the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <7db033d9-eeaa-4874-8c74-39e8f92de863n@googlegroups.com> |
| In reply to | #218501 |
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.
[toc] | [prev] | [next] | [standalone]
| From | undefined Hancock-4 <hancock4@bbs.cpcn.com> |
|---|---|
| Date | 2021-07-23 11:46 -0700 |
| Subject | Re: the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <24c0eb50-4365-4e9a-8286-9ed009f17b1an@googlegroups.com> |
| In reply to | #218515 |
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.
[toc] | [prev] | [next] | [standalone]
| From | undefined Hancock-4 <hancock4@bbs.cpcn.com> |
|---|---|
| Date | 2021-07-23 11:56 -0700 |
| Subject | Re: the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <933c7f28-a120-4f18-ba8c-79f301438224n@googlegroups.com> |
| In reply to | #218489 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2021-07-23 16:27 -0700 |
| Subject | Re: the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <917703269.648769294.167021.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #218525 |
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
[toc] | [prev] | [next] | [standalone]
| From | undefined Hancock-4 <hancock4@bbs.cpcn.com> |
|---|---|
| Date | 2021-08-07 12:38 -0700 |
| Subject | Re: the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <f8c7aa87-4fbe-4c06-92ca-de74da43f991n@googlegroups.com> |
| In reply to | #218529 |
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?
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2021-08-07 20:04 +0000 |
| Subject | Re: the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <semp0n$a8$1@newsreader4.netcologne.de> |
| In reply to | #218567 |
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.
[toc] | [prev] | [next] | [standalone]
| From | "Kerr-Mudd, John" <admin@127.0.0.1> |
|---|---|
| Date | 2021-08-07 22:24 +0100 |
| Subject | Re: the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <20210807222453.00f7893586f33a2f70f92845@127.0.0.1> |
| In reply to | #218568 |
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.
[toc] | [prev] | [next] | [standalone]
| From | "Kerr-Mudd, John" <admin@127.0.0.1> |
|---|---|
| Date | 2021-08-07 22:27 +0100 |
| Subject | Re: the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <20210807222719.dd6e773fa8340d25e05f76bc@127.0.0.1> |
| In reply to | #218568 |
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. > Urgh indeed. I was quite taken aback to be told ICL had (George III?) a JCL that was just simple If Else conditionals. > 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.
[toc] | [prev] | [next] | [standalone]
| From | undefined Hancock-4 <hancock4@bbs.cpcn.com> |
|---|---|
| Date | 2021-08-10 11:49 -0700 |
| Subject | Re: the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <823a0c4f-a1a2-4bb8-b727-d327a790ce04n@googlegroups.com> |
| In reply to | #218568 |
On Saturday, August 7, 2021 at 4:04:40 PM UTC-4, Thomas Koenig wrote: > undefined Hancock-4 <hanc...@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. 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.
[toc] | [prev] | [next] | [standalone]
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
Back to top | Article view | alt.folklore.computers
csiph-web