Whenever a new history record is written by the NDF_ library, the name of the currently executing application is stored with it. The intention is that this should subsequently allow the software which was used to be identified as fully as possible. In practice, there are several possible sources from which the name of an application may be obtained, so a system of defaulting is used which operates as follows.
The first place in which the NDF_ library looks for an application name is the APPN argument of the NDF_HPUT routine. If this is not blank (and a new history record is being created by this routine), then the value supplied is used directly. This means that the writer of an application which explicitly writes history text via NDF_HPUT can also explicitly supply the name of the application as it is to appear in any new history record.
Whether it is a good idea to supply a name in this manner depends on the circumstances. The advantage is that the name given can be very specific (for example it might contain a version number for the application) and can easily be updated if the application is changed. Conversely, it makes it more difficult to re-use that software in another application and users may be confused if they invoke the application via a command whose name differs from that which is ``hard-wired'' into the software.
If the APPN argument to NDF_HPUT is blank, or if a new history record is being written by some other means (by the default history recording mechanism, for instance), the NDF_ library next looks to see if a ``current'' application name has previously been defined and, if so, it uses it. A current name may be declared at any time by calling the routine NDF_HAPPN, for example:
CALL NDF_HAPPN( 'ADDSPEC Version 6.1-5', STATUS )
and may be revoked by calling the same routine with a blank first argument.
This method is best used in situations where several applications may be invoked by a single executable program. For instance, some software packages have a structure similar to the following, where a command is repeatedly obtained and the appropriate routine (application) is then invoked:
* Loop to obtain commands.
1 CONTINUE
CALL GETCMD( CMD, STATUS )
* Define the current application name.
CALL NDF_HAPPN( CMD // ' (Mypack V3.4-2)', STATUS )
* Invoke the appropriate routine.
IF ( CMD .EQ. 'ADD' ) THEN
CALL ADD( ... )
ELSE IF ( CMD .EQ. 'SUB' ) THEN
CALL SUB( ... )
ELSE IF ( CMD .EQ. 'MUL' ) THEN
CALL MUL( ... )
ELSE IF ( CMD .EQ. 'DIV' ) THEN
CALL DIV( ... )
...
END IF
...
* Return for the next command.
GO TO 1
In such a situation, the NDF_ library has no way of telling when one application has finished and a new one is beginning, so it cannot generate separate names for them. This problem is solved by including a call to NDF_HAPPN before invoking each application, as above.
The final method of obtaining an application name is used only if both of the above methods have failed to produce a (non-blank) name. In this case, the NDF_ library will use a default method, whose precise details may depend on the software environment or operating system in use. For instance, the name of the currently executing file might be used.
The main disadvantage of allowing the NDF_ library to generate the application name itself is that it will not contain precise details (such as a software version number) and may not always be able to distinguish between separate applications invoked from within a single executable program, as in the earlier example. Nevertheless, it is recommended that this method should be adopted first, and either of the above methods substituted if it proves inadequate.