Re: OT: How much does software weigh? (was:What's a "ton" of JCL?)
On 12/04/2015 09:04 AM, Paul Gilmartin wrote: > On Fri, 4 Dec 2015 08:00:52 +, Vernooij, CP (ITOPT1) - KLM wrote: > >> 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.' >> > Decades ago, I was assigned to assist a scientist's converting his operation > to a central computer. One of the first questions he asked me was, > "How long can the computer remember a number?" > > -- gil > > ... > Maybe not what the scientist meant, but actually not an unreasonable question. It depends on where the number in stored. If you never bother to write it to external storage and just keep in in volatile memory, then it is only kept until some program deletes it or overwrites it or a power-down occurs. If you write it to external storage, it depends on the associated retention period of the data set containing it. It could be set for indefinite retention, or in other cases set for auto-deletion based on an event, elapsed time, or time since last referenced. With older mainframes, some external media, and some PC platforms, mean-time-between-failure was significant as well. I do wonder if Einstein's relation between mass and energy means that theoretically a computer might have some minuscule difference in mass depending on the energy states of its internal components, If so, obviously not enough difference to be significant in the real world, but that could mean that in theory a computer might have a very slight variance in mass depending on what software was executing. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT: How much does software weigh? (was:What's a "ton" of JCL?)
On Fri, 4 Dec 2015 08:00:52 +, Vernooij, CP (ITOPT1) - KLM wrote: >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.' > Decades ago, I was assigned to assist a scientist's converting his operation to a central computer. One of the first questions he asked me was, "How long can the computer remember a number?" -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT: How much does software weigh? (was:What's a "ton" of JCL?)
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 di
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
