To store structures in a subfile of a backing-store file.
The STORE directive allows you to store data structures or procedures in a backing-store file. The file can be opened using the OPEN directive, and there is also a backing-store workfile attached to channel 0 which is automatically deleted at the end of a GenStat run.
Each backing-store file contains a number of subfiles. Each subfile starts with a catalogue, recording which structures it stores. Then come the attributes and the values of each data structure. A subfile name can be either an unsuffixed identifier or a suffixed identifier with a numerical suffix. The identifiers of subfiles are kept in a separate catalogue to the identifiers of data structures, so you do not need to worry about keeping the identifiers of data structures and subfiles distinct. However, if you use a suffixed identifier for a subfile, Sub say, you cannot also use the identifier Sub. There are two types of subfiles. Ordinary subfiles can hold any type of structures except procedures; procedure subfiles hold only procedures (and their dependent structures).
Whenever you store a structure in a subfile, GenStat automatically stores also all the associated structures to which it points. If these associated structures also point to further structures, then they are stored too, and so on. Some of the structures may be unnamed and some structures may be system structures. For example
TEXT [VALUES=A,B,C] T
FACTOR [LABELS=T; VALUES=1...3] F
creates a subfile containing factor F. The complete definition of factor F depends on text T to supply level names. So T is stored too. The text T depends on a system structure (indicating the length of each line), which is therefore also stored. Hence to save factor F, GenStat has actually saved three structures. However, this is all automatic, so you do not need to worry about any of the details of the system structures.
When you store a structure with a suffixed identifier, GenStat may have to set up a series of pointer structures if they are not already present. An example is:
VARIATE [VALUES=1,2] V[1,2]
STORE [PRINT=catalogue] V
The first line sets up a pointer structure V, pointing to V and V. To store variate V, a pointer structure V has to be set up in the subfile, pointing to V only. Thus two structures are saved on backing store, namely V and V. The original pointer V in the program is left unchanged. (If the example had stored the whole of V, no such complications would have arisen.)
The structures to be stored are specified by the IDENTIFIER parameter. The CHANNEL option indicates the backing-store file to use, and the SUBFILE option specifies the subfile that is created. Both these options can be omitted; by default the file will be the workfile, and the subfile will be called SUBFILE. The structures that are stored in the subfile are merely copies of the structures in the job, so the original structures remain available for further use within the job.
The STOREDIDENTIFIER parameter allows you to give a structure a different name within the subfile: For example,
VARIATE [VALUES=10.2,15.3,21.4,16.8,22.3] Weight
STORE Weight; STOREDIDENTIFIER=WtWeek2
stores a structure with identifier Weight within GenStat as a structure with identifier WtWeek2 in the backing-store file. If you want to rename only some of the structures, you can either respecify the existing identifier, or insert * at the appropriate point in the list. For example, you could store X and Y, renaming only Y as Yy, by
STORE X,Y; STOREDIDENTIFIER=X,Yy
STORE X,Y; STOREDIDENTIFIER=*,Yy
You can give an unnamed structure in the list of either parameter. For example
STORE !(10.2,15.3,21.4,16.8,22.3); STOREDIDENTIFIER=WtWeek2
But of course you will not be able to retrieve any structure that has been stored as an unnamed structure (except perhaps as a dependent structure of another structure).
All the structures in a subfile must have distinct identifiers, and GenStat will report a fault if you try to give two the same name. You thus need to be careful if you are storing structures inside a procedure, as the same identifier can be used for one structure within the procedure, and for another one outside; you cannot store both in the same subfile.
Procedures that have been retrieved automatically from libraries cannot be stored by STORE.
You can set option PRINT=catalogue to obtain a catalogue of the subfiles in the backing-store file, and of the structures in the subfile just created. If you also set option UNNAMED=yes GenStat will also list any unnamed structures, with details of how they depend on each other.
The LIST option controls how the IDENTIFIER list is interpreted. The default setting inclusive simply stores the structures that have been listed.
Alternatively, if you set LIST=all GenStat will store all the structures in the current job that have identifiers and whose types have been defined. If the statement is inside a procedure, then only the structures defined within the procedure are stored. If you are storing procedures, then this setting will store all procedures that you have created explicitly in this job, by PROCEDURE or RETRIEVE statements.
Finally, you can set LIST=exclusive to store everything that you have not included in the IDENTIFIER parameter: that is, all the other named structures that are currently accessible, or all the other procedures that have been created in this job. Note, though, that some of the structures in the IDENTIFIER list may be stored if they are needed to complete the set of structures to be stored. If you use this setting, the STOREDIDENTIFIER parameter is ignored. For example
TEXT [VALUES=a,b] T
FACTOR [LABELS=T] F
TEXT [VALUES='variate text'] Vt
VARIATE V; EXTRA=Vt
creates four named structures, T, F, V and Vt. The statement
STORE [LIST=inclusive] T
stores the text T;
stores all the four structures that have identifiers;
STORE [LIST=exclusive] F,T
stores Vt and V; and
STORE [LIST=exclusive] Vt,T
results in all four structures being saved, because V points to Vt, and F points to T.
If a subfile of the specified name already exists on the backing-store file, the storing operation will usually fail. You can then set option METHOD=overwrite to overwrite the old subfile, that is, to replace the old subfile with a new subfile; alternatively, you can put METHOD=replace to form a new backing-store file containing only the new subfile. Setting METHOD=update adds new structures to an existing subfile. The MERGE option then controls what happens if a data structure that is being added to the file is already present; by default it overwrites the previous version but, if you put MERGE=yes, only new structures are added to the file.
To make your files secure, you can specify a password using the PASSWORD option. Once you have done this, you must include the same password in any future use of STORE or MERGE with this same userfile; spaces, case and newlines are significant in the password. You cannot change the password in a userfile once you have set it, but you can use the MERGE directive to create a new userfile with no password or with a new password. If you set the password to be a text whose values have been restricted, the restriction is ignored.
The PROCEDURE option indicates whether the subfile is to store procedures (PROCEDURE=yes), or ordinary data structures.
Options: PRINT, CHANNEL, SUBFILE, LIST, METHOD, PASSWORD, PROCEDURE, UNNAMED, MERGE.
Parameters: IDENTIFIER, STOREDIDENTIFIER.
Directives: RETRIEVE, CATALOGUE, MERGE, OPEN, RECORD, RESUME.
Procedures: EXPORT, IMPORT, DBEXPORT, DBIMPORT.