ACF2/DB2

[John VanBruwaene]

We looked at this product a few years ago and had so many reasons for not
using it that I'm not sure we will ever consider it again. Some of the
ones that I can remember are:

- it modifies IBM OCO code and does not run in any exits (this is bad for
stability and problem solving).
- You could not get more than 4K worth of rules per resource (at that time
there was no nextkey support)
- We felt very uncomfortable getting rid of DB2's security environment
- Questions like how does this fit in with secondary authid support
- etc.
Have things changed? I don't know -- we haven't had a reason to
re-evaluate ACF2/DB2.

Our comp[any has made extensive use of secondary authID support that
includes support for ACF2 resources -- it works just as well as ACF2/DB2
support and is supported.

//--------John VanBruwaene----TMG---------
// Internet (Home): jv...@hookup.net
// Internet (Work): catm...@ibmmail.com
//----------------------------------------

[Jerome Peter]

I'm a DBA in a DB2 shop which uses ACF2/DB2 in all environments.

We have found that the product seem to work very well most of the time
and has allowed us to create a range of generic rules which significantly
reduces the amount of time/effort spent on the administration of DB2
internal security.

For example, we have set up generic rules along the following lines :-

Sub-system DB2P
Resource type TBL
Name PROD.SLP-
Access SELECT
UIDs BUS**ABC

This type of rule would allow provide SELECT authority on all tables
beginning PROD.SLP to any users with an ACF2 UID string which started
BUS**ABC. This means that we can create new tables beggining PROD.SLP and
not have to change a single security rule. This is VERY useful within
development where we have set up a number of differing
development/testing environments with a handful of ACF2/DB2 rules which
require NO changes (try doing that with DB2).

With reference to Andy Lankester's note, I would agree that some DB2
catalog products use the DB2 catalog to migrate GRANT statements when
moving database structures. However, the experience I've had with this
type of product and ACF2/DB2, seems to show that migrations are not
really a problem. Generally, any new objects would be covered by any
'catch all' rules or specific rules could be set-up in advance.

I'm not claiming that ACF2/DB2 is a perfect product. I have some concerns
about CA's capability to ensure ACF2/DB2 keeps current with new releases
of DB2 (afew years back, we had to delay the migration to 2.3 until
ACF2/DB2 supported Packages). Secondly, we have had one occasion when the
technical support provided was a little slow, and it took a couple of
weeks to resolve a problem where an internal ACF2 table was filling up
which caused QMF users (in particular) to get authority errors.

Finally, I'm aware of some products that access the DB2 catalog tables
directly for any authority information, without going through the
standard DB2 security interface. So far, these products have tended to be
in the realm of DB2 DBA catalog tools which have required a seperate
GRANT SYSADM statement to be executed.

I hope this helps a little.

If you wold like any further information, please feel free to continue
this discussion through USENET or e-mail me directly.

Many Thanks ...... Jerry McKeon (jer...@cix.compulink.co.uk)