This is a connect authorization issue so it’s the very first
thing that Db2 is doing, and so anything related to Db2 security or
resource limit will not work. I think you would have to modify the
authorization exit to reject these users prior to Db2 calling RACF
to authenticate them. We did, long age, use a modified
authorization exit at your site for SYSADM auth id’s. That
was for TSO connections. You will have to modify the exit for DDF
connections. Then, I am not sure about this, but you would have to
toggle the exit. Maybe someone can confirm if this would actually
require a bounce of the subsystems.
Not a lot of work, and you might be able to do it quickly.
I’m just not sure about whether you need to bounce Db2. Of
course you’d have to toggle back to the default routine when
they fix the authid in question.
Daniel L Luksetich
DanL Database Consulting
IBM GOLD Consultant
IBM Champion for Analytics
IDUG Content Committee Past-Chairman
IDUG DB2-L Administrator
IBM Certified Database Adminstrator – DB2 11 DBA for z/OS
IBM Certified System Administrator – DB2 11 for z/OS
IBM Certified Application Developer – DB2 11 for z/OS
IBM Certified Advanced Database Administrator – DB2 10.1 for
Linux UNIX and Windows
From: Tony Saul <[login to unmask email]>
Sent: Wednesday, April 18, 2018 10:37 PM
To: [login to unmask email]; Donna Domovic
<[login to unmask email]>
Subject: [DB2-L] - RE: How to prevent distributed user from
connecting to DB2
I haven't tried this, but could you use the DSNRLMT01 resource
If the DSNRLMT01 could be used, maybe you could have automation
that will update the DSNRLMT01 table based on receiving the
DSNL030I error. Then when the particular server has the password
updated, the entry in DSNRLMT01 can be deleted.
On Thursday, 19 April 2018, 11:56:41 am ACST, Donna Domovic
<[login to unmask email] <mailto:[login to unmask email]>
This is going to sound like a strange question but I'm hoping
someone can help.
In RACF, we currently have the DIST profile in the DSNR class set
up so that everyone can connect to DB2 from PCs, servers, etc. We
do want to keep it this way because of the large number of users
and applications we have. The ids are required to have passwords
and be authorized to the data they're accessing so this handles our
The problem is that we have situation where the password for the id
used to connect expires or the script is not updated when it
changes which results in the id being revoked This would normally
not be a problem but many of our applications don't put in error
handling (I know this should be a requirement) which means the
application continues to run and we et 1000's of DSNL030I messages
(usually every few seconds) which flood the console and the DB2
MSTR started task.
The question I have is, is there a way prevent certain ids from
connecting while allowing all other ids to connect?
We are trying to work with the applications to get the required
error checking added but I have very little faith that that will
Hopefully this question makes sense. If you have any questions,
please let me know.
-----End Original Message-----
-----End Original Message-----