Comparison of CP-level Versus CMS-level

Develop Implementation Strategy › Implementation by Facility › OS/DOS Data Sets and Volumes › Comparison of CP-level Versus CMS-level

Comparison of CP-level Versus CMS-level

These two DASD data security methods differ in behavior and in the data configurations they support. The following table summarizes these differences:

CP-level	CMS-level
All VSAM I/O treated as SYSVSAM.Vvolser	Supports VSAM by cluster/catalog name
Enforced only for full-pack minidisks	OS- or DOS-formatted minidisk support
Intercepts actual I/O,guest operating system-independent	Enforced only for programs using CMS OPEN interface
May be disabled system-wide with NOSIOCHK control option	Always active if installed in the IPLed CMS system
Cannot be bypassed	Can be defeated by sophisticated users
Fails access on first physical I/O to data set with condition code 3	Fails access at OPEN time

Another important consideration in evaluating CP-level Data Set Protection is that it may deny access to certain unusually complex channel programs whose design prevents, or presents a threat to, accurate data set identification. While such channel programs typically indicate a deliberate attempt to circumvent security, it is possible for a well-intended program or system to unintentionally encounter this situation if it is using unusual I/O techniques or accessing nonstandard direct-access data structures. This denial occurs for undefined or DORMant users. You must identify users of applications with the potential for risk in this area and test this feature with them before implementing it.

Also be aware that neither of these two types of protection are intended to be used with other guest operating systems or with multi-user service virtual machines (such as data base servers). Since these systems perform work on behalf of a number of different accessors, CA Top Secret is unable to determine whose authority to apply for access verification. Such systems must provide their security or request verification on behalf of end-users via the CA Top Secret Application Interface, and must be defined with NOVOLCHK and NODSNCHK attributes.

See the Implementation Guide for additional information on data set security implementation procedures.