Snapshot File Outputs
Snapshot creates two output files for each data set you select to clone—one data file and one parameter patch file (unless you enable the SPAN ENTRIES parameter, in which case all data set information is written to one patch file. See SPAN ENTRIES for more information.).
Snapshot creates one data file for each data set, with default titles as follows:
— or —
These files contain all of the records in the database as of the time of the “snapshot.” The actual data in the files is formatted according to your entry for FORMAT (for example, COMMAFORMAT, FIXEDFORMAT, or RAWFORMAT).
If the data set has variable formats, each record format type has its own file. These file names have an additional node, as follows:
— or —
In addition, the NOTE file attribute of each output data file contains the ending audit location.
Snapshot writes state information in a separate file for each data set, as explained next.
All parameter patch (CONTROL) files are titled the same as the data files, but with the CONTROL node appended to the file title, as in the following example:
— or —
This control file contains STATEINFO data that reflects the audit location, format level, etc., of the cloned data. The STATEINFO data is passed to DBEngine.
The STATEINFO data is in the same format as the STATEINFO that appears in the DATABridge Span parameter file for each data set. The layout of the STATEINFO data is described in the file SYMBOL/DATABRIDGE/INTERFACE.
An advantage to having the STATEINFO data in a separate file is when you use Snapshot to clone a database and then later decide you want to update the cloned database instead of creating it again. In this case, insert the contents of the individual datafilename/CONTROL of the data sets you want to track into the DATABridge Span parameter file. For each data set for which control information is placed in the DATABridge Span parameter file, include a comment that identifies the data set.
Note: This STATEINFO data should be also inserted in the secondary database parameters information. This is important for the secondary database to keep track of the location in the audit file of the last update.