Yes - I have -- I am no longer an instant deep AI catalog interface on the how to. But here goes
As with many things there are many ways to skin a cat. I used pervasive encryption of z/OS and RACF. Defined keys and stored them in the ICSF CKDS. Defined the RACF permission for who could access those keys. Defined the RACF DSD profiles for the DB2 tablespaces and Indexspaces to use the keys created above. Allowed the DB2MSTR address space all the access he could want to those keys and those physical tablespaces, etc. Online SHRLEVEL CHANGE reorg of the tablespaces then cause the creation of new physical tablespace under the new encryption rules. You can unload, del/def and reload them in a multistep nightmare but that is a bit uglier. The entry in the z/OS catalog will link the key label to the data during the initial allocation of the file. Data Management will 'pervasively' encrypt/decrypt as you do reads and writes to the physical files. ---- There are of course other ways to trigger or select what keys to use for the pervasive encryption. If you are manally doing IDCAMS DEL/DEFS then the responsibility for key specification is up to you. Your SMS ACS routines could be used to override the choice for the files you wish. I also believe there are ways in the DB2 Catalog TABLESPACE definitions to specifiy the pervasive key to use. RACF holds the final permissions for whether you can encrypt at all and which key labels that you allow to be used. ---- If you are talking about old fashioned field or row level encryption of parts of a table, I am outta here. That was a little beyond my toolset and knowledge. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN