ARCHIVE: save an observation to disc

This page is part of the ING document INS-DAS-24: client-server interface for control of cameras

Purpose: save one run to disc, in a FITS file.

Actors: udas_run or udas_keep client; udas_camera server.

Outline: the client invokes the ARCHIVE action on the server. The server saves the run, with associated telemetry, in a FITS file and may also make that file visible to the archiving software.

Normal course of events:

Client invokes the ARCHIVE action on the server with these arguments:

Argument1: the rank-number of the run on which the action is to operate.
Argument2: name of the instrument to which the observation applies.
Argument3: the keyword "archive".
Argument4: the scratch-file number, set to 1 (this number is checked but not used because the data are not going to a scratch file in the normal sequence).

Server locates and reads in packet files of FITS-header cards previously filed by tasks of the observing system. The set of packets to read is determined by the given name of the instrument.
Server creates a FITS file in the current directory for observation files, giving it a working file-name that is neither the name of any observation scratch-file nor the name of any archivable observation-file.
Server writes into the file the images currently contained in the run, the FITS header-cards reads from the packets, and any relevant telemetry that the camera server holds internally.
Server closes the file and renames it into the standard sequence for archivable observations.
Server returns good status for the action to the client.
Server does not use the renamed FITS-file again.

Variations:

In step 1, the keyword is "scratch" instead of "archive" and the scratch-file number in Argument4 is any positive integer. In step 5, the server renames the working file as a scratch file instead of an archiveable file.
In step 1, the keyword is "glance" instead of "archive". The server skips steps 2, 3 and 4 and goes on to step 5. (This form of the action is provided only for symmetry.)
In step 2, one or more of the header-packet files are missing or unreadable. Server logs an error message for each at debug level, but does not alert the client or the end-user. Server carries on with the usable packet-files, if any, and completes the action normally.
At step 4, 5, or 6, there is a problem with writing the file (e..g lack of disc-space). Server writes an error message directly to the log, skips the remaining steps, and returns status BADFITSFILE or OBSDISCSFULL to the client.