z/TPF - Group home

Support for the tpf_systemerror_atexit function (PJ47122)

By Barry Goldberg posted 17 days ago


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.




         value ++;




         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 ",



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");







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