Re: Duplicate Batch Job
W dniu 2013-05-08 19:10, Mark Zelden pisze: On Wed, 8 May 2013 11:41:43 -0500, Paul Gilmartin paulgboul...@aim.com 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 assume JES3 has something similar. ...and what is default if JES2PARM does not specify any ? -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
Of me Paul Gilmartin wrote: begin extract 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. /end extract This is true; but it misses the point, at least in part. I (and others) have used this epithet to characterize an ahistorical point of view, one that reflects or appears to reflect radical ignorance of what has been. Even the disagreeable past is prologue. Moreover, there is a substantive difference between characterizing an opinion as that of an intelligent Martian and attempting to interdict the expression of that opinion. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
On Wed, 8 May 2013 22:40:13 -0400, John Gilmore jwgli...@gmail.com 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 IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
In 0700587285424887.wa.paulgboulderaim@listserv.ua.edu, on 05/08/2013 at 11:41 AM, Paul Gilmartin paulgboul...@aim.com 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 early JCL errors OUTPUT is not processed See the foils on 2.1. What class (if any) does TSO SUBMIT supply when it allocates INTRDR? Look at your IKJTSO00. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
:: -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 19:10, Mark Zelden pisze: :: On Wed, 8 May 2013 11:41:43 -0500, Paul Gilmartin :: paulgboul...@aim.com 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 :: assume JES3 has something similar. :: :: ...and what is default if JES2PARM does not specify any ? My 1.11 manual says the default is A if none is specified. Was this omitted from your copy? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
On Tue, 7 May 2013 12:49:32 -0500, Paul Gilmartin paulgboul...@aim.com 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 exit. You'd be surprised how many secure installations permit a TSO user to allocate an internal reader and write a job to it. Why is that a problem? 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 JES or SMF exits. Actually, I'm not sure you can stop users from allocating an INTRDR and still allow them to submit jobs from TSO, since even SUBMIT goes through the INTRDR. So I've never believed in using IKJEFF10 to enforce installation restrictions on job content. Control resources, not tools. Definitely! -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
Gerhard said that his client, the US f ederal entity acronym ed LUGA (Large Unnamed Government Agency), thought it was a security problem and eliminated the possibility that it could happen again when Gerhard showed how easy it was to do it. Bill Fairchild Franklin, TN - Original Message - From: Walt Farrell walt.farr...@gmail.com 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 paulgboul...@aim.com 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 exit. You'd be surprised how many secure installations permit a TSO user to allocate an internal reader and write a job to it. Why is that a problem? 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 JES or SMF exits. Actually, I'm not sure you can stop users from allocating an INTRDR and still allow them to submit jobs from TSO, since even SUBMIT goes through the INTRDR. So I've never believed in using IKJEFF10 to enforce installation restrictions on job content. Control resources, not tools. Definitely! -- Walt -- 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: Duplicate Batch Job
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 JES or SMF exits. I never said that I consider it a security problem, only that I installed software at sites that did. No idea what their auditors or management are concerned about. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
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 depend on any restrictions imposed by IKJEFF10; you would have to use JES or SMF exits. I never said that I consider it a security problem, only that I installed software at sites that did. No idea what their auditors or management are concerned about. Ah! Job security! Walt suggests that it's pretty hard to stop them. How did you (or they) do it? I suppose if TSO SUBMIT operates in authorized state one could hack allocation to restrict INTRDR to authorized programs. Does ISPF SUBMIT invoke TSO SUBMIT in authorized state? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
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.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
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 restrictions imposed by IKJEFF10; you would have to use JES or SMF exits. I never said that I consider it a security problem, only that I installed software at sites that did. No idea what their auditors or management are concerned about. 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. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
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 periodically, and what I found is 1) development programmers submitting a sequence of different jobs, chiefly compiles, etc. and assemblies, etc. reusing the same jobname and 2) a single production-control recovery/restart blunder. Paul Gilmartin's point is the crucial one. One can never stop up all the ratholes, but resources can be protected from being accessed at all or from being altered. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
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, 7 May 2013 13:34:07 -0400, Gerhard Postpischil wrote: I once installed a package at a hush-hush installation (program needed configuration data, then submitted assembly/link jobs) and was told it wouldn't work because they prohibited TSO job submission. They were surprised when my jobs started running. Next time I talked to them, they had modified JES2 so that internal reader allocation went to class B (punch) instead! 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?) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
On Wed, 8 May 2013 10:55:37 -0500, Paul Gilmartin paulgboul...@aim.com 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 specified on the JOBCARD. -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
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 -0500, Elardus Engelbrecht wrote: 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
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 punch?) It will run. The B is the MSGCLASS if one is not specified on the JOBCARD. And the SYSPRINT piles up in the punch queue. If the submitters didn't specify a SYSOUT class. I think I'm seeing som whimsy in Gerhard's anecdote. Does the SYSOUT class on INTRDR override the class(es) in: // OUTPUT JESDS=ALL,... if MSGCLASS is not specified? (I suspect not.) I know that for some early JCL errors OUTPUT is not processed, but MSGCLASS is respected. I need to try to see how the class on INTRDR plays in this game. What class (if any) does TSO SUBMIT supply when it allocates INTRDR? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
On Wed, 8 May 2013 11:41:43 -0500, Paul Gilmartin paulgboul...@aim.com 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 assume JES3 has something similar. What is this, MVS 101? :-) -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
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 instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
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 aphorism contains the word, fine. ;) -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU wrote on 05/08/2013 11:55:37 AM: From: Paul Gilmartin paulgboul...@aim.com 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 mechanism to replace SUBMIT which, based on an authorization scheme, a job runs with authority other than one's own. And all actions are logged. And noone has the authority to approve one's own job. The approval scheme is granular enough that each person has one or more demographics of group. Each approver has a list of groups they can approve. It has a number of usability features involving symbolic replacement and running lists of jobs. One can also specify the lpar to run on, but unfortunately not the plex. Written in Rexx assembler w/reports in cobol. - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
For those shops that don't have this kind of capability and don't have the resources to manage or control it, check out UpTown from RES (www.res-it.com). It does all of the below and more. Regards, Mitch McCluhan, Legacy Modernization Consultant -Original Message- From: Kirk Talman rkueb...@tsys.com To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU Sent: Wed, May 8, 2013 12:50 pm Subject: Re: Duplicate Batch Job IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU wrote on 5/08/2013 11:55:37 AM: From: Paul Gilmartin paulgboul...@aim.com 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 mechanism to eplace SUBMIT which, based on an authorization scheme, a job runs with uthority other than one's own. And all actions are logged. And noone as the authority to approve one's own job. The approval scheme is granular enough that each person has one or more emographics of group. Each approver has a list of groups they can pprove. It has a number of usability features involving symbolic replacement and unning lists of jobs. One can also specify the lpar to run on, but nfortunately not the plex. Written in Rexx assembler w/reports in cobol. - he information contained in this communication (including any ttachments hereto) is confidential and is intended solely for the ersonal and confidential use of the individual or entity to whom t is addressed. If the reader of this message is not the intended ecipient or an agent responsible for delivering it to the intended ecipient, you are hereby notified that you have received this ommunication in error and that any review, dissemination, copying, r unauthorized use of this information, or the taking of any ction in reliance on the contents of this information is strictly rohibited. If you have received this communication in error, lease notify us immediately by e-mail, and delete the original essage. Thank you -- or IBM-MAIN subscribe / signoff / archive access instructions, end 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: Duplicate Batch Job
In cahtvvrww2c2_tq8uszm44p6pznvcbvgl6ffkkh68w8bogw4...@mail.gmail.com, on 05/07/2013 at 02:35 PM, Jake anderson justmainfra...@gmail.com 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 prevent duplicates. JES2 by default will only only allow a jobname on one initiator at a time, but that's a separate issue. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
In cee89.5cf94be0.3ebad...@aol.com, on 05/07/2013 at 05:50 PM, Ed Finnell efinnel...@aol.com 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 J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
Space in the JESx checkpoint area is also a finite resource even if the job never runs. Each job submitted requires a small amount of DASD space in the checkpoint area. Perhaps you should also consider preventing any given user from submitting an infinite number of valid, authorized, uniquely-named jobs. Bill Fairchild Franklin, TN - Original Message - From: Kirk Talman rkueb...@tsys.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, May 8, 2013 2:50:32 PM Subject: Re: Duplicate Batch Job IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU wrote on 05/08/2013 11:55:37 AM: From: Paul Gilmartin paulgboul...@aim.com 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 mechanism to replace SUBMIT which, based on an authorization scheme, a job runs with authority other than one's own. And all actions are logged. And noone has the authority to approve one's own job. The approval scheme is granular enough that each person has one or more demographics of group. Each approver has a list of groups they can approve. It has a number of usability features involving symbolic replacement and running lists of jobs. One can also specify the lpar to run on, but unfortunately not the plex. Written in Rexx assembler w/reports in cobol. - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- 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: Duplicate Batch Job
Perhaps we all should consider a better use of our time than worrying about
inconsequential things such as duplicate jobs being submitted? (8-{]}
I, for one, do not understand what the problem is. (8-{[}
-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL
-Original Message-
From: DASDBILL2 dasdbi...@comcast.net
Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Date: Wed, 8 May 2013 22:19:02
To: IBM-MAIN@LISTSERV.UA.EDU
Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
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 requires a small amount of DASD space in the
checkpoint area. Perhaps you should also consider preventing any given user
from submitting an infinite number of valid, authorized, uniquely-named jobs.
Bill Fairchild
Franklin, TN
- Original Message -
From: Kirk Talman rkueb...@tsys.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, May 8, 2013 2:50:32 PM
Subject: Re: Duplicate Batch Job
IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU wrote on
05/08/2013 11:55:37 AM:
From: Paul Gilmartin paulgboul...@aim.com
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 mechanism to
replace SUBMIT which, based on an authorization scheme, a job runs with
authority other than one's own. And all actions are logged. And noone
has the authority to approve one's own job.
The approval scheme is granular enough that each person has one or more
demographics of group. Each approver has a list of groups they can
approve.
It has a number of usability features involving symbolic replacement and
running lists of jobs. One can also specify the lpar to run on, but
unfortunately not the plex.
Written in Rexx assembler w/reports in cobol.
-
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying,
or unauthorized use of this information, or the taking of any
action in reliance on the contents of this information is strictly
prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original
message. Thank you
--
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: Duplicate Batch Job
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 IT managements: 1) If it can be counted, count it, repeatedly, even if it is not clear what use can be made of these counts, and 2) interdict, or anyway attempt to interdict, any practice that is judged to be anomalous. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
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 Martian. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 much Appreciated. /Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
Jake, What level of z/OS and JES are you running? 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@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 much Appreciated. /Jake -- 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: Duplicate Batch Job
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 Original One is in Running State ? Nothing can prevent you to submit duplicate jobs, but you can consider using TYPRUN=HOLD and release your job(s) one by one at will. For automation, consider using conditions to release a job in JESx. Or just train your users to submit them one by one. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 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 stars...@mindspring.comwrote: Jake, What level of z/OS and JES are you running? 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@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 much Appreciated. /Jake -- 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: Duplicate Batch Job
Can you explain what the problem is with the second 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: 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 stars...@mindspring.comwrote: Jake, What level of z/OS and JES are you running? 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@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 much Appreciated. /Jake -- 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 information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
I should have added, If JES2 then it is working as designed. Users are allowed to submit as many as the same job name as they like. The only difference is whether they run concurrently or one at a time. I am not sure why you want to prevent a user from submitting any number of jobs with the same job name. What is the problem? Are TSO Users or Batch jobs doing the submitting? Can you determine who/what is submitting the jobs and correct that process? 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. If you 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 and JES are you running? 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@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 much Appreciated. /Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
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 will solve your problem. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 cannot run because the INIT is busy with JOB 1. Is that correct? If so, add a second INIT with the same class. So long as DELAY_SUB is set in JES2 to only run one duplicate job at a time, then you can setup multiple INITs with the same class and have more work run Most shops do this. So in JES2 you might have INIT 1 CLASS A INIT 2 CLASS A and B INIT 3CLASS B and A So if two jobs enter and use CLASS A, then INIT 1 and 2 would allow A to run before B, but INIT 3 would run Class B over Class A Does that make sense? What restrictions are in your shop that you would NOT be able to do this? The inits can be idle waiting for work with little over head. And JES2 (I presumed you are JES2) will handle the work load Or you can look at WLM and see how a JES2 WLM Managed INIT would work. Most shops have day time inits and night time inits. So during the day you might have 6 CLASS A inits to handle test work load. At night you switch the inits to have only ONE Class A init to allow minimal TEST and more PROD work. 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. Lizette -Original Message- From: IBM 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 Genuine Jobs. Lizette, We are having JES2. /Jake On Tue, May 7, 2013 at 2:32 PM, Vernooij, CP - SPLXM kees.verno...@klm.comwrote: Can you explain what the problem is with the second 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: 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 stars...@mindspring.comwrote: Jake, What level of z/OS and JES are you running? 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@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 much Appreciated. /Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
Also, Read the Manual z/OS V1R11.0 JES2 Initialization and Tuning Guide z/OS V1R10.0-V1R11.0 This will explain how JES2 runs the workload. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Tuesday, 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 cannot run because the INIT is busy with JOB 1. Is that correct? If so, add a second INIT with the same class. So long as DELAY_SUB is set in JES2 to only run one duplicate job at a time, then you can setup multiple INITs with the same class and have more work run Most shops do this. So in JES2 you might have INIT 1 CLASS A INIT 2 CLASS A and B INIT 3CLASS B and A So if two jobs enter and use CLASS A, then INIT 1 and 2 would allow A to run before B, but INIT 3 would run Class B over Class A Does that make sense? What restrictions are in your shop that you would NOT be able to do this? The inits can be idle waiting for work with little over head. And JES2 (I presumed you are JES2) will handle the work load Or you can look at WLM and see how a JES2 WLM Managed INIT would work. Most shops have day time inits and night time inits. So during the day you might have 6 CLASS A inits to handle test work load. At night you switch the inits to have only ONE Class A init to allow minimal TEST and more PROD work. 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. Lizette -Original Message- From: IBM 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 Genuine Jobs. Lizette, We are having JES2. /Jake On Tue, May 7, 2013 at 2:32 PM, Vernooij, CP - SPLXM kees.verno...@klm.comwrote: Can you explain what the problem is with the second 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: 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 stars...@mindspring.comwrote: Jake, What level of z/OS and JES are you running? 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@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 much Appreciated. /Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
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 choosed to limit usage of MVS and JES2 commands. BTW: my users do not compete for the inits, rather CPU time. Lucky you. ;-D My users are grabbing everything - inits, spool space, CPU, memory, diskspace, tapes. They think my storage admin is a jolly fat man living in north pole with elves dealing out cheap diskspace... ;-D As Lizette said, we also have rules in the day and night on WLM, inits, scheduling, etc. to spread out workload. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
How is this a problem. The jobs can only use one initiator at a time. The waiting jobs only tie up some SPOOL space. - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: Jake anderson justmainfra...@gmail.com Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Tue, 7 May 2013 14:35:49 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List 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 Genuine Jobs. Lizette, We are having JES2. /Jake On Tue, May 7, 2013 at 2:32 PM, Vernooij, CP - SPLXM kees.verno...@klm.comwrote: Can you explain what the problem is with the second 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: 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 stars...@mindspring.comwrote: Jake, What level of z/OS and JES are you running? 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@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 much Appreciated. /Jake -- 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 information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- 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: Duplicate Batch Job
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 instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
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 only one init for that job's class, then TYPRUN=HOLD is not needed (assuming those jobs are running in the correct sequence). Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 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. I once installed a package at a hush-hush installation (program needed configuration data, then submitted assembly/link jobs) and was told it wouldn't work because they prohibited TSO job submission. They were surprised when my jobs started running. Next time I talked to them, they had modified JES2 so that internal reader allocation went to class B (punch) instead! Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
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 a TSO user to allocate an internal reader and write a job to it. Why is that a problem? Control resources, not tools. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
As a suggestion, when this type of issue comes up and, assuming the site has a vendor supplied automated scheduler, check out UpTown from RES (www.res-it.com). It allows the scheduler tool to manage any on demand or on request jobs automatically. Regards, Mitch McCluhan, Legacy Modernization Consultant. -Original Message- From: Gerhard Postpischil gerh...@valley.net To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU 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 look at IKJEFT10 exit. You'd be surprised how many secure installations permit a TSO user to llocate an internal reader and write a job to it. I once installed a package at a hush-hush installation (program needed onfiguration data, then submitted assembly/link jobs) and was told it ouldn't work because they prohibited TSO job submission. They were urprised when my jobs started running. Next time I talked to them, hey had modified JES2 so that internal reader allocation went to class (punch) instead! Gerhard Postpischil radford, Vermont -- or IBM-MAIN subscribe / signoff / archive access instructions, end 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: Duplicate Batch Job
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? Control resources, not tools. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
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 you arguing that bad response/throughput of ISPF/TSO SUBMIT is a merit? One reason to employ alternatives to ISPF/TSO SUBMIT is the restrictions is imposes on RECFM and LRECL. (It's documented that NJE has similar restrictions.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
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)? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
