View previous topic :: View next topic
|
Author |
Message |
vasanthz
Global Moderator
Joined: 28 Aug 2007 Posts: 1742 Location: Tirupur, India
|
|
|
|
Hi,
We have 2 lpars and JES2 is shared between them and also the DASD.
We need to route all jobs containing a particular PGM=XXXXYYYY to one single LPAR.
Basically we are trying to restrict a product to run only in 1 lpar, eventhough the batch job could be submitted on the other.
Could you please give me pointers of how this could be achieved.
Would WLM or Automation software be able to do this?
Regards, |
|
Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
|
|
|
|
See the discussion about the SYSAFF=xxx parameter in the /*JOBPARM statement (or its JES3 equivalent) in the JCL reference manual for your z/OS release.
Here you specify the system ID as it is used in JES2 or JES3 directly; it does not key on a program name as you propose.
If you insist on keying on a program name, you can use an exit, at least in JES2. This exit is not going to be simple to write. |
|
Back to top |
|
|
vasanthz
Global Moderator
Joined: 28 Aug 2007 Posts: 1742 Location: Tirupur, India
|
|
|
|
Hi Steve,
Thank you for your thoughts, I am aware of the SYSAFF parameter and it works well in our site, but there is a possibility that a user might run a batch job without the SYSAFF parameter and the product would get invoked in the lpar which we don't intend to run.
I have no experience in JES2 exits and would have research what it is. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
JES3 makes this an easy task since the global routes work to each LPAR. JES2, it's not so easy. Can you assign the job to a particular job class? If so, start an initiator on the desired LPAR with that job class and make sure no initiators on the other LPAR have that job class. If this is not an option, you may have to write a JES2 user exit. |
|
Back to top |
|
|
Pete Wilson
Active Member
Joined: 31 Dec 2009 Posts: 580 Location: London
|
|
|
|
You can specify the SYSAFF with a 'minus' before an LPAR name you DO NOT want the job to run on.
e.g.
/*JOBPARM SYSAFF=(-lpar1)
There's also the option for SCHENV= on the jobcard (scheduling environment) that can be set up for this purpose. I haven't set one up but I have seen it used a lot to ensure certain jobs run only on selected LPAR's to help with licencing costs for example. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10873 Location: italy
|
|
|
|
Quote: |
but there is a possibility that a user might run a batch job without the SYSAFF parameter and the product would get invoked in the lpar which we don't intend to run. |
IMO the whole discussion is a moot point
If You rely on an hand coded parameter, whatever the choice - CLASS, SYSAFF, ROUTE, SCHENV -
the human error factor will always be there and You will have to live with that ... |
|
Back to top |
|
|
Willy Jensen
Active Member
Joined: 01 Sep 2015 Posts: 712 Location: Denmark
|
|
|
|
Can you remove that program from lpars where you don't want it to run? |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10873 Location: italy
|
|
|
|
Quote: |
Can you remove that program from lpars where you don't want it to run? |
I also had thought on how to prevent the execution on the wrong LPAR
- RACF, private libraries, hacking the control blocks , ...
but all might leave behind a lot of garbage
tht' s why I did not suggest it |
|
Back to top |
|
|
Pete Wilson
Active Member
Joined: 31 Dec 2009 Posts: 580 Location: London
|
|
|
|
You could have an initial REXX step that issues the MVS command 'D SYMBOLS' and sets a non-zero retrun code if wrong LPAR name is shown in the &SYSNAME returned in the display. That way any subsequent steps would only execute if the steps sets RC=00.
But SHENV in my experience works perfectly. We use it to ensure PGM=SAS jobs only run on selected LPAR's to save licensing costs. Never seen any issue with it for many years. |
|
Back to top |
|
|
vasanthz
Global Moderator
Joined: 28 Aug 2007 Posts: 1742 Location: Tirupur, India
|
|
|
|
Hi All,
Thank you for your inputs. The SCHENV or SYSAFF parameter would work but as Enrico mentioned, there is always the possibility that a user might submit a job which does not have those parameters.
Quote: |
Can you assign the job to a particular job class? If so, start an initiator on the desired LPAR with that job class and make sure no initiators on the other LPAR have that job class. |
This is a nice idea but I don't know how to assign a CLASS to a job based on the program the job runs. We have a JES2 exit written which automatically changes CLASS parameters, but it is on assembler and difficult to understand.
Quote: |
Can you remove that program from lpars where you don't want it to run? |
This is a potential idea. But I don't know how to do this. The DASD is shared between two lpars and product datasets are catalogued on both the lpars. So I dont know how to make datasets available only on specific lpar.
Quote: |
RACF, private libraries, hacking the control blocks |
I am no RACF expert either, is it possible to make universal access of NONE only on 1 lpar? |
|
Back to top |
|
|
|