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
