Prevent batch jobs from accessing Data Sharing member

Lockwood Lyon

Prevent batch jobs from accessing Data Sharing member
Esteemed List,

I need to test the viability/quality of some DB2 V7 for z/OS PUTnnnn maintenance. To do this I want to bring up one member of our 4-way DB2 data sharing group with the maintenance applied, but prevent batch jobs from running against it :)

So, basically, we have a 4-way DS group with DB2 subsystems DSN1 - DSN4. Subsystems DSN1, DSN2, and DSN3 are already up on our two production LPARs. The IEFSSNxx member of ParmLib has these MVS subsystems defined with a Group name of GRP1.

All (well, most) of our batch jobs attach to the Group Attach name, GRP1.

A typical SSN entry is:

SUBSYS SUBNAME(DSN4) INITRTN(DSN3INI) INITPARM('DSN3EPX,-DSN4,S,GRP1')

So, I want to bring up DSN4, prevent batch access, while allowing SPUFI, distributed (i.e., thru DDF), etc.

I considered the MVS SETSSI command, but the Activate/Deactivate parameters don't allow me to change the InitParm. At least that's what the manuals seems to say.

I considered bringing up DSN4 in ACCESS(MAINT) mode, but this makes it inconvenient to run multiple tests or do regression testing.

Any other ideas? Thx in advance!

- Lockwood Lyon
Meijer Stores

Wayne Driscoll

Re: Prevent batch jobs from accessing Data Sharing member
(in response to Lockwood Lyon)
Lockwood,
Just a thought off the top of my head, but since each member has its own
zparm, you should be able to set the IDBACK parm to zero, which will disable
all CAF and RRS connections. You also might want to lower IDFORE to limit
the ability for TSO attach to succeed as well.
Wayne Driscoll
Product Developer
Quest Software Inc.
[login to unmask email]
Note: All opinions are strictly my own.

-----Original Message-----
From: Lockwood Lyon [mailto:[login to unmask email]
Sent: Friday, January 03, 2003 1:07 PM
To: [login to unmask email]
Subject: [DB2-L] Prevent batch jobs from accessing Data Sharing member


Esteemed List,

I need to test the viability/quality of some DB2 V7 for z/OS PUTnnnn
maintenance. To do this I want to bring up one member of our 4-way DB2 data
sharing group with the maintenance applied, but prevent batch jobs from
running against it :)

So, basically, we have a 4-way DS group with DB2 subsystems DSN1 - DSN4.
Subsystems DSN1, DSN2, and DSN3 are already up on our two production LPARs.
The IEFSSNxx member of ParmLib has these MVS subsystems defined with a Group
name of GRP1.

All (well, most) of our batch jobs attach to the Group Attach name, GRP1.

A typical SSN entry is:

SUBSYS SUBNAME(DSN4) INITRTN(DSN3INI)
INITPARM('DSN3EPX,-DSN4,S,GRP1')

So, I want to bring up DSN4, prevent batch access, while allowing SPUFI,
distributed (i.e., thru DDF), etc.

I considered the MVS SETSSI command, but the Activate/Deactivate parameters
don't allow me to change the InitParm. At least that's what the manuals
seems to say.

I considered bringing up DSN4 in ACCESS(MAINT) mode, but this makes it
inconvenient to run multiple tests or do regression testing.

Any other ideas? Thx in advance!

- Lockwood Lyon
Meijer Stores

James Campbell

Re: Prevent batch jobs from accessing Data Sharing member
(in response to Wayne Driscoll)
A well known limitation of DB2.

Fortunately, I've never actually had this problem myself, but the way
I've pondered on doing this is to modify all the permissions for racf
class DSNR profiles DSN4(in your case).BATCH, DSN4.MASS, DSN4.SASS,
DSN4.DIST and DSN4.RRSAF so that only known users can use them.

If you use Wayne's IDBACK=0 method, remember that QMF uses CAF - so
would be locked out.

James Campbell


On 3 Jan 2003 at 14:07, Lockwood Lyon wrote:

