This information describes what the system does when you save a database file.
Use the SAVOBJ command to save individual database files. You can use the FILEMBR (file member) parameter to save:
v A list of members from one database file.
v The same group of members from multiple files.
Here is what the system does when you save a database file:
Table 24. Saving database files
Type of File What is saved
Physical file, TYPE(*DATA), keyed access path1 Description, data, access path Physical file, TYPE(*DATA), access path not keyed Description, data
Physical file, TYPE(*SRC), keyed access path Description, data
Logical file2 Description
1 The following types of access paths are included as keyed access paths: keyed access paths, primary key constraints, unique constraints, referential constraints.
2 You can save the access path for a logical file by saving the associated physical files using the SAVLIB, SAVOBJ, or SAVCHGOBJ command and specify the ACCPTH parameter..
The description for a file might include the following:
v Definitions of triggers and the programs that are associated with the file, but not the programs themselves. You must save the programs separately.
v Definitions of any constraints for the file.
Special considerations apply when you restore a file that has trigger programs or referential constraints defined.
Related concepts:
“Saving journaled objects and libraries” on page 75
When you save a journaled object or journaled library, the system writes an entry to the journal for each object that you save.
Related information:
SAVOBJ command
How the system restores files with referential constraints How the system restores files with triggers
Saving access paths:
When you restore a database file, but you did not save the access path to the database, the system rebuilds the access path. You can significantly reduce the amount of time it takes you to recover if you save the access paths. However, the process that saves access paths increases the time for the save operation and the amount of media that you use.
To save access paths that are owned by logical files, specify ACCPTH(*YES) on the SAVCHGOBJ, SAVLIB, and SAVOBJ commands when you save the physical files. The system saves access paths when you save the physical file because the physical file contains the data that is associated with the access path. When you save the logical file, you are saving only the description of the logical file.
When a save command (SAVLIB, SAVOBJ, SAVCHGOBJ, SAVRSTLIB, SAVRSTOBJ, or SAVRSTCHG) is performed, the save access paths parameter value is determined by the QSAVACCPTH system value when ACCPTH(*SYSVAL) is specified. When ACCPTH(*YES) or ACCPTH(*NO) is specified, this system value is ignored. If access paths are to be saved, the process that saves access paths increases the time for the save operation and the amount of media that you use. However, by having the access paths saved, you significantly reduce the amount of time it takes to recover a system because the access paths do not need to be rebuilt.
The system saves access paths that logical files own, and that are not used for referential constraints if all of the following are true:
v You specify ACCPTH(*YES) on the save command for the physical files.
v All based-on physical files under the logical file are in the same library, contain data, and are being saved at the same time on the same save command.
v The logical file is MAINT(*IMMED) or MAINT(*DLY).
In all cases, the system saves an access path only if it is valid and not damaged at the time of the save operation.
When you save a physical file that is not a source file, the system saves the following types of access paths with it, even if you do or do not specify ACCPTH(*YES):
v Keyed access paths that are owned by the physical file v Primary key constraints
v Unique constraints v Referential constraints
If the based-on physical files and the logical files are in different libraries, the system saves the access paths. However, the system might not restore these access paths.
Related information:
How the system restores access paths
EXAMPLE - Saving files in a network:
This information describes a physical file and how logical files have access paths over the physical file.
The following figure shows a physical file, FILEA in the LIB1 library. Logical file FILEB in LIB1 and logical file FILEC in LIB2 have access paths over physical file FILEA in LIB1.
The following table shows which parts of this file network different commands save:
Figure 2. Saving Access Paths
Table 25. Saving a File Network
Command What is saved
SAVLIB LIB(LIB1) ACCPTH(*YES)
FILEA: description, data, keyed access path FILEB: description, access path
FILEC: access path SAVOBJ OBJ(FILEA) LIB(LIB1)
ACCPTH(*YES)
FILEA: description, data, keyed access path FILEB: access path
FILEC: access path SAVLIB LIB(LIB2)
ACCPTH(*YES)
FILEC: description
Saving files with referential constraints:
Referential constraints link multiple files together in a network, similar to the network for access paths. You might think of this as a relationship network. If possible, you should save all the files in a relationship network in a single save operation.
If you restore files that are in a relationship network during separate restore operations, the system must verify that the relationships are still valid and current. You can avoid this process and improve restore performance if you save and restore relationship networks in a single operation.
Related information:
How the system restores files with referential constraints