Re: JES2 Policies

[Joe Monk]

"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.Please be reminded that a

Re: JES2 Policies

[R.S.]

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 
Service Class STCLOW  and CLASS X


L

Re: JES2 Policies

[R.S.]

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

[G. Tom Russell]

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

[retired mainframer]

> -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

[Mike Schwab]

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-
> > From: IBM Mainframe Discussion List  O

Re: JES2 Policies

[Seymour J Metz]

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 Capital City of Warsa

Re: JES2 Policies

[R.S.]

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

[R.S.]

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 looking into JES2 Policies.

The current goal 

Re: JES2 Policies

[Joe Monk]

"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

[R.S.]

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

[R.S.]

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

[Gadi Ben-Avi]

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 change a job's class or service

Re: JES2 Policies

[kekronbekron]

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.
> > >
> > > Has anyone done something lik

Re: JES2 Policies

[Gadi Ben-Avi]

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

--
For IBM-MAIN su

Re: JES2 Policies

[Seymour J Metz]

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

[Jesse 1 Robinson]

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

[Lizette Koehler]

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%2Fdata=04%7C01%7Callan.staller%40HCL.COM%7Cd04848476fc74265206f08d880df1093%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637401042848982511%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=f0M%2Bw7n1t2uPc1f6IUlanGNRz%2BZw1CD5wT9SS%2BUeIpU%3Dreserved=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%2Fdata=04%7C01%7Callan.staller%40HCL.COM%7Cd0484
> 8476fc74265206f08d880df1093%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637401042848982511%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=f0M%2Bw7n1t2uPc1f6IUlanGNRz%2BZw1CD5wT9SS%2BUeIpU%3Dreserved=0,
&g

Re: JES2 Policies

[Lizette Koehler]

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%2Fdata=04%7C01%7Callan.staller%40HCL.COM%7Cd04848476fc74265206f08d880df1093%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637401042848982511%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=f0M%2Bw7n1t2uPc1f6IUlanGNRz%2BZw1CD5wT9SS%2BUeIpU%3Dreserved=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%2Fdata=04%7C01%7Callan.staller%40HCL.COM%7Cd0484
> 8476fc74265206f08d880df1093%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637401042848982511%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=f0M%2Bw7n1t2uPc1f6IUlanGNRz%2BZw1CD5wT9SS%2BUeIpU%3Dreserved=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

[Seymour J Metz]

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
>> on certain values i

Re: JES2 Policies

[Allan Staller]

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%2Fdata=04%7C01%7Callan.staller%40HCL.COM%7Cd04848476fc74265206f08d880df1093%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637401042848982511%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=f0M%2Bw7n1t2uPc1f6IUlanGNRz%2BZw1CD5wT9SS%2BUeIpU%3Dreserved=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%2Fdata=04%7C01%7Callan.staller%40HCL.COM%7Cd0484
> 8476fc74265206f08d880df1093%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637401042848982511%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=f0M%2Bw7n1t2uPc1f6IUlanGNRz%2BZw1CD5wT9SS%2BUeIpU%3Dreserved=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 to 
lists...@listserv.ua.edu with the message: INFO IBM-M

Re: JES2 Policies

[Lizette Koehler]

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:

- powiadom nas o tym w mailu 

Re: JES2 Policies

[R.S.]

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

[Clark Morris]

[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

[Joe Monk]

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

[Mike Shorkend]

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





--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: JES2 Policies

[R.S.]

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