Hello,
In one of our education system. We find Same Job being Submitted Multiple
Times(8 Times). Apology for my ignorance, Are there any way to restrict the
Duplicate Job Submission when Original One is in Running State ?
Any Suggestions Or help is much Appreciated.
/Jake
-
@LISTSERV.UA.EDU
Subject: Duplicate Batch Job
Hello,
In one of our education system. We find Same Job being Submitted Multiple
Times(8 Times). Apology for my ignorance, Are there any way to restrict the
Duplicate Job Submission when Original One is in Running State ?
Any Suggestions Or help is
Jake anderson wrote:
>In one of our education system. We find Same Job being Submitted Multiple
>Times(8 Times).
What is submitting it? Automation? User themselves? Extra step which place
something in JESx Internal Reader?
>Are there any way to restrict the Duplicate Job Submission when Ori
t; Are the jobs running concurrently or just waiting execution?
>
> Lizette
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jake anderson
> Sent: Tuesday, May 07, 2013 1:36 AM
> To: IBM-MAIN@LIST
: Duplicate Batch Job
Hello Lizette,
We are at Z/OS 1.8. The first Job is in Execution status(Active) and the
other Same Job too in Execution but they are waiting for the Execution.
/Jake
On Tue, May 7, 2013 at 2:24 PM, Lizette Koehler
wrote:
> Jake,
>
> What level of z/OS and JES are yo
are JES3 I am not sure what might work.
Lizette
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Lizette Koehler
Sent: Tuesday, May 07, 2013 1:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Duplicate Batch Job
Jake,
What level of z/OS
job waiting for
> execution?
>
> Regards,
> Kees.
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jake anderson
> Sent: Tuesday, May 07, 2013 11:00
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re
Jake anderson wrote:
>The problem is that same Job is submitted multiple times
But WHAT is submitting it? You must look at the ORIGEN of the job(s) and fix it
there.
>and which Leads to unavailability of Initiator to other Genuine Jobs.
As I have said previously, just use TYPRUN=HOLD. That wi
Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jake anderson
Sent: Tuesday, May 07, 2013 2:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Duplicate Batch Job
Hello,
The problem is that same Job is submitted multiple times and which Leads to
unavailability of Initiator to other
, May 07, 2013 2:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Duplicate Batch Job
So you have only one class defined in one INIT and it is active. You have 2
jobs come into the system with different names. Job 1 runs in this init for
(example) 5 hours. It is a test job. Then Job 2 comes in and
May 07, 2013 2:14 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Duplicate Batch Job
>
> So you have only one class defined in one INIT and it is active. You have
> 2
> jobs come into the system with different names. Job 1 runs in this init
> for
> (example) 5 hours. It is
Lizette Koehler wrote:
> And JES2
The OP has JES2.
>You would make sure any TEST job uses CLASS A, and Production would only use
>CLASS B. that way you can restrict how much of Class A or Class B runs at a
>particular time in the day.
Good idea. If the OP upgrades from unsupported v1.8 to r
W dniu 2013-05-07 11:21, Elardus Engelbrecht pisze:
Lizette Koehler wrote:
And JES2
The OP has JES2.
You would make sure any TEST job uses CLASS A, and Production would
only use CLASS B. that way you can restrict how much of Class A or
Class B runs at a particular time in the day.
Good i
Radoslaw Skorupka pisze:
>> I can't wait for v2.1. My users are competing all the way grabbing all those
>> inits the full 24 hours. ;-)
>Well, I have some exit (IEFUJI) which provides additional (MISSING!) security
>check.
I'm aware of that, but I'm using IEFUJI for accounting purposes. I ch
2013 14:35:49
To:
Reply-To: IBM Mainframe Discussion List
Subject: Re: Duplicate Batch Job
Hello,
The problem is that same Job is submitted multiple times and which Leads to
unavailability of Initiator to other Genuine Jobs.
Lizette,
We are having JES2.
/Jake
On Tue, May 7, 2013 at 2
>As I have said previously, just use TYPRUN=HOLD. That will solve your problem.
How since only one initiator is in use?
-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL
--
For IBM-MAIN subscribe / signoff / archive access in
Ted MacNEIL wrote:
>>As I have said previously, just use TYPRUN=HOLD. That will solve your problem.
>How since only one initiator is in use?
Whether he has one or many inits, he still have the problem that one job is
running and others with the same name are waiting.
But I agree, if he has onl
On 5/7/2013 5:02 AM, Lizette Koehler wrote:
The only way I can think of restricting is an exit in JES2. Or if this is a
TSO User you may wish to look at IKJEFT10 exit.
You'd be surprised how many "secure" installations permit a TSO user to
allocate an internal reader and write a job to it.
On Tue, 7 May 2013 13:34:07 -0400, Gerhard Postpischil wrote:
>On 5/7/2013 5:02 AM, Lizette Koehler wrote:
>> The only way I can think of restricting is an exit in JES2. Or if this is a
>> TSO User you may wish to look at IKJEFT10 exit.
>
>You'd be surprised how many "secure" installations permit
Consultant.
-Original Message-
From: Gerhard Postpischil
To: IBM-MAIN
Sent: Tue, May 7, 2013 10:34 am
Subject: Re: Duplicate Batch Job
On 5/7/2013 5:02 AM, Lizette Koehler wrote:
The only way I can think of restricting is an exit in JES2. Or if this is a
TSO User you may wish to
Yeah, we had a bright VMer said he could run circles around ISPF with XEDIT
macros. Well maybe after six thousand job submissions. Had to retool him
pretty good
In a message dated 5/7/2013 12:49:40 P.M. Central Daylight Time,
paulgboul...@aim.com writes:
Why is that a problem?
Cont
On Tue, 7 May 2013 17:50:32 -0400, Ed Finnell wrote:
>Yeah, we had a bright VMer said he could run circles around ISPF with XEDIT
> macros. Well maybe after six thousand job submissions. Had to retool him
>pretty good
>
How was he submitting the jobs? NJE? FTP? Other (specify)?
But are yo
RJE-VM guest to JES3 spool. SPF was pretty primitive back then and some
pretty convoluted CLISTs were written at application level.
In a message dated 5/7/2013 5:29:29 P.M. Central Daylight Time,
paulgboul...@aim.com writes:
How was he submitting the jobs? NJE? FTP? Other (specify)?
On Tue, 7 May 2013 12:49:32 -0500, Paul Gilmartin wrote:
>On Tue, 7 May 2013 13:34:07 -0400, Gerhard Postpischil wrote:
>
>>On 5/7/2013 5:02 AM, Lizette Koehler wrote:
>>> The only way I can think of restricting is an exit in JES2. Or if this is a
>>> TSO User you may wish to look at IKJEFT10 ex
Message -
From: "Walt Farrell"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, May 8, 2013 7:37:40 AM
Subject: Re: Duplicate Batch Job
On Tue, 7 May 2013 12:49:32 -0500, Paul Gilmartin wrote:
>On Tue, 7 May 2013 13:34:07 -0400, Gerhard Postpischil wrote:
>
>>On 5/7
On 5/8/2013 8:37 AM, Walt Farrell wrote:
I'm not sure why Gerhard thinks that is a security problem, gil. But
certainy if users push jobs through the INTRDR directly (as opposed
to via TSO/E SUBMIT or ISPF SUB) then you can't depend on any
restrictions imposed by IKJEFF10; you would have to use J
On Wed, 8 May 2013 10:33:46 -0400, Gerhard Postpischil wrote:
>On 5/8/2013 8:37 AM, Walt Farrell wrote:
>> I'm not sure why Gerhard thinks that is a security problem, gil. But
>> certainy if users push jobs through the INTRDR directly (as opposed
>> to via TSO/E SUBMIT or ISPF SUB) then you can't
Paul Gilmartin wrote:
>Does ISPF SUBMIT invoke TSO SUBMIT in authorized state?
No. You can choose to exclude it in IKJPRMxx and the program SUBMIT (alias of
IKJEFF01) in SYS1.CMDLIB has this attribute AC=00.
Groete / Greetings
Elardus Engelbrecht
---
Elardus Engelbrecht wrote a &^%$# TYPO!
>... IKJPRMxx ...
Must be IKJTSOxx
Groan... :-/
Groete / Greetings
Elardus Engelbrecht
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.
On 5/8/2013 7:33 AM, Gerhard Postpischil wrote:
On 5/8/2013 8:37 AM, Walt Farrell wrote:
I'm not sure why Gerhard thinks that is a security problem, gil. But
certainy if users push jobs through the INTRDR directly (as opposed
to via TSO/E SUBMIT or ISPF SUB) then you can't depend on any
restrict
I do sometimes use a TSO/ISPF submit command in a development/testing
context. In production I instead use the device of directing output
to the INTRDR defined in a DD statement or the like.
In two places where I could do so conveniently I have this morning
checked the use of duplicate jobnames p
On Wed, 8 May 2013 08:37:12 -0700, Ed Jaffe wrote:
>
>They might have simply put their 'control's in the wrong exits (TSO) and
>were too lazy to refit them into the (JES and SMF) exits where they
>belonged.
>
A plausible motivation is that they want all jobs submitted via their scheduler.
On Tue
On Wed, 8 May 2013 10:55:37 -0500, Paul Gilmartin wrote:
>Does the class matter? If I allocate:
>
>//SYSUT2 DD SYSOUT=(B,INTRDR)
>
>... will the job not run? Will the punch writer contend with INTRDR?
>(You mean they had a punch?)
>
It will run. The "B" is the MSGCLASS if one is not sp
Back before OCO, SUBMIT issued SVC 100 (called FIB, for foreground initiated
background) and most of the code ran within that SVC. It probably still does. I
think the SVC was/is also used by STATUS, CANCEL, and OUTPUT to access the JES
subsystem interface.
Bill
On Wed, 8 May 2013 09:54:27 -050
On Wed, 8 May 2013 11:08:36 -0500, Mark Zelden wrote:
>On Wed, 8 May 2013 10:55:37 -0500, Paul Gilmartin wrote:
>
>>Does the class matter? If I allocate:
>>
>>//SYSUT2 DD SYSOUT=(B,INTRDR)
>>
>>... will the job not run? Will the punch writer contend with INTRDR?
>>(You mean they had a punc
On Wed, 8 May 2013 11:41:43 -0500, Paul Gilmartin wrote:
> What class (if any) does TSO SUBMIT supply when it allocates INTRDR?
>
It depends. A default is specified in UADS (if used) or RACF / security
product.
If nothing is there, it takes the default for INTRDR specified in JES2, and I
assum
On Wed, 8 May 2013 12:10:36 -0500, Mark Zelden wrote:
>
>What is this, MVS 101? :-)
>
There's an aphorism I haven't used here in a while. I'll let readers guess.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access ins
On 5/8/2013 10:14 AM, Paul Gilmartin wrote:
On Wed, 8 May 2013 12:10:36 -0500, Mark Zelden wrote:
What is this, MVS 101? :-)
There's an aphorism I haven't used here in a while. I'll let readers guess.
I'll assume no pun intended wrt use of the word "readers." I'll further
assume the apho
IBM Mainframe Discussion List wrote on
05/08/2013 11:55:37 AM:
> From: Paul Gilmartin
>
> On Wed, 8 May 2013 08:37:12 -0700, Ed Jaffe wrote:
> >
> A plausible motivation is that they want all jobs submitted via
> their scheduler.
I agree that one should control resources. We have written a
irk Talman
To: IBM-MAIN
Sent: Wed, May 8, 2013 12:50 pm
Subject: Re: Duplicate Batch Job
IBM Mainframe Discussion List wrote on
5/08/2013 11:55:37 AM:
> From: Paul Gilmartin
>
On Wed, 8 May 2013 08:37:12 -0700, Ed Jaffe wrote:
>
A plausible motivation is that they want all
In
,
on 05/07/2013
at 02:35 PM, Jake anderson said:
>The problem is that same Job is submitted multiple times and which
>Leads to unavailability of Initiator to other Genuine Jobs.
If you are concerned with what the job does rather than with the job
name then I doubt that there is any way to
In , on 05/07/2013
at 05:50 PM, Ed Finnell said:
>Yeah, we had a bright VMer said he could run circles around ISPF
>with XEDIT macros.
Well, I'm a TSO bigot, but XEDIT has significant advantages over
ISPF/PDF EDIT. OTOH, ISPF/PDF EDIT also has advantages over XEDIT.
--
Shmuel (Seymour
, uniquely-named jobs.
Bill Fairchild
Franklin, TN
- Original Message -
From: "Kirk Talman"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, May 8, 2013 2:50:32 PM
Subject: Re: Duplicate Batch Job
IBM Mainframe Discussion List wrote on
05/08/2013 11:55:37 AM:
> From: P
: DASDBILL2
Sender: IBM Mainframe Discussion List
Date: Wed, 8 May 2013 22:19:02
To:
Reply-To: IBM Mainframe Discussion List
Subject: Re: Duplicate Batch Job
Space in the JESx checkpoint area is also a finite resource even if the job
never runs. Each job submitted
Ted MacNeil's point is well taken.
In any well-managed shop duplicate jobnames are chiefly if not
exclusively a phenomenon of development LPARs, where they are neither
deleterious nor important.
We have here yet another instance of one or the other of the two least
productive preoccuptations of
On Wed, 8 May 2013 22:40:13 -0400, John Gilmore wrote:
>
>... 2) interdict, or anyway attempt to
>interdict, any practice that is judged to be anomalous.
>
In some cases when someone has espoused a practice or point of
view that you judge to be anomalous, you characterize him as
an "intelligent Ma
W dniu 2013-05-08 19:10, Mark Zelden pisze:
On Wed, 8 May 2013 11:41:43 -0500, Paul Gilmartin wrote:
What class (if any) does TSO SUBMIT supply when it allocates INTRDR?
It depends. A default is specified in UADS (if used) or RACF / security
product.
If nothing is there, it takes the defa
Of me Paul Gilmartin wrote:
In some cases when someone has espoused a practice or point of view
that you judge to be anomalous, you characterize him as an
"intelligent Martian".
This is true; but it misses the point, at least in part. I (and
others) have used this epithet to characterize an ah
On Wed, 8 May 2013 22:40:13 -0400, John Gilmore wrote:
> 2) interdict, or anyway attempt to
>interdict, any practice that is judged to be anomalous.
see Dilbert character, 'Mordac the Preventer of Information Services'
--
For I
In <0700587285424887.wa.paulgboulderaim@listserv.ua.edu>, on
05/08/2013
at 11:41 AM, Paul Gilmartin said:
>Does the SYSOUT class on INTRDR override the class(es) in:
>// OUTPUT JESDS=ALL,...
>if MSGCLASS is not specified?
The answer changes with z/OS 2.1.
>I know that for some
:>: -Original Message-
:>: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
:>: Behalf Of R.S.
:>: Sent: Wednesday, May 08, 2013 11:27 PM
:>: To: IBM-MAIN@LISTSERV.UA.EDU
:>: Subject: Re: Duplicate Batch Job
:>:
:>: W dniu 2013-05-08
W dniu 2013-05-10 06:14, retired mainframer pisze:
:>: >
:>: >> What class (if any) does TSO SUBMIT supply when it allocates INTRDR?
:>: >>
:>: >
:>: > It depends. A default is specified in UADS (if used) or RACF /
:>: security product.
:>: > If nothing is there, it takes the default for INTRDR
52 matches
Mail list logo
