Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
You might find this interesting to look at. http://members.ozemail.com.au/~oscarptyltd/Jol_Scheduling_and_Networking_Guide.pdf I will send more information tomorrow. Thoughts create things. So we can see what we have created, people and the universe reflect back to us. So, think beautiful thoughts. They will come back to you. And, in computer technology, think simplicity and ease of use. Which was what I wanted when I created the easy network and scheduling facility. Clement Clarke -- 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
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
In [EMAIL PROTECTED], on 05/27/2008 at 09:51 AM, Hal Merritt [EMAIL PROTECTED] said: Doesn't anyone remember the famous 'Mellon Bank Mods'? Yes. I'd guess that about 20% of the list readership does. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
David Cole wrote: All I was suggesting was a very simple mechanism by which jobs could be guaranteed to run in the order submitted, nothing more, nothing less. This guarantee is already there for some JES2 users (those with CNVTNUM=1). Why not make it possible for everybody? Seeing you got several different excellent replies, please allow me to give you a proposed solution. It may or may not work for you: Write a REXX or CLIST where you submit jobs using a list of members as input. Put a waiting subroutine (a simple DO loop) between each submission long enough to allow JES2 to convert the job and place it in the Input Queue. Wait time in a busy JES2 Sysplex is usually 3 to 5 seconds between job conversions. Having the same jobname for all jobs and placing everything in one input queue will help you there. I do this for 'ad hoc' requests (Not scheduled) where I create datasets, create several audit reports and then finally FTP them to customers together with e-mail(s) stating that the audit reports are ready. After FTP everything is then deleted. Some these jobs do indeed submit other jobs via IEBGENER as a last step as suggested earlier in this thread. Will this help you? Groete / Greetings Elardus Engelbrecht -- 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
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
we in fact have a in-house production utility that does exactly that kind of looping suggested - except that we have the number of seconds to loop as a parm on the exec card - not exactly a guarentee, but changing a parm on an execute JCL is easier than re-writing a rexx or assembler ... (and avoids the one-size fits all scenerio) Chris Hoelscher Senior IDMS DB2 Database Administrator Humana Inc 502-476-2538 [EMAIL PROTECTED] The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. -- 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
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
Elardus Engelbrecht wrote: Write a REXX or CLIST where you submit jobs using a list of members as input. Put a waiting subroutine (a simple DO loop) between each submission long enough to allow JES2 to convert the job and place it in the Input Queue. Wait time in a busy JES2 Sysplex is usually 3 to 5 seconds between job conversions. If you use FTP to submit jobs, you can wait for job *completion* before submitting the next one. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
Doesn't anyone remember the famous 'Mellon Bank Mods'? Among several other useful features, they offered /*BEFORE, /*AFTER, exclusivity (any job, but only one of a thread at a time), and so on. They died out many moons ago, perhaps because they mods became a upgrade nightmare, or perhaps it was the OCO. More, the job schedulers became sophisticated and powerful enough to handle the most complex of these issues. So, my $0.02 (before taxes) would be to consider a job scheduler. One big benefit is you can have one tomorrow as opposed to waiting potentially years for IBM to consider JES modifications. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Cole Sent: Friday, May 23, 2008 1:17 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix) As noted in my prior post, I think it is a shame that the IBM-JES2 folks make it so difficult to serialize a thread of jobs. It seems to me that this is such an obvious thing to want to do, but when JES2 is started with CNVTNUM=2 (and there are strong reasons for must shops to want to do this), such serialization becomes problematic. The thing is, a JES2 supported solution, it seems to me, would be both ideal and easy to implement. Here's my idea: (1) support a //card option or a /*card option by which a user could provide an arbitrary serialization name. Example: /*JOBPARM THREADNAME=xyz. Use this name on each job in the thread. (2) Run the threaded jobs into a reader in the same order that you want the jobs to run. (Allow subsequent SUBMITs to add to a thread, if desired.) (3) The first converter to pick up one of the threaded jobs will always pick up the first one. (4) When that converter sees the thread name, it takes ownership of that thread such that all other converters will refuse to process jobs having that same name. Then, of course, the jobs would be queued for execution in the same order by which they were read, and if only one initiator ware assigned the thread's execution class, then they would, in fact, execute in that same order. There are, of course, several ancillary details: * Thread names will have to have some reasonable expiration interval. * $D/$T command will need to allow operators to display and manipulate threads to allow them to display and fix problems. * Some mechanism (ownerid perhaps?) need to be created to prevent unrelated threads having the same name from colliding. It's been several decades since I used to be a JES2 programmer, but from what I remember, it doesn't seem to me that this should be too hard. I'd guess that implementing such a scheme would take maybe only a week or few of my time. Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
-snip we in fact have a in-house production utility that does exactly that kindof looping suggested - except that we have the number of seconds to loop as a parm on the exec card - not exactly a guarentee, but changing a parm on an execute JCL is easier than re-writing a rexx or assembler ... (and avoids the one-size fits all scenerio) -unsnip That's a very good idea, Chris. Let me suggest a modification: wait until a job has finished conversion and is queued for execution before submitting the next job. Use the subsystem interfaces for submitting the job and checking on it's status. Could be a gold mine in disguise. -- 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
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
The Mellon Bank Mods were written prior to JES2's ability to run more than one converter process. Consequently, they do not guarantee serialization for the same reason that CNVTNUM=2 users don't get serialization. For more info, see: http://bama.ua.edu/cgi-bin/wa?A2=ind0805L=IBM-MAINP=R89127X=5479D13E719614079CY=dbcole%40colesoft.com Dave At 5/27/2008 10:51 AM, Hal Merritt wrote: Doesn't anyone remember the famous 'Mellon Bank Mods'? Among several other useful features, they offered /*BEFORE, /*AFTER, exclusivity (any job, but only one of a thread at a time), and so on. They died out many moons ago, perhaps because they mods became a upgrade nightmare, or perhaps it was the OCO. More, the job schedulers became sophisticated and powerful enough to handle the most complex of these issues. So, my $0.02 (before taxes) would be to consider a job scheduler. One big benefit is you can have one tomorrow as opposed to waiting potentially years for IBM to consider JES modifications. -- 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
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
On Tue, 27 May 2008 09:51:33 -0500, Hal Merritt [EMAIL PROTECTED] wrote: Doesn't anyone remember the famous 'Mellon Bank Mods'? Among several other useful features, they offered /*BEFORE, /*AFTER, exclusivity (any job, but only one of a thread at a time), and so on. snip Yes. I mentioned them in one of the first responses to Dave and Sam also mentioned them (with a lot more detail). http://bama.ua.edu/cgi-bin/wa?A2=ind0805L=ibm-mainD=1amp;O=DT=0P=193078 http://bama.ua.edu/cgi-bin/wa?A2=ind0805L=ibm-mainD=1amp;T=0O=DF=S=P=202977 Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
That's if the job names used are the FTP logon userid +1 character. If they are different, the jobs are not tracked. If someone has different information, I would love to hear it. On Tue May 27 7:09 , Edward Jaffe [EMAIL PROTECTED] sent: Elardus Engelbrecht wrote: Write a REXX or CLIST where you submit jobs using a list of members as input. Put a waiting subroutine (a simple DO loop) between each submission long enough to allow JES2 to convert the job and place it in the Input Queue. Wait time in a busy JES2 Sysplex is usually 3 to 5 seconds between job conversions. If you use FTP to submit jobs, you can wait for job *completion* before submitting the next one. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- -- 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
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
No, if you use JES interface level 2 with FTP, you can use any job name. Bill On Tue, 27 May 2008 12:16:30 -0400, Gary Green [EMAIL PROTECTED] wrote: That's if the job names used are the FTP logon userid +1 character. If they are different, the jobs are not tracked. If someone has different information, I would love to hear it. On Tue May 27 7:09 , Edward Jaffe [EMAIL PROTECTED] sent: Elardus Engelbrecht wrote: Write a REXX or CLIST where you submit jobs using a list of members as input. Put a waiting subroutine (a simple DO loop) between each submission long enough to allow JES2 to convert the job and place it in the Input Queue. Wait time in a busy JES2 Sysplex is usually 3 to 5 seconds between job conversions. If you use FTP to submit jobs, you can wait for job *completion* before submitting the next one. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- -- 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
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
Gary Green wrote: That's if the job names used are the FTP logon userid +1 character. If they are different, the jobs are not tracked. If someone has different information, I would love to hear it. You should be using 'JESINTERFACE:EVEL 2' -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
Steve is having a little trouble posting to IBM-Main, so I am posting this for him. See below: Howdy, I didn't catch the beginning of this thread, but I would like you to know that the Mellon Mods are alive and well! Although I decided a year or so ago that we should start calling them the SHARED SPOOL MODS, since I have maintained them for a dozen or so years now, and have done a completed re-write twice in that time. ANYWAY, they can still be found on the CBT TAPE website, go to latest updates are always available to download here (at the bottom of the light blue box) then scroll down to file # 766, Shared Spool Mods- Mellon for JES2 z/OS1.7 and 1.8. I will do 1.9 after we get it ordered ourselves. I have included in this distribution an INSTALLATION MANUAL, an OPERATIONS COMMAND MANUAL, and a USER'S MANUAL to explain everything better than in the past. We can now handle a number of different methods of controlling how and when jobs do and do not become eligible for selection including the following: /*AFTER jobname (allow execution after jobname jobname runs) /*BEFORE jobname( same as after, but before!) /*WITH jobname (only run if and where jobname jobname runs) /*WITHOUT jobname (run where jobname is not running) /*HOLDFOR hh:mm:ss (hold the job in the input queue for hh:mm:ss) /*HOLDTIL hh:mm:ss (hold the job on the input queue until hh:mm:ss) /*CNTL resname,EXC (control execution of a number of jobs using /*CNTL resname,SHR an arbitrary resname, and EXCLUSIVE or SHARED Control(same basic logic as an ENQ but for jobs). /*ROUTE XEQ resname for compatibility - works just like SCHENV= This was the original reason for these mods. Those are the features that are used by the users - the JCL coders. On the operations side of things, we have begun cutting some SMF records for some many of the actions we take. We have enhanced the $DJ command to display reasons that a job may be delayed while in the input queue. We implemented a number of changes specifically because of WLM managed inits including, the ability to limit (or stop) the number of jobs started on any lpar, for a given class, the ability to limit the number of total jobs that match a specific jobmask, or userid mask, this prevents one user or group of users from monopolizing resources. The ability to limit jobs by class, within a single LPAR, gives us the ability to use WLM managed inits for classes that must not be allowed to execute on all systems - tape class jobs are limited in our shop for instance and not allowed to run on some of our lpars, while WLM still manages the class on the remaining lpars in the MAS. There are other real advantages to limiting or stopping WLM managed jobs by class when you start into a maintenance window if you think about it. As has been the case for at least the last eight years, no changes to JES2 code, this is all implemented via exits, all source is provided, and is packaged in SMP/E format. PLUS, if anyone tells me they installed them, I have a box of coffee cups in my basement that all say I INSTALLED THE SHARED SPOOL MODS, that I am still trying to give away. I just need to know where to send them. Future changes that I plan to make include Automatic resource routing based on Program or PROC names. Automatic job Classing (changes the jobclass) based on program or proc, or owning userid, step completion notification options, HSM dataset recall at job reader time (or just prior to job execution time for time delayed jobs), and others. In short - if you haven't looked at the Shared Spool Mods lately - you probably should, they do a lot more now, and will do even more in the near future. [EMAIL PROTECTED] Stephen McColley Enterprise Information Services SunTrust Banks, Inc. Tel: 404.230-5182 - Robert B. Richards(Bob) US Office of Personnel Management 1900 E Street NW Room: BH04L Washington, D.C. 20415 Phone: (202) 606-1195 Email: [EMAIL PROTECTED] - -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Cole Sent: Tuesday, May 27, 2008 11:18 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix) snipped -- 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
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
That makes all the off-topic discussions, admittedly some started by me, worth it! Thanks! On Tue May 27 10:23 , Edward Jaffe [EMAIL PROTECTED] sent: Gary Green wrote: That's if the job names used are the FTP logon userid +1 character. If they are different, the jobs are not tracked. If someone has different information, I would love to hear it. You should be using 'JESINTERFACE:EVEL 2' -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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 -- 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
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
On Tue, 27 May 2008 10:23:17 -0700, Edward Jaffe wrote: Gary Green wrote: That's if the job names used are the FTP logon userid +1 character. If they are different, the jobs are not tracked. If someone has different information, I would love to hear it. You should be using 'JESINTERFACE:EVEL 2' They spelled 'EVIL' wrong, didn't they? -- Tom Schmidt (I'm still working on EVIL1) -- 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
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
Tom Schmidt wrote: On Tue, 27 May 2008 10:23:17 -0700, Edward Jaffe wrote: You should be using 'JESINTERFACE:EVEL 2' They spelled 'EVIL' wrong, didn't they? Mr. Knievel might disagree. :-) -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
My assumption was his fingers were typing faster than the Windows-controlled keyboard could handle and dropped the L. ;-) On Tue May 27 14:04 , Tom Schmidt [EMAIL PROTECTED] sent: On Tue, 27 May 2008 10:23:17 -0700, Edward Jaffe wrote: Gary Green wrote: That's if the job names used are the FTP logon userid +1 character. If they are different, the jobs are not tracked. If someone has different information, I would love to hear it. You should be using 'JESINTERFACE:EVEL 2' They spelled 'EVIL' wrong, didn't they? -- Tom Schmidt (I'm still working on EVIL1) -- 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 -- 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
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
On Tue, 27 May 2008 12:17:33 -0700, Edward Jaffe wrote: Tom Schmidt wrote: On Tue, 27 May 2008 10:23:17 -0700, Edward Jaffe wrote: You should be using 'JESINTERFACE:EVEL 2' They spelled 'EVIL' wrong, didn't they? Mr. Knievel might disagree. :-) So you need to be a daredevil to want to use that option? -- Tom Schmidt (It allows you to skip 50 batch jobs in a single jump of a virtual motorcycle??) -- 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
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
Yes... Now that he jumped over 24 delivery vans. About 10-12 more than his father. On Tue May 27 12:17 , Edward Jaffe [EMAIL PROTECTED] sent: Tom Schmidt wrote: On Tue, 27 May 2008 10:23:17 -0700, Edward Jaffe wrote: You should be using 'JESINTERFACE:EVEL 2' They spelled 'EVIL' wrong, didn't they? Mr. Knievel might disagree. :-) -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
On Tue, 27 May 2008 12:17:33 -0700, Edward Jaffe [EMAIL PROTECTED] wrote: Tom Schmidt wrote: On Tue, 27 May 2008 10:23:17 -0700, Edward Jaffe wrote: You should be using 'JESINTERFACE:EVEL 2' They spelled 'EVIL' wrong, didn't they? Mr. Knievel might disagree. :-) We've got to stop the OT-ness. I won't prolong the thread by posting to the list; rather to the individual. As controversial as my remarks often are, I think I usually stay closer to the charter than the above, even when I hijack the topic. -- gil -- 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
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
JES2 or JES3 or both are choices when installing z/OS. No price differential. And I'm sure Mr. Cole does well enough enhancing and selling XDC to believe he doesn't need a job with IBM. On the other hand, the JES2 folks have been know to add function (exit loader as a recent example) and some way of supporting FIFO is something I wanted a decade ago or more. In the end we just did with out and used carbon based processors to sort the reams of output. Putting Mellon mods on wasn't an option then, and might not have been adequate anyway given this latest discussion. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Friday, May 23, 2008 8:17 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix) On Fri, 23 May 2008 14:16:55 -0400, David Cole wrote: As noted in my prior post, I think it is a shame that the IBM-JES2 folks make it so difficult ... And that JES2 doesn't do device setup and highwater mark reservation, and that JES2 doesn't verify data set availability, and that JES2 doesn't do better syntax checking, and that JES2 doesn't check for duplicate DDNAMEs within a step, and that JES2 doesn't balance load across systems, and ... If JES2 did everything that JES3 does, it wouldn't be JES2 any more, would it? Am I right in assuming that JES3 costs more than JES2? Doesn't the vendor, then need to provide differentiating features to justify the expense? Of course, it's only human nature to wish that one's only favorite feature were added as an enhancement to the lower priced product. -- gil -- 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 -- 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
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
Gibney, Dave wrote: JES2 or JES3 or both are choices when installing z/OS. No price differential. Like many components installed with ServerPac, JES3 is an optionally-priced feature of z/OS. It is activated via IFAPRDxx in parmlib. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
I hope your being faceteous (not sure if thats spelled right). He'll just apply at IBM for a job, and then tell them he's going to become the head of JES2!! I liked Sam Knudson's response yesterday, I think on this topic, where someone made the reply that they should go to IBM with their complaints and requests. His response was that this is a great place to talk about complaints, and then go to IBM. Eric Bielefeld On Fri, 23 May 2008 23:16:43 -0500, Kenneth E Tomiak [EMAIL PROTECTED] wrote: Snip Entering real requirements to IBM is one way. He can also get a job with IBM, become the head of JES2 and fight for his cause. -- 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
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
Sorry, I didn't know it was extra. Thank you -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Saturday, May 24, 2008 12:27 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix) Gibney, Dave wrote: JES2 or JES3 or both are choices when installing z/OS. No price differential. Like many components installed with ServerPac, JES3 is an optionally-priced feature of z/OS. It is activated via IFAPRDxx in parmlib. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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 -- 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
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
Thanks Sam! You're response was immensely better than mine would have been. Dave At 5/23/2008 10:11 PM, Knutson, Sam wrote: OTOH IBM-MAIN is a great place to brain storm and refine a requirement before submitting it to IBM as a marketing request or through SHARE. A unique audience of customers, ISV developers, and IBM folks exists here that is usually not available to comment unless you stumble into the right hotel bar during the week SHARE is in town:-) Complaints voiced here may lead to others pointing out available solutions or full understanding of the history that lead to the current behavior. Best Regards, Sam Knutson, GEICO System z Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 Think big, act bold, start simple, grow fast... Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Friday, May 23, 2008 6:00 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix) I think it is a shame that the IBM-JES2 folks make it so difficult to serialize a thread of jobs. It seems to me that this is such an obvious thing to want to do, but when JES2 is started with CNVTNUM=2 (and there are strong reasons for must shops to want to do this), such serialization becomes problematic. The thing is, a JES2 supported solution, it seems to me, would be both ideal and easy to implement Blather! Blather! Blather! IBM does not take complaints on IBM-Main as requirements. You want changes? Go through the channels. I'm sorry it doesn't work as desired, but b*tching here will not change anything. - Too busy driving to stop for gas! -- 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
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
At 5/24/2008 12:16 AM, Kenneth E Tomiak wrote: Just because David would JES2 to handle scheduling does not mean implementing it would be easy. Laying out how he would like the interface is but the tip of the iceberg. As indicated in my post, I've had experience as a JES2 programmer (about two decades worth). By that I mean, that once upon a time I knew intimately the details of JES2's internal structures and logic, and that I wrote many dozens of simple and complex mods to JES2 (and HASP) for various employers from the '60s (at Rutgers, then Yale) into the '80s (for DC bandits). So my estimate, that implementing the support that I suggested would not be too difficult and could be done in a matter of weeks, was based on experience, not random guessing. Certainly, my suggestion is potentially just a first step in a far more complex set of issues that arise should you decide to expand my idea into a more comprehensive job networking solution, but I was by no means suggesting that. After all, as is well known, there already are 3rd party solutions that deal with those complexities quite well. All I was suggesting was a very simple mechanism by which jobs could be guaranteed to run in the order submitted, nothing more, nothing less. This guarantee is already there for some JES2 users (those with CNVTNUM=1). Why not make it possible for everybody? At 5/24/2008 12:16 AM, Kenneth E Tomiak wrote: Just because David would [want] JES2 to handle scheduling does not mean implementing it would be easy. Laying out how he would like the interface is but the tip of the iceberg. Entering real requirements to IBM is one way. He can also get a job with IBM, become the head of JES2 and fight for his cause. Saying that what I proposed is my cause is a bit of an overstatement. ;-) I was just making a suggestion, not a demand. As I've already noted, I already have my solution to the problem. Saying that I wanted JES2 to handling scheduling also is an overstatement. All I did was suggest a very simple way by which JES2 could be changed so that it could guarantee job sequencing, should a user want it. That is a far cry from job scheduling. At 5/23/2008 11:16 PM, Paul Gilmartin wrote: On Fri, 23 May 2008 14:16:55 -0400, David Cole wrote: As noted in my prior post, I think it is a shame that the IBM-JES2 folks make it so difficult ... And that JES2 doesn't do device setup and highwater mark reservation, and that JES2 doesn't verify data set availability, and that JES2 doesn't do better syntax checking, and that JES2 doesn't check for duplicate DDNAMEs within a step, and that JES2 doesn't balance load across systems, and ... If JES2 did everything that JES3 does, it wouldn't be JES2 any more, would it? Am I right in assuming that JES3 costs more than JES2? Doesn't the vendor, then need to provide differentiating features to justify the expense? Of course, it's only human nature to wish that one's only favorite feature were added as an enhancement to the lower priced product. I am not suggesting a convergence between JES2 and JES3 (although there has already been a considerable amount of that since the old HASP vs. ASP wars). I also am not suggesting anything that would be complex or difficult to implement (such as the several JES3 features that you referenced). I was just saying that it would be such a simple thing to do, and that because it is so simple, I feel that it's a shame that IBM doesn't do it. At 5/23/2008 11:16 PM, Paul Gilmartin wrote: Am I right in assuming that JES3 costs more than JES2? I don't think that you are correct (at least not directly). IIRC, JES2/JES3 is just a choice you make when ordering a system. There is no additional charge for either. (But also IIRC, doesn't JES3 consume more resources than JES2 and so costs would be increased in that way? Our are my prejudices obsolete?) Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- 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
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
As noted in my prior post, I think it is a shame that the IBM-JES2 folks make it so difficult to serialize a thread of jobs. It seems to me that this is such an obvious thing to want to do, but when JES2 is started with CNVTNUM=2 (and there are strong reasons for must shops to want to do this), such serialization becomes problematic. The thing is, a JES2 supported solution, it seems to me, would be both ideal and easy to implement. Here's my idea: (1) support a //card option or a /*card option by which a user could provide an arbitrary serialization name. Example: /*JOBPARM THREADNAME=xyz. Use this name on each job in the thread. (2) Run the threaded jobs into a reader in the same order that you want the jobs to run. (Allow subsequent SUBMITs to add to a thread, if desired.) (3) The first converter to pick up one of the threaded jobs will always pick up the first one. (4) When that converter sees the thread name, it takes ownership of that thread such that all other converters will refuse to process jobs having that same name. Then, of course, the jobs would be queued for execution in the same order by which they were read, and if only one initiator ware assigned the thread's execution class, then they would, in fact, execute in that same order. There are, of course, several ancillary details: * Thread names will have to have some reasonable expiration interval. * $D/$T command will need to allow operators to display and manipulate threads to allow them to display and fix problems. * Some mechanism (ownerid perhaps?) need to be created to prevent unrelated threads having the same name from colliding. It's been several decades since I used to be a JES2 programmer, but from what I remember, it doesn't seem to me that this should be too hard. I'd guess that implementing such a scheme would take maybe only a week or few of my time. Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- 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
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
WLM managed Init's? IIRC, Jobs are placed in queue in FIFO order within Service Class. snip The thing is, a JES2 supported solution, it seems to me, would be both ideal and easy to implement. Here's my idea: (1) support a //card option or a /*card option by which a user could provide an arbitrary serialization name. Example: /*JOBPARM THREADNAME=xyz. Use this name on each job in the thread. (2) Run the threaded jobs into a reader in the same order that you want the jobs to run. (Allow subsequent SUBMITs to add to a thread, if desired.) (3) The first converter to pick up one of the threaded jobs will always pick up the first one. (4) When that converter sees the thread name, it takes ownership of that thread such that all other converters will refuse to process jobs having that same name. Then, of course, the jobs would be queued for execution in the same order by which they were read, and if only one initiator ware assigned the thread's execution class, then they would, in fact, execute in that same order /snip -- 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
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
At 5/23/2008 02:23 PM, Staller, Allan wrote: WLM managed Init's? IIRC, Jobs are placed in queue in FIFO order within Service Class. The trouble is, your FIFO order is the order in which the collective converters finish processing their jobs and place them onto the execution queues. Because multiple converters process in parallel, and different jobs take different lengths of time to convert, the order in which jobs complete conversion can be different from the order in which jobs start conversion. Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- 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
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
Hi Dave,
What you describe is pretty much what the Mellon Mods for JES2 provided.
I would like to see equivalent function added to base JES2 by IBM.
Thruput Manager provides this function too. Here is user doc for the Mellon
Mods syntax for comparison.
Thanks, Sam
Users Guide - How to use the features of these Mods
- Control Statements
You take advantage of the Mellon Shared Spool mods via JECL
statements. There are currently five supported statements, they are:
/*CNTL XEQ resource, { EXC | SHR }
/*ROUTE XEQ secheduling environment name | HERE
/*WITH jobname
/*AFTER jobname
/*BEFORE jobname
The /*CNTL XEQ statement is used to add an additional job selection
criterion based on other executing jobs current use of the same resource
name. The /*CNTL XEQ must be placed in columns 1 through 10. The
resource name is arbitrary, and is made of up to eight (8) characters
with no embedded blanks. The resource name follows the literal /*CNTL
and must be preceded by at least one, but not more than 30 blank spaces.
If the shared (SHR) or exclusive (EXC) keywords are used, they must
immediately follow the resource name and be preceded by a comma. If
neither the SHR nor EXC keyword is specified SHR is assumed.
You may specify up to eight /*CNTL statements; additional statements are
disregarded.
Examples:
Assume jobnames ABC, and CDE are currently in execution with the
following /*CNTL XEQ statements -
//ABC JOB (other stuff)
/*CNTL XEQ MYNAME,SHR
//CDE JOB (other stuff)
/*CNTL XEQ MYNAME,SHR
Then if job EFG is submitted with the following, /*CNTL statement -
//EFG JOB (other stuff)
/*CNTL XEQ MYNAME,EXC
The job will not be selected for execution as long as either job ABC or
CDE continues to run.
Next if job XYZ is submitted with the following, /*CNTL statement -
//XYZ JOB (acctng info)
/*CNTL XEQ MYNAME Ú SHR is the default
It would be immediately available for execution.
When no jobs remain in execution with a /*CNTL XEQ MYNAME job EFG with
the EXC requirement would be available for job selection. Assume it has
now been selected, and a new job enters the system with the following
/*CNTL statement -
//WXY JOB (acctng info)
/*CNTL XEQ MYNAME
Job WXY will not be available for job execution until job XYZ that
holds the resource name exclusively ends. If other jobs are submitted
with resource names other than MYNAME, they will be treated separately
and only other jobs with /*CNTL statements that reference the same
resource name will affect their availability for job selection.
The /*CNTL statement only provides additional job selection criterion,
and does not replace other JES2 requirements for job selection such as
available initiators, appropriate job class and so on. The resource
name is arbitrary, you make it up, there is no need for anyone to add
the name to WLM, or any other table before it is used.
The /*ROUTE XEQ is a standard JES2 statement used to route your job to a
specific execution node. We have usurped the use of the statement, and
when we read an XEQ statement, we test to see if the name following the
XEQ literal is a valid WLM scheduling environment name. If the name is
a valid scheduling environment name, and if no schenv value is present
on the JOB card, we use the XEQ name in the same way the job statement
parameter SCHENV is used, otherwise we let JES2 handle it normally.
The literal /*ROUTE must begin in column 1. The literal XEQ must
follow /*ROUTE, and may be separated by one to twenty blank spaces.
The resource name, if not a valid JES2 node name, must follow the XEQ
literal by between 1 and 35 blank spaces. The resource name can be
between 1 and 16 characters long, if the name is longer than 16
characters, only the first 16 are used.
There is one specific exception to all of the above, if the literal
following XEQ is HERE, then the jobs system affinity is set to the
system where you submitted the job, quite a handy feature itself.
You may specify more than one /*ROUTE statement; but only the last will
be used.
Examples:
//ABC JOB (job acctng),SCHENV=BEFOREALL
/*ROUTE XEQ AFTERALL == ignored because a valid schenv is specified
//ABC JOB (job acctng),SCHENV=BEFOREALL
/*ROUTE XEQ N6 == a valid JES2 routing node, both jes2 routing and
//* schenv are valid for this job.
//ABC JOB (jobacctng)
/*ROUTE XEQ BEFOREALL == BEFOREALL is setup the same as SCHENV above
//TUV JOB (jobacctng)
/*ROUTE XEQ HERE == the jobs will only execute where submitted.
The /*WITH statement specifies that the job is only available for
selection while the jobname named on the /*WITH statement is in
execution. The condition is satisfied even if the jobname that must be
executing is executing on a different system within the same MAS
environment. If more than one /*WITH statement is read; only the last
one is kept.
Example:
//FGH JOB (acctng info)
/*WITHJKL
This
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
Hi Sam,
You had me until I read this:
A few final notes concerning the relationship
between /*BEFORE, and /*AFTER. Many people try
to use these statements, and stack two or more
jobs in the same PDS member and submit them all
at the same time with one SUBMIT command. This
usually works as expected, but sometimes JES2
will NOT PROCESS the jobs in the order they
appear in the submitted member. This can result
in a job with a /*AFTER statement for a prior
job you think JES2 has already seen and
processed because of the sequence in the
submitted member, being processed and initiated
before JES2 ever finishes reading the job that
is the object of the /*AFTER statement. This
problem can be avoided by making sure that jobs
with /*BEFORE and /*AFTER requirements are
submitted separately from each other and in an appropriate sequence.
The disordering of the jobs that you refer to is
exactly the problem that my suggestion (THREADNAME=name) attempts to fix.
Thanks, though, for the memory lane stroll. I had
forgotten about /*BEFORE and friends, but your
post reminded me that I had first seen them when
I was working at a DC shop in the early '80s.
Dave
At 5/23/2008 02:35 PM, Knutson, Sam wrote:
Hi Dave,
What you describe is pretty much what the Mellon Mods for JES2 provided.
I would like to see equivalent function added to base JES2 by IBM.
Thruput Manager provides this function
too. Here is user doc for the Mellon Mods syntax for comparison.
Thanks, Sam
Users Guide - How to use the features of these Mods
- Control Statements
You take advantage of the Mellon Shared Spool mods via JECL
statements. There are currently five supported statements, they are:
/*CNTL XEQ resource, { EXC | SHR }
/*ROUTE XEQ secheduling environment name | HERE
/*WITH jobname
/*AFTER jobname
/*BEFORE jobname
The /*CNTL XEQ statement is used to add an additional job selection
criterion based on other executing jobs current use of the same resource
name. The /*CNTL XEQ must be placed in columns 1 through 10. The
resource name is arbitrary, and is made of up to eight (8) characters
with no embedded blanks. The resource name follows the literal /*CNTL
and must be preceded by at least one, but not more than 30 blank spaces.
If the shared (SHR) or exclusive (EXC) keywords are used, they must
immediately follow the resource name and be preceded by a comma. If
neither the SHR nor EXC keyword is specified SHR is assumed.
You may specify up to eight /*CNTL statements; additional statements are
disregarded.
Examples:
Assume jobnames ABC, and CDE are currently in execution with the
following /*CNTL XEQ statements -
//ABC JOB (other stuff)
/*CNTL XEQ MYNAME,SHR
//CDE JOB (other stuff)
/*CNTL XEQ MYNAME,SHR
Then if job EFG is submitted with the following, /*CNTL statement -
//EFG JOB (other stuff)
/*CNTL XEQ MYNAME,EXC
The job will not be selected for execution as long as either job ABC or
CDE continues to run.
Next if job XYZ is submitted with the following, /*CNTL statement -
//XYZ JOB (acctng info)
/*CNTL XEQ MYNAME Ú SHR is the default
It would be immediately available for execution.
When no jobs remain in execution with a /*CNTL XEQ MYNAME job EFG with
the EXC requirement would be available for job selection. Assume it has
now been selected, and a new job enters the system with the following
/*CNTL statement -
//WXY JOB (acctng info)
/*CNTL XEQ MYNAME
Job WXY will not be available for job execution until job XYZ that
holds the resource name exclusively ends. If other jobs are submitted
with resource names other than MYNAME, they will be treated separately
and only other jobs with /*CNTL statements that reference the same
resource name will affect their availability for job selection.
The /*CNTL statement only provides additional job selection criterion,
and does not replace other JES2 requirements for job selection such as
available initiators, appropriate job class and so on. The resource
name is arbitrary, you make it up, there is no need for anyone to add
the name to WLM, or any other table before it is used.
The /*ROUTE XEQ is a standard JES2 statement used to route your job to a
specific execution node. We have usurped the use of the statement, and
when we read an XEQ statement, we test to see if the name following the
XEQ literal is a valid WLM scheduling environment name. If the name is
a valid scheduling environment name, and if no schenv value is present
on the JOB card, we use the XEQ name in the same way the job statement
parameter SCHENV is used, otherwise we let JES2 handle it normally.
The literal /*ROUTE must begin in column 1. The literal XEQ must
follow /*ROUTE, and may be separated by one to twenty blank spaces.
The resource name, if not a valid JES2 node name, must follow the XEQ
literal by between 1 and 35 blank spaces. The resource name can be
between 1 and 16
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
WLM managed Init's? IIRC, Jobs are placed in queue in FIFO order within Service Class. Same problem -- dependent on the converter time. And, more than one init could could be started due to goals being missed. - Too busy driving to stop for gas! -- 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
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Cole Sent: Friday, May 23, 2008 1:17 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix) As noted in my prior post, I think it is a shame that the IBM-JES2 folks make it so difficult to serialize a thread of jobs. It seems to me that this is such an obvious thing to want to do, but when JES2 is started with CNVTNUM=2 (and there are strong reasons for must shops to want to do this), such serialization becomes problematic. The thing is, a JES2 supported solution, it seems to me, would be both ideal and easy to implement. Here's my idea: (1) support a //card option or a /*card option by which a user could provide an arbitrary serialization name. Example: /*JOBPARM THREADNAME=xyz. Use this name on each job in the thread. SNIP How about getting IBM to support //*NET in the JES2 world? Wouldn't that get you what you are after (assuming you have used JES3 and know about NETWORKED JOBS). Regards, Steve Thompson -- All opinions expressed by me are my own and may not necessarily reflect those of my employer. -- -- 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
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
I think it is a shame that the IBM-JES2 folks make it so difficult to serialize a thread of jobs. It seems to me that this is such an obvious thing to want to do, but when JES2 is started with CNVTNUM=2 (and there are strong reasons for must shops to want to do this), such serialization becomes problematic. The thing is, a JES2 supported solution, it seems to me, would be both ideal and easy to implement Blather! Blather! Blather! IBM does not take complaints on IBM-Main as requirements. You want changes? Go through the channels. I'm sorry it doesn't work as desired, but b*tching here will not change anything. - Too busy driving to stop for gas! -- 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
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
OTOH IBM-MAIN is a great place to brain storm and refine a requirement before submitting it to IBM as a marketing request or through SHARE. A unique audience of customers, ISV developers, and IBM folks exists here that is usually not available to comment unless you stumble into the right hotel bar during the week SHARE is in town:-) Complaints voiced here may lead to others pointing out available solutions or full understanding of the history that lead to the current behavior. Best Regards, Sam Knutson, GEICO System z Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 Think big, act bold, start simple, grow fast... -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Friday, May 23, 2008 6:00 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix) I think it is a shame that the IBM-JES2 folks make it so difficult to serialize a thread of jobs. It seems to me that this is such an obvious thing to want to do, but when JES2 is started with CNVTNUM=2 (and there are strong reasons for must shops to want to do this), such serialization becomes problematic. The thing is, a JES2 supported solution, it seems to me, would be both ideal and easy to implement Blather! Blather! Blather! IBM does not take complaints on IBM-Main as requirements. You want changes? Go through the channels. I'm sorry it doesn't work as desired, but b*tching here will not change anything. - Too busy driving to stop for gas! -- 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 This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- 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
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
On Fri, 23 May 2008 14:16:55 -0400, David Cole wrote: As noted in my prior post, I think it is a shame that the IBM-JES2 folks make it so difficult ... And that JES2 doesn't do device setup and highwater mark reservation, and that JES2 doesn't verify data set availability, and that JES2 doesn't do better syntax checking, and that JES2 doesn't check for duplicate DDNAMEs within a step, and that JES2 doesn't balance load across systems, and ... If JES2 did everything that JES3 does, it wouldn't be JES2 any more, would it? Am I right in assuming that JES3 costs more than JES2? Doesn't the vendor, then need to provide differentiating features to justify the expense? Of course, it's only human nature to wish that one's only favorite feature were added as an enhancement to the lower priced product. -- gil -- 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
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
Or even try to turn a product that does one thing to incorporate another product for free. Job schedulers exists to manage the serialization and coordination of jobs beyond mere submittal. The free alternative is already there, they can put an IEBGENER step at the end of the a job to submit the next one. Just because David would JES2 to handle scheduling does not mean implementing it would be easy. Laying out how he would like the interface is but the tip of the iceberg. Entering real requirements to IBM is one way. He can also get a job with IBM, become the head of JES2 and fight for his cause. On Fri, 23 May 2008 22:16:41 -0500, Paul Gilmartin [EMAIL PROTECTED] wrote: On Fri, 23 May 2008 14:16:55 -0400, David Cole wrote: As noted in my prior post, I think it is a shame that the IBM-JES2 folks make it so difficult ... Of course, it's only human nature to wish that one's only favorite feature were added as an enhancement to the lower priced product. -- 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
