As with all datasets on DASD, z/OS establishes the encryption-related attributes of Adabas database container datasets when the datasets are created. The Adabas component responsible for I/O operations (ADAIOR) recognizes encrypted datasets and adjusts its processing logic to deal with them properly. The Adabas nucleus and utilities are for the most part unaware of the encryption of database container datasets.
It is technically possible to encrypt some of the ASSO and DATA container datasets and to leave others unencrypted — for example, to encrypt ASSOR1 and DATAR1 but not ASSOR2 and DATAR2. ADAIOR performs the necessary encryption and decryption operations and makes the presence of the encryption transparent to the nucleus and utilities.
Conceivable motivations for encrypting only parts of ASSO and DATA might be:
To encrypt only sensitive data
To save part of the CPU overhead inherent with encryption
If only parts of ASSO and DATA are encrypted, sensitive files would be put on encrypted containers (for both ASSO and DATA!) and the other files, on unencrypted containers (to keep enough free space for the sensitive files).
Such a setup is possible but not recommended. The fact that the Adabas nucleus and utilities are not involved in the encryption logic generates practical issues:
The DBA must direct the placement of all files manually (for example, using the xxRABN or xxxxVOLUME parameters in ADALOD, ADAORD or ADASAV), distinguishing the sensitive files from the others.
The DBA must ensure manually that the Adabas nucleus and utilities do not perform secondary file extent allocations automatically, which might not adhere to the intentions of the DBA.
For many databases, organizing the placement of files in the database by targeting the desired database container datasets is probably impractical.