Step 1 I would put the default CLASS= in every job. Easier to change the default than add a new line.
On Thu, Nov 5, 2020 at 6:09 AM R.S. <[email protected]> wrote: > > Now we know more. Maybe still not enough ;-) > However we may assume: > a) there is finite number of the jobs > b) you know all the jobs - that means all PDS/PDSE's with the jobs. No > secret libraries, no forgotten user libraries, etc. > c) the jobs are not generated dynamically by some "black box" tool, so > all the jobs are known. > d) jobs have accnt field with some known/documented format and its > content clearly tell you which class to use (let's simplify it to just > jobclasses A, B, C - good, better, the best) > > In such scenario I would think about mass change. > Simply, for any job with ACCNT containing GOOD place CLASS=A. For any > job with ACCNT containing BTTR place CLASS=B, and for each job with BEST > place CLASS=C. > > Note: it doesn't matter whether you have 100, 1000 or 10000 jobs. > OK, for 100 jobs it is still feasible to change it manually. ;-) > > Note2: Since the jobs are already in production, with NO classes, there > is no big problem to change it gradually. Even "forgotten" libraries can > be changed later, when detected. > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > > W dniu 05.11.2020 o 06:21, Gadi Ben-Avi pisze: > > Hi Everone. > > Thanks for responding. > > > > We 'purchased' a system from another site. > > The jobs that came with the system do not have a CLASS parameter specified. > > They do have specific values in the accounting fields that are supposed to > > assign the job to specific classes. > > I assume they had an exit that did all of this. > > > > Up until now, all of the jobs ran in the same class, with the same service > > class. > > I've been asked to assign a lower service class to jobs that have a > > specific (not specified as yet) value in the accounting data. > > > > The simplest way would have been to tell the job owners to code a CLASS > > parameter on the JOB card, but they say that that is too much work. > > > > I looked at doing this using WLM definitions. > > It works if the value in the accounting data is in the first 8 bytes. > > Otherwise, it get complicated to write, debug, and read. > > > > I read about JES2 Policies, so I looked it up in the documentation. > > > > Gadi > > > > > > -----Original Message----- > > From: IBM Mainframe Discussion List <[email protected]> On Behalf Of > > Jesse 1 Robinson > > Sent: Wednesday, November 4, 2020 10:05 PM > > To: [email protected] > > Subject: Re: JES2 Policies > > > > In a previous life at the late great Security Pacific, we an *elaborate* > > scheme based on account numbers. Even the job name was generated from > > account number. To control all this, we had a VSAM file containing all > > valid account numbers along with indications of who could submit jobs with > > each number. An array of JES2 and SMF exits were employed to make all this > > work. At the end of the year, account numbers were used for chargeback to > > respective departments for resource usage. > > > > There is no way in h*ll I would recommend this complex scheme for a modern > > shop. But yes, with enough time and $$, it can be done. > > > > . > > . > > J.O.Skip Robinson > > Southern California Edison Company > > Electric Dragon Team Paddler > > SHARE MVS Program Co-Manager > > 323-715-0595 Mobile > > 626-543-6132 Office ⇐=== NEW > > [email protected] > > > > -----Original Message----- > > From: IBM Mainframe Discussion List <[email protected]> On Behalf Of > > Lizette Koehler > > Sent: Wednesday, November 4, 2020 10:53 AM > > To: [email protected] > > Subject: (External):Re: JES2 Policies > > > > *** EXTERNAL EMAIL - Use caution when opening links or attachments *** > > > > Initial Request: > > The current goal is to change a job's class or service class depending on > > certain values in the accounting information. > > > > It also seems to me that a JCL tool, Like JCLPLUS could put rules into JCL > > Scanning and force users to adhere to a standard. But that would mean you > > have a Source management system that is used to deploy Jobs to various > > systems. > > > > It could have rules that say, if Account Code is this, then the job should > > have Service Class STCLOW and CLASS X > > > > > > Lizette > > > > > > -----Original Message----- > > From: IBM Mainframe Discussion List <[email protected]> On Behalf Of > > Allan Staller > > Sent: Wednesday, November 4, 2020 11:35 AM > > To: [email protected] > > Subject: Re: JES2 Policies > > > > Wouldn't RACF jobclass controls be more appropriate? > > > > -----Original Message----- > > From: IBM Mainframe Discussion List <[email protected]> On Behalf Of > > Joe Monk > > Sent: Wednesday, November 4, 2020 10:31 AM > > To: [email protected] > > Subject: Re: JES2 Policies > > > > [CAUTION: This Email is from outside the Organization. Unless you trust the > > sender, Don’t click links or open attachments as it may be a Phishing > > email, which can steal your Information and compromise your Computer.] > > > > Radoslaw, > > > > I think what the OP is really saying is that certain accounts should be > > restricted from certain jobclasses i.e. DEV cant use PROD jobclasses. So, > > if they code a CLASS=X, but the account info says that they dont have > > access to CLASS=X, then dump the job. > > > > OP: This has been around a long time, and is very mature... > > > > Joe > > > > On Wed, Nov 4, 2020 at 8:20 AM R.S. <[email protected]> wrote: > > > >> W dniu 04.11.2020 o 13:10, Gadi Ben-Avi pisze: > >>> Hi, > >>> I've started looking into JES2 Policies. > >>> > >>> The current goal is to change a job's class or service class > >>> depending > >> on certain values in the accounting information. > >>> >From reading the manual, it seems that this is possible. > >>> > >>> Has anyone done something like this? > >>> Is there a way to debug these policies? > >>> > >>> Is this feature mature enough to use? > >> I dare to disagree ...with your goal. More precisely I disagree with > >> your presentation of the goal. > >> Does it really have to depend on account information? Why? > >> > >> That means user has to code something in the jobcard, in the first > >> positional. So he may code CLASS= keyword as well, can't he? > >> Maybe your accnt infor is already somehowe controlled (my guess, lack > >> of information). However jobclass can be RACF-controlled. > >> And this is quite mature way to control job classes and (indirectly) > >> service classes. > >> > >> -- > >> Radoslaw Skorupka > >> Lodz, Poland > > > > > ====================================================================== > > Jeśli nie jesteś adresatem tej wiadomości: > > - powiadom nas o tym w mailu zwrotnym (dziękujemy!), > - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub > zapisałeś na dysku). > Wiadomość ta może zawierać chronione prawem informacje, które może > wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia > (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza > prawo i może podlegać karze. > > mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 > Warszawa,www.mBank.pl, e-mail: [email protected]. Sąd Rejonowy dla m. st. > Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 0000025237, > NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na > 01.01.2020 r. wynosi 169.401.468 złotych. > > If you are not the addressee of this message: > > - let us know by replying to this e-mail (thank you!), > - delete this message permanently (including all the copies which you have > printed out or saved). > This message may contain legally protected information, which may be used > exclusively by the addressee.Please be reminded that anyone who disseminates > (copies, distributes) this message or takes any similar action, violates the > law and may be penalised. > > mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 > Warszawa,www.mBank.pl, e-mail: [email protected]. District Court for the > Capital City of Warsaw, 12th Commercial Division of the National Court > Register, KRS 0000025237, NIP: 526-021-50-88. Fully paid-up share capital > amounting to PLN 169.401.468 as at 1 January 2020. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
