Calls to the database manager and to the terminal manager are made using a parameter block (SRV_PARA or TRM_PARA in dp4ci.h). If an error is detected, on return the field para.error will be set to a non zero value and various other fields are set to give more information about the error. para.error is where the error level passed to dp4_halt() comes from.
If the error is a system error and SRVn was called para.error==3 and sys_error() is called.
If the error is a fail error and SRVN was called para.error==4 and sys_fail() is called.
If para.error==2 then dp4_error() or dp4_halt() are called depending on
further information in the parameter block.
para.error ==2 is generated from calls to TRM when the user indicates that he
wished to terminate the program (dp4_halt() is called), or when a system or
fail error has been processed by the terminal manager (dp4_error() is called)
The parameters passed to dp4_error() give the details of the error that arose.
If para.error==1 then sys_message() is called. However this facility is never used by the current database manager or by TRMn
When calls to TRMn or SRVn succeed para.error==0.
If para.error has any other value then the call has failed catastrophically probably because SRVn or TRMn are not running or the channel to them is broken. In very old DP4 releases this situation depended on para.error being uninitialised. Post release 4.516 para.error is initialised to 5. If on return para.error is outside range 0 to 4 then if the call was into SRVn sys_fail(9) is generated. (In 4.515 and before a call to sys_fail() was generated using the error information supposedly returned from SRVn. This was obviously garbage and hence caused completely spurious fail messages to be generated when the channel to SRVn was broken.)
If para.error is outside range 0 to 4 after a call to to TRMn then dp4_halt() is called immediately, with parameter 5, (there is no point trying to call sys_fail() as this function itself needs the terminal manager).
Attentive readers will have noted that the generation of calls to sys_error() and sys_fail() through para.error being 3 or 4 was described only in connection with SRVn. This is because traditionally TRM generates calls to sys_error() and sys_fail() internally and then returns with para.error 2, so that when control returns to the application an error message has already been produced.
With 4.6xx/4.523 you can optionally force the terminal manager to return error information in the same way as for calls to the database manager. This is achived by setting the high order bit of df_libtype as follows:
df_libtype |= 0x8000;
This is not recommended because in some situations it is difficult for TRMn to return the information needed for the call to the error function. Additionally TRMn always returns to the point at which errors were generated, and does not longjmp(), so treating them in the same way as SRVn might potentially introduce problems with errors never actually getting reported.