Idea Details

Enhance Top Secret for DB2 security administration

Last activity 05-31-2019 01:56 AM
Josef Thaler's profile image
08-13-2015 03:13 PM

As a Top Secret Security Administrator I need an efficient, effective and clear implementation of the administration of DB2-ressources.


Therefore I suggest to enhance Top Secret for DB2, to precede each checked ressourcename with an optional customizable prefix.


Installations, which have to run several db2 subsystems in the same sysplex and have to graduate and distingush the security permissions between the particular db2 subsystems could significantly benefit from the business value of this enhancement:


  1. From a conceptual perspective the local db2 ressourcenames (for one facility) will become global ressourcenames.
  2. Ownership of ressources and their administrative permissions could be introduced per db2 subsystem.
  3. The permission to a db2 ressource of a particular db2 subsystem would not be needed to be specified with control option FACILITY( ) any more.
  4. All powerful instruments of TSS commands could be used much more efficient (TSS LIST, TSS WHOHAS, TSSSIM, and so on)
  5. The first two characters of the db2-ressource would be maskable (today it’s not possible because of the minimum prefix length)
  6. The number of db2-facilities could be reduced to one or two. The entry-access to the db2 subsystems is anyway controlled by “DB2” resclass.
  7. The ressourcename would become similar to Websphere-MQ-ressourcenames (MQ-entities like MQQUEUE etc. begin with the queue-manager-id)
  8. A competitive inferiority (IBM's optional RACF/DB2 external security module supports the choice between "single subsystem class scope"  and "multi-subsystem class scope"!) could be turned in a superior approach by this enhancement.
  9. The "best match" determination will be improved. (in the current implementation FACILITY( ) is not involved in "best match" determination; this leads to misunderstandings and arises the need additional administration. e.g PER DB2TABLE(XYZ) FAC(DSN1) undercuts a PER DB2TABLE(XY) FAC(DSN2) although these are different db2-subsystems)


There is no formal demand how to implement this enhancement.

For illustration purposes I suggest a new DB2FAC TSS-startup-option in addition to DB2FAC(DBT1=DSNDBT1) (while DBT1 is the DB2-membername and DSNDBT1 the facility-id), for example:




(while DB2GRP should be replaced by the DB2-sharing-group-identifier – let’s say DBTG - resp. ‚DBTG‘ as literal)


Current permissions, for example (and in assumption of above control options)



would “prefixed” have to look like





Yes, the implementation of such a ressource prefix would ask for a conversion of the current permissions, but I would consider this effort very worth because of the resulting better, more efficient and concludent security administration of db2 ressources.


As non-native-english speaker my definition of the enhancement might be not clear enough in formulation, any amendment and supplement would be appreciated very much.


reworked 2015-08-18: Business value item 7 added.


reworked 2015-09-03: Business value item 8 added.

reworked on 2015-11-09: Business value item 9 added.


03-14-2016 03:38 PM

Hello Kimberly,

thank you for your status-update and your acceptance of this idea to the wishlist.

I'm confronted to the disadvantages of the current implementation at every db2-security-admin.

In the meantime I know, that via TSSINSTX it could be possible to insert the Db2-group into the ressourcename, but I hesitate to develop and implement such a solution, because a transformation of all db2-related permissions would be necessary (with all included risks) to achieve the benefit in security-admin.

When a solution would be available out-of-the-box in future, a second transformation of all db2-related permissions could become necessary.

Therefore I'd like to ask you for an indication, why - in light of the essential advantages listed in the original post - this idea can not be picked up now, and what you would recommend for the meantime? Would there be a better alternative than TSSINSTX?

Many thanks and kind regards,


02-05-2016 12:20 PM

Hello Josef and TSS Community - Thank you for your contribution of this enhancement idea!


CA is continually working to improve its software and services to best meet the needs of its customers and your input is vital to that effort. The CA Top Secret product team has reviewed your enhancement idea and decided to add it to our Wishlist to maintain this idea for consideration in a future release. The Community will continue to be able to vote on this enhancement idea which can increase the priority of it in the Team's backlog. When the product team knows it will being working on this enhancement idea, the status will be changed to "currently planned."

12-18-2015 01:32 AM

This is really great news, John!


yes, I'm interested

  • although I'd prefer a solution out of the box for several reasons, e.g. I really believe, that the suggested idea comes down to a real enhancement not only for my site, please see the business value in the original post. You might still vote for it.
  • although or just because I asked the question to CA Technical Support and got the answer:

I'll try to make contact soon ...



12-17-2015 08:01 PM



The basic functionality that you are seeking, specifically, to be able to apply a prefix to various DB2xxxxx resources, can easily be implemented via the TSS installation exit.


Please feel free to contact me to discuss how this can be accomplished.


John P. Baker

09-04-2015 07:06 AM

Hello Josef, i have voted for this enhancment. Although our number of db2 subsystem is lower than yours, this enhancement would be helpful for us if we use more than one test db2

09-04-2015 02:24 AM



Yes, that's interesting. It should make thing easier.


Sincerely, Jacques.

09-03-2015 11:28 AM

Hello RVS,


as meanwhile confirmed by a CA Support case, there is currently no way to implement the suggested enhancement (in short: local scope vs. global scope of db2-ressourcenames) in Top Secret by Exit TSSINSTX or other means.


As I think, that the idea would be a real enhancement, I'd like to invite you and everybody here again to reflect, comment and support this request.


Kind regards,


08-25-2015 08:55 AM

Hello RVS,

thank you so much for your update and hints, and to bring my attention to the question, whether Db2 itself could be customized ... in a quick research I found in DB2-manuals:


"Customizing the RACF/DB2 external security module (optional)"


CLASSOPT Specifies the class scope option

Allowable values are:

1 single subsystem class scope

2 multi-subsystem class scope. This is the default.


This could be the starting point to the solution! Perhaps also for you (to get rid of ressouce class translation, if this is used only to separate the ressource-names ... ) 


PS.:  I just realized, that my hit refers to RACF but anyway it's a good starting Point to for further researches for Top Secret ... 


Kind regards,


08-25-2015 08:35 AM

hello maybe its an option to only translate important classes e.g DB2TABLE, DB2DBASE for every subsystem.

use other resources like (not so important) DB2SEQ unchanged (maybe already in all record)


or is it possible with db2 exits to change the string that is check in esm?


cics itself has a secprefix parm. maybe db2 has somthing similar. but i have never tested anything in this area.

08-20-2015 11:34 AM

Hello RVS,


many thanks for your helpful comment, to bring my attention to "ressource class translation", and that you are thinking and sharing ...


Unfortunately this approach would not work for our installation because of the number of db2 systems being driven in our shop.


Beyond this, one of my consiterations to bring this enhancement request, is my experience, that it's the best way to use the concepts  of a product in the intended way:

RESCLASS represents the type of ressource to be accessed

FACILITY represents the application Environment though which a ressource can be accessed and the user logs on.

RESNAME repesents the ressource identification of the ressource being accessed.


I think, this enhancement request introduces a kind of "high level qualifier" to the DB2 ressources.

  • I'm pretty sure, that in many z/OS installations using db2 are more than one db2 subsystem.
  • So, if you come in contact to a ressource  DB2TABLE(creator.tablename) you immediately ask yourself: In which Db2-subsystem?  Because from my view a table in subsystem_one is a complete different entity than a table with the same name in subsystem_two.
  • I'm also pretty sure, that in many z/OS installations are more than one icf user catalog; probably deviding datasets of different stages in separate usercatalogs, (for example: development versus test versus prod) depending from the high level qualifer (hlq):
  • Would you then access the dataset by using its low-level-qualifiers and "hide" its high-Level-qualifier in the FACILITY-Attribute?
  • Or illustrated in TSS-commands: would you use PER(acid) DATASET(llq1.llq2.llq3) FACILITY(hlq) or would you prefer PER(acid) DATASET(hlq.llq1.llq2.llq3)
  • Therefore I also would prefer to - and this is the quintessence of this idea - use a PER(acid) DB2TABLE(dsnx.creator.tablename) to a PER(acid) DB2TABLE(creator.tablename) FACILITY(dsnx) because of all the business value noted in my original post.


Any additional comments, alternatives, experiences, opinions, votes ... ... are very welcome and appreciated.



08-20-2015 07:51 AM

hello such a feature is nice, but there is another similar option already in tss


resource class translation


define e.g. xxxTABLE Resource in RDT similar to DB2TABLE


thein in your TSS Parm add the following to




we use this to use separate permissions for a test and production db2

we have defined 17 such translated resources.


of course if you have lots of db2 instances you may run out of resclasses

08-18-2015 08:00 AM

I discussed this idea with Josef.  This sounds like a good idea, although I'm not sure how much work would be involved or the complexity needed to create such a function in Top Secret.  Josef was keen for this idea to be progressed by CA because there was a great need for this function within his company, due to the many Resources required to be administered.