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: [email protected] 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 Road VOICE: 540-456-8536 Afton, VA 22920 FAX: 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
