McKown, John wrote:
-----Original Message-----
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Wayne Driscoll
Sent: Friday, December 01, 2006 5:50 PM
To: [email protected]
Subject: Re: Cancelling a job/tso user in a 100% CPU situation.
The problem comes in if the job that is being cancelled has
control of a
resource that is required for a higher importance job to run.
Wayne Driscoll
Yes, in fact, the test job had an PDSE latch or something and had "hung
up" access to a PDSE library. There was no CPU to available to
effectuate the CANCEL. And the TSO environment was that the programmer
"did a stupid" and did a batch-like function in TSO. This works most of
the time, but at month-end it is a known way to take 1/2 day off waiting
for a response. And, no, I'm not upping 3rd period TSO to be better than
production batch. The programmers should "know better", but they, like
all of us, get in a hurry and want a "quick and dirty" which turns into
a "very slow, but filthy" way.
And so your refusal to "up 3rd period TSO" helps how? Is
this the politically wisest approach? [Note: I don't
know the answers in your situation; but I do know that
mainframers (myself included) are often accused of being
stubborn when being helpful might be a better approach.]
Kind regards,
-Steve Comstock
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
