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 | 19 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 3 of 3 — ← Prev page 1 2 [3]
| From | J. Clarke <jclarke.873638@gmail.com> |
|---|---|
| Date | 2021-08-10 15:34 -0400 |
| Subject | Re: the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <n3l5hgpfd1djlftbii08nhg0t2p1qpvldt@4ax.com> |
| In reply to | #218578 |
On Tue, 10 Aug 2021 11:49:07 -0700 (PDT), undefined Hancock-4 <hancock4@bbs.cpcn.com> wrote: >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. There's a particular job where one of these days I'm going to set it up to send me an email, and on receipt of the email have Windows retrieve and do stuff with the output.
[toc] | [prev] | [next] | [standalone]
| From | Robin Vowels <robin.vowels@gmail.com> |
|---|---|
| Date | 2021-08-07 18:13 -0700 |
| Subject | Re: the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <fef29167-07a7-4f7f-8805-6d9efcf36f92n@googlegroups.com> |
| In reply to | #218567 |
On Sunday, August 8, 2021 at 5:38:58 AM UTC+10, undefined Hancock-4 wrote: > 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? . It was overly complex. No need to specify block size and record length on CDC's Cyber 70 series.
[toc] | [prev] | [next] | [standalone]
| From | undefined Hancock-4 <hancock4@bbs.cpcn.com> |
|---|---|
| Date | 2021-08-10 11:45 -0700 |
| Subject | Re: the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <4e5c3103-2cfb-4a8c-963c-686e4eef7b07n@googlegroups.com> |
| In reply to | #218571 |
On Saturday, August 7, 2021 at 9:13:26 PM UTC-4, Robin Vowels wrote: > On Sunday, August 8, 2021 at 5:38:58 AM UTC+10, undefined Hancock-4 wrote: > > 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? > . > It was overly complex. No need to specify block size and record length > on CDC's Cyber 70 series. It appeared that the Cyber 70 was about ten years newer than S/360, so perhaps disk blocking and usage was more efficient. But blocking is important, be it handled automatically by software (as Z series does now) or by the programmer.
[toc] | [prev] | [next] | [standalone]
| From | Robin Vowels <robin.vowels@gmail.com> |
|---|---|
| Date | 2021-08-11 06:36 -0700 |
| Subject | Re: the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <39d7331b-638a-4a2b-ad2d-9515c50b6e8en@googlegroups.com> |
| In reply to | #218577 |
On Wednesday, August 11, 2021 at 4:45:14 AM UTC+10, undefined Hancock-4 wrote: > On Saturday, August 7, 2021 at 9:13:26 PM UTC-4, Robin Vowels wrote: > > On Sunday, August 8, 2021 at 5:38:58 AM UTC+10, undefined Hancock-4 wrote: > > > 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? > > . > > It was overly complex. No need to specify block size and record length > > on CDC's Cyber 70 series. . > It appeared that the Cyber 70 was about ten years newer than S/360, so perhaps > disk blocking and usage was more efficient. But blocking is important, be it > handled automatically by software (as Z series does now) or by the programmer. . The operating system Kronos on the Cyber 70 series was derived from that on the earlier 6600 series, predating the S/360.
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2021-08-11 08:00 -0700 |
| Subject | Re: the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <622934222.650386697.367250.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #218582 |
Robin Vowels <robin.vowels@gmail.com> wrote: > On Wednesday, August 11, 2021 at 4:45:14 AM UTC+10, undefined Hancock-4 wrote: >> On Saturday, August 7, 2021 at 9:13:26 PM UTC-4, Robin Vowels wrote: >>> On Sunday, August 8, 2021 at 5:38:58 AM UTC+10, undefined Hancock-4 wrote: >>>> 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? >>> . >>> It was overly complex. No need to specify block size and record length >>> on CDC's Cyber 70 series. > . >> It appeared that the Cyber 70 was about ten years newer than S/360, so perhaps >> disk blocking and usage was more efficient. But blocking is important, be it >> handled automatically by software (as Z series does now) or by the programmer. > . > The operating system Kronos on the Cyber 70 series was derived from > that on the earlier 6600 series, predating the S/360. > I never thought of CDC operating systems as particularly advanced, though. It seems like they got the job done, but without a lot of frills. Sort of like the hardware. -- Pete
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2021-08-10 10:57 -0700 |
| Subject | Re: the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <355421830.650310799.612177.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #218567 |
undefined Hancock-4 <hancock4@bbs.cpcn.com> wrote: > 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? > You could do 90% of the stuff with 20% of the complexity. Burroughs large system MCP had some JCL (WFL?) but as I recall we rarely needed it. A job card and an execute card was about it. Things like DSNs were coded in the program, although they could be overridden in exceptional cases. I don’t think the systems supported a lot of exotic peripherals or options. -- Pete
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2021-08-10 18:29 +0000 |
| Subject | Re: the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <seugi302kun@news1.newsguy.com> |
| In reply to | #218575 |
On 2021-08-10, Peter Flass <peter_flass@yahoo.com> wrote: > undefined Hancock-4 <hancock4@bbs.cpcn.com> wrote: > >> In looking over JCL, we see a million options. But they were necessary >> to handle many different I/O situations. <snip> >> How did this compare to the JCL of other large scale computer systems? > > You could do 90% of the stuff with 20% of the complexity. Burroughs large > system MCP had some JCL (WFL?) but as I recall we rarely needed it. A job > card and an execute card was about it. Things like DSNs were coded in the > program, although they could be overridden in exceptional cases. I don’t > think the systems supported a lot of exotic peripherals or options. A friend worked in a small Burroughs shop (1700). I think it wasn't so much that not many peripherals were supported, but that the system had a lot of device independence. You didn't need a special procedure for each device, but just pointed your program at whatever device you wanted to use and let the MCP sort it out. Also, there wasn't such a plethora of file formats. I always hated the amount of work you had to do to access a program module (source or binary) on a traditional mainframe system. Mind you, given the overhead of each file (look at the VTOC layout, for instance), storing each program module in a separate file was simply not feasible in that environment. -- /~\ 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
[toc] | [prev] | [next] | [standalone]
| From | undefined Hancock-4 <hancock4@bbs.cpcn.com> |
|---|---|
| Date | 2021-08-10 11:54 -0700 |
| Subject | Re: the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <f4a30f2f-20a5-41b3-988c-1021626fc26fn@googlegroups.com> |
| In reply to | #218575 |
On Tuesday, August 10, 2021 at 1:57:35 PM UTC-4, Peter Flass wrote: > You could do 90% of the stuff with 20% of the complexity. Burroughs large > system MCP had some JCL (WFL?) but as I recall we rarely needed it. A job > card and an execute card was about it. Things like DSNs were coded in the > program, although they could be overridden in exceptional cases. I don’t > think the systems supported a lot of exotic peripherals or options. It wasn't every day, but periodically we had to write special JCL to handle a special imported or exported file. We'd have to look up options in the JCL manual, like bypassing standard label records, getting to multiple files on a tape, or special formatting. For instance, almost all files were in standard format, but every so often we'd use option U. All those commas for positional parameters!
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-08-10 19:44 +0000 |
| Subject | Re: the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <iGAQI.863$wq1.19@fx14.iad> |
| In reply to | #218575 |
Peter Flass <peter_flass@yahoo.com> writes: >undefined Hancock-4 <hancock4@bbs.cpcn.com> wrote: >> I remember a large university data center and the numerous requests to mount >> disk and tapes for specific jobs. The system had to track all that stuff. >> >> This is just scratching the surface. >> >> How did this compare to the JCL of other large scale computer systems? >> > >You could do 90% of the stuff with 20% of the complexity. Burroughs large >system MCP had some JCL (WFL?) but as I recall we rarely needed it. A job >card and an execute card was about it. Things like DSNs were coded in the >program, although they could be overridden in exceptional cases. I don’t >think the systems supported a lot of exotic peripherals or options. Actually, there were a fair number of peripherals supported, including MICR reader/sorters, various types of tape drives, 100-byte and 180-byte sector media (disk vs. pack), tape listers (finance), high-speed host interconnects, terminal controllers, etc et al. The command language was simple. The filesystems (both disk and pack) were extent-based and normally the MCP was responsible for allocation, the application specified record size, block size, etc in the file information block (FIB) in the application. ?EX PROGRAM; MEM + 300 ?FILE INPUT = FRED CRD ?FILE OUTPUT = FREDOT PBK ?FILE ARCHIVE = FREDTP MTP which would direct the internal file INPUT to a card deck named 'FRED' (either from a real reader or a pseudo-card reader that reads disk files). The output listing would go to printer backup (i.e. on disk); specify PRN instead and the output would go to a printer named FREDOT automatically if the printer is ready (all printers could be named). If PROGRAM opened ARCHIVE, the MCP would look for a mounted tape named FREDTP, and if not found, would suspend the program until the operator mounted the tape and made the unit ready, or if the program opened the tape OUTPUT, then the MCP would look for a mounted scratch tape, or suspend the program until a scratch tape was ready on any drive (assigned by the operator if necessary).
[toc] | [prev] | [next] | [standalone]
| From | undefined Hancock-4 <hancock4@bbs.cpcn.com> |
|---|---|
| Date | 2021-08-13 12:26 -0700 |
| Subject | Re: the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <6e9da922-8f23-4851-a2e4-a785c305d0c7n@googlegroups.com> |
| In reply to | #218581 |
On Tuesday, August 10, 2021 at 3:44:16 PM UTC-4, Scott Lurndal wrote: > Peter Flass <peter...@yahoo.com> writes: > >You could do 90% of the stuff with 20% of the complexity. Burroughs large > >system MCP had some JCL (WFL?) but as I recall we rarely needed it. A job > >card and an execute card was about it. Things like DSNs were coded in the > >program, although they could be overridden in exceptional cases. I don’t > >think the systems supported a lot of exotic peripherals or options. > Actually, there were a fair number of peripherals supported, including > MICR reader/sorters, various types of tape drives, 100-byte and > 180-byte sector media (disk vs. pack), tape listers (finance), > high-speed host interconnects, terminal controllers, etc et al. Interestingly, one of the 'non standard' peripherals we attached was a Burroughs microfiche printer. On 360-OS, it was very easy, just changed one parameter on the JCL. OS had device independence, so program changes and recompilations were not necessary to change devices. Major advantage. However, on 360-DOS, it was necessary to recompile the program since the device was specified in the program code. As an aside, those microfiche printers were slick machines. Produced very high quality cards. Automatically produced the appropriate visible index at the top or with minimal setup. Saved a huge volume of paper, big savings in storage space and the visible index was faster to locate data.
[toc] | [prev] | [next] | [standalone]
| From | Anne & Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2021-08-13 09:49 -1000 |
| Subject | Re: the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <874kbtunu5.fsf@localhost> |
| In reply to | #218584 |
undefined Hancock-4 <hancock4@bbs.cpcn.com> writes: > Interestingly, one of the 'non standard' peripherals we attached was a Burroughs > microfiche printer. On 360-OS, it was very easy, just changed one parameter on the > JCL. OS had device independence, so program changes and recompilations were > not necessary to change devices. Major advantage. > > However, on 360-DOS, it was necessary to recompile the program since the device > was specified in the program code. > > As an aside, those microfiche printers were slick machines. Produced very high quality > cards. Automatically produced the appropriate visible index at the top or with minimal > setup. Saved a huge volume of paper, big savings in storage space and the visible index > was faster to locate data. home office 1977/1978, cdi miniterm, ibm tieline, and compact microfiche viewer. plant site had microfiche printer and could get 24hr turn around ... had couple hundred microfiche at home, source listings, documentation, etc. http://www.garlic.com/~lynn/miniterm.jpg -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | undefined Hancock-4 <hancock4@bbs.cpcn.com> |
|---|---|
| Date | 2021-08-16 12:52 -0700 |
| Subject | Re: the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <4174b972-2d48-4e42-b492-21918138caaen@googlegroups.com> |
| In reply to | #218585 |
On Friday, August 13, 2021 at 3:49:41 PM UTC-4, ly...@garlic.com wrote: > > As an aside, those microfiche printers were slick machines. Produced very high quality > > cards. Automatically produced the appropriate visible index at the top or with minimal > > setup. Saved a huge volume of paper, big savings in storage space and the visible index > > was faster to locate data. > home office 1977/1978, cdi miniterm, ibm tieline, and compact microfiche > viewer. plant site had microfiche printer and could get 24hr turn around > ... had couple hundred microfiche at home, source listings, > documentation, etc. Someone somehow hacked into the microfiche system and printed a bunch of pictures. When my boss retired he gave me an envelope, "here, you might like this". It wasn't source code. In the old days, people printed pictures from the line printer, which were very coarse. Some had some shading to them by using different characters and overprinting. Can't imagine anyone doing that today, let alone hanging them up in their cube.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-08-16 20:06 +0000 |
| Subject | Re: the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <4zzSI.41202$yS5.896@fx46.iad> |
| In reply to | #218586 |
undefined Hancock-4 <hancock4@bbs.cpcn.com> writes: >On Friday, August 13, 2021 at 3:49:41 PM UTC-4, ly...@garlic.com wrote: > >> > As an aside, those microfiche printers were slick machines. Produced very high quality >> > cards. Automatically produced the appropriate visible index at the top or with minimal >> > setup. Saved a huge volume of paper, big savings in storage space and the visible index >> > was faster to locate data. >> home office 1977/1978, cdi miniterm, ibm tieline, and compact microfiche >> viewer. plant site had microfiche printer and could get 24hr turn around >> ... had couple hundred microfiche at home, source listings, >> documentation, etc. > >Someone somehow hacked into the microfiche system and printed a bunch of pictures. >When my boss retired he gave me an envelope, "here, you might like this". It wasn't source code. > >In the old days, people printed pictures from the line printer, which were very coarse. Some >had some shading to them by using different characters and overprinting. Can't imagine >anyone doing that today, let alone hanging them up in their cube. I've got one of those of myself (done with a 256-gray-scale capture system in 1981). I still have a copy of the 9track poster tape that was handed around in those days - there's a poster of a 727 going over the golden gate bridge that required taping several full-width listing side by each, and a really nice on of the moon (the finished moon was about 2' in diameter when all the pieces were taped together), and a handful of tame (by modern standards) topless models.
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2021-08-16 23:31 +0000 |
| Subject | Re: the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <sfeshc02k2j@news2.newsguy.com> |
| In reply to | #218588 |
On 2021-08-16, Scott Lurndal <scott@slp53.sl.home> wrote: > undefined Hancock-4 <hancock4@bbs.cpcn.com> writes: > >> In the old days, people printed pictures from the line printer, which >> were very coarse. Some had some shading to them by using different >> characters and overprinting. Can't imagine anyone doing that today, >> let alone hanging them up in their cube. > > I've got one of those of myself (done with a 256-gray-scale capture > system in 1981). > > I still have a copy of the 9track poster tape that was handed around > in those days - there's a poster of a 727 going over the golden gate > bridge that required taping several full-width listing side by each, > and a really nice on of the moon (the finished moon was about 2' in > diameter when all the pieces were taped together), and a handful of > tame (by modern standards) topless models. I have one of those tapes myself. On mine the moon is about 5 feet across. Another nice one was of Spock holding a model of the Enterprise. -- /~\ 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
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-08-17 15:41 +0000 |
| Subject | Re: the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <1NQSI.2$EG5.1@fx20.iad> |
| In reply to | #218590 |
Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes: >On 2021-08-16, Scott Lurndal <scott@slp53.sl.home> wrote: > >> undefined Hancock-4 <hancock4@bbs.cpcn.com> writes: >> >>> In the old days, people printed pictures from the line printer, which >>> were very coarse. Some had some shading to them by using different >>> characters and overprinting. Can't imagine anyone doing that today, >>> let alone hanging them up in their cube. >> >> I've got one of those of myself (done with a 256-gray-scale capture >> system in 1981). >> >> I still have a copy of the 9track poster tape that was handed around >> in those days - there's a poster of a 727 going over the golden gate >> bridge that required taping several full-width listing side by each, >> and a really nice on of the moon (the finished moon was about 2' in >> diameter when all the pieces were taped together), and a handful of >> tame (by modern standards) topless models. > >I have one of those tapes myself. On mine the moon is about 5 feet >across. Another nice one was of Spock holding a model of the Enterprise. Yeah, 5' sounds right. I haven't seen my copy of the poster in decades, it may still be in a box in storage. The enterprise poster is on that tape. I did read the tape yesterday on the Burroughs Simulator (it is an ANSI labeled EBCDIC tape); I should get the old dot matrix epson 132-column printer out of storage and (if I can find a parallel port and new ribbon anywhere :-) see if I can't print a couple of the posters.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-08-18 16:38 +0000 |
| Subject | Re: the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <1IaTI.577$LV.240@fx05.iad> |
| In reply to | #218591 |
scott@slp53.sl.home (Scott Lurndal) writes: >Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes: >> >>I have one of those tapes myself. On mine the moon is about 5 feet >>across. Another nice one was of Spock holding a model of the Enterprise. >I did read the tape yesterday on the Burroughs Simulator (it is >an ANSI labeled EBCDIC tape); I should get the old dot matrix epson >132-column printer out of storage and (if I can find a parallel >port and new ribbon anywhere :-) see if I can't print a couple of the posters. > $ (cd /work/4mmtapes/chm/; dd if=poster_890825_1600.tap conv=ascii | strings | grep -i hdr1) HDR1SMALL.CAT POSTER00010001 77051 000000000000 HDR1LARGE.CAT POSTER00010002 77051 000000000000 HDR1SMALL.DOG POSTER00010003 77051 000000000000 HDR1LARGE.DOG POSTER00010004 77051 000000000000 HDR1SMALL.NUDE POSTER00010005 77051 000000000000 HDR1LARGE.NUDE POSTER00010006 77051 000000000000 HDR1PICASSO.SYLVETTE POSTER00010007 77051 000000000000 HDR1EINSTEIN POSTER00010008 77051 000000000000 HDR1MOUTN.CLIMBER POSTER00010009 77051 000000000000 HDR1MR.SPOCK POSTER00010010 77051 000000000000 HDR1ARMSTRNG.ON.MOON POSTER00010011 77051 000000000000 HDR1DEAN.AND.NIXON POSTER00010012 77051 000000000000 HDR1MOON POSTER00010013 77051 000000000000 HDR1BEETHOVN POSTER00010014 77051 000000000000 HDR1PLANE.B727 POSTER00010015 77051 000000000000 HDR1ISU.CY POSTER00010016 77054 000000000000 HDR1CLIPPER.SHIP POSTER00010017 77054 000000000000 HDR1MONA.LISA POSTER00010018 77054 000000000000 HDR1PIECE.OF.PI POSTER00010019 77054 000000000000 HDR1CAPN.ANDY POSTER00010020 77054 000000000000 HDR1DOG POSTER00010021 77054 000000000000 HDR1ECOLOGY POSTER00010022 77054 000000000000 HDR1PEACE.SYMBOL POSTER00010023 77054 000000000000 HDR1ALFRED POSTER00010024 77054 000000000000 HDR1EDITH POSTER00010025 77054 000000000000 HDR1RAQUEL.WELCH POSTER00010026 77054 000000000000 HDR1JFK POSTER00010027 77054 000000000000 HDR1JFK POSTER00010028 77054 000000000000 HDR1ROAD.RUNNER POSTER00010029 77054 000000000000 HDR1ROAD.RUNNER POSTER00010030 77054 000000000000 HDR1GOOD.GRIEF POSTER00010031 77054 000000000000 HDR1CHARLIE.BROWN POSTER00010032 77054 000000000000 HDR1LINUS POSTER00010033 77054 000000000000 HDR1LUCY POSTER00010034 77054 000000000000 HDR1SCHROEDR POSTER00010035 77054 000000000000 HDR1SNOOPY POSTER00010036 77054 000000000000 HDR1SNOOPY POSTER00010037 77054 000000000000 HDR1SNOOPY POSTER00010038 77054 000000000000 HDR1SNOOPY.ACE POSTER00010039 77054 000000000000 HDR1SNOOPY.CURSE POSTER00010040 77054 000000000000 HDR1SNOOPY.DISH POSTER00010041 77054 000000000000 HDR1SNOOPY.HANG POSTER00010042 77054 000000000000 HDR1SNOOPY.HANG.ON POSTER00010043 77054 000000000000 HDR1SNOOPY.HUG POSTER00010044 77054 000000000000 HDR1SNOOPY.PUNT POSTER00010045 77054 000000000000 HDR1PLAYBOY.RABBIT POSTER00010046 77054 000000000000 HDR1PLAYBOY.RABBIT POSTER00010047 77054 000000000000 HDR1PLAYBOY.RABBIT POSTER00010048 77054 000000000000 HDR1PLAYBOY.RABBIT POSTER00010049 77054 000000000000 HDR1PLAYBOY.RABBIT POSTER00010050 77054 000000000000 HDR1PLAYBOY.RABBIT POSTER00010051 77054 000000000000 HDR1NUDE POSTER00010052 77054 000000000000 HDR1NUDE POSTER00010053 77054 000000000000 HDR1NUDE POSTER00010054 77054 000000000000 HDR1NUDE.DOT POSTER00010055 77054 000000000000 HDR1NUDE.MIRROR POSTER00010056 77054 000000000000 HDR1NUDE.MISS.JUNE POSTER00010057 77054 000000000000 HDR1NUDE.RECLING POSTER00010058 77054 000000000000 HDR1NUDE.RECLING POSTER00010059 77054 000000000000 HDR1NUDE.STOOL POSTER00010060 77054 000000000000 HDR1NUDE.STOOL POSTER00010061 77054 000000000000 HDR1NUDE.STOOL POSTER00010062 77054 000000000000 HDR1NUDE.STOOL POSTER00010063 77054 000000000000 HDR1NUDE.STOOL POSTER00010064 77054 000000000000 HDR1NUDE.STOOL POSTER00010065 77054 000000000000 HDR1NUDE.STOOL POSTER00010066 77054 000000000000 HDR1LBJ POSTER00010067 77054 000000000000 HDR1XMAS.VIRGIN.MARY POSTER00010068 77054 000000000000 HDR1XMAS.WREATH POSTER00010069 77054 000000000000 HDR1XMAS.WREATH.MCHNYPOSTER00010070 77054 000000000000 HDR1XMAS.SANTA POSTER00010071 77055 000000000000 HDR1XMAS.SOLTICE POSTER00010072 77055 000000000000 HDR1XMAS.JOY POSTER00010073 77055 000000000000 HDR1XMAS.WISE.MEN POSTER00010074 77055 000000000000 HDR1XMAS.MERRY.XMAS POSTER00010075 77055 000000000000 HDR1XMAS.MERRY.XMAS POSTER00010076 77055 000000000000 HDR1XMAS.RAINDEER POSTER00010077 77055 000000000000 HDR1XMAS.RAINDEER POSTER00010078 77055 000000000000 HDR1XMAS.RAINDEER POSTER00010079 77060 000000000000 HDR1PLI.UNCOBOL POSTER00010080 77335 000000000000 HDR1SNOOPY.RUDE POSTER00010081 77343 000000000000 HDR1LINUS.PEACE POSTER00010082 77343 000000000000 HDR1SNOOPY.HOP POSTER00010083 77343 000000000000 HDR1STARSHIP POSTER00010084 80034 000000000000IBM OS/VS 370382 & HDR1STARWARS POSTER00010085 81199 000000000000IBM OS/VS 370383 &
[toc] | [prev] | [next] | [standalone]
| From | "Kerr-Mudd, John" <admin@127.0.0.1> |
|---|---|
| Date | 2021-08-18 18:29 +0100 |
| Subject | Re: the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <20210818182953.bd9b45aa1246f37eae75c16a@127.0.0.1> |
| In reply to | #218597 |
On Wed, 18 Aug 2021 16:38:21 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > scott@slp53.sl.home (Scott Lurndal) writes: > >Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes: > > >> > >>I have one of those tapes myself. On mine the moon is about 5 feet > >>across. Another nice one was of Spock holding a model of the Enterprise. > > >I did read the tape yesterday on the Burroughs Simulator (it is > >an ANSI labeled EBCDIC tape); I should get the old dot matrix epson > >132-column printer out of storage and (if I can find a parallel > >port and new ribbon anywhere :-) see if I can't print a couple of the posters. > > > $ (cd /work/4mmtapes/chm/; dd if=poster_890825_1600.tap conv=ascii | strings | grep -i hdr1) > HDR1SMALL.CAT POSTER00010001 77051 000000000000 > HDR1LARGE.CAT POSTER00010002 77051 000000000000 > HDR1SMALL.DOG POSTER00010003 77051 000000000000 > HDR1LARGE.DOG POSTER00010004 77051 000000000000 > HDR1SMALL.NUDE POSTER00010005 77051 000000000000 > HDR1LARGE.NUDE POSTER00010006 77051 000000000000 > HDR1PICASSO.SYLVETTE POSTER00010007 77051 000000000000 > HDR1EINSTEIN POSTER00010008 77051 000000000000 > HDR1MOUTN.CLIMBER POSTER00010009 77051 000000000000 > HDR1MR.SPOCK POSTER00010010 77051 000000000000 > HDR1ARMSTRNG.ON.MOON POSTER00010011 77051 000000000000 > HDR1DEAN.AND.NIXON POSTER00010012 77051 000000000000 > HDR1MOON POSTER00010013 77051 000000000000 > HDR1BEETHOVN POSTER00010014 77051 000000000000 > HDR1PLANE.B727 POSTER00010015 77051 000000000000 > HDR1ISU.CY POSTER00010016 77054 000000000000 > HDR1CLIPPER.SHIP POSTER00010017 77054 000000000000 > HDR1MONA.LISA POSTER00010018 77054 000000000000 > HDR1PIECE.OF.PI POSTER00010019 77054 000000000000 > HDR1CAPN.ANDY POSTER00010020 77054 000000000000 > HDR1DOG POSTER00010021 77054 000000000000 > HDR1ECOLOGY POSTER00010022 77054 000000000000 > HDR1PEACE.SYMBOL POSTER00010023 77054 000000000000 > HDR1ALFRED POSTER00010024 77054 000000000000 > HDR1EDITH POSTER00010025 77054 000000000000 > HDR1RAQUEL.WELCH POSTER00010026 77054 000000000000 > HDR1JFK POSTER00010027 77054 000000000000 > HDR1JFK POSTER00010028 77054 000000000000 > HDR1ROAD.RUNNER POSTER00010029 77054 000000000000 > HDR1ROAD.RUNNER POSTER00010030 77054 000000000000 > HDR1GOOD.GRIEF POSTER00010031 77054 000000000000 > HDR1CHARLIE.BROWN POSTER00010032 77054 000000000000 > HDR1LINUS POSTER00010033 77054 000000000000 > HDR1LUCY POSTER00010034 77054 000000000000 > HDR1SCHROEDR POSTER00010035 77054 000000000000 > HDR1SNOOPY POSTER00010036 77054 000000000000 > HDR1SNOOPY POSTER00010037 77054 000000000000 > HDR1SNOOPY POSTER00010038 77054 000000000000 > HDR1SNOOPY.ACE POSTER00010039 77054 000000000000 > HDR1SNOOPY.CURSE POSTER00010040 77054 000000000000 > HDR1SNOOPY.DISH POSTER00010041 77054 000000000000 > HDR1SNOOPY.HANG POSTER00010042 77054 000000000000 > HDR1SNOOPY.HANG.ON POSTER00010043 77054 000000000000 > HDR1SNOOPY.HUG POSTER00010044 77054 000000000000 > HDR1SNOOPY.PUNT POSTER00010045 77054 000000000000 > HDR1PLAYBOY.RABBIT POSTER00010046 77054 000000000000 > HDR1PLAYBOY.RABBIT POSTER00010047 77054 000000000000 > HDR1PLAYBOY.RABBIT POSTER00010048 77054 000000000000 > HDR1PLAYBOY.RABBIT POSTER00010049 77054 000000000000 > HDR1PLAYBOY.RABBIT POSTER00010050 77054 000000000000 > HDR1PLAYBOY.RABBIT POSTER00010051 77054 000000000000 > HDR1NUDE POSTER00010052 77054 000000000000 > HDR1NUDE POSTER00010053 77054 000000000000 > HDR1NUDE POSTER00010054 77054 000000000000 > HDR1NUDE.DOT POSTER00010055 77054 000000000000 > HDR1NUDE.MIRROR POSTER00010056 77054 000000000000 > HDR1NUDE.MISS.JUNE POSTER00010057 77054 000000000000 > HDR1NUDE.RECLING POSTER00010058 77054 000000000000 > HDR1NUDE.RECLING POSTER00010059 77054 000000000000 > HDR1NUDE.STOOL POSTER00010060 77054 000000000000 > HDR1NUDE.STOOL POSTER00010061 77054 000000000000 > HDR1NUDE.STOOL POSTER00010062 77054 000000000000 > HDR1NUDE.STOOL POSTER00010063 77054 000000000000 > HDR1NUDE.STOOL POSTER00010064 77054 000000000000 > HDR1NUDE.STOOL POSTER00010065 77054 000000000000 > HDR1NUDE.STOOL POSTER00010066 77054 000000000000 > HDR1LBJ POSTER00010067 77054 000000000000 > HDR1XMAS.VIRGIN.MARY POSTER00010068 77054 000000000000 > HDR1XMAS.WREATH POSTER00010069 77054 000000000000 > HDR1XMAS.WREATH.MCHNYPOSTER00010070 77054 000000000000 > HDR1XMAS.SANTA POSTER00010071 77055 000000000000 > HDR1XMAS.SOLTICE POSTER00010072 77055 000000000000 > HDR1XMAS.JOY POSTER00010073 77055 000000000000 > HDR1XMAS.WISE.MEN POSTER00010074 77055 000000000000 > HDR1XMAS.MERRY.XMAS POSTER00010075 77055 000000000000 > HDR1XMAS.MERRY.XMAS POSTER00010076 77055 000000000000 > HDR1XMAS.RAINDEER POSTER00010077 77055 000000000000 > HDR1XMAS.RAINDEER POSTER00010078 77055 000000000000 > HDR1XMAS.RAINDEER POSTER00010079 77060 000000000000 > HDR1PLI.UNCOBOL POSTER00010080 77335 000000000000 > HDR1SNOOPY.RUDE POSTER00010081 77343 000000000000 > HDR1LINUS.PEACE POSTER00010082 77343 000000000000 > HDR1SNOOPY.HOP POSTER00010083 77343 000000000000 > HDR1STARSHIP POSTER00010084 80034 000000000000IBM OS/VS 370382 & > HDR1STARWARS POSTER00010085 81199 000000000000IBM OS/VS 370383 & I recall a Snoopy (calendar, IIRC) but the porn passed me by; please repost! (smiley) -- Bah, and indeed Humbug.
[toc] | [prev] | [next] | [standalone]
| From | Anne & Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2021-07-27 18:12 -1000 |
| Subject | Re: the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <87wnpbnkj8.fsf@localhost> |
| In reply to | #218525 |
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.yelavich.com/cicshist.htm https://web.archive.org/web/20071124013919/http://www.yelavich.com/history/toc.htm OS/360 was enormously disk intensive ... with all the fragmented module loads ... that I did very careful system generations ... arranging sysgen statements to carefully place files&modules to optimize disk arm seek and PDS directory multi-track search. I've frequently mentioned that student fortran programs ran less than second on 709 tape->tape ... but initial move to OS/360 (360/67 running as 360/65) student fortran took over a minute, installing HASP ... cut that in half. Initial careful sysgens cut it almost by 2/3rds (most of it still furious disk activity). Didn't get to better than 709 until single step WATFOR montor (batched multiple jobs in single execution). Single step startup overhead was still over 4secs ... but batching 40-60 student jobs running at (watfor) 20,000 cards/min (333 cards/sec) ... student jobs 30-60 cards, so 4sec startup/shutdown spread over 50 batched jobs 4sec/50=.08sec/job plus 50cards/333=.15sec/job ... avg .23sec. ... note that ACP/TPF was highly optimized code and was really difficult to add hardware multiprocessor support. 3081 was originally going to be multiprocessor only machine and IBM was afraid that the whole ACP/TPF market would move to clone mainframe makers ... that were coming out with new, faster single processor machines (high-end single proceessor amdahl had nearly the same processing as two processor 3081k ... and two processor high-end amdahl was twice that ... better than the four processor 3084). Eventually IBM did come out with 3083 ... a 3081 with one of the processors removed (initially for the ACP/TPF market). It took a while longer and whole lot of effort before had ACP/TPF supporting real multiprocessor operation. past SMP, multiprocessor, compare&swap, etc posts http://www.garlic.com/~lynn/subtopic.html#smp ... trivia: problem for CICS was even worse ... above referenced cics history table of contents ... doesn't have multiprocessor exploitation until 2004. ... other CICS trivia: CICS had a slight of hand work around, running multiple instances with workload partitioned across the different instances. I visited a datacenter around the turn of the century that claimed it was concurrently running 120-130 CICS instances on their system. -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | Anne & Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2021-07-27 18:49 -1000 |
| Subject | Re: the wonders of SABRE, was Magnetic Drum reservations 1952 |
| Message-ID | <87sfzzniuh.fsf@localhost> |
| In reply to | #218547 |
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
[toc] | [prev] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | alt.folklore.computers
csiph-web