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 <IBM-MAIN@LISTSERV.UA.EDU> 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. <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. >>> >>> 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 0000025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 0000025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to 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
