As already indicated, there may be circumstances where finer control over the recording of history information is required than is provided simply by the state of the history component. For instance, you might want to disable further recording of history information for an NDF without losing the record of its past processing history. There may also be cases in which rather brief history information is required in order to save file space, or other circumstances where the fullest possible information is required (perhaps if the processed data were intended for archiving).
These requirements are met by the history update mode associated with an NDF's history component. It may have any of the following states, with the associated meanings:
`DISABLED' No history recording is to take place `QUIET' Only brief history information is to be recorded `NORMAL' Normal history recording is required `VERBOSE' The fullest possible history information is required
When a history component is first defined, its update mode defaults to `NORMAL'. This may subsequently be altered using the NDF_HSMOD routine, so long as `WRITE' access is available for the NDF, as follows:
CALL NDF_HSMOD( 'DISABLED', INDF, STATUS )
The update mode string may be abbreviated (to not less than 3 characters).
The history update mode is a permanent attribute of the history component and remains with it to affect subsequent recording of history information, although it may be given a new value at any time. It affects both default history recording and (potentially) history information written explicitly by applications, according to its value at the time the information is written.
As might be expected, the HMODE argument of NDF_HPUT (set to `NORMAL'
in the example in §) corresponds with the
history update mode argument of NDF_HSMOD. In this case, it
specifies the ``priority'' which the history information should have
and takes one of the following values:
`QUIET' | Highest priority |
`NORMAL' | Normal priority |
`VERBOSE' | Lowest priority |
The text supplied to NDF_HPUT will actually be written to the NDF only if:
Otherwise, NDF_HPUT will simply return without action (or error).
The purpose of this is to allow applications to tailor their explicit recording of history information to the setting of the history update mode attribute of the NDFs they are processing. Thus, most history text might be classed as `NORMAL' but additional information classed as `VERBOSE' could also be provided and would only be available to users who request it (by setting the history update mode of their NDFs appropriately). Really vital information should be classed as `QUIET', and will then always be delivered unless history recording has been completely disabled.
If the HMODE argument of NDF_HPUT is left blank, it defaults to `NORMAL'.