Joel:
Finding quality operators in the first place is always an issue.
Having said that the nightmare of telling the difference between job
AAAA and job AAAA is not easy and is just fraught with possibility of
error and frankly in a shop where hundred (if not thousands) of jobs
come in and out of a system in a shift is just too easy to make a
mistake in any given minute. Even if you have iron rules on jobnames
it is almost impossible to determine what is what adding duplicate
jobnames to the mix makes errors bound to happen.
Ed
Ed
On May 2, 2013, at 9:42 AM, Joel C. Ewing wrote:
Ah, the dubious "joys" of working in an environment where quality
control consists of firing the one who appears to have committed an
error, rather than analyzing the problem and eliminating the root-
cause factors that could lead to the same error being repeated by
someone else in the future. I likely wouldn't have stayed at the
same place for 32+ years if they hadn't had a better approach to
quality control.
If it is too difficult to train your operators (or any employee) to
perform a process with 100% reliability, then it is the process
that needs to be examined and changed, not the operator. Having
multiple things in the same system with the same name when you care
to treat them differently is an obvious process-design no-no.
I can recall an analogous process-design error at the hardware
level, where IBM had both 120V and 240V versions of the 3174
controller with a detachable power cord, no distinction in the cord
connectors at the controller end between the 120V- and 240V-cords,
and we somehow ended up with a mix of 120V and 240V 3174
controllers. The individual who smoked and did expensive damage to
a 120V controller hooking it to 240V during a minor equipment
shuffle was judged to be the victim of an error waiting to happen
(and continued to be a valued employee).
Joel C. Ewing
On 05/02/2013 12:03 AM, Ed Gould wrote:
DASDBILL2:
Yes I know about the option. My question is why would anyone want
to have it allowed.
Trying to resolve operator problems would be a nightmare.
How can a operator figure out which job to cancel?
As a follow on say operator cancels job aaaaaa and aaaaa is an
online system . The "other " job aaaaaaa was a was data base restore.
Both would be grounds for firing in a shop where I worked.
Ed
On May 1, 2013, at 2:20 PM, DASDBILL2 wrote:
Ed,
Duplicate jobnames are allowed or not allowed at the discretion
of the customer. There is now a parameter to allow duplicate
jobnames' running simultaneously. Those shops that do not want
havoc can opt not to use the new parameter. All shops are not
identical.
Bill Fairchild
Franklin, TN
----- Original Message -----
From: "Ed Gould" <edgould1...@comcast.net>
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, May 1, 2013 10:24:03 AM
Subject: Re: Check whether job still running
Ed:
I am somewhat surprised that you indicate that duplicate jobnames
are
to be allowed. I have worked in a few shops that job naming stand is
frozen and it would wreek havoc if a duplicate jobname were to be
allowed running at the same time.
Ed
On May 1, 2013, at 12:07 AM, Ed Jaffe wrote:
On 4/30/2013 8:25 PM, Robert A. Rosenberg wrote:
If you can live with JOB1 and JOB2 having the same jobname and you
use JES2, that will handle the wait since JES2 will not allow JOB2
to be initiated so long as JOB1 is executing.
This is true only with JOBDEF DUPL_JOB=DELAY. More and more JES2
shops these days are implementing JOBDEF DUPL_JOB=NODELAY to
provide function similar to JES3 DUPJOBNM=YES functionality.
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/
--
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
