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