Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.folklore.computers > #153134 > unrolled thread
| Started by | "Bill Cunningham" <nospam@nspam.invalid> |
|---|---|
| First post | 2015-10-20 17:47 -0400 |
| Last post | 2015-12-22 11:43 -0800 |
| Articles | 20 on this page of 115 — 29 participants |
Back to article view | Back to alt.folklore.computers
high level language idea "Bill Cunningham" <nospam@nspam.invalid> - 2015-10-20 17:47 -0400
Re: high level language idea Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-21 01:09 +0000
Re: high level language idea "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-21 14:44 -0500
Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-21 13:15 -0700
Re: high level language idea davidmylastname@acm.org (David Griffith) - 2015-10-21 01:16 +0000
Re: high level language idea "Bill Cunningham" <nospam@nspam.invalid> - 2015-10-21 14:26 -0400
Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-21 12:13 -0700
Re: high level language idea "Bill Cunningham" <nospam@nspam.invalid> - 2015-10-21 15:23 -0400
Re: high level language idea bert <bert.hutchings@btinternet.com> - 2015-10-21 03:53 -0700
Re: high level language idea rpw3@rpw3.org (Rob Warnock) - 2015-10-21 13:47 +0000
Re: high level language idea "gareth" <no.spam@thank.you.invalid> - 2015-10-21 14:58 +0100
Re: high level language idea Walter Banks <walter@bytecraft.com> - 2015-10-21 10:34 -0400
Re: high level language idea Bob Eager <news0005@eager.cx> - 2015-10-21 16:43 +0000
Re: high level language idea rpw3@rpw3.org (Rob Warnock) - 2015-10-21 14:46 +0000
Re: high level language idea "Bill Cunningham" <nospam@nspam.invalid> - 2015-10-21 14:29 -0400
Re: high level language idea Jon Elson <jmelson@wustl.edu> - 2015-10-21 14:19 -0500
Re: high level language idea Roberto Waltman <usenet@rwaltman.com> - 2015-10-21 15:24 -0400
Re: high level language idea Jon Elson <jmelson@wustl.edu> - 2015-10-22 14:13 -0500
Re: high level language idea "Osmium" <r124c4u102@comcast.net> - 2015-10-23 09:55 -0500
Re: high level language idea Peter Flass <peter_flass@yahoo.com> - 2015-10-23 11:42 -0400
Re: high level language idea "Osmium" <r124c4u102@comcast.net> - 2015-10-23 11:48 -0500
Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-23 10:47 -0700
Re: high level language idea Jon Elson <elson@pico-systems.com> - 2015-10-24 21:24 -0500
Re: high level language idea Jon Elson <elson@pico-systems.com> - 2015-10-24 21:14 -0500
Re: high level language idea Jon Elson <elson@pico-systems.com> - 2015-10-25 11:31 -0500
Re: high level language idea Bob Eager <news0005@eager.cx> - 2015-10-25 18:13 +0000
Re: high level language idea Anne & Lynn Wheeler <lynn@garlic.com> - 2015-10-23 11:20 -0700
Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-23 11:45 -0700
Re: high level language idea Jon Elson <elson@pico-systems.com> - 2015-10-24 21:11 -0500
Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-27 07:40 -0700
Re: high level language idea Anne & Lynn Wheeler <lynn@garlic.com> - 2015-10-27 08:30 -0700
Re: high level language idea Anne & Lynn Wheeler <lynn@garlic.com> - 2015-10-27 09:11 -0700
Re: high level language idea Dan Espen <despen@verizon.net> - 2015-10-27 12:52 -0400
Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-27 10:22 -0700
Re: high level language idea Dan Espen <despen@verizon.net> - 2015-10-27 14:37 -0400
Re: high level language idea Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-27 19:55 +0000
Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-27 17:46 -0700
Re: high level language idea Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-28 01:22 +0000
Re: high level language idea jmfbahciv <See.above@aol.com> - 2015-10-28 12:58 +0000
Re: high level language idea "gareth" <no.spam@thank.you.invalid> - 2015-10-28 13:59 +0000
Re: high level language idea jmfbahciv <See.above@aol.com> - 2015-10-29 13:55 +0000
Re: high level language idea Bob Eager <news0005@eager.cx> - 2015-10-29 14:28 +0000
Re: high level language idea "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-10-30 05:06 +1100
Re: high level language idea pechter@S20.pechter.dyndns.org (William Pechter) - 2015-10-29 19:55 +0000
Re: high level language idea Lawrence Statton <lawrence@senguio.mx> - 2015-10-29 14:21 -0600
Re: high level language idea pechter@S20.pechter.dyndns.org (William Pechter) - 2015-10-29 19:50 +0000
Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-28 07:33 -0700
Re: high level language idea Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-28 16:58 +0000
Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-28 10:10 -0700
Re: high level language idea Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-28 20:08 +0000
Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-28 13:58 -0700
Re: high level language idea "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-27 15:53 -0500
Re: high level language idea - TTF Dan Espen <despen@verizon.net> - 2015-10-27 17:11 -0400
Re: high level language idea - TTF scott@slp53.sl.home (Scott Lurndal) - 2015-10-28 13:24 +0000
Re: high level language idea - TTF hancock4@bbs.cpcn.com - 2015-10-28 07:37 -0700
Re: high level language idea - TTF Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-28 16:58 +0000
Re: high level language idea - TTF Dan Espen <despen@verizon.net> - 2015-10-28 15:10 -0400
Re: high level language idea Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-28 01:22 +0000
Re: high level language idea Anne & Lynn Wheeler <lynn@garlic.com> - 2015-10-28 08:04 -0700
Re: high level language idea Dan Espen <despen@verizon.net> - 2015-10-27 11:34 -0400
Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-27 10:14 -0700
Re: high level language idea Dan Espen <despen@verizon.net> - 2015-10-27 14:30 -0400
Re: high level language idea Bob Eager <news0005@eager.cx> - 2015-10-27 19:29 +0000
Re: high level language idea Dan Espen <despen@verizon.net> - 2015-10-27 16:57 -0400
Re: high level language idea Bob Eager <news0005@eager.cx> - 2015-10-27 21:50 +0000
Re: high level language idea Dan Espen <despen@verizon.net> - 2015-10-27 17:58 -0400
Re: high level language idea Ahem A Rivet's Shot <steveo@eircom.net> - 2015-10-28 09:04 +0000
Re: high level language idea "gareth" <no.spam@thank.you.invalid> - 2015-10-28 09:42 +0000
Re: high level language idea Roberto Waltman <usenet@rwaltman.com> - 2015-10-28 14:55 -0400
Re: high level language idea Roberto Waltman <usenet@rwaltman.com> - 2015-10-28 15:02 -0400
Re: high level language idea Bob Eager <news0005@eager.cx> - 2015-10-28 19:15 +0000
Re: high level language idea Lawrence Statton <lawrence@senguio.mx> - 2015-10-28 13:25 -0600
Re: high level language idea Michael Black <et472@ncf.ca> - 2015-10-28 17:54 -0400
Re: high level language idea Ahem A Rivet's Shot <steveo@eircom.net> - 2015-10-28 19:19 +0000
Re: high level language idea Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-28 21:09 +0000
Re: high level language idea scott@slp53.sl.home (Scott Lurndal) - 2015-10-28 13:36 +0000
Re: high level language idea Andrew Swallow <am.swallow@btinternet.com> - 2015-10-28 17:54 +0000
Re: high level language idea Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-28 20:08 +0000
Re: high level language idea "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-28 17:54 -0500
Re: high level language idea Alan Bowler <atbowler@thinkage.ca> - 2015-11-13 16:05 -0500
Re: high level language idea Peter Flass <peter_flass@yahoo.com> - 2015-11-13 17:20 -0500
Re: high level language idea Walter Banks <walter@bytecraft.com> - 2015-11-15 08:14 -0500
Re: high level language idea Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-27 19:55 +0000
Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-27 18:00 -0700
Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-21 12:21 -0700
Re: high level language idea "Bill Cunningham" <nospam@nspam.invalid> - 2015-10-21 15:25 -0400
Re: high level language idea "Bill Cunningham" <nospam@nspam.invalid> - 2015-10-21 17:14 -0400
Re: high level language idea jmfbahciv <See.above@aol.com> - 2015-10-22 12:51 +0000
Re: high level language idea Peter Flass <peter_flass@yahoo.com> - 2015-10-21 17:56 -0400
Re: high level language idea Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-21 19:43 +0000
Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-21 13:09 -0700
Re: high level language idea Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-22 02:52 +0000
Re: high level language idea "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-23 16:04 -0500
Re: high level language idea Walter Bushell <proto@panix.com> - 2015-10-28 20:19 -0400
Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-21 07:35 -0700
Re: high level language idea Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-21 19:43 +0000
Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-21 13:00 -0700
Re: high level language idea Anne & Lynn Wheeler <lynn@garlic.com> - 2015-10-21 13:35 -0700
Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-21 13:50 -0700
Re: high level language idea Peter Flass <peter_flass@yahoo.com> - 2015-10-21 17:56 -0400
Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-22 07:22 -0700
Re: high level language idea John Levine <johnl@iecc.com> - 2015-10-24 00:42 +0000
Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-24 20:26 -0700
Re: high level language idea "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-25 18:36 -0500
Re: high level language idea Anne & Lynn Wheeler <lynn@garlic.com> - 2015-10-21 15:31 -0700
Re: high level language idea Alan Bowler <atbowler@thinkage.ca> - 2015-11-20 17:17 -0500
Re: high level language idea Alan Bowler <atbowler@thinkage.ca> - 2015-11-20 17:00 -0500
Re: high level language idea Bob Eager <news0005@eager.cx> - 2015-11-20 22:20 +0000
Re: high level language idea Peter Flass <peter_flass@yahoo.com> - 2015-11-21 08:35 -0500
Re: high level language idea "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-23 16:00 -0500
Re: high level language idea Bob Eager <news0005@eager.cx> - 2015-10-23 21:07 +0000
Re: high level language idea Alan Bowler <atbowler@thinkage.ca> - 2015-11-20 17:31 -0500
Re: high level language idea Gene Wirchenko <genew@telus.net> - 2015-11-25 11:28 -0800
Re: high level language idea Alan Bowler <atbowler@thinkage.ca> - 2015-12-22 14:00 -0500
Re: high level language idea Gene Wirchenko <genew@telus.net> - 2015-12-22 11:43 -0800
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | "Osmium" <r124c4u102@comcast.net> |
|---|---|
| Date | 2015-10-23 11:48 -0500 |
| Message-ID | <d8v6ncFeeskU1@mid.individual.net> |
| In reply to | #153252 |
"Peter Flass" wrote: > Osmium <r124c4u102@comcast.net> wrote: >> "Jon Elson" wrote: >> >>> Roberto Waltman wrote: >>> >>>> Jon Elson wrote: >>>> >>>>> ... The number of bugs in OS/360 were legendary, and they NEVER >>>>> stamped >>>>> them all out. >>>> >>>> I recall reading somewhere that the number of bugs was more or less a >>>> constant, with each new OS release introducing as many new bugs as >>>> fixes for old ones. >>> Yes, trying to maintain a huge piece of software, with thousands of >>> separately assembled routines, some linked to the "kernel" and a bunch >>> called in as needed, after it has been in use for MANY years, and hacked >>> on >>> by hundreds or thousands of programmers, seems REALLY daunting. The >>> number >>> of unintended interactions seems vast. >> >> If they did, in fact, accommodate the hackers, it was a failure of >> management. They should have provided a written interface when they >> released the OS to the wild and made it clear that *this* *is* the >> interface. Not some fascinating stuff that multiple someones had gleaned >> by >> reverse engineering or whatever. >> >> IBM was big enough that they could have enforced such a rule. >> >> > > it was all open-source. No need to reverse-engineer anything. As late as > MVS/XA I had a VSAM open exit where the call location had to be gleaned by > looking at the fiche and disassembling the PL/S module, although it > started > out as a straightforward source update in MVS/370. > > I think JES2, or most of it, is still distributed as source, because so > many users had so many different mods. Out JES guy had tons and knew the > jes code i side and out. If I understand that, the implied interface was the released code; if your code works with our code, all is good. That sounds like a prescription for chaos. and I foresee problems, *huge* problems. This was a major decision my management, perhaps it was tacit, but it was still a management decision.
[toc] | [prev] | [next] | [standalone]
| From | hancock4@bbs.cpcn.com |
|---|---|
| Date | 2015-10-23 10:47 -0700 |
| Message-ID | <feb9d7b9-d6b6-4a2c-9f66-5cfc70379a76@googlegroups.com> |
| In reply to | #153253 |
On Friday, October 23, 2015 at 12:48:46 PM UTC-4, Osmium wrote: > If I understand that, the implied interface was the released code; if your > code works with our code, all is good. That sounds like a prescription for > chaos. and I foresee problems, *huge* problems. This was a major decision my > management, perhaps it was tacit, but it was still a management decision. For what it's worth, all installations I ever had contact with never touched the operating system _code_ as released from IBM. There was enough to do just selecting various options, especially as the systems grew more complex, let alone write home-rolled exit routines. JCL allowed programmers to do a great many things in establishing the execution parameters for their program, but the operating system could set defaults and block many options to preserve system integrity. Two examples: there were job classes and task switching priorities. By use of those, a programmer could jump ahead of others in line, but often the site wouldn't allow it. Likewise, TSO and CICS had many options that had to be configured. One employer imported a complex application from a vendor, and then made extensive changes to customize it. The problem was that every year the application was reissued, which meant my employer had to reapply all the customization to the new release. P-I-T-A! Compounding the challenge was that the release was in true ANSI COBOL, not the IBM variant.
[toc] | [prev] | [next] | [standalone]
| From | Jon Elson <elson@pico-systems.com> |
|---|---|
| Date | 2015-10-24 21:24 -0500 |
| Message-ID | <fdSdnSU3DKTnoLHLnZ2dnUU7-VudnZ2d@giganews.com> |
| In reply to | #153258 |
hancock4@bbs.cpcn.com wrote: > On Friday, October 23, 2015 at 12:48:46 PM UTC-4, Osmium wrote: > > > For what it's worth, all installations I ever had contact with never > touched the operating system _code_ as released from IBM. Well, our group at Washington University DID modify the code. They had good reasons to do it when they did so, and they did it VERY carefully, because the consequences of a goof would be visible to a lot of people. Also, we probably had a larger support staff than might be usual for such a small operation. Jon
[toc] | [prev] | [next] | [standalone]
| From | Jon Elson <elson@pico-systems.com> |
|---|---|
| Date | 2015-10-24 21:14 -0500 |
| Message-ID | <0c6dnSJsV85zp7HLnZ2dnUU7-WmdnZ2d@giganews.com> |
| In reply to | #153253 |
Osmium wrote: > > If I understand that, the implied interface was the released code; if your > code works with our code, all is good. That sounds like a prescription for > chaos. and I foresee problems, *huge* problems. This was a major decision > my management, perhaps it was tacit, but it was still a management > decision. USERS essentially never needed to look at OS code, IBM docs were just about the best there were, and the published interfaces were **WELL** defined and documented. But, if you were curious how IBM did something, or maybe found a quirk, you could dig in the code to understand why it worked that way. Jon
[toc] | [prev] | [next] | [standalone]
| From | Jon Elson <elson@pico-systems.com> |
|---|---|
| Date | 2015-10-25 11:31 -0500 |
| Message-ID | <pOOdne6kWO9QnrDLnZ2dnUU7-c2dnZ2d@giganews.com> |
| In reply to | #153312 |
Jon Elson wrote: > Osmium wrote: > > >> >> If I understand that, the implied interface was the released code; if >> your code works with our code, all is good. That sounds like a >> prescription for chaos. and I foresee problems, *huge* problems. This was >> a major decision my management, perhaps it was tacit, but it was still a >> management decision. > USERS essentially never needed to look at OS code, IBM docs were just > about the best there were, and the published interfaces were **WELL** > defined and documented. > > But, if you were curious how IBM did something, or maybe found a quirk, > you could dig in the code to understand why it worked that way. For instance, one physics professor built a flying spot scanner to read in photos from particle tracking experiment, and at the time to only real computer on campus was the 360/50. So, he built a channel interface and wrote all his own code to communicate with it. Later, when minis were available, but storage peripherals often cost more than the CPU, he built what was called the spider net. He had a central PDP-11 that was attached to the 360 with a channel interface, and had over a dozen serial cards in it. These were connected to "client" PDP-11s with a single RG-78 coax cable, and sent data at 1 mbit/second. So, he had a dedicated disk pack on the system, and a server program ran all the time on the 360, waiting for a request from the PDP-11. When it got one, it would perform the disk I/O requested and send it back over the channel to the PDP. Jon
[toc] | [prev] | [next] | [standalone]
| From | Bob Eager <news0005@eager.cx> |
|---|---|
| Date | 2015-10-25 18:13 +0000 |
| Message-ID | <d94kdvFeq5aU21@mid.individual.net> |
| In reply to | #153328 |
On Sun, 25 Oct 2015 11:31:08 -0500, Jon Elson wrote: > Later, when minis were available, but storage peripherals often cost > more than the CPU, he built what was called the spider net. He had a > central PDP-11 that was attached to the 360 with a channel interface, > and had over a dozen serial cards in it. These were connected to > "client" PDP-11s with a single RG-78 coax cable, and sent data at 1 > mbit/second. > > So, he had a dedicated disk pack on the system, and a server program ran > all the time on the 360, waiting for a request from the PDP-11. When it > got one, it would perform the disk I/O requested and send it back over > the channel to the PDP. We did that with our ICL 4130, using a PDP-11 and a couple of RP02s. It worked well apart from one day. I'd accidentally run a program that generated a very large file, filling up the RP disk. When I deleted the file, the PDP-11 took so long deleting it that the 4130 timed out the PDP-11 and effectively crashed. -- Using UNIX since v6 (1975)... Use the BIG mirror service in the UK: http://www.mirrorservice.org
[toc] | [prev] | [next] | [standalone]
| From | Anne & Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2015-10-23 11:20 -0700 |
| Message-ID | <87y4etsayj.fsf@lhwserver.localdomain> |
| In reply to | #153252 |
Peter Flass <peter_flass@yahoo.com> writes: > it was all open-source. No need to reverse-engineer anything. As late as > MVS/XA I had a VSAM open exit where the call location had to be gleaned by > looking at the fiche and disassembling the PL/S module, although it started > out as a straightforward source update in MVS/370. > > I think JES2, or most of it, is still distributed as source, because so > many users had so many different mods. Out JES guy had tons and knew the > jes code i side and out. I've periodically mentioned that litigation resulted in 23June1969 unbundle, starting to charge for (application) software, SE services, maint., etc. ... some past posts http://www.garlic.com/~lynn/submain.html#unbundle however, the company manage to make the case that kernel (operating system) software should still be free. Somewhat because of the clone processor makers get market foothold during the FS period (because of lack of 370 products) ... some past FS posts http://www.garlic.com/~lynn/submain.html#futuresys there is a decision to transition to start charging for (new) kernel software ... there is period during the late 70s and early 80s, where parts of kernel were free and other parts were charged for ... you can see this in the hercules simulator project that has the latest "free" software. Eventually transition is made to charging for all software ... about the same time as the OCO-wars (object code only ... no longer shipping source). computerworld article from google books https://books.google.com/books?id=hSBrPSYgjI4C&pg=PT58&lpg=PT58&dq=oco-wars+ibm&source=bl&ots=yBMaklHV-x&sig=P8_h7-FSQOnbM0-TQO0OzK_UwaM&hl=en&sa=X&ved=0CD4Q6AEwBWoVChMIuqDXn5nZyAIVxDqICh1zSAWR#v=onepage&q=oco-wars%20ibm&f=false part of JES2 folklore is that they did all their source maintenance using vm370/cms (originally cp67/cms) multi-level update infrastructure ... and then had to go thru conversion to the MVS-based system for release. misc. past posts mentioning HASP, JES2, NJE, etc http://www.garlic.com/~lynn/submain.html#hasp misc. past posts mentioning OCO-wars http://www.garlic.com/~lynn/2005u.html#57 IPCS Standard Print Service http://www.garlic.com/~lynn/2006n.html#34 Not Your Dad's Mainframe: Little Iron http://www.garlic.com/~lynn/2006o.html#14 SEQUENCE NUMBERS http://www.garlic.com/~lynn/2007k.html#15 Data Areas Manuals to be dropped http://www.garlic.com/~lynn/2007m.html#15 Patents, Copyrights, Profits, Flex and Hercules http://www.garlic.com/~lynn/2007u.html#6 Open z/Architecture or Not http://www.garlic.com/~lynn/2007u.html#8 Open z/Architecture or Not http://www.garlic.com/~lynn/2008d.html#42 VM/370 Release 6 Waterloo tape (CIA MODS) http://www.garlic.com/~lynn/2009i.html#45 dynamic allocation http://www.garlic.com/~lynn/2009i.html#72 Linux versioning file system http://www.garlic.com/~lynn/2009k.html#0 Timeline: The evolution of online communities http://www.garlic.com/~lynn/2009k.html#20 If you don't have access to a mainframe http://www.garlic.com/~lynn/2009k.html#48 Timeline: 40 Years Of Unix http://www.garlic.com/~lynn/2009r.html#7 The 50th Anniversary of the Legendary IBM 1401 http://www.garlic.com/~lynn/2009r.html#49 "Portable" data centers http://www.garlic.com/~lynn/2010j.html#17 Personal use z/OS machines was Re: Multiprise 3k for personal Use? http://www.garlic.com/~lynn/2010j.html#19 Personal use z/OS machines was Re: Multiprise 3k for personal Use? http://www.garlic.com/~lynn/2010j.html#20 Personal use z/OS machines was Re: Multiprise 3k for personal Use? http://www.garlic.com/~lynn/2010j.html#22 Personal use z/OS machines was Re: Multiprise 3k for personal Use? http://www.garlic.com/~lynn/2010k.html#30 Idiotic programming style edicts http://www.garlic.com/~lynn/2010k.html#65 Idiotic programming style edicts http://www.garlic.com/~lynn/2010k.html#67 Idiotic programming style edicts http://www.garlic.com/~lynn/2010l.html#1 Honoree pedigrees http://www.garlic.com/~lynn/2010l.html#15 Age http://www.garlic.com/~lynn/2010p.html#30 Philosophy: curiousity question http://www.garlic.com/~lynn/2011b.html#87 The first personal computer (PC) http://www.garlic.com/~lynn/2011c.html#56 The real cost of outsourcing http://www.garlic.com/~lynn/2011h.html#75 pdp8 to PC- have we lost our way? http://www.garlic.com/~lynn/2011i.html#7 Do you remember back to June 23, 1969 when IBM unbundled http://www.garlic.com/~lynn/2011i.html#17 Got to remembering... the really old geeks (like me) cut their teeth on Unit Record http://www.garlic.com/~lynn/2011o.html#33 Data Areas? http://www.garlic.com/~lynn/2012.html#58 An approach to Dump formatting of Control Blocks http://www.garlic.com/~lynn/2012j.html#20 Operating System, what is it? http://www.garlic.com/~lynn/2012j.html#30 Can anybody give me a clear idea about Cloud Computing in MAINFRAME ? http://www.garlic.com/~lynn/2012j.html#31 How smart do you need to be to be really good with Assembler? http://www.garlic.com/~lynn/2012j.html#79 Slackware http://www.garlic.com/~lynn/2012k.html#62 Any cool anecdotes IBM 40yrs of VM http://www.garlic.com/~lynn/2012o.html#63 Is it possible to hack mainframe system?? http://www.garlic.com/~lynn/2013b.html#26 New HD http://www.garlic.com/~lynn/2013l.html#66 model numbers; was re: World's worst programming environment? http://www.garlic.com/~lynn/2013m.html#55 'Free Unix!': The world-changing proclamation made 30 years ago today http://www.garlic.com/~lynn/2013o.html#45 the nonsuckage of source, was MS-DOS, was Re: 'Free Unix! http://www.garlic.com/~lynn/2014.html#19 the suckage of MS-DOS, was Re: 'Free Unix! http://www.garlic.com/~lynn/2014i.html#5 "F[R]eebie" software http://www.garlic.com/~lynn/2014m.html#35 BBC News - Microsoft fixes '19-year-old' bug with emergency patch http://www.garlic.com/~lynn/2015.html#84 a bit of hope? What was old is new again http://www.garlic.com/~lynn/2015.html#85 a bit of hope? What was old is new again http://www.garlic.com/~lynn/2015b.html#19 What were the complaints of binary code programmers that not accept Assembly? http://www.garlic.com/~lynn/2015d.html#14 3033 & 3081 question http://www.garlic.com/~lynn/2015d.html#48 Western Union envisioned internet functionality http://www.garlic.com/~lynn/2015d.html#59 Western Union envisioned internet functionality http://www.garlic.com/~lynn/2015h.html#32 (External):Re: IBM -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | hancock4@bbs.cpcn.com |
|---|---|
| Date | 2015-10-23 11:45 -0700 |
| Message-ID | <2dc0e17f-e190-4fa7-9df9-a0f531ee660a@googlegroups.com> |
| In reply to | #153259 |
On Friday, October 23, 2015 at 2:20:56 PM UTC-4, Anne & Lynn Wheeler wrote: > there is a decision to transition to start charging for (new) kernel > software ... there is period during the late 70s and early 80s, where > parts of kernel were free and other parts were charged for ... you can > see this in the hercules simulator project that has the latest "free" > software. Eventually transition is made to charging for all software > ... about the same time as the OCO-wars (object code only ... no longer > shipping source). computerworld article from google books Yes, our third-party leased 360-40 had mostly free software, but some premium items. Basically, I think old stuff was free, while new stuff was a cost. Today, I believe C/A owns most products and charges a fortune for them, even if they are functionally stablized. Many companies have to pay for them because they have some legacy application still using them (e.g. a 4GL), and the cost of conversion would be too high. It would seem to me that C/A owning much of the mainframe utility software would be seen as monopoly, but apparently not.
[toc] | [prev] | [next] | [standalone]
| From | Jon Elson <elson@pico-systems.com> |
|---|---|
| Date | 2015-10-24 21:11 -0500 |
| Message-ID | <0c6dnSNsV87bp7HLnZ2dnUU7-WmdnZ2d@giganews.com> |
| In reply to | #153248 |
Osmium wrote: > "Jon Elson" wrote: > >> Roberto Waltman wrote: >> >>> Jon Elson wrote: >>> >>>>... The number of bugs in OS/360 were legendary, and they NEVER stamped >>>>them all out. >>> >>> I recall reading somewhere that the number of bugs was more or less a >>> constant, with each new OS release introducing as many new bugs as >>> fixes for old ones. >> Yes, trying to maintain a huge piece of software, with thousands of >> separately assembled routines, some linked to the "kernel" and a bunch >> called in as needed, after it has been in use for MANY years, and hacked >> on >> by hundreds or thousands of programmers, seems REALLY daunting. The >> number >> of unintended interactions seems vast. > > If they did, in fact, accommodate the hackers, it was a failure of > management. They should have provided a written interface when they > released the OS to the wild and made it clear that *this* *is* the > interface. Not some fascinating stuff that multiple someones had gleaned > by reverse engineering or whatever. OS/360 was an "open" OS, meaning that anyone who was legally running it had the source code. And, every significant installation felt compelled to tinker with stuff, customizing, or in some cases fixing IBM's bugs. These were not "hackers", meaning outsiders, these were the system support staff at any place that had such a group. They got hundreds of update and patches (PTFs or Program Temporary Fixes) a month, and could decide whether to install each one or let it ride. Many local fixes were submitted back to IBM, and would be reviewed by their support people and often were incorporated into fixes they later released. Jon
[toc] | [prev] | [next] | [standalone]
| From | hancock4@bbs.cpcn.com |
|---|---|
| Date | 2015-10-27 07:40 -0700 |
| Message-ID | <80d5c94e-13ec-4e05-9724-fa67c2993f26@googlegroups.com> |
| In reply to | #153311 |
On Saturday, October 24, 2015 at 10:11:20 PM UTC-4, Jon Elson wrote: > OS/360 was an "open" OS, meaning that anyone who was legally running it had > the source code. And, every significant installation felt compelled to > tinker with stuff, customizing, or in some cases fixing IBM's bugs. These > were not "hackers", meaning outsiders, these were the system support staff > at any place that had such a group. They got hundreds of update and patches > (PTFs or Program Temporary Fixes) a month, and could decide whether to > install each one or let it ride. Keeping PTFs applied and up to date was a busy task for system programmers at a large installation. They had to be reviewed to see if the contents were relevant to the particular installation. Sometimes they had to be loaded when the machine was idle and then re-IPL'd. They had to be carefully tracked and loaded in the proper order. When I worked with a Univac 90/30, they would send us PTF's on _paper_. That is, we had to keypunch a bunch of hex characters from the document, and naturally it had to be 100% accurate. Imagine keypunching several rows of the following: E2D6C3D240C9E340E3D640D4C540E2D6C3D240C9E340E3D640D4C540
[toc] | [prev] | [next] | [standalone]
| From | Anne & Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2015-10-27 08:30 -0700 |
| Message-ID | <87r3kgfhxa.fsf@lhwserver.localdomain> |
| In reply to | #153378 |
hancock4@bbs.cpcn.com writes: > Keeping PTFs applied and up to date was a busy task for system > programmers at a large installation. They had to be reviewed to see > if the contents were relevant to the particular installation. > Sometimes they had to be loaded when the machine was idle and then > re-IPL'd. They had to be carefully tracked and loaded in the proper > order. also regression tests ... PTFs could introduce failures &/or incompatibilities ... like "fixes" for JCL that had side-effect that would result in production jobs to stop running. -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | Anne & Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2015-10-27 09:11 -0700 |
| Message-ID | <87mvv4ffzu.fsf@lhwserver.localdomain> |
| In reply to | #153380 |
Anne & Lynn Wheeler <lynn@garlic.com> writes: > also regression tests ... PTFs could introduce failures &/or > incompatibilities ... like "fixes" for JCL that had side-effect that > would result in production jobs to stop running. another side-effect ... over time, PTFs could significantly degrade the performance of my system. When I did sysgen, I tore apart sysgen2 output of sysgen1 and re-organized lots of the sequence to carefully place files and PDS library members on disk to optimize arm seek motion (& PDS multi-track search member lookup) ... which got nearly 3 times throughput improvement on fortgclg student jobs. PTFs would typically "replace" one or more PDS library members. "Replace" is something of misnomer ... it would insert new member at the end of the library and null out the member being replaced ... destroying careful physical ordering on disk. After six months of PTFs, my carefully generated system could loose half or more of the performance optimization (enough PTFs might also use up max. space that had been pre-allocated for library file). old post with part of 60s SHARE presentation I made on system optimization that I did as undergraduate. Most of it is about significant rewrites of (virtual machine) cp67 system code to cut simulation pathlengths ... benchmarking os/360 fortgclg in virtual machine. Part of the post also discusses the optimizations that I did for os/360. http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14 recent posts mentioning fortran http://www.garlic.com/~lynn/2015h.html#21 the legacy of Seymour Cray http://www.garlic.com/~lynn/2015h.html#35 high level language idea -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | Dan Espen <despen@verizon.net> |
|---|---|
| Date | 2015-10-27 12:52 -0400 |
| Message-ID | <n0oa0t$4vo$1@dont-email.me> |
| In reply to | #153383 |
Anne & Lynn Wheeler <lynn@garlic.com> writes: > Anne & Lynn Wheeler <lynn@garlic.com> writes: >> also regression tests ... PTFs could introduce failures &/or >> incompatibilities ... like "fixes" for JCL that had side-effect that >> would result in production jobs to stop running. > > another side-effect ... over time, PTFs could significantly degrade the > performance of my system. > > When I did sysgen, I tore apart sysgen2 output of sysgen1 and > re-organized lots of the sequence to carefully place files and PDS > library members on disk to optimize arm seek motion (& PDS multi-track > search member lookup) ... which got nearly 3 times throughput > improvement on fortgclg student jobs. I assume you did this optimization of arm movement manually. Too bad you didn't automate the process into something you could pass on to customers. I'm thinking: 1. Turn on a monitor that watches arm movement into files 2. run a re-org that places key files accordingly. With solid state and striping seemingly taking over the usefulness of this kind of thing is diminishing rapidly. -- Dan Espen
[toc] | [prev] | [next] | [standalone]
| From | hancock4@bbs.cpcn.com |
|---|---|
| Date | 2015-10-27 10:22 -0700 |
| Message-ID | <6123c033-1d82-479c-8f1a-85e575784187@googlegroups.com> |
| In reply to | #153384 |
On Tuesday, October 27, 2015 at 12:52:49 PM UTC-4, D_J_E wrote: > 1. Turn on a monitor that watches arm movement into files > 2. run a re-org that places key files accordingly. On our Univac 90/30, we had 3330-type disk drives, with an open glass top so we could see the disk arm action. As a small installation, we didn't spend much time on optimization. Sometimes we would run a job where the input and output file would reside on the same disk pack. During processing, the head would violently go back and forth, and the disk drive would shake like a washing machine. Properly placing such files saved a lot of wall clock time. One big challenge with the 90/30 was that it mostly worked like an IBM computer, but our Univac support people were used to Univac style machines, and certain techniques--ok on a Univac--would be very slow on IBM or not work at all. Our manager would bring in programs and expect them to run fine, and not understand why they didn't run at all.
[toc] | [prev] | [next] | [standalone]
| From | Dan Espen <despen@verizon.net> |
|---|---|
| Date | 2015-10-27 14:37 -0400 |
| Message-ID | <n0og4e$tud$2@dont-email.me> |
| In reply to | #153387 |
hancock4@bbs.cpcn.com writes: > On Tuesday, October 27, 2015 at 12:52:49 PM UTC-4, D_J_E wrote: > >> 1. Turn on a monitor that watches arm movement into files >> 2. run a re-org that places key files accordingly. > > On our Univac 90/30, we had 3330-type disk drives, with an open glass > top so we could see the disk arm action. As a small installation, we > didn't spend much time on optimization. Sometimes we would run a job > where the input and output file would reside on the same disk pack. > During processing, the head would violently go back and forth, and the > disk drive would shake like a washing machine. For cases where drives are limited, that's a perfect case for split cylinder. The only case where I actually used split cylinder was on a 2 drive 1440. Of course that was years before IBM invented split cylinder. > Properly placing such files saved a lot of wall clock time. > > One big challenge with the 90/30 was that it mostly worked like an IBM > computer, but our Univac support people were used to Univac style > machines, and certain techniques--ok on a Univac--would be very slow > on IBM or not work at all. Our manager would bring in programs and > expect them to run fine, and not understand why they didn't run at > all. To this day we have "issues" running Univac designed code on our z/OS machine. Seems like a Univac could load small load modules a lot faster than an IBM mainframe. When we run the Univac designed stuff, the z/OS machine spends a large portion of it's time adjusting (AKA swizzling) address constants in loaded modules. -- Dan Espen
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2015-10-27 19:55 +0000 |
| Message-ID | <n0oksb17sl@news3.newsguy.com> |
| In reply to | #153387 |
On 2015-10-27, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote: > On our Univac 90/30, we had 3330-type disk drives, with an open > glass top so we could see the disk arm action. You lucky soul. There was only one installation in Vancouer that had 8430/8433 drives. The machines I worked on started out with 8416s which had the glass top, but these were all replaced by 8418s (a double-density version), which had an opaque top that incorporated an air duct into the spindle; we could no longer see the heads move. Fortunately I discovered that if you set one of the display rollers properly, the front panel LEDs would show information from the IDA (integrated disk adapter) to which 8418s were attached: specifically, the currently-accessed drive and the length of the current seek. > As a small installation, we didn't spend much time on optimization. > Sometimes we would run a job where the input and output file would > reside on the same disk pack. During processing, the head would > violently go back and forth, and the disk drive would shake like > a washing machine. > > Properly placing such files saved a lot of wall clock time. Yup. My basic rule for large files was to try never to put an input and an output file on the same drive. Most systems I worked on had 4 drives, so this was usually not difficult. -- /~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs) \ / I'm really at ac.dekanfrus if you read it the right way. X Top-posted messages will probably be ignored. See RFC1855. / \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
[toc] | [prev] | [next] | [standalone]
| From | hancock4@bbs.cpcn.com |
|---|---|
| Date | 2015-10-27 17:46 -0700 |
| Message-ID | <a0395158-69ed-4ea8-adf8-b641e3e58fbd@googlegroups.com> |
| In reply to | #153394 |
On Tuesday, October 27, 2015 at 3:56:25 PM UTC-4, Charlie Gibbs wrote: > Yup. My basic rule for large files was to try never to put an > input and an output file on the same drive. Most systems I worked > on had 4 drives, so this was usually not difficult. Actually, I'm trying to remember how many disk drives we had--it may have been only one. Back then, 100 meg was a lot of space and we were a small outfit. The operating system for the 90/30 would allow up to five jobs running at once. But I discovered CPU and disk contention effectively limited us to one job at a time. It would actually take longer to run two jobs side by side rather than serially. (One good thing about being small was that I could get the machine to myself and experiment.)
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2015-10-28 01:22 +0000 |
| Message-ID | <n0p7vr02cpd@news7.newsguy.com> |
| In reply to | #153417 |
On 2015-10-28, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote: > On Tuesday, October 27, 2015 at 3:56:25 PM UTC-4, Charlie Gibbs wrote: > >> Yup. My basic rule for large files was to try never to put an >> input and an output file on the same drive. Most systems I worked >> on had 4 drives, so this was usually not difficult. > > Actually, I'm trying to remember how many disk drives we had--it may > have been only one. Back then, 100 meg was a lot of space and we were > a small outfit. I never heard of a system with less than two drives. It just wouldn't be worth it. How would you do backups? (Many systems I worked on didn't have tape.) > The operating system for the 90/30 would allow up to five jobs running > at once. But I discovered CPU and disk contention effectively limited > us to one job at a time. It would actually take longer to run two jobs > side by side rather than serially. (One good thing about being small > was that I could get the machine to myself and experiment.) The number of jobs was a sysgen option - you could configure as many as seven job slots (at least in later versions of OS/3). Some cheapskates would configure only three slots, but the job slot tables were too small for this to justify limiting yourself that way. In my experience, three concurrent jobs would hit the point of diminishing returns, although this would vary according to how I/O-bound you were, how well you could spread files across drives, and how much memory you had. (Most systems I worked on had 192K; some people would try to cheap out - with the encouragement of low-balling salesmen - and wound up with 128K, which put them in a world of hurt.) One irritating quirk of OS/3 was that it didn't time-slice jobs of equal priority. If you ran a CPU-bound job against an I/O-bound one (or your program went into a loop), the I/O-bound job would grind to a halt. You could adjust priorities from the console to get both jobs running smoothly, or specify priorities in JCL. This latter option became much more practical in a later relase which let you specify a default priority other than the lowest, which meant that you could lower the priority of CPU-bound jobs, rather than having to modify the JCL for every other job in the shop to increase their programs' priority. I suppose that in a commercial environment, where most jobs were I/O-bound, this wasn't as bad a crime as it would be in a scientific shop, but still, it was a pain. I remember trying to copy a disk file to a tape in a shop that was running a CPU-bound payroll program. Now I know payroll is very important, but these guys went right over the top, doing things like cranking the priority up as high as it would go even though it didn't make the job run any faster. What it did do was make my tape dump come to a halt, even though it used neglegible CPU. When nobody was looking, I'd re-adjust the priorities - the payroll job's tape drive would still write its usual block every 5 seconds (I said it was CPU-bound), while my tape drive would run full bore. Naturally, once the staff came back and saw this, they immediately reshuffled the priorities so my job stopped. Grrr... -- /~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs) \ / I'm really at ac.dekanfrus if you read it the right way. X Top-posted messages will probably be ignored. See RFC1855. / \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
[toc] | [prev] | [next] | [standalone]
| From | jmfbahciv <See.above@aol.com> |
|---|---|
| Date | 2015-10-28 12:58 +0000 |
| Message-ID | <PM00052329FEF97EA9@aca4145e.ipt.aol.com> |
| In reply to | #153423 |
Charlie Gibbs wrote: > On 2015-10-28, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote: > >> On Tuesday, October 27, 2015 at 3:56:25 PM UTC-4, Charlie Gibbs wrote: >> >>> Yup. My basic rule for large files was to try never to put an >>> input and an output file on the same drive. Most systems I worked >>> on had 4 drives, so this was usually not difficult. >> >> Actually, I'm trying to remember how many disk drives we had--it may >> have been only one. Back then, 100 meg was a lot of space and we were >> a small outfit. > > I never heard of a system with less than two drives. It just wouldn't > be worth it. How would you do backups? (Many systems I worked on > didn't have tape.) <snip> Many PDP-8 and PDP-11 systems had just one disk drive. I suspect someone bought a KL with just the front end disk drive. ISTR a story about a customer bitching they had to buy the disk drive. /BAH
[toc] | [prev] | [next] | [standalone]
| From | "gareth" <no.spam@thank.you.invalid> |
|---|---|
| Date | 2015-10-28 13:59 +0000 |
| Message-ID | <n0qk7a$587$1@dont-email.me> |
| In reply to | #153436 |
"jmfbahciv" <See.above@aol.com> wrote in message news:PM00052329FEF97EA9@aca4145e.ipt.aol.com... > Charlie Gibbs wrote: >> On 2015-10-28, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote: >> >>> On Tuesday, October 27, 2015 at 3:56:25 PM UTC-4, Charlie Gibbs wrote: >>> >>>> Yup. My basic rule for large files was to try never to put an >>>> input and an output file on the same drive. Most systems I worked >>>> on had 4 drives, so this was usually not difficult. >>> >>> Actually, I'm trying to remember how many disk drives we had--it may >>> have been only one. Back then, 100 meg was a lot of space and we were >>> a small outfit. >> >> I never heard of a system with less than two drives. It just wouldn't >> be worth it. How would you do backups? (Many systems I worked on >> didn't have tape.) > > <snip> > > Many PDP-8 and PDP-11 systems had just one disk drive. I suspect > someone bought a KL with just the front end disk drive. ISTR a story > about a customer bitching they had to buy the disk drive. The embedded PDP-11 systems that I worked on in the late 1970s didn't have any disk drives, just a paper tape reader & punch.
[toc] | [prev] | [next] | [standalone]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | alt.folklore.computers
csiph-web