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