<< >> Contents

APPENDIX 12 - NOTES FOR VAX/VMS USERS


This Appendix provides information for users of the Cambridge Structural Database System VAX/VMS implementation.

12.1. Introduction - Features of the 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.

12.1.1. SPLIT DATABASE

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.

12.1.2. DATABASE COMPRESSION

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.

12.1.3. FOREGROUND/BACKGROUND PROCESSES

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.

12.1.4. INVERTED SCREENS

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.

Switching off the Inverted Screens

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:

12.1.5. ACTIVITY DISPLAY

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.

Switching off the Activity Display

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

12.1.6. 3D SCREENS

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.

Switching off the 3D Screens in QUEST 3D

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

12.2. QUEST

This section describes ways in which QUEST may be used under VAX/VMS.

12.2.1. USING THE QUEST PROCEDURE

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

Example 1 - Interactive Searches

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.

Example 2 - Question Files

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.

Example 3 - Question Files

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

Example 4 - Searching Database Subsets

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.

Example 5 - Interactive Method

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.

Example 6 - Using SPAWN

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

Example 7 - Using SUBMIT

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.

12.2.2. MAINTAINING MULTIPLE QUEST INITIALISATION AND CONFIGURATION FILES

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$INIT

Now, 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.

12.2.3. VIRTUAL DATABASES

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.

Using 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.

Examples

	<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)

Maintaining Database Subsets

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.

Interrupting QUEST Searches

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.

12.2.4. QUEST FILES

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

12.3. GSTAT

12.3.1. USING THE GSTAT PROCEDURE

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 

Example 1 - Interactive GSTAT Session

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.

Example 2 - Instructions in a File

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

Example 3 - Interactive Method

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.

12.3.2. GSTAT FILES

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

12.4. PLUTO

12.4.1. USING THE PLUTO PROCEDURE

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 

Example 1 - Interactive PLUTO Session

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.

Example 2 - Instructions in a File

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

Example 3 - Interactive Method

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.

12.4.2. PLUTO FILES

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

12.5. RETFIL

12.5.1. INTRODUCTION

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.

12.5.2. STARTING RETFIL

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)

Example

	<PROMPT>	$ CSD
		$ RETFIL PROBLEM 

If only one command is given to RETFIL then it can be the second parameter on the command line

Example

	<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.

Example

	<PROMPT>	$ CSD
		$ RETFIL PROBLEM TT:
		LIST
		ALL
		^Z
Retrieval 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.

Example

	<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.

12.5.3. RETFIL COMMANDS


* 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.

Examples

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.

12.5.4. LIST COMMAND OUTPUT

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=).

12.6. CSDCONVERT

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.

12.6.1. EXAMPLE

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.


<< >> Contents