I know that story. Since it's Friday, here's another: A reporter asked Alan Sheppard what he was thinking about as he blasted off.
Response: Every part in here was built by the lowest bidder. Scary! - -teD - Original Message From: Vernooij, CP (ITOPT1) - KLM Sent: Friday, December 4, 2015 03:01 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: OT: How much does software weigh? (was:What's a "ton" of JCL?) That's what NASA asked their programmers when designing the Apollo's. They answered: 'Nothing.'. 'Really, we can hardly believe this.'. 'It is true, we only use the holes in the punchcards.' Kees. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ted MacNEIL Sent: 04 December, 2015 6:33 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: OT: What's a "ton" of JCL? Is that counting the weight of the boxes themselves? - -teD - Original Message From: Thomas Kern Sent: Friday, December 4, 2015 00:14 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: OT: What's a "ton" of JCL? Approximately 274905 cards. 2000 cards per box is about 14.55 lbs. 137.45 boxes per ton(2000lbs) It is Friday now. /Tom Kern On 12/03/2015 22:40, Joel C. Ewing wrote: > On 12/03/2015 12:16 PM, Paul Gilmartin wrote: >> On Thu, 3 Dec 2015 10:43:38 -0600, Joel C. Ewing wrote: >>> ... Because DOS/VS had native support for source and object >>> libraries, those were kept online, but there was no decent native >>> support to effectively submit production job JCL from libraries ... >>> >> Astonishing. You could RYO editor but not RYO "SUBMIT". > OLE' was envisioned and implemented by one person, James Stevens, the > head of Tech Services at a time when it was a one or two man operation > (I raised the body count to 3) -- he probably created OLE' as late night > entertainment for his own convenience and benefit to make development of > his Mini-Task on-line environment and other utilities less tedious. It > went company-wide since it significantly improved the efficiency of 40+ > programmers versus fiddling with individual cards in a deck. JCL didn't > get changed as much and Operator's time was considered less valuable; > and since they only picked up the entire job deck and moved it around > as a unit it wasn't that obvious that a significant amount of time would > be saved by avoiding the use of decks for production JCL. > > OLE' did have the ability to submit jobs to DOS, but the interactive > OLE' work areas assigned to individual users were each a pre-defined > number of "pages" of 24 80-byte records and the total size of all areas > was constrained by the capacity of a 3330. With those space constraints, > the normal practice was to keep in one's OLE' area(s) only data actively > being edited along with some shorter job streams used for testing and > development. It would have been possible to submit a short batch job > from OLE' to extract a production job stream from a source library and > load it into part of the an OLE' area (as was done for source code > editing), wait for that job to run, and then submit the production job > from OLE'; but by the time an Operator had done that they could have > already loaded a physical deck. There just didn't seem to be enough > cost-benefit to justify converting JCL from cards to DASD until MVS > changed the equation. >>> ... and the >>> company was averse to spending on "unneeded" additional software, so >>> production JCL was created in OLE' but punched and kept on cards for use >>> by Operations. >>> >> The supplies must have been cheap. > My impression was that the volume of new cards was low enough to be a > trivial cost compared to the cost of printer paper, and I never saw a > card filing cabinet wear out. Maintenance on the card reader/punch > became more of a nuisance and issue after the units aged at least a > decade, but the cost of that was a minor part of the hardware > maintenance contract. >>> When we started DOS/VSE to MVS/XA migration in 1985, we were already >>> running the maximum of four, shared-SPOOL DOS/VSE systems under VM ... >>> >> Was that limit imposed by VM or by the DOS/VSE shared spool? I'd >> suspect the latter. >> >> -- gil >> > Definitely was not a VM limitation. DOS/VSE had a shared "lock" file to > coordinate library and other inter-system sharing and that file could be > shared by a maximum of four systems (and with four systems one did at > times see performance problems with that drive). I can't remember at > this point whether the SPOOLER ("POWER"), was limited to four systems > for shared spool because it depended on the "lock" file or whether it > had its own internal design limits as well. > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ******************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ******************************************************** ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
