In a message dated 3/29/2007 3:45:39 P.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
>Some jobs are real problems.
Which is, or was long ago, a very good reason to define and rigorously
enforce job classes. I worked on a massive local mod to JES2 in 1977 that
determined many resour
Some jobs are real problems. For instance, we had one that required six
tape drives (out of eight), and lots of work space. We had a special
class, without a matching initiator, and required the jobs for that
class to be scheduled by Operations. Just
On 28 Mar 2007 13:30:53 -0700, in bit.listserv.ibm-main you wrote:
>> -Original Message-
>> From: IBM Mainframe Discussion List
>> [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL
>> Sent: Wednesday, March 28, 2007 4:15 PM
>> To: IBM-MAIN@BAMA.UA
On 29 Mar 2007 10:41:40 -0700, [EMAIL PROTECTED] (Shmuel
Metz , Seymour J.) wrote:
>>If people are doing that, then your charge back policies should be
>>reviewed. NOT, what the user is doing to get their job done.
>
>The users' jobs include following company policies.
That is correct.But as
In a recent note, "(IBM Mainframe Discussion List)" said:
> Date: Wed, 28 Mar 2007 15:41:14 EDT
>
> charge-back policy is in effect. I heard long ago about a user who was
> printing free
> copies of a large document by submitting the document as comment statements
> with a deliberate JCL erro
Clark Morris wrote:
Why verify and fail when the system can just make it what it should be
this week? How is productivity helped.
Some jobs are real problems. For instance, we had one that
required six tape drives (out of eight), and lots of work space.
We had a special class, without a ma
>Just submit a job and be done with it.
Can we have an AMEN, brothers and sisters?
-
Too busy driving to stop for gas!
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the
>I can hijack a C initiator to get my work done and to with the other
>programmers!", shouldn't I, as the system administrator, make sure
that the programmer doesn't get away with it?
We are talking a matter of degree.
If one programmer/user is doing it, fine, remediation includes everything up
On Wed, 28 Mar 2007 21:10:20 +, Ted MacNEIL <[EMAIL PROTECTED]> wrote:
>
>But, in all cases nobody was required to specify job classes when we were done.
>And, if they did, they were ignored -- T/M set the class.
>
That's the way it should be done. We run TM on some LPARs and (unfortunately)
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL
> Sent: Wednesday, March 28, 2007 4:15 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Job class enforcement was Re: IEFC603I PROCLIB
> DEVIC
In a message dated 3/28/2007 3:14:21 P.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
>If you have draconian policies, users will perform unusual acts to get
around it.
Too true. And the policies don't even have to be draconian. This is normal
human behavior. As many lawyers know,
>> One reason - the job's submitter may be trying to run his work at
> lower cost
> than the correct job class would cost, assuming a job-class-based
> charge-back policy is in effect.
If people are doing that, then your charge back policies should be reviewed.
NOT, what the user is doing to ge
>Why verify and fail when the system can just make it what it should be this
>week? How is productivity helped.
I wish I had ThruPut Mangler, again!
I've used it at three different instances of my career, and at all three we
went from over 30 jobclasses to less than 10.
One down to four.
Produc
On Mar 28, 2007, at 2:41 PM, (IBM Mainframe Discussion List) wrote:
In a message dated 3/28/2007 2:29:46 P.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
Why verify and fail when the system can just make it what it
should be this
week? How is productivity helped.
One reason - the job
In a message dated 3/28/2007 2:29:46 P.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
>Why verify and fail when the system can just make it what it should be this
week? How is productivity helped.
One reason - the job's submitter may be trying to run his work at lower cost
than the
On 28 Mar 2007 11:47:22 -0700, in bit.listserv.ibm-main you wrote:
>Clark Morris wrote:
>> As someone who modified an exit 6 from the CBT tape that set job class
>> based on job requirements to meet my shop's needs, I obviously
>> disagree vehemently. Job class is a means of assigning work. If t
Clark Morris wrote:
As someone who modified an exit 6 from the CBT tape that set job class
based on job requirements to meet my shop's needs, I obviously
disagree vehemently. Job class is a means of assigning work. If the
job class is based on job requirements known at JCL interpretation,
then
In a recent note, Clark Morris said:
> Date: Wed, 28 Mar 2007 10:15:06 -0300
>
> As someone who modified an exit 6 from the CBT tape that set job class
> based on job requirements to meet my shop's needs, I obviously
> disagree vehemently. Job class is a means of assigning work. If the
> job cl
On 28 Mar 2007 04:21:06 -0700, in bit.listserv.ibm-main you wrote:
>In <[EMAIL PROTECTED]>, on 03/24/2007
> at 10:43 AM, Clark Morris <[EMAIL PROTECTED]> said:
>
>>This may relate to the user-surly approach of a lot of mainframe
>>implementation. People should know enough not submit a job / sta
19 matches
Mail list logo