> Esteemed List,
>
> I need to test the viability/quality of some DB2 V7 for z/OS PUTnnnn maintenance. To do this I want to bring up one member of our 4-way DB2 data sharing group with the maintenance applied, but prevent batch jobs from running against it :)
>
> So, basically, we have a 4-way DS group with DB2 subsystems DSN1 - DSN4. Subsystems DSN1, DSN2, and DSN3 are already up on our two production LPARs. The IEFSSNxx member of ParmLib has these MVS subsystems defined with a Group name of GRP1.
>
> All (well, most) of our batch jobs attach to the Group Attach name, GRP1.
>
> A typical SSN entry is:
>
> SUBSYS SUBNAME(DSN4) INITRTN(DSN3INI) INITPARM('DSN3EPX,-DSN4,S,GRP1')
>
> So, I want to bring up DSN4, prevent batch access, while allowing SPUFI, distributed (i.e., thru DDF), etc.
>
> I considered the MVS SETSSI command, but the Activate/Deactivate parameters don't allow me to change the InitParm. At least that's what the manuals seems to say.
>
> I considered bringing up DSN4 in ACCESS(MAINT) mode, but this makes it inconvenient to run multiple tests or do regression testing.
>
> Any other ideas? Thx in advance!
>
> - Lockwood Lyon
> Meijer Stores
>



Chris White

Re: Prevent batch jobs from accessing Data Sharing member
(in response to James Campbell)
Here's a couple of half-baked ideas on the subject...

1. I'm not sure about this one, but is it possible to create a subsystem
definition in parmlib for the 'maint' subsystem with a DIFFERENT (un-
advertised) group attach name? If so, that should do it. If not, then...

2. I have not tested this, but I remember hearing a presentation a few
years back that included this topic. The presenter claimed that all
attempts to attach to DB2 via the group attach name seemed to go to the
first subsystem defined in IEFSSNxx. He had a 'maint' subsystem that was
defined last in each parmlib. He could bring up the 'maint' subsystem
while the 'regular' subsystem was running and the only threads that
attached to the 'maint' subsystem were ones that explicitly called for it
by SSID instead of group attach name. This was before WLM was as
sophisticated as it is today so things may be different now...

HTH...

Chris White

===<snip>===>
On Sun, 5 Jan 2003 14:25:46 +1000, James Campbell
<[login to unmask email]> wrote:

>A well known limitation of DB2.
>
>Fortunately, I've never actually had this problem myself, but the way
>I've pondered on doing this is to modify all the permissions for racf
>class DSNR profiles DSN4(in your case).BATCH, DSN4.MASS, DSN4.SASS,
>DSN4.DIST and DSN4.RRSAF so that only known users can use them.
>
>If you use Wayne's IDBACK=0 method, remember that QMF uses CAF - so
>would be locked out.
>
>James Campbell
>
>
>On 3 Jan 2003 at 14:07, Lockwood Lyon wrote:
>
>> Esteemed List,
>>
>> I need to test the viability/quality of some DB2 V7 for z/OS PUTnnnn
maintenance. To do this I want to bring up one member of our 4-way DB2 data
sharing group with the maintenance applied, but prevent batch jobs from
running against it :)
>>
>> So, basically, we have a 4-way DS group with DB2 subsystems DSN1 -
DSN4. Subsystems DSN1, DSN2, and DSN3 are already up on our two production
LPARs. The IEFSSNxx member of ParmLib has these MVS subsystems defined
with a Group name of GRP1.
>>
>> All (well, most) of our batch jobs attach to the Group Attach name, GRP1.
>>
>> A typical SSN entry is:
>>
>> SUBSYS SUBNAME(DSN4) INITRTN(DSN3INI) INITPARM('DSN3EPX,-
DSN4,S,GRP1')
>>
>> So, I want to bring up DSN4, prevent batch access, while allowing SPUFI,
distributed (i.e., thru DDF), etc.
>>
>> I considered the MVS SETSSI command, but the Activate/Deactivate
parameters don't allow me to change the InitParm. At least that's what the
manuals seems to say.
>>
>> I considered bringing up DSN4 in ACCESS(MAINT) mode, but this makes it
inconvenient to run multiple tests or do regression testing.
>>
>> Any other ideas? Thx in advance!
>>
>> - Lockwood Lyon
>> Meijer Stores
>>
>
>
>
the DB2-L webpage at http://listserv.ylassoc.com. The owners of the list
can