Currently the z/TPF system supports the atexit function which you can use to define functions to be called on a last-in first-out (LIFO) basis when the ECB exits. However, this function cannot be called when the ECB is exiting with a system error (SNAPC or SERRC dump). To handle this case, PJ47122 provides 2 new functions tpf_systemerror_atexit and tpf_systemerror_remove_atexit .
The tpf_systemerror_atexit function registers the functions to be called if a system error (SNAPC or SERRC with EXIT) occurs. This function has the same restrictions on the function definition as the atexit function. When the routine that calls the tpf_systemerror_atexit function (for example FUNC A) finishes processing, the tpf_systemerror_remove_atexit function should be called to unregister the function. Information about the dump (similar to what is displayed by the ZDHST command) will be passed to the function. A new function that is registered by the tpf_systemerror_atexit function (let’s say FUNC B) will not have access to the stack frame that was in the FUNC A. FUNC B must issue a return. If FUNC B exits or issues another dump, then any other functions added by the tpf_systemerror_atexit function will not be called. The registered functions will be called in the subsystem in which the tpf_systemerror_atexit was done. If a commit scope is open when the error occurs, it will not be rolled back. The tpf_systemerror_remove_atexit function is designed mainly to be used in ‘middleware’ where the function in question may be called in many different ways. Using the tpf_systemerror_remove_atexit function will prevent problems that occur after FUNC A has completed from activating FUNC B (which may not know how to handle them) .
For heap or multi database facility (MDBF) corruption dumps, the functions registered by the tpf_systemerror_atexit are not called.
Here is some sample code on using these functions.
This sample sets valid4 to be called when an error occurs. In this sample a serrc_error is added for illustration. The ebw000 field is used as an indicator in the ECB to tell valid4 function if we need to commit the data or not.
tpf_systemerror_atexit(valid4);
tx_begin();
value ++;
ecbptr()->ebw000=0;
create_fa();
update_fa();
ecbptr()->ebw000=1; // indicate to error processing we should
// commit the data
// force a dump
If (i== 0)
serrc_op_ext(SERRC_EXIT, 0x94204
"HA HA HA ",
'I',NULL
tpf_systemerror_remove_atexit();
The following sample shows the definition of the valid4 function which determines whether to commit the data or roll it back after the error occurs.
void valid4(struct idssye *i)
{
wtopc_text("in valid yy4 \n");
if (ecbptr()->ebw000==1)
{
wtopc_text("commit \n");
tx_commit();
}
else
tx_rollback();
return
}
What could be done in these user defined functions.
1) Clean up business event queues after an error
2) Do a postc to clean up an event instead of relying on the eventc timeout mechanism
3) Issue a warning message that a process did not complete normally