Re: OT: What's a "ton" of JCL?
I have never written any JCL on the boxes, just labels and notes.
/Tom Kern
On 12/04/2015 00:33, Ted MacNEIL wrote:
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 IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT: What's a "ton" of JCL?
Haven't you seen the WORD "JCL" on card boxes I have:)
Ed
On Dec 4, 2015, at 6:48 PM, Thomas Kern wrote:
I have never written any JCL on the boxes, just labels and notes.
/Tom Kern
On 12/04/2015 00:33, Ted MacNEIL wrote:
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 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
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
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
