This Appendix provides information for users of the Cambridge Structural Database System VAX/VMS implementation.
This section covers some of the features within the QUEST environment under VAX/VMS which are different from the Machine Independent Package (MIP).
To make use of them it is not necessary to know how these features work but an idea of how they operate can help in understanding how the program performs in given situations.
In the MIP package the information items for the entries are kept together in a single sequential file. This results in two major drawbacks:
* To position the file at a given entry it is necessary to read all the
entries between your current location and the entry to which you wish to go.
Thus a search starting at a refcode towards the end of the database can take a
considerable time to reach the required location in the file before even
starting to search.
* When the program is searching and an entry fails a test on the MASK
record then all the rest of the data for that entry must be read before the
next entry can be checked.
The VAX/VMS version of QUEST solves these problems by separating the MASK records from the Text + Connectivity (TEXT/CONN) and the Structural Data (DATA) records.
It also uses a look-up table which allows it to locate the correct MASK record for any given refcode.
The files used in these cases have the suffixes SAV and IDX, the main data files being: PRISCR.SAV
SECSCR.SAV
TERSCR.SAV
MASTER.IDX
If you create a subset of the database then QUEST will produce a matching set of files based on the problem name, for example, TEST1.SAV and TEST1.IDX.
The look-up table is called REFMASK.IDX and this allows the program to determine the entry number for any given refcode.
Because of limitations of the technique used to locate the position of a given screen record within the SAV file it has been necessary to divide the screen file into sections not exceeding 32643 disk units; hence the need for PRImary, SECondary and TERtiary SAV files.
When an entry has passed the screening tests on its MASK record it is then necessary to obtain the next section of the information for that entry. This information is stored, in indexed form, in the MASTER.IDX file. This means that a READ command inside QUEST can be given a key to look for and this will read the required information from the MASTER.IDX file without having to read through the whole database.
The information for an entry is divided up in the MASTER.IDX file into TEXT/CONN and DATA records. Once past the MASK record the TEXT/CONN record is read and this is followed by the DATA record if required. This means, for example, that a search on an author's name will have enough information after passing the MASK tests and reading the TEXT/CONN information to be determined correctly so that the usually larger DATA record does not have to be read.
Because of the large amount of information in the database, the entries in the MASTER.IDX file are compressed using the VMS DCX function. This results in a typical saving of 32% in terms of the information actually stored within the MASTER.IDX file and 27% for the whole database when the size of the MASK records, which are not compressed, are taken into account.
This is a feature of the VAX/VMS implementation which is shared with the other machine-dependent packages.
For the MIP implementation searching of the database will stop when an entry is hit and will not proceed again until the user has decided whether to keep or reject the entry.
In the foreground/background approach the background process continues to search for the next hit while the user is studying the last hit in the foreground process. This reduces the time for a typical interactive search as the user does not spend as much time waiting between hits.
This is a recent addition to the VAX/VMS package. The approach here is that rather than go through all the MASK records finding which pass the screening test these entries are determined at the beginning by manipulation of records which contain this information for each entry in the database.
Physically, there is a record for each bit-screen which contains a bit for each entry in the database. By combining these using the same rules as those for the tests in the question it is possible to determine which entries will pass the screening process.
As a useful side effect of this it is possible to show the number of entries that will pass not only the screening for the individual tests involved but also all the combinations of these tests up to the point where the final list of entries that pass the screening is produced. For example:
>SCREEN 32 35 -38 -39 -41 -42 -43 -45
>T1 *AUTH SMITH
>T2 *AUTH JONES
>T3 *ELEM Br
>T4 *COMP BENZENE
>QUEST (T1,T2)+(T3-T4)
Now searching D/B .....
Test 4 cannot use folded bit tests
Screens [ 73244 entries maximum]
Test 1 [ 13809 entries maximum]
Test 2 [ 9765 entries maximum]
Test 3 [ 36713 entries maximum]
Test 4 [102589 entries maximum]
Test A from combination of tests 1 & 2 [ 19863 entries maximum]
Test B from inverting test 4 [102589 entries maximum]
Test C from intersection of tests 3 & B [ 36713 entries maximum]
Test D from intersection of tests A & C [ 7072 entries maximum]
Intersection of screens with test D [ 4483 entries maximum]
There are several points to notice from this example:
* The screens are treated as a separate test.
* Because the screening is only the first stage of the testing it is only
possible to report the maximum number of entries that will pass the test.
For example, test T2 for JONES gives a maximum number of entries of 9765; if this test is done on its own then it is found that the number of entries that actually pass this test are 1360.
* The *AUTH test uses folded bits. This means that a single bit is set for
more that one situation.
For example bit 231 is set if an author's name contains any of the letter-pairs:
AM, BP, CS, DV, EY, GB, HE, IH, JK, KN, LQ, MT, NW, OZ, QC, RF, SI, TL, UO, VR, WU, XX, ZA
As a result they can be used only in a positive manner and cannot be used to .NOT. another test.
An obvious example of this is the following question:
>T1 *AUTH SMITHE
>T2 *AUTH SMITH
>QUES T1-T2
All the bits set for test T2 would be set for test T1 so if the bit manipulation were to go ahead in the normal way then the result would be that no entries would be selected.
* Since *COMP also uses folded bits test T4 does not do any screening so
that the maximum number of entries reported is equal to the total number of
entries in the database. Because no screening is possible when this test is
inverted to produce test B the number of entries that pass this test is the
same as for test T4.
If, for some reason, you wish to switch off the inverted screens this can be done by commenting out the following line in the CSD$COM:QUEST_SETUP.COM file by putting a ! after the $ :
$ assign /user_mode use_screens CSDINVSCR
Note that this will affect all users of the database so another option is to take a copy of the above file into your local directory and rename it as, for example, QUESTNINV.COM.
After editing this file a search with no screens can be done by entering a command such as:
$ @QUESTNINV PROB TT:
This feature is linked to the inverted screens. Users of previous versions of the CSD will expect the program to inform them of the progress of the search by printing lines such as:
hits after 53000 entries, 90% screenout at GAGYES
hits after 54000 entries, 90% screenout at GAVFOY
The use of the inverted screens, where the search jumps to entries that pass the screening, means that it is no longer certain that entries at the 1000 entry positions will be investigated. Rather than explicitly inserting these entries it was decided that some other method of displaying the progress of an search should be used.
The activity display is a line across the top of the screen where the length of the line is proportional to the current position in the database. For example, if the search is half-way through the database then the line will extend half-way across the screen.
Currently the old "1000 entry information lines" are still printed if an entry on a boundary is investigated.
Like the inverted screens, this feature can also be switched off by not assigning a logical name in the CSD$COM:QUEST_SETUP.COM file. In this case the line to comment out or remove is as follows:
$ assign /user_mode use_activity_display CSDACTDIS
The use of the 3D screens applies to all implementations of Graphics QUEST3D and information on 3D screens is given in chapter 7 of Volume 1.
The only difference for the VAX/VMS system is that it is possible, if required, to switch off the screens by, again, having a logical name undefined. In this case the line to remove or comment out is as follows:
$ assign /user_mode use_3dscreens CSD3DSCR
This section describes ways in which QUEST may be used under VAX/VMS.
The first time you use QUEST (or any other CCDC software package) in a session you should type:
<PROMPT> $ CSD
This command defines the symbols and logicals necessary to invoke the software. You need type it only once, at the beginning of the session.
To carry out a QUEST search on the VAX, the command line may contain three pieces of information in addition to the QUEST command:
root_filename A name of your choice used by the QUEST program to produce output files of the generic name root_filename.XXX where XXX indicates the contents of the file (listed below in section 12.2.4 "QUEST Files").
It is good practice to choose a root_filename that describes the search you are doing, for example SUGARS. This will make files easier to locate after the search.
input_option If you wish to carry out an interactive search of the database, you must use the VAX/VMS specific command, TT:
If you wish to use QUEST commands already set up in a question file prior to invoking QUEST, you should enter the filename of the question file here.
database The CSD master database is the default database; therefore this piece of information may be omitted if the search is to be made on the master database.
If, however, the search is to be made on a subset of the database, the filename of the subset should be entered.
Note that if a search is to be carried out on a subset of the master database, all three pieces of information must be present.
(Subsets of the master database are created by using the SAVE ASER command within QUEST, or the CCDC RETFIL command)
A QUEST search is initiated using this information by typing:
<PROMPT> QUEST root_filename input_option database
The following table summarises the various search commands that can be used to initiate QUEST.
Command line
|
root_filename
|
input_option
|
database
|
example
|
| $
QUEST A TT:
|
A
|
Typed
interactively
|
CSD
Master
|
|
| $
QUEST A
|
A
|
VAX
file A.QUE
|
CSD
Master
|
|
| $
QUEST A B
|
A
|
VAX
file B.QUE
|
CSD
Master
|
|
| $
QUEST A TT: C
|
A
|
Typed
interactively
|
VAX
file C
|
|
| $
QUEST A B C
|
A
|
VAX
file B.QUE
|
VAX
file C
|
|
| $
QUEST A A C
|
A
|
VAX
file A.QUE
|
VAX
file C
|
|
| $
QUEST
|
SPECIFY
|
SPECIFY
|
SPECIFY
|
An interactive search of the CSD master database may be initiated by typing:
<PROMPT> QUEST OUTPUT TT:
This will allow you to enter the question commands immediately.
If you make a mistake, the question may be terminated with CTRL-Z, which will return you to the VAX $ prompt.
Note that the output files from this search will be named OUTPUT.XXX.
If your QUEST search commands are in a file called MYFILE.QUE, QUEST is initiated by typing:
<PROMPT> $ QUEST MYFILE
Note that the output files from this search will be named MYFILE.XXX.
If your QUEST search commands are in a file called MYFILE.QUE but you want your output files to be called OUTPUT.XXX then QUEST is initiated by typing:
<PROMPT> $ QUEST OUTPUT MYFILE
In the examples above, the searches will be carried out on the default database, the CSD master database. However, it is also possible to carry out a search of a subset of the master database.
The SAVE ASER command allows you to create a database containing only those entries which are hits for a question.
For example, in Example 3 above, if SAVE ASER had been one of the command lines included in the MYFILE.QUE question file, then the database files OUTPUT.IDX and OUTPUT.SAV would have been created by QUEST for all those entries that satisfied the rest of the command lines in the question file.
To carry out an interactive search on this subset, the following command should be issued:
<PROMPT> $ QUEST NEWFILE TT: OUTPUT
This will create output files of the generic name NEWFILE.XXX
If you wanted to carry out a search of the database subset using a new question file, e.g. SPECIFIC.QUE, and saving the output to files prefixed with NEWFILE, you would issue the command:
<PROMPT> $ QUEST NEWFILE SPECIFIC OUTPUT
However, if you wanted to carry out a search of the database subset using a question file NEWFILE.QUE, you would have to issue the command:
<PROMPT> $ QUEST NEWFILE NEWFILE OUTPUT
The command line
<PROMPT> $ QUEST NEWFILE NEWOUTPUT
would be interpreted by the VAX as meaning a search of the CSD master database using a query file called NEWOUTPUT.QUE.
Typing:
<PROMPT> $ QUEST
will give an interactive guide with defaults.
You may use any name at any prompt but output files should not have exactly the same name as input files.
For example, if you are using a subset of the database called MYBASE.IDX, MYBASE.SAV then do not use these same names for output files to contain a further subset of the database.
If you decide to specify all files explicitly, and you could have used the one-line input, the command procedure will print out a message telling you how to do so.
Using SPAWNed sub-processes allows you to free your terminal for other use while the QUEST job is running, although the job must run to completion while you are in the same login session.
For instructions on using the SPAWN command, please consult your VAX/VMS User Manual.
Examples of valid SPAWN commands to run a QUEST job would be:
<PROMPT> $ SPAWN /NOWAIT /NOTIFY /OUT=SPAWN.LIS QUEST TESTQ <PROMPT> $ SPAWN /NOWAIT /NOTIFY/OUT=SPAWN.LIS - _$ QUEST SPECIFIC SPECIFIC MYDBASE
The SUBMITcommand allows you to enter batch jobs on the VAX.
SUBMIT requires that a command file (XXX.COM) exists which contains the commands which will run the QUEST job.
For instructions on using the SUBMIT command, please consult your VAX/VMS User Manual.
Example
The following commands have been set up in a file CSDJOB.COM:
<PROMPT> $ CSD $ QUEST TESTQ
This should then be submitted using a DCL command such as:
<PROMPT> $ SUBMIT CSDJOB.COM /NOTIFY /LOG /NOPRINT
Alternatively, you may insert the following line into your LOGIN.COM file, ensuring that it will be executed in BATCH mode:
<PROMPT> $ CSD
Then you may submit a QUEST job from the DCL command line, rather than needing to create a separate file for every problem name you want to use. For example:
<PROMPT> $ SUBMIT /NOTIFY /LOG /NOPRINT CSD$COM:QUEST_SETUP- _ PARAMETER=([MYDIR.CURRENT]PROBLEM, - _ [MYDIR.CURRENT]PROBLEM, - _ [MYDIR.CURRENT]MYSUBSET)
The point to note here is that you can specify the QUEST parameters on the SUBMIT line but if the files are not in your login directory you will need to specify the directory as well as rootname.
Chapter 13 in Volume 1 ("Customising Your QUEST/QUEST3D Implementation") explains how the VAX/VMS implemetation of QUEST searches for QUEST Initialisation files in the order:
If the logical QUEST$INIT is assigned a value then this file is used. For example, you can type:
<PROMPT> $ ASSIGN MY_INIT.QUE QUEST$INIT
and QUEST will use the instructions in MY_INIT.QUE every session.
To remove a previous assignment, type:
<PROMPT> $ DEASSIGN QUEST$INIT
If there is a file in the current directory called QUEST_INIT.QUE then this file is used.
If there is a file in the user's home directory called QUEST_INIT.QUE (SYS$LOGIN) then this file is used.
Otherwise, the file CSD$TOP:QUEST_INIT.QUE will be used.
The release copy of this file contains only comments but your local system manager can always add instructions to this file if everyone at your site uses a common set of instructions.
Similarly, QUEST3D Configuration files are searched for in the order:
If the logical QUEST$FIG is assigned a value then this file is used.
For example, you can type:
<PROMPT> $ ASSIGN MY_CONFIG.FIG QUEST$FIG
and QUEST will use the colours in MY_CONFIG.FIG every session.
To remove a previous assignment, type:
<PROMPT> $ DEASSIGN QUEST$FIG
If there is a file in the current directory called QUEST.FIG then this file is used.
If there is a file in the user's home directory called QUEST.FIG (SYS$LOGIN) then this file is used.
Otherwise, the file CSD$TOP:quest.fig will be used.
Some users may find that they wish to maintain, for example, multiple QUEST Initialisation files.
This section shows one method of doing so safely and efficiently.
Suppose that sometimes you use QUEST on a Tektronix 4200 Series terminal with a mouse and wish to use the graphics. On other occasions you only have access to a 4100 Series terminal. On still other occasions you do not wish to use the graphics at all.
You could create the following files in your login directory (SYS$LOGIN), and insert the following text:
<PROMPT> $ EDIT SYS$LOGIN:QUEST_INIT.T420 COMMENT TEK 4200 Series initialisation file TERMINAL T420X DEVICE MOUSE MENU <PROMPT> $ EDIT SYS$LOGIN:QUEST_INIT.T410 COMMENT TEK 4100 Series initialisation file TERMINAL T410X MENU <PROMPT> $ EDIT SYS$LOGIN:QUEST_INIT.BLANK COMMENT Blank Initialisation File - no functional commands
Then, in your LOGIN.COM, you could insert the following lines:
<PROMPT> $ EDIT SYS$LOGIN:LOGIN.COM $ T420 :== ASSIGN SYS$LOGIN:QUEST_INIT.T420 QUEST$INIT $ T410 :== ASSIGN SYS$LOGIN:QUEST_INIT.T410 QUEST$INIT $ BLANK :== ASSIGN SYS$LOGIN:QUEST_INIT.BLANK QUEST$INIT $ NOINIT :== DEASSIGN QUEST$INITNow, every time you log on, you just type the instruction corresponding to the terminal you are using.
For example, if you are using a 4200 Series terminal, just type:
<PROMPT> $ T420
and every subsequent QUEST session, until you log out or change the assignment of QUEST$INIT, will automatically enter full menus mode for a Tek 4200 Series terminal.
Similarly, typing BLANK will ensure that QUEST just uses the initialisation file containing only your one-line comment (you could equally use an empty file).
Typing NOINIT will deassign the logical QUEST$INIT so that QUEST will search in the directories [], SYS$LOGIN: and CSD$TOP: for a file called QUEST_INIT.QUE in the usual way.
Of course, the above discussion can be applied equally well to QUEST Configuration files and the logical QUEST$FIG.
The QUEST program in the VAX/VMS package has software which supports searches on a virtual database.
A "virtual" database is one defined by a list of refcodes and although the QUEST program searche behaves as if it were searching a subset database the subset database is not physically created prior to searching (unlike the RETRIEVE option).
Note: The statistics printed at the end of the run (f1 read , f2 read f3 read and f2-4 skipped) are not meaningful after a search on a virtual database.
* The list of refcodes must be in a file.
* It is highly desirable (but not essential) that these refcodes are sorted
into alphabetical order.
* The refcodes must be formatted with one refcode per line and each refcode
beginning in column 1.
* The file can have any name but must be assigned to the logical name
CSDVIRTDB.
The assignment is in effect until cancelled (using DEASSIGN) or the user logs out.
This assignment could be made either by the user or by the site-specific search software which produces the list.
<PROMPT> $ CSD $ ASSIGN INHOUSE.GCD CSDVIRTDB $ QUEST PROB TT:
(an automatic message confirms to the user that a virtual database is being used and the file which defines the database is also identified).
<PROMPT> $ DEASSIGN CSDVIRTDB $ QUEST PROB TT:
(search is, as normal, on the full database)
The format of the database will change from time to time to allow for new information items to be added for each entry and to improve search efficiency. For this reason the use of database files (nnn.IDX ,nnn.SAV) is not the recommended way to maintain subsets.
Users who wish to use the same subset over a long period should retain a list of refcodes (nnn.GCD) defining the sub-set. It is also good practice to retain the question (nnn.QUE) which was used to create the subset.
Under VAX/VMS, the RETFIL program will convert these refcodes into the current database format, or the Virtual Database facility may be used, thereby saving disk space.
The "RETRIEVE" and "SAVE ASER" commands can also be used in the QUEST program to create a subset in the current database format. This route has the adavantage that, as an option, any new additions to refcode families can be added to the subset.
The normal function of <control-C> within VMS is to terminate an executing image and present a prompt
<SCREEN> $
Unless the user types CONTINUE (or simply C) then the image is irreversibly terminated.
Within the QUEST program it is sometimes desirable to stop database searching but not exit from the program.
If you press <CTRL-C> when the database is being searched then the search is terminated and a prompt appears asking you if you want to exit.
If you reply No then the program is once again ready for you to compose new tests and/or questions.
If you press <CTRL-C> when the program is not searching the database the normal $ prompt is obtained.
Example:
In this example the year is intended to be 1980 but is first entered incorrectly as 1890. The search produces no hits and is aborted using <CTRL-C>. The correct test is then defined as T2 and this second test is used to define the question in the next search.
<PROMPT> $ QUEST EXMPL1 TT:
<SCREEN> QUEST$FIG (the QUEST configuration file) is CSDROOT:[RELEASE]QUEST.FIG;5 QUEST$INIT (the QUEST startup file) is CSDROOT:[RELEASE]QUEST_INIT.QUE;6 Database number 1 CSD$MASTER = CSD master database Disabling broadcast messages from MAIL,PHONE,QUEUE for duration of run Type "HELP" for an introduction to the documentation facility QUEST92 started at 30-OCT-1992 07:01:14.52 database creation date : 1-OCT-1992 09:00:00.00 Database is DCX compressed DATABASE VERSION 5.04 MODE=4 DATA=11111110101000001101111111111111 Graphics QUEST3D Software Now interpreting instructions in QUEST initialisation file >COMM These are comments in the QUEST initialisation file. This file can >COMM contain commands, such as terminal type, that are always entered. >COMM For more information enter HELP INITIALISATION FILES within QUEST. Now continue (or type "EXIT" to finish)
<PROMPT> >t1 *year 1890 <PROMPT> >quest t1
Now searching D/B ..... Test 1 [102589 entries maximum] hits after 1000 entries, 100% screenout at ADRMVL hits after 2000 entries, 100% screenout at ANDION10 hits after 3000 entries, 100% screenout at AZTHYN hits after 4000 entries, 100% screenout at BAMFIE
<PROMPT> Press <CTRL-C>
<SCREEN> Quest Search Terminated - - - - - - - - - - - - - - - - - - - - - - - > End of database encountered > Exit(Y/N) ?N > This will destroy all SAVE files ! > Do you really want to Exit (Y/N) ? N > Finished reading ASER Hits......... 0 D/B entries.. 4999 CONNSER calls 0 SCREened out. 100% F2-4 skipped. 0 F1 read...... 4 F2 read...... 0 F3 read...... 0 F4 read...... 0 Max MDATe....920701 database creation date : 1-OCT-1992 09:00:00.00 Database is DCX compressed Now continue (or type "EXIT" to finish)
<PROMPT> > T2 *YEAR 1980 > QUEST T2
<SCREEN> - - - - - - - - - + - - - - - - - - - + - - - - - - - - - + - - - - - - - - - + - - - - - - - - - + - - - - - - - - *REFC = AADMPY // *COMP = 2,4-Diamino-5-(1-adamantyl)-6-methylpyrimidine ethylsulfonate // *FORM = C15 H23 N4 1+,C2 H5 O3 S1 1- // *AUTH = V.Cody, S.F. Zakrzewski // *CODE = 395 (Am. Cryst. Assoc., Ser. 2) // *VOLU = 7 // *PAGE = 13 // *YEAR = 1980 // - - - - - - - - - + - - - - - - - - - + - - - - - - - - - + - - - - - - - - - + - - - - - - - - - + - - - - - - - -etc.
The following table lists the file types and file names used by QUEST.
<prob> is the problem name used in starting the QUEST search.
The 2-, 3- or 4-character filename suffix indicates the contents or purpose of the file.
For example, if you typed
<PROMPT> $ QUEST GLUCOSE TT: ... > SAVE FDAT ... > QUEST ...
a file called GLUCOSE.DAT would be created, containing an FDAT entry for every `hit'.
Input Files
Vax File Name
|
Function
|
Basic
QUEST Command
|
Graphics
QUEST3D Procedure
|
In
or Out?
|
| QUEST$FIG 2. []QUEST.FIG 3. SYS$LOGIN: QUEST.FIG 4. CSD$TOP: QUEST.FIG |
QUEST3D
graphics configuration file. Allows users to change the colours used by
Graphics Version QUEST3D. On machine-specific implementations, the file is
searched for in one of four locations.
|
Not
available
|
The
file is read automatically, if it exists.
|
Input
|
| QUEST$INIT 2. []QUEST_INIT. QUE 3. SYS$LOGIN: QUEST_INIT.QUE 4. CSD$TOP: QUEST_INIT.QUE |
QUEST
initialisation file. Allows users to specify instructions that will be
executed automatically every time QUEST starts. On machine-specific
implementations, the file is searched for in one of four locations.
|
The
file is read automatically, if it exists.
|
The
file is read automatically, if it exists.
|
Input
|
| <prob>.QUE
or TT:, usually
|
QUEST
instruction document, ie, the commands that will define the QUEST search.
|
Input
| ||
| <prob>.RBR
|
Restrict
by refcode. Only entries whose refcodes are in the file on unit 30 will be
searched. Note that for VAX/VMS users, the preferred way of doing this is to
use a virtual database subset.
|
INIT
7
|
INIT
7
|
Input
|
| <prob>.RCO
|
RECOVER.
This enables you to set up a QUEST instruction document, which will be read by
QUEST when you issue the RECOVER instruction. See also QUEST Initialisation files. |
RECOVER
|
If
RECOVER is to be used, it should be issued before entering graphics mode. (ie,
before typing MENU)
|
Input
|
| <prob>.RUN
|
Reserved
for Graphical Input demonstration purposes.
|
Not
applicable
|
Input
| |
| CSD$GINDAT: TEMPLATE.DAT |
Graphical
Input Template File
|
Not
applicable
|
Select
TEMPLATE in the BUILD menu.
|
Input
|
| CSD$GINDAT: MENU.NEW |
Used
in Development versions of the QUEST input menu package. Not used in release
versions.
|
Not
applicable
|
-
|
Input
|
| CSD$TOP: HELPTEXT.TXT |
The
QUEST HELP file.
|
HELP
|
Select
HELP in any menu.
|
Input
|
| CSDVIRTDB
|
Reserved
for VAX version - The virtual database (CSDVIRTDB) facility.
|
Use
the ASSIGN command to specify the value of CSDVIRTDB
|
Input
| |
| SYS$COMMAND
|
Used
by Tek graphics
|
-
|
-
|
Input
|
Output Files
Vax File Name
|
Function
|
Basic
QUEST Command
|
Graphics
QUEST3D Procedure
|
In
or Out?
|
| <prob>.SVE
|
STORE-FRAGMENT
file.
|
Not
applicable
|
STORE-/FETCH-/DELETE-FRAGMENT
commands in the FILES menu.
|
Input/Output
|
| <prob>.BIB
|
FBIB
file - Bibliographic information for `hit' database entries.
|
SAVE
FBIB
|
Select
SAVE FBIB in the SEARCH menu.
|
Output
|
| <prob>.CON
|
FCON
file - chemical connectivity information for `hit' database entries.
|
SAVE
FCON
|
Select
SAVE FCON in the SEARCH menu.
|
Output
|
| <prob>.DAT
|
FDAT
file, containing one entry for each database `hit' kept by the user.
|
SAVE
FDAT
|
Select
SAVE FDAT in the SEARCH menu.
|
Output
|
| <prob>.DBG
|
Reserved
for Graphical Input debugging.
|
Output
| ||
| <prob>.FGD
|
QUEST3D
search fragment definition
|
Not
available
|
Output
| |
| <prob>.FGN
|
QUEST3D
search fragment numbers
|
Not
available
|
Output
| |
| <prob>.FSER
|
FSER
file - formatted database subset for `hit' database entries. The ADAPT program
may be used to convert this file to the ASER file format. Usually only used by
CCDC staff.
|
SAVE
FSER
|
Select
COMMAND in the BUILD or SEARCH menus, and type SAVE FSER.
|
Output
|
| <prob>.GCD
|
REFCODE
file, containing the refcodes of every database `hit' kept by the user.
|
SAVE
REFCODE
|
Select
SAVE REFC in the SEARCH menu.
|
Output
|
| <prob>.GLS
|
GLIST
|
Output
| ||
| <prob>.IDX
|
For
machine-specific implementations, this is one of a pair which constitute a
seachable database subset.
|
SAVE
ASER
|
Select
SAVE ASER in the SEARCH menu.
|
Output
|
| <prob>.INS
|
Used
by Graphical Input to communicate with QUEST program. It is of no relevance to
the user .
|
Not
applicable
|
-
|
Output
|
| <prob>.JNL
|
QUEST
Journal file - automatically provides record of a QUEST session's query, and
any `hit' entries.
|
No
instruction switches this on, but storing of `hit' information may be turned
off with the NOJOURNAL command
|
No
instruction switches this on, but storing of `hit' information may be turned
off by selecting NOJOURNAL in the SEARCH menu.
|
Output
|
| <prob>.MDL
|
MODEL
file. (Interface to molecular modelling packages)
|
Not
available
|
Select
SAVE MODEL in the SEARCH menu.
|
Output
|
| <prob>.PS
|
POSTSCRIPT
file, containing 2D chemical diagrams for all `hit' entries.
|
Not
available
|
Select
POSTSCRIPT in the SEARCH menu.
|
Output
|
| <prob>.SAV
|
ASER
file (database subset), containing one entry for each database `hit' kept by
the user.
|
SAVE
ASER
|
Select
SAVE ASER in the SEARCH menu.
|
Output
|
| <prob>.STS
|
QUEST3D/STATS
binary interface file.
|
Not
available
|
Output
| |
| <prob>.SUM
|
QUEST3D
search scratch/summary list
|
Not
available
|
Output
| |
| <prob>.TAB
|
QUEST3D
search cumulative table
|
Not
available
|
Output
|
The first time you use GSTAT (or any other CCDC software package) in a session you should type:
<PROMPT> $ CSD
This command defines the symbols and logicals necessary to invoke the software. You need type it only once, at the beginning of the session.
To carry out a GSTAT session on the VAX, the command line may contain two pieces of information in addition to the GSTAT command:
root_filename A name of your choice used by the GSTAT program to produce output files of the generic name root_filename.XXX where XXX indicates the contents of the file (listed below in section 12.3.2 "GSTAT Files").
The input FDAT file must also be called root_filename.DAT.
It is good practice to choose a root_filename that describes the search you are doing, for example SUGARS. This will make files easier to locate after the session.
input_option If you wish to enter your instruction interactively, you must use the VAX/VMS specific command, TT:
If you wish to use GSTAT commands already set up in a question file (which is not named ROOT_FILENAME.GEO) prior to invoking GSTAT you should enter the filename of the GSTAT instruction file here.
The CCDC-recommended filetype extension for GSTAT instruction documents is .GEO.
A GSTAT session is initiated using this information by typing:
<PROMPT> GSTAT root_filename input_option
An interactive GSTAT session may be initiated by typing:
<PROMPT> GSTAT SUGARS TT:
(assuming that you have created an FDAT file called SUGARS.DAT by running QUEST)
This will allow you to enter the question instructions immediately.
If you make a mistake, the session may be terminated with CTRL-Z, which will return you to the VAX $ prompt.
Note that the output files from this run will be named SUGARS.XXX.
Suppose that: your GSTAT instructions are in a file called MYFILE.GEO
your FDAT data are in a file called MYFILE.DAT
GSTAT is initiated by typing:
<PROMPT> $ GSTAT MYFILE
Note that the output files from this session will be named MYFILE.XXX.
Ifyour GSTAT instructions are in a file called MYFILE.GEO
but you want your output files to be called OUTPUT.XXX
GSTAT is initiated by typing:
<PROMPT> $ GSTAT OUTPUT MYFILE.GEO
or just
<PROMPT> $ GSTAT OUTPUT MYFILE
Typing:
<PROMPT> $ GSTAT
will give an interactive guide with defaults.
You may use any name at any prompt but output files should not have exactly the same name as input files.
If you decide to specify all files explicitly, and you could have used the one-line input, the command procedure will print out a message telling you how to do so.
The following table lists the file types and file names used by GSTAT.
<prob> is the problem name used in starting the GSTAT session. The 3- or 5-character filename suffix indicates the contents or purpose of the file.
For example, if you typed
<PROMPT> $ GSTAT GLUCOSE ...
a file called GLUCOSE.DAT would be used for input.
Input Files
Vax File Name
|
Function
|
GSTAT
Instruction
|
In
or Out?
|
| <prob>.DAT
|
FDAT
file, containing one entry for each database `hit' kept by the user.
|
Input
| |
| <prob>.FGN
|
Binary
file containing fragment numbers, written during a QUEST3D search to
communicate information to GSTAT.
|
Input
| |
| <prob>.GEO
|
instructions
to be read in when the input is not typed in via a terminal
|
Input
|
Output Files
<prob>.CLS
|
Coordinates
of the "Most representative fragment(s)" (MRF) deduced by the CLUSTER analysis
package.
|
OUTPUT
COORD
|
Output
|
| <prob>.COR
|
list
of atom labels, atomic coords - orthogonal or fractional
|
OUPUT
COORD
|
Output
|
| <prob>.FAC
|
Output
file containing Principal Component Analysis (PCA) scores for each fragment.
|
PCA/FAC
|
Output
|
| <prob>.GCD
|
8-character
reference codes for database entries which survive all selection procedures.
|
COD
|
Output
|
| <prob>.LIS
|
output
when not directed to a terminal
|
Output
| |
| <prob>.SUP
|
list
of unit cell parameters, atomic coordinates
|
SUPERpose
|
Output
|
| <prob>.TAB
|
scratch
file for manipulation of fragment geometry table
|
Output
| |
| <prob>.TABLE
|
Fragment
geometry file.
|
FIL
|
Output
|
The first time you use PLUTO (or any other CCDC software package) in a session you should type:
<PROMPT> $ CSD
This command defines the symbols and logicals necessary to invoke the software. You need type it only once, at the beginning of the session.
To carry out a PLUTO session on the VAX, the command line may contain two pieces of information in addition to the PLUTO command:
root_filename A name of your choice used by the PLUTO program to produce output files of the generic name root_filename.XXX where XXX indicates the contents of the file (listed below in section 12.4.2 "PLUTO Files").
The input FDAT file must also be called root_filename.DAT.
It is good practice to choose a root_filename that describes the search you are doing, for example SUGARS. This will make files easier to locate after the session.
input_option If you wish to enter your instruction interactively, you must use the VAX/VMS specific command, TT:
If you wish to use PLUTO commands already set up in a question file (which is not named ROOT_FILENAME.CMD) prior to invoking PLUTO, you should enter the filename of the PLUTO instruction file here.
The CCDC-recommended filetype extension for PLUTO instruction documents is .CMD.
A PLUTO session is initiated using this information by typing:
<PROMPT> PLUTO root_filename input_option
An interactive PLUTO session on the saved data file SUGARS.DAT may be initiated by typing:
<PROMPT> PLUTO SUGARS TT:
This will allow you to enter the question instructions immediately.
If you make a mistake, the session may be terminated with CTRL-Z, which will return you to the VAX $ prompt.
Note that the output files from this run will be named SUGARS.XXX.
If your PLUTO instructions are in a file called MYFILE.CMD, PLUTO is initiated by typing:
<PROMPT> $ PLUTO MYFILE
Note that the output files from this run will be named MYFILE.XXX.
If your PLUTO instructions are in a file called MYFILE.CMD
but you want your output files to be called OUTPUT.XXX
PLUTO is initiated by typing:
<PROMPT> $ PLUTO OUTPUT MYFILE.CMD
or just
<PROMPT> $ PLUTO OUTPUT MYFILE
Typing:
<PROMPT> $ PLUTO
will give an interactive guide with defaults.
You may use any name at any prompt but output files should not have exactly the same name as input files.
If you decide to specify all files explicitly, and you could have used the one-line input, the command procedure will print out a message telling you how to do so.
The following table lists the file types and file names used by PLUTO.
<prob> is the problem name used in starting the PLUTO session. The 3 character filename suffix indicates the contents or purpose of the file.
For example, if you typed
<PROMPT> $ PLUTO GLUCOSE
then a file called GLUCOSE.DAT would be used for input.
Vax File Name
|
Function
|
In
or Out?
|
| <prob>.CMD
|
PLUTO
instruction document, if not interactive.
|
Input
|
| <prob>.DAT
|
FDAT
file, containing one entry for each database `hit' kept by the user.
|
Input
|
| <prob>.LIS
|
PLUTO
listing file.
|
Output
|
| The
file to which Tektronix escape sequences are sent (Usually the terminal)
|
Output
|
RETFIL will retrieve CSD entries on the basis of a file of reference codes.
Although QUEST can be used to retrieve on the basis of refcodes, RETFIL is faster and more efficient.
The reference codes must be given one per line beginning in the first column of each line.
Valid CSD reference codes always begin with six alphabetic characters. These may be followed by two digits which decribe the "publication history".
The input refcodes may be given in any order.
Normally the refcode file will have been written by QUEST but the user can create a refcode file using a text editor or by entering the refcodes when the program is running.
The program will log the success of the retrieval for each refcode, and will stop when all selected refcodes have been located.
When the program stops, the program will list those refcodes which were not located.
Possible explanations for unsuccessful retrieval are:
* the refcode was mistyped
* the refcode was duplicated in the input
* the refcode has been changed by CCDC (This occurs only very rarely.
Out-of-date refcodes may still be retrieved using the *PREFCODE test in a QUEST
search).
The output forms which may be specified are:
ASER FBIB FCON FDAT LIST POSTSCRIPT or REFCODE
* ASER subfile (database format) for later use by QUEST.
* FBIB subfile containing the bibliographic information.
* FCON subfile containing the chemical connection tables. This is useful
for special applications in computational chemistry.
* FDAT subfile for use as input to the geometry package GSTAT, or to the
plotting package PLUTO.
* LISTing of important information for each CSD entry.
* POSTSCRIPT subfile containing the chemical diagram.
The program operates on the master database file or on subsets of the database created by QUEST.
The other input is the optional file of refcodes.
When a refcode list is input to the program, all combinations of the output forms can be obtained.
When the refcode list is omitted the complete input database file is processed and, in addition to the ASER/FBIB/FCON/FDAT/LIST/POSTSCRIPT output forms, it is possible to obtain as output a refcode listing of the contents of the input database file.
VAX version users invoke RETFIL by:
<PROMPT> $ CSD $ RETFIL [problem_name command_file database]
The RETFIL command line takes at most three optional parameters:
the problem name:
the command file name or a single command or TT:
the input database
If a problem name is being used then the input is <name>.RFI (RFI = RETFIL Input)
<PROMPT> $ CSD $ RETFIL PROBLEM
If only one command is given to RETFIL then it can be the second parameter on the command line
<PROMPT> $ CSD $ RETFIL PROBLEM LIST $ RETFIL PROBLEM ALL
If you want to enter the commands interactively then use TT: as the second argument and terminate the input with control-Z.
<PROMPT> $ CSD $ RETFIL PROBLEM TT: LIST ALL ^ZRetrieval will usually be on the master database. If you want to process an entire subset of the database (as for example might be created by SAVE ASER in QUEST) then specify the database subset name as the third argument.
<PROMPT> $ CSD $ RETFIL PROBLEM ALL MYDBASE
Note: It is not possible to use both a subset of the database and a refcode list as input.
If a refcode list is used then retrieval must be from the master database.
* There are only 8 possible command words which the program will accept.
* Each must be input on a separate line.
* The commands are read in on FORTRAN logical unit 5.
If the keyword ALL is not present on unit 5 then the program will proceed to read the input list of refcodes on FORTRAN logical unit 3. Only CSD entries with these refcodes will then be selected.
Keyword Action
ALL No refcode list will be read.
All entries in the input database file
will be selected to be processed.
ASER An ASER-format database file will be created on units 4 and 9.
This
file will contain all entries selected.
FBIB An FBIB file will be written on unit 18.
This file will contain all
entries selected.
The type component of the filename is .BIB.
FDAT An FDAT file will be written on unit 1.
This file will contain all
entries selected.
The type component of the file name is .DAT
FCON An FCON file will be written on unit 10.
This file will contain all
entries selected.
The type component of the file name is .CON
POSTSCRIPT A PostScript listing will be written on unit 28.
This file will
contain the chemical diagram for all entries selected.
The type component of
the file name is .PS
RCOD A refcode listing will be written on unit 3.
This file will contain all
entries selected.
The type component of the file name is .GCD
LIST A summary for each selected CSD entry will be written to unit 6.
Generate an FDAT file and produce a summary LISTing for the refcodes on unit 6.
The input to RETFIL is:
FDAT
LIST
Generate an FDAT file, an FCON file, a file of Reference CODes, and a summary LISTing for all entries in the database file on unit 2.
The input to RETFIL is:
ALL
FDAT
FCON
RCOD
LIST
Notes: The combinations ALL
ASER
or RCOD
will work!
The first produces a direct copy of the input database.
The second produces a direct copy of the input reference code file.
If the LIST command is used the program writes a summary listing (suitable for printing) which contains the following information:
Refcode Compound name
Compound name synonym, if available
Molecular formula
Qualifying phrases, if available
Authors' names
Journal references
Entry summary information
Each information field in LIST begins on a new line.
The 'entry summary information' contains:
* main chemical class assignment
* number of 3D atomic coordinates stored (coord=) for this entry.
* crystallographic R-factor (Rfac=).
Note that Rfac=0.000 indicates that this item was not recorded in the original paper.
* the SIGF flag which describes the mean estimated standard deviation of a
C-C bond length.
= not given
= 0.001 - 0.005 Å
= 0.006 - 0.010 Å
= 0.011 - 0.030 Å
= > 0.030 Å
* the INTF flag which indicates the method of intensity measurement.
= not given
= photographic
= densitometer
= diffractometer
* the space group (Spgp=).
The October 1992 release of the database contains new information which has resulted in the need to change slightly the format of the stored database.
Some users will have made subsets of the database and will want to be able to convert these old subsets.
To perform the conversion the CSDCONVERT command is provided.
Note that the command procedure invoked to initiate a QUEST search tests the specified database files and will halt if an old format database file is found.
Suppose an old database is THIAZOL.IDX and THIAZOL.SAV.
To convert the database
specify the problem name (THIAZOL) as the first parameter.
<PROMPT> $ CSDCONVERT THIAZOL
This creates an intermediate file - a list of refcodes THIAZOL.GCD.
To complete the task use the RETFIL program to process the list.
<PROMPT> $ RETFIL THIAZOL ASER
This creates a new pair of files (THIAZOL.SAV,THIAZOL.IDX) which together make a new database suitable for the current software.
You should check that the new database is acceptable to the software and then PURGE the .IDX and .SAV files.