In this section, we will go through the steps necessary to create a dump file description object used to dump some portion of the database.
In figures 6.1 and 6.2 you'll see an example of such an object and can use it to follow along with the description.
Figure: A newly created dump file description object
Figure: A complete dump file description object
1. Create a dump file description object by creating a new item in a folder and expanding it in the `dump file description' view. The dump file description GPD is available in the Dump GPD map, which is one of the system level gpd maps.
Creating such an object will give you something that looks like figure 6.1.
2. Decide the file name of the dumped t2lincks file that will be written out and put it on the first line. The default name, dumpfile.t2l, may also be left unchanged, in which case it will be used as the filename. You may use a full path name, but can also use names relative to the current working directory.
3. The second line, the date, should be left unaltered.
4. If desired, write an appropriate file preamble by changing `empty: preamble' to whatever you want. The preamble text is written literally at the beginning of the file, and it is intended to be used for comments (beginning with #) to describe the general contents of the dump file.
5. Next, if desired, write a file `postamble', text to be written literally to the end of the dump file. Do this by changing `empty: postamble' to the postamble you want. This text is typically a specification of where in the database the information should be put when reloaded.
A few examples of what this might be are:
The .set command, which aliases a particular node path. For example,
set myuser from ``System Root'' +USERS:partain:1
would assign the symbolic name `myuser' to the node accessed by following the link USERS:partain:1 from the System Root. System Root is a predefined constant. The value of this command is that this symbolic name (`myuser') can then be used in linking in that which you are dumping into a well-known spot in the database.
The .links command, which puts a link to an object in a well-known object. For example,
links myusers FOLDER Item = dumpobject
would put a link at FOLDER:Item:1 in `myuser' (defined above) to the object defined as dumpobject in the names section (see number 6 below).
Using the combination of these two commands, you are able to link the dump objects into the database. Otherwise, they will be added but you will have no way to find them!
Note that these commands are t2lincks commands, so you can put any t2lincks command here that you want. See the t2lincks man page for more information.
Note that these commands are t2lincks commands, so you can put any t2lincks command here that you want. See the t2lincks man page for more information.
6. In the <<names>> section, you can predefine symbolic names for specific nodes. Normally only the `root' nodes of the dumped structure are named explicitly, since you need to know these names in the postamble (to hook in the structure a reload time). Still, you may name any object. All explicitly named objects will generate an `.object...' command.
7. Finally, you list all compositions you want to save in the dump file. This is done in the <<contents>> section by first stating which GPD will be used in the dump and all of the compositions to be dumped under that GPD. This is similar to the way that windows are chosen at log in time. Under a GPD name you put links to all objects to save using that view. Note that this does not recursively descend through the database. If you wish to do this, see the next section.