IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Route a product's job to specific lpar


IBM Mainframe Forums -> All Other Mainframe Topics
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
vasanthz

Global Moderator


Joined: 28 Aug 2007
Posts: 1689
Location: Tiruppur, India

PostPosted: Thu Mar 02, 2017 2:22 am
Reply with quote

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
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 870
Location: The Universe

PostPosted: Thu Mar 02, 2017 4:26 am
Reply with quote

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
View user's profile Send private message
vasanthz

Global Moderator


Joined: 28 Aug 2007
Posts: 1689
Location: Tiruppur, India

PostPosted: Thu Mar 02, 2017 5:13 am
Reply with quote

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
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8569
Location: Dubuque, Iowa, USA

PostPosted: Thu Mar 02, 2017 7:21 am
Reply with quote

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
View user's profile Send private message
Pete Wilson

Active User


Joined: 31 Dec 2009
Posts: 490
Location: London

PostPosted: Thu Mar 02, 2017 1:27 pm
Reply with quote

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
View user's profile Send private message
enrico-sorichetti

Senior Moderator


Joined: 14 Mar 2007
Posts: 10714
Location: italy

PostPosted: Thu Mar 02, 2017 2:02 pm
Reply with quote

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
View user's profile Send private message
Willy Jensen

Active User


Joined: 01 Sep 2015
Posts: 416
Location: Denmark

PostPosted: Thu Mar 02, 2017 3:28 pm
Reply with quote

Can you remove that program from lpars where you don't want it to run?
Back to top
View user's profile Send private message
enrico-sorichetti

Senior Moderator


Joined: 14 Mar 2007
Posts: 10714
Location: italy

PostPosted: Thu Mar 02, 2017 3:41 pm
Reply with quote

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
View user's profile Send private message
Pete Wilson

Active User


Joined: 31 Dec 2009
Posts: 490
Location: London

PostPosted: Thu Mar 02, 2017 6:27 pm
Reply with quote

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
View user's profile Send private message
vasanthz

Global Moderator


Joined: 28 Aug 2007
Posts: 1689
Location: Tiruppur, India

PostPosted: Fri Mar 03, 2017 6:26 am
Reply with quote

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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> All Other Mainframe Topics

 


Similar Topics
Topic Forum Replies
No new posts REMOVE DUPLICATE RECORDS BASED ON A S... DFSORT/ICETOOL 4
No new posts using TXT2PDF to colour specific lines All Other Mainframe Topics 3
No new posts DFSORT to handle in between specific ... DFSORT/ICETOOL 6
No new posts Extracting a list of ALL DSN's on an ... IBM Tools 14
No new posts Dates compare on specific dates using... DFSORT/ICETOOL 2
Search our Forums:

Back to Top