Security for IMS DDL

Security for issuing the DDL

You can set up security around who can issue the DDL and make changes to resources. For example, you might not want Application Developers to make DB changes, only PSB changes.

Security for activating the DDL

You can set up less security around who can issue the DDL to make changes but more security around who activates them. For example, you might have Application Developers make the changes but only System Programmers or DBAs activate the changes after analyzing the impact of the changes, meaning, reorganizing or application outages.

Security for resources

You might want to consider what the DDL does under the covers as part of that change. For example, DDL for DROP DATABASE will eventually try to delete data sets, however, you might have RACF® restricting those data sets. In this case, ensure that IMS is authorized so that it can actually perform the task.

In IMS Enterprise Suite Explorer for Development, you can restrict who can submit DDL to IMS.

For more information, see Submitting DBD field changes to IMS with IMS 14.

In IMS, you can restrict who can access a given PSB.

This uses existing security mechanisms for PSBs. You can secure the PSB named DFSCP001 to restrict who can issue DDL. For more information, see Security for ODBA application programs.

In IMS, you can restrict who can issue the IMPORT DEFN command for IMS Explorer security.

IMPORT is a type-2 command; the command security is the existing type-2 command security in OM. The security is based on IMPORT DEFN, therefore, you will need to write OM security exit to have granular security based on SOURCE(CATALOG). For more information, see CSL OM command security.