next up previous
Next: Efficiency Considerations
Up: ADDITIONAL FACILITIES
Previous: Retaining Converted Data

Specifying Where the Native NDF is Stored   

If the native NDF copy of a foreign dataset is not being kept, then the NDF library will, by default, store it within the HDS scratch file, as described earlier. This is generally most efficient. However, not all conversion utilities will necessarily be able to access such an NDF, particularly if they know nothing of the NDF or HDS data formats themselves. This would be the case with a general purpose data compression utility, for instance.

The NDF library therefore allows you to specify where the native NDF copy of the data should be stored. This is done by defining environment variables containing message tokens that evaluate to the name you want this NDF to have.

Up to two such environment variables may be defined for each foreign format. Their names are generated by prefixing `NDF_KEEP_' and `NDF_TEMP_' to the foreign format name (in upper case), and they correspond to the two cases (a) where the native copy of the NDF is being kept, and (b) where it is not. The two cases are handled separately, but the message tokens available are the same in both instances, as follows:

Token Value
dir Directory in which the foreign file resides
name Foreign file name (without directory or extension)
type Foreign file extension (with leading `.')
vers Foreign file version number (blank if not supported)
fxs Foreign extension specifier (see §[*] )
fxscl Clean version of fxs (all non-alphanumeric characters replaced by underscores)
fmt Foreign format name (upper case)

For example, if we were defining a COMPRESSED format and wanted to ensure that the native NDF data was always stored in its own file in the default directory, so that the UNIX ``compress'' utility could access it, we might use:

setenv NDF_KEEP_COMPRESSED ^name
setenv NDF_TEMP_COMPRESSED tmp_^name

Then, whatever the setting of the `KEEP' tuning parameter, the name of an NDF in the default directory would be generated, so the HDS scratch file would never be used to hold the NDF copy of data from a COMPRESSED dataset. Note that specifying an explicit NDF name in this way does not affect whether the native NDF copy is deleted when the dataset is released. This is still determined by the `KEEP' tuning parameter (see §[*]).

If, in the above example, the foreign dataset were called /home/me/data/nebula.sdf.Z (and the `KEEP' tuning parameter was not set), then the NDF name would be tmp_nebula and this name would be passed (as the value of the `^ndf' message token) to any conversion commands that needed to be invoked. The NDF itself would reside in an HDS file called tmp_nebula.sdf (the `.sdf' extension being added automatically by HDS).

Note that the value given for the NDF_KEEP_COMPRESSED environment variable above is, in fact, the same as its default. You should generally be wary of setting this to anything except its default value because the user of an application might well be confused if he sets the NDF_KEEP environment variable to specify that the NDF should be kept, but it ends up with an unexpected name. This facility does, however, give control over which directory is used to store the file.



next up previous
Next: Efficiency Considerations
Up: ADDITIONAL FACILITIES
Previous: Retaining Converted Data


Starlink System Note 20
R.F.Warren-Smith & D.S.Berry
17th July 2000
E-mail:ussc@star.rl.ac.uk

Copyright © 2000 Council for the Central Laboratory of the Research Councils