Re: JES2 Policies
"BTW: Your case seem ridiculous (tenths of hour? Every job accounted?), but - this is more important - it has nothing to do with the problem." Yes. Chargebacks for mainframe time, and accounting when LPARs are leased to 3rd party customers. When I was a customer of a mainframe service provider, we paid $8,000 per CPU hour which was a very competitive rate for a 2 processor LPAR. So, you bet. A tenth of an hour was $800. BTW, lawyers bill their clients in tenths of an hour. At $1000/hr for a partner, 6 minutes is $100. And, the systems that lawyers use, have client matter codes for billing. They are required to for the court. Joe On Wed, Nov 11, 2020 at 4:39 PM R.S. wrote: > W dniu 05.11.2020 o 20:01, retired mainframer pisze: > >> -Original Message- > >> From: IBM Mainframe Discussion List On > >> Behalf Of R.S. > >> Sent: Thursday, November 05, 2020 4:20 AM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: JES2 Policies > >> > >> Joe, > >> > >> And I'm pretty sure no business department is interested in ACCNT field > >> and its content. Believe me or not: IT is a tool to achieve business > >> goal, but the details, guts, fields, commas are NOT in the scope of > >> business focus. They want working application, it is up to IT how to do > >> it. Changing ACCNT or classes are not strategic. > >> BTW: Gadi's further explanation sched more light on that. > >> That's why I proposed solution for real need. Not just abstract > >> excercise to solve. > >> > >> -- > >> Radoslaw Skorupka > >> Lodz, Poland > > Why would you think that? When I was working, our office had several > different contracts active simultaneously. Many were "cost plus" rather > than "fixed fee." It was not unusual to spend a portion of each day on > different ones. We were required to daily document our time on each to the > nearest tenth of an hour. Similarly, when we logged on to TSO or submitted > a batch job, we were required to specify the account field that > corresponded to that contract. We had an exit (IEFACTRT?) that captured > this along with job statistics, such as CPU time, I/O counts, etc and cut > appropriate SMF records. These formed the basis for billing the > customers. It was also used by management to determine how accurate > initial estimates were and then refine our process for estimating future > bids. > > Why do I think that? This is my experience. I saw and *solved* many > scenarios where weird (OK, unusual) requirements were NOT business need, > but were derivative of those. Yes, I sustain - business dept has no > interest in ACCNT field, TRK vs CYL vs AVG and many other technical > things. BTW: I also saw other scenarios but I have *never* saw > reasonable explanation for them. Of course this is only my limited 25+ > yo experience. I would be happy to learn such cases. > > BTW: Your case seem ridiculous (tenths of hour? Every job accounted?), > but - this is more important - it has nothing to do with the problem. > Please, read Gadi's further explanations. In this case the only purpose > (*) of ACCNT field is to manage job class and service class assignment. > (*) > (Fine print: this is the only purpose we know. However why to suspect > there are other hidden purposes? How to satisfy them? And what's wrong > with CLASS= keyword in jobcard?) > > -- > 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: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy > XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 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.
Re: JES2 Policies
This is matter of the tool used to do mass change. IMHO there is no rocket science to write some simple REXX script adding keyword parameter to existing statement with preserving JCL rules coding. Of course there is nothing wrong with two step approach - first for adding CLASS=existing_default, and second with change this value to other. BTW: many years ago I supported some "wannabe-programmer" and "wannabe - consultant", who was unable to change jobclass. Yes, the problem was CLASS=5 and his task was to change it to CLASS=A or just delete this parameter. It took him 7 hours and many attempts to surrender ...and demand JES2 reconfiguration. ;-) Yes, JCL syntax and ISPF Edit were black magic for him. Few years later his company hired me to teach JCL. Usually it takes 4.5 days (IBM course), but they demanded to compress it to one day. Oh, students had very weak knowledge about ISPF and Edit. -- Radoslaw Skorupka Lodz, Poland W dniu 05.11.2020 o 16:44, Mike Schwab pisze: 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. 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 1 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 On Behalf Of Jesse 1 Robinson Sent: Wednesday, November 4, 2020 10:05 PM To: IBM-MAIN@LISTSERV.UA.EDU 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 robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lizette Koehler Sent: Wednesday, November 4, 2020 10:53 AM To: IBM-MAIN@LISTSERV.UA.EDU 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 Se
Re: JES2 Policies
W dniu 05.11.2020 o 20:01, retired mainframer pisze: -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Thursday, November 05, 2020 4:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES2 Policies Joe, And I'm pretty sure no business department is interested in ACCNT field and its content. Believe me or not: IT is a tool to achieve business goal, but the details, guts, fields, commas are NOT in the scope of business focus. They want working application, it is up to IT how to do it. Changing ACCNT or classes are not strategic. BTW: Gadi's further explanation sched more light on that. That's why I proposed solution for real need. Not just abstract excercise to solve. -- Radoslaw Skorupka Lodz, Poland Why would you think that? When I was working, our office had several different contracts active simultaneously. Many were "cost plus" rather than "fixed fee." It was not unusual to spend a portion of each day on different ones. We were required to daily document our time on each to the nearest tenth of an hour. Similarly, when we logged on to TSO or submitted a batch job, we were required to specify the account field that corresponded to that contract. We had an exit (IEFACTRT?) that captured this along with job statistics, such as CPU time, I/O counts, etc and cut appropriate SMF records. These formed the basis for billing the customers. It was also used by management to determine how accurate initial estimates were and then refine our process for estimating future bids. Why do I think that? This is my experience. I saw and *solved* many scenarios where weird (OK, unusual) requirements were NOT business need, but were derivative of those. Yes, I sustain - business dept has no interest in ACCNT field, TRK vs CYL vs AVG and many other technical things. BTW: I also saw other scenarios but I have *never* saw reasonable explanation for them. Of course this is only my limited 25+ yo experience. I would be happy to learn such cases. BTW: Your case seem ridiculous (tenths of hour? Every job accounted?), but - this is more important - it has nothing to do with the problem. Please, read Gadi's further explanations. In this case the only purpose (*) of ACCNT field is to manage job class and service class assignment. (*) (Fine print: this is the only purpose we know. However why to suspect there are other hidden purposes? How to satisfy them? And what's wrong with CLASS= keyword in jobcard?) -- 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: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 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: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 Policies
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. This sounds like ThruPut Manager. I never used the product myself, but when I supported WLM I worked with many customers that used it. The product had a lot of flexibility in assigning job classes and WLM service classes from data derived by scanning the JCL when a job was submitted. -- *G. Tom Russell* “Stay calm. Be brave. Wait for the signs” — Jasper FriendlyBear “… and remember to leave good news alone.” — Gracie HeavyHand -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 Policies
> -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of R.S. > Sent: Thursday, November 05, 2020 4:20 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: JES2 Policies > > Joe, > > And I'm pretty sure no business department is interested in ACCNT field > and its content. Believe me or not: IT is a tool to achieve business > goal, but the details, guts, fields, commas are NOT in the scope of > business focus. They want working application, it is up to IT how to do > it. Changing ACCNT or classes are not strategic. > BTW: Gadi's further explanation sched more light on that. > That's why I proposed solution for real need. Not just abstract > excercise to solve. > > -- > Radoslaw Skorupka > Lodz, Poland Why would you think that? When I was working, our office had several different contracts active simultaneously. Many were "cost plus" rather than "fixed fee." It was not unusual to spend a portion of each day on different ones. We were required to daily document our time on each to the nearest tenth of an hour. Similarly, when we logged on to TSO or submitted a batch job, we were required to specify the account field that corresponded to that contract. We had an exit (IEFACTRT?) that captured this along with job statistics, such as CPU time, I/O counts, etc and cut appropriate SMF records. These formed the basis for billing the customers. It was also used by management to determine how accurate initial estimates were and then refine our process for estimating future bids. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 Policies
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. 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 1 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 On Behalf Of > > Jesse 1 Robinson > > Sent: Wednesday, November 4, 2020 10:05 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > 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 > > robin...@sce.com > > > > -Original Message- > > From: IBM Mainframe Discussion List On Behalf Of > > Lizette Koehler > > Sent: Wednesday, November 4, 2020 10:53 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > 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- > > Fro
Re: JES2 Policies
Part of real need is complying with lawful management edicts, even when they are not wise. You have an obligation to point out the problems, but if management wants to do it regardless, then you must shut up and code. Of course, in that situation it is prudent to retain an audit trail showing that you did object. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of R.S. [r.skoru...@bremultibank.com.pl] Sent: Thursday, November 5, 2020 7:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES2 Policies Joe, This is not my call (honestly I don't know this idiom). This is not my dog, this is not my business. I can leave it with no answer, but my willing is to help. And part of the help is not to just code the exit, but discuss about solution. And I'm pretty sure no business department is interested in ACCNT field and its content. Believe me or not: IT is a tool to achieve business goal, but the details, guts, fields, commas are NOT in the scope of business focus. They want working application, it is up to IT how to do it. Changing ACCNT or classes are not strategic. BTW: Gadi's further explanation sched more light on that. That's why I proposed solution for real need. Not just abstract excercise to solve. -- Radoslaw Skorupka Lodz, Poland W dniu 05.11.2020 o 13:05, Joe Monk pisze: > "However I think it not valid > requirement, there is no business need behind it." > > Thats not your call to make. They are entitled to run their business how > they see fit. > > Joe > > On Thu, Nov 5, 2020 at 5:53 AM R.S. wrote: > >> W dniu 04.11.2020 o 19:50, Lizette Koehler pisze: >>> Can RACF see the account code and make a decision? >> Obviously not. RACF is also unable to see submitters trousers, check how >> many days left to nearest holiday, etc. >> >>> That is what (as I understand it) the initial requirement is. >> Yes, that requirement was presented to us. However I think it not valid >> requirement, there is no business need behind it. >> It is more complex: some reasonable business need led to use accnt. And >> this is worth to discuss IMHO. Or just go back to business need and >> discuss how to satisfy it. To avoid Rube Goldberg machinery. >> >> >> -- >> 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,http://secure-web.cisco.com/1yUJH6CPVdYQVq1v6JcA0Qu8ySvxWpkIbN6z7Tlu1aYl5APLNz8vZBPxnDa839idcMCNIuAs3xGzchKO1lvL1WGWj2HiJ-i5fXxxBuV4fU8rAfJDBOMVbqBknEoKQKR6Xt5IFQgCiWhA4zIENjWrPFsrXStD1r7YrAMtxNh-1S3lU-pqBwrKxvoSQ2Ed1IHUen44QAPRg79znKQwYd-xz9LItjPRi4_KwhtWnUw90CGs5KDjrd9DKfcLG_xFzLhGj8khxj42aw8tI6CuFYmjyvsdOJeRqNL_DVJoY-sDntRa6SLX3Z3T4nxIin_G0n7Gs1jfohhkReYNyQ2whaEPePb_sB92872FuxoW1dDv27chJDrgnYPwWooRQKWbDsrwac_O5AZHwPezwr3TWzU8Gwz5shBs785GBHx2xRSBnHFK3U1JkLfqHKN-ZJ9rvCsuaXTy5y3P0u4c2NaFKuBKWJg/http%3A%2F%2Fwww.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 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,http://secure-web.cisco.com/1yUJH6CPVdYQVq1v6JcA0Qu8ySvxWpkIbN6z7Tlu1aYl5APLNz8vZBPxnDa839idcMCNIuAs3xGzchKO1lvL1WGWj2HiJ-i5fXxxBuV4fU8rAfJDBOMVbqBknEoKQKR6Xt5IFQgCiWhA4zIENjWrPFsrXStD1r7YrAMtxNh-1S3lU-pqBwrKxvoSQ2Ed1IHUen44QAPRg79znKQwYd-xz9LItjPRi4_KwhtWnUw90CGs5KDjrd9DKfcLG_xFzLhGj8khxj42aw8tI6CuFYmjyvsdOJeRqNL_DVJoY-sDntRa6SLX3Z3T4nxIin_G0n7Gs1jfohhkReYNyQ2whaEPePb_sB92872FuxoW1dDv27chJDrgnYPwWooRQKWbDsrwac_O5AZHwPezwr3TWzU8Gwz5shBs785GBHx2xRSBnHFK3U1JkLfqHKN-ZJ9rvCsuaXTy5y3P0u4c2NaFKuBKWJg/http%3A%2F%2Fwww.mBank.pl, e-mail: kont...@mbank.pl. District Court for the C
Re: JES2 Policies
Joe, This is not my call (honestly I don't know this idiom). This is not my dog, this is not my business. I can leave it with no answer, but my willing is to help. And part of the help is not to just code the exit, but discuss about solution. And I'm pretty sure no business department is interested in ACCNT field and its content. Believe me or not: IT is a tool to achieve business goal, but the details, guts, fields, commas are NOT in the scope of business focus. They want working application, it is up to IT how to do it. Changing ACCNT or classes are not strategic. BTW: Gadi's further explanation sched more light on that. That's why I proposed solution for real need. Not just abstract excercise to solve. -- Radoslaw Skorupka Lodz, Poland W dniu 05.11.2020 o 13:05, Joe Monk pisze: "However I think it not valid requirement, there is no business need behind it." Thats not your call to make. They are entitled to run their business how they see fit. Joe On Thu, Nov 5, 2020 at 5:53 AM R.S. wrote: W dniu 04.11.2020 o 19:50, Lizette Koehler pisze: Can RACF see the account code and make a decision? Obviously not. RACF is also unable to see submitters trousers, check how many days left to nearest holiday, etc. That is what (as I understand it) the initial requirement is. Yes, that requirement was presented to us. However I think it not valid requirement, there is no business need behind it. It is more complex: some reasonable business need led to use accnt. And this is worth to discuss IMHO. Or just go back to business need and discuss how to satisfy it. To avoid Rube Goldberg machinery. -- 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: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 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: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 Policies
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 1 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 On Behalf Of Jesse 1 Robinson Sent: Wednesday, November 4, 2020 10:05 PM To: IBM-MAIN@LISTSERV.UA.EDU 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 robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lizette Koehler Sent: Wednesday, November 4, 2020 10:53 AM To: IBM-MAIN@LISTSERV.UA.EDU 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 On Behalf Of Allan Staller Sent: Wednesday, November 4, 2020 11:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES2 Policies Wouldn't RACF jobclass controls be more appropriate? -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joe Monk Sent: Wednesday, November 4, 2020 10:31 AM To: IBM-MAIN@LISTSERV.UA.EDU 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. wrote: W dniu 04.11.2020 o 13:10, Gadi Ben-Avi pisze: Hi, I've started l
Re: JES2 Policies
"However I think it not valid requirement, there is no business need behind it." Thats not your call to make. They are entitled to run their business how they see fit. Joe On Thu, Nov 5, 2020 at 5:53 AM R.S. wrote: > W dniu 04.11.2020 o 19:50, Lizette Koehler pisze: > > Can RACF see the account code and make a decision? > Obviously not. RACF is also unable to see submitters trousers, check how > many days left to nearest holiday, etc. > > > That is what (as I understand it) the initial requirement is. > Yes, that requirement was presented to us. However I think it not valid > requirement, there is no business need behind it. > It is more complex: some reasonable business need led to use accnt. And > this is worth to discuss IMHO. Or just go back to business need and > discuss how to satisfy it. To avoid Rube Goldberg machinery. > > > -- > 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: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy > XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 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: kont...@mbank.pl. District Court for the > Capital City of Warsaw, 12th Commercial Division of the National Court > Register, KRS 025237, 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 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: JES2 Policies
W dniu 04.11.2020 o 19:50, Lizette Koehler pisze: Can RACF see the account code and make a decision? Obviously not. RACF is also unable to see submitters trousers, check how many days left to nearest holiday, etc. That is what (as I understand it) the initial requirement is. Yes, that requirement was presented to us. However I think it not valid requirement, there is no business need behind it. It is more complex: some reasonable business need led to use accnt. And this is worth to discuss IMHO. Or just go back to business need and discuss how to satisfy it. To avoid Rube Goldberg machinery. -- 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: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 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: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 Policies
W dniu 04.11.2020 o 19:29, Lizette Koehler pisze: [...] I worked in a shop with over 500 exits in JES2/zOS/Vtam etc... Each upgrade took longer to do - basically do to validation of the code. One upgrade we decided to reduce that down and let the system perform its own functions. Went down to 30 exits and the systems worked just fine and upgrade times were faster. More than 500 exits? Well, I would have a problem to point where the exits are implemented. Not to explain the reasons. -- 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: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 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: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 Policies
Probably using an exit, or maybe more than one. -Original Message- From: IBM Mainframe Discussion List On Behalf Of kekronbekron Sent: Thursday, November 5, 2020 10:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES2 Policies Is it an option to ask how they managed this in the source site? - KB ‐‐‐ Original Message ‐‐‐ On Thursday, November 5, 2020 10:51 AM, Gadi Ben-Avi wrote: > 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 IBM-MAIN@LISTSERV.UA.EDU On Behalf > Of Jesse 1 Robinson > Sent: Wednesday, November 4, 2020 10:05 PM > To: IBM-MAIN@LISTSERV.UA.EDU > 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 > robin...@sce.com > > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf > Of Lizette Koehler > Sent: Wednesday, November 4, 2020 10:53 AM > To: IBM-MAIN@LISTSERV.UA.EDU > 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 IBM-MAIN@LISTSERV.UA.EDU On Behalf > Of Allan Staller > Sent: Wednesday, November 4, 2020 11:35 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: JES2 Policies > > Wouldn't RACF jobclass controls be more appropriate? > > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf > Of Joe Monk > Sent: Wednesday, November 4, 2020 10:31 AM > To: IBM-MAIN@LISTSERV.UA.EDU > 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. r.skoru...@bremultibank.com.pl 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 c
Re: JES2 Policies
Is it an option to ask how they managed this in the source site? - KB ‐‐‐ Original Message ‐‐‐ On Thursday, November 5, 2020 10:51 AM, Gadi Ben-Avi wrote: > 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 IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > Jesse 1 Robinson > Sent: Wednesday, November 4, 2020 10:05 PM > To: IBM-MAIN@LISTSERV.UA.EDU > 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 > robin...@sce.com > > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > Lizette Koehler > Sent: Wednesday, November 4, 2020 10:53 AM > To: IBM-MAIN@LISTSERV.UA.EDU > 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 IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > Allan Staller > Sent: Wednesday, November 4, 2020 11:35 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: JES2 Policies > > Wouldn't RACF jobclass controls be more appropriate? > > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of Joe > Monk > Sent: Wednesday, November 4, 2020 10:31 AM > To: IBM-MAIN@LISTSERV.UA.EDU > 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. r.skoru...@bremultibank.com.pl 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. > > > > >
Re: JES2 Policies
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 On Behalf Of Jesse 1 Robinson Sent: Wednesday, November 4, 2020 10:05 PM To: IBM-MAIN@LISTSERV.UA.EDU 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 robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lizette Koehler Sent: Wednesday, November 4, 2020 10:53 AM To: IBM-MAIN@LISTSERV.UA.EDU 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 On Behalf Of Allan Staller Sent: Wednesday, November 4, 2020 11:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES2 Policies Wouldn't RACF jobclass controls be more appropriate? -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joe Monk Sent: Wednesday, November 4, 2020 10:31 AM To: IBM-MAIN@LISTSERV.UA.EDU 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. 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 --
Re: JES2 Policies
Well, if I had to use account numbers for such purposes I would control it through RACF profiles. And, no, I would not run a job in the wrong job class if validation failed. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jesse 1 Robinson [jesse1.robin...@sce.com] Sent: Wednesday, November 4, 2020 3:04 PM To: IBM-MAIN@LISTSERV.UA.EDU 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 robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lizette Koehler Sent: Wednesday, November 4, 2020 10:53 AM To: IBM-MAIN@LISTSERV.UA.EDU 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 On Behalf Of Allan Staller Sent: Wednesday, November 4, 2020 11:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES2 Policies Wouldn't RACF jobclass controls be more appropriate? -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joe Monk Sent: Wednesday, November 4, 2020 10:31 AM To: IBM-MAIN@LISTSERV.UA.EDU 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. 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 -- 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: 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 robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lizette Koehler Sent: Wednesday, November 4, 2020 10:53 AM To: IBM-MAIN@LISTSERV.UA.EDU 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 On Behalf Of Allan Staller Sent: Wednesday, November 4, 2020 11:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES2 Policies Wouldn't RACF jobclass controls be more appropriate? -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joe Monk Sent: Wednesday, November 4, 2020 10:31 AM To: IBM-MAIN@LISTSERV.UA.EDU 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. 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 Policies
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 On Behalf Of Allan Staller Sent: Wednesday, November 4, 2020 11:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES2 Policies Wouldn't RACF jobclass controls be more appropriate? -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joe Monk Sent: Wednesday, November 4, 2020 10:31 AM To: IBM-MAIN@LISTSERV.UA.EDU 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. 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, > https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.m > bank.pl%2F&data=04%7C01%7Callan.staller%40HCL.COM%7Cd04848476fc74265206f08d880df1093%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637401042848982511%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=f0M%2Bw7n1t2uPc1f6IUlanGNRz%2BZw1CD5wT9SS%2BUeIpU%3D&reserved=0, > e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział > Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 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,https://apc01.safelinks.protection.outlook.com/?url=http%3A%2 > F%2Fwww.mbank.pl%2F&data=04%7C01%7Callan.staller%40HCL.COM%7Cd0484 > 8476fc74265206f08d880df1093%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637401042848982511%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=f0M%2Bw7n1t2uPc1f
Re: JES2 Policies
Can RACF see the account code and make a decision? That is what (as I understand it) the initial requirement is. Check the account code and verify the CLASS. Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Wednesday, November 4, 2020 11:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES2 Policies Wouldn't RACF jobclass controls be more appropriate? -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joe Monk Sent: Wednesday, November 4, 2020 10:31 AM To: IBM-MAIN@LISTSERV.UA.EDU 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. 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, > https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.m > bank.pl%2F&data=04%7C01%7Callan.staller%40HCL.COM%7Cd04848476fc74265206f08d880df1093%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637401042848982511%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=f0M%2Bw7n1t2uPc1f6IUlanGNRz%2BZw1CD5wT9SS%2BUeIpU%3D&reserved=0, > e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział > Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 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,https://apc01.safelinks.protection.outlook.com/?url=http%3A%2 > F%2Fwww.mbank.pl%2F&data=04%7C01%7Callan.staller%40HCL.COM%7Cd0484 > 8476fc74265206f08d880df1093%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637401042848982511%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=f0M%2Bw7n1t2uPc1f6IUlanGNRz%2BZw1CD5wT9SS%2BUeIpU%3D&reserved=0, > e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, > 12th Commercial Division of the National Court Register, KRS 025237, NIP: > 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at > 1 January 2020. >
Re: JES2 Policies
While I am always on the lookout for new features that allow replacing local mods with exits and replacing exits with parameters, sometimes the new way is more work or harder to maintain. You have to carve the bird at the joint. The advantage of a program product is that someone else does the maintenance. The disadvantage of a program product is also that someone else does the maintenance. If the vendor doesn't have the same priorities that you do, or worse, drops the product, then you're out on a limb. You have to look at the trade-offs and decide what makes sense for your shop. That said: "Now these are the Laws of the Jungle, and many and mighty are they; But the head and the hoof of the Law and the haunch and the hump is — " document. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Lizette Koehler [stars...@mindspring.com] Sent: Wednesday, November 4, 2020 1:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES2 Policies I have to put in one small comment (well maybe a couple) Start Rant\ First, look at z/OSEM by Trident Software. It does everything you want and more. And if you consider this product, that is what you are trying to create. If the process you want to build is like z/OSEM it should be easy. But it requires a high level of assembler coding expertise. And if it were easy, there would not be a product like z/OSEM to do it. All shops could do it with their eyes close. When you start putting in lots of exits and IF THIS / THEN THAT logic into JES2 or z/OS you will find your processing will have to be constantly reviewed for the "exceptions" >From my view (and I do not know your shop so take this with a grain of salt) Either you let the system run in a vanilla process or you will spend many man (or woman) hours in updating the code you want to implement with upgrades or fixes. IBM will try hard to make sure exits are less impacted by changes, but it cannot be guaranteed. Scenario: The exits are in and working. Now you want to upgrade to the next level of z/OS - how much time will you dedicate to validating these exits and ensure they work as expected? Who can support these exits once the person that wrote them are gone? I know companies will prefer to have someone write code rather than buy a product. However, once SYSPROG1 writes assembler routines to do specific functions, then what happens when that person leaves and there is no one to manage/support those exits in Assembler. /End of Rant Note: Here are some products that might help Trident Software z/OSEM DTS Software EasyExit I worked in a shop with over 500 exits in JES2/zOS/Vtam etc... Each upgrade took longer to do - basically do to validation of the code. One upgrade we decided to reduce that down and let the system perform its own functions. Went down to 30 exits and the systems worked just fine and upgrade times were faster. Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Wednesday, November 4, 2020 10:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES2 Policies First, I still disagree to keep prod and dev on same system. However this is different topic. Second, in your scenario user can put wrong class, but system automagically recognize it using ACCNT field. So - we assume possibility of user mistake in the class coding, but we rely on ACCNT field. Why? Is the field protected from mistakes? How? I don't see any sense here, I'm sorry. When we allow user to use two classes but one is for "better" jobs, and the second for "worse" jobs - in fact we stil allow user to decide. Or make a mistake. For simple control of job classes and service classes (that was in the question) it is enough to use standard RACF profiles. Why to to complicate it? In fact majority of discussion is based on some assumptions, not real and clearly presented needs. That's why I wrote provocating words in my previous message (however no offence intended). Just to encourage OP to better explanation. -- Radoslaw Skorupka Lodz, Poland W dniu 04.11.2020 o 17:30, Joe Monk pisze: > 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. 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 >&g
Re: JES2 Policies
Wouldn't RACF jobclass controls be more appropriate? -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joe Monk Sent: Wednesday, November 4, 2020 10:31 AM To: IBM-MAIN@LISTSERV.UA.EDU 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. 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, > https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.m > bank.pl%2F&data=04%7C01%7Callan.staller%40HCL.COM%7Cd04848476fc74265206f08d880df1093%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637401042848982511%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=f0M%2Bw7n1t2uPc1f6IUlanGNRz%2BZw1CD5wT9SS%2BUeIpU%3D&reserved=0, > e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział > Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 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,https://apc01.safelinks.protection.outlook.com/?url=http%3A%2 > F%2Fwww.mbank.pl%2F&data=04%7C01%7Callan.staller%40HCL.COM%7Cd0484 > 8476fc74265206f08d880df1093%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637401042848982511%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=f0M%2Bw7n1t2uPc1f6IUlanGNRz%2BZw1CD5wT9SS%2BUeIpU%3D&reserved=0, > e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, > 12th Commercial Division of the National Court Register, KRS 025237, 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email t
Re: JES2 Policies
I have to put in one small comment (well maybe a couple) Start Rant\ First, look at z/OSEM by Trident Software. It does everything you want and more. And if you consider this product, that is what you are trying to create. If the process you want to build is like z/OSEM it should be easy. But it requires a high level of assembler coding expertise. And if it were easy, there would not be a product like z/OSEM to do it. All shops could do it with their eyes close. When you start putting in lots of exits and IF THIS / THEN THAT logic into JES2 or z/OS you will find your processing will have to be constantly reviewed for the "exceptions" >From my view (and I do not know your shop so take this with a grain of salt) Either you let the system run in a vanilla process or you will spend many man (or woman) hours in updating the code you want to implement with upgrades or fixes. IBM will try hard to make sure exits are less impacted by changes, but it cannot be guaranteed. Scenario: The exits are in and working. Now you want to upgrade to the next level of z/OS - how much time will you dedicate to validating these exits and ensure they work as expected? Who can support these exits once the person that wrote them are gone? I know companies will prefer to have someone write code rather than buy a product. However, once SYSPROG1 writes assembler routines to do specific functions, then what happens when that person leaves and there is no one to manage/support those exits in Assembler. /End of Rant Note: Here are some products that might help Trident Software z/OSEM DTS Software EasyExit I worked in a shop with over 500 exits in JES2/zOS/Vtam etc... Each upgrade took longer to do - basically do to validation of the code. One upgrade we decided to reduce that down and let the system perform its own functions. Went down to 30 exits and the systems worked just fine and upgrade times were faster. Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Wednesday, November 4, 2020 10:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES2 Policies First, I still disagree to keep prod and dev on same system. However this is different topic. Second, in your scenario user can put wrong class, but system automagically recognize it using ACCNT field. So - we assume possibility of user mistake in the class coding, but we rely on ACCNT field. Why? Is the field protected from mistakes? How? I don't see any sense here, I'm sorry. When we allow user to use two classes but one is for "better" jobs, and the second for "worse" jobs - in fact we stil allow user to decide. Or make a mistake. For simple control of job classes and service classes (that was in the question) it is enough to use standard RACF profiles. Why to to complicate it? In fact majority of discussion is based on some assumptions, not real and clearly presented needs. That's why I wrote provocating words in my previous message (however no offence intended). Just to encourage OP to better explanation. -- Radoslaw Skorupka Lodz, Poland W dniu 04.11.2020 o 17:30, Joe Monk pisze: > 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. 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:
Re: JES2 Policies
First, I still disagree to keep prod and dev on same system. However this is different topic. Second, in your scenario user can put wrong class, but system automagically recognize it using ACCNT field. So - we assume possibility of user mistake in the class coding, but we rely on ACCNT field. Why? Is the field protected from mistakes? How? I don't see any sense here, I'm sorry. When we allow user to use two classes but one is for "better" jobs, and the second for "worse" jobs - in fact we stil allow user to decide. Or make a mistake. For simple control of job classes and service classes (that was in the question) it is enough to use standard RACF profiles. Why to to complicate it? In fact majority of discussion is based on some assumptions, not real and clearly presented needs. That's why I wrote provocating words in my previous message (however no offence intended). Just to encourage OP to better explanation. -- Radoslaw Skorupka Lodz, Poland W dniu 04.11.2020 o 17:30, Joe Monk pisze: 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. 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: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 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: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 Policies
[Default] On 4 Nov 2020 08:31:10 -0800, in bit.listserv.ibm-main joemon...@gmail.com (Joe Monk) wrote: >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. If the system knows what classes are legal for a given account and resource requirement, then it should change the job class to a legal one rather than bounce the job. A submitter should be able to submit a job and based on the account and resources requested the system should assign the appropriate job class. That was how I designed my rewrite of the American Natural Resources EXIT 6 (In the ancient Philips Lighting mods on the CBT tape). Clark Morris > >OP: This has been around a long time, and is very mature... > >Joe > >On Wed, Nov 4, 2020 at 8:20 AM R.S. 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: kont...@mbank.pl. S?d Rejonowy dla m. st. Warszawy >> XII Wydzia? Gospodarczy Krajowego Rejestru S?dowego, KRS 025237, 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: kont...@mbank.pl. District Court for the >> Capital City of Warsaw, 12th Commercial Division of the National Court >> Register, KRS 025237, 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 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: JES2 Policies
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. 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: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy > XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 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: kont...@mbank.pl. District Court for the > Capital City of Warsaw, 12th Commercial Division of the National Court > Register, KRS 025237, 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 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: JES2 Policies
Yes definitely can be done. I have implemented it. You need to be very current on you maintenance, especially in a MAS Gadi - contact me privately if you like. On Wed, 4 Nov 2020 at 16:20, R.S. 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: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy > XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 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: kont...@mbank.pl. District Court for the > Capital City of Warsaw, 12th Commercial Division of the National Court > Register, KRS 025237, 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Mike Shorkend m...@shorkend.com Tel: +972524208743 <https://www.linkedin.com/in/MikeShorkend/> <https://twitter.com/mikeShorkend> -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 Policies
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: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 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: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
JES2 Policies
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? Thanks Gadi -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN