Previous: Format
Up: Using the Mailserver
Next: Comments
Previous Page: Format
Next Page: Comments

Pitfalls

The one important aspect of server queries to keep in mind is that if a command fails, either because it is invalid (spelling), or because a search command fails to turn up any observations satisfying the search specification(s), then the command is aborted and the next one is executed. Thus, a server session does not break on a failed command. This may lead to unwanted situations. For instance, if you did a search on the master catalogue, and the search does not yield any observation, then the default input table will still be `0' (and not `1'). If your message now contains as next instruction the LIST command, you are specifying to list the whole catalogue; not surprisingly, you will never get any reply from the server if that happens.

Therefore, the golden rule with instructions for the server is: always specify both the INPUT_TABLE and the OUTPUT_TABLE, and also other qualifiers, such as /NOCOM, /NOREQ, etc. . If the input table for a command is specified, and the table does not exist, the command is simply aborted with an error message. If a listing is specified with:

LIST/INP=..

and the table does not exist, no other (default) table will be listed either, and you will get in the returned message a diagnosis of the problem back, upon which you may improve your query, and resubmit it to the server.

A similar problem can occur when you follow this advise, but the actual list is so long that you still run into (quota) problems: If you do not have a good idea how long a listing will be, stagger your server query, and first submit a query with only the SELECT/NOLIST/.... command, followed by exit. You will get a message back, stating how large your output query table is. If it is smaller then, say 1000 lines, then proceed and resubmit your query, now with the list instruction added.