IBM Mainframe Forum

Was just curious, Is possible to establish an end of task activity?

Well, usually in a typical DB2 batch application, the main program is either called the DSN program (TSO Attach) or calls a main Call Attach Facility which controls the connectivity with DB2.

Basically, I'm trying to do is to create a Smart CAF (Call Attach Facility) utility.
While experimenting, I noticed that our Cobol code is compiled with the DYNAM compile option, which in turns dynamically calls the DSNHLI SQL interface module.
However, I figured out how to create an alias of this module in my load library which calls my utility. Basically, my utility when called for the first time, establish the necessary connectivity with DB2, loads a copy of itself and passes control to the real DB2 interface module. In essences it terminates and stays resident (TSR), since it’s load count does not go down to zero.

My dilemma, is how to determine when the last program is executed, so that I can perform the final disconnect from DB2. I know to locate the current TCB information, but I cannot seem access the end of task activity routine. Although, the address of Save Area of the first program in task is listed in the TCB map, it does not appears addressable.
I not sure if there is a way to establish/schedule an end of task routine in this context.

You have the end of task exit routine established by the ETXR=xxxx parameter on the ATTACH macro that might be capable of performing the end of task activities you need. I have never used this routine or ever determined at what point in system end of task processing the routine is entered. It appears it is run under an IRB in the TCB of the originating task, so (and I'm guessing here)

• All allocated storage has been freed except storage in subpools shared with the originating task.
• All possible data sets have been closed.
• TCBFSA points to nothing (since the related storage has been freed).

I think all this routine can do is

• POST an ECB in the originating task that the subtask has completed, though this seems unnecessary because you have the ATTACH macro ECB parameter.
• DETACH the subtask TCB.

You also have the system end of task function. This is specified by the subsystem calls. This requires the routine be in CSA or LPA. It may be system wide rather than address space owned. If you have the patience you can find an example in the modules that used to be known as HASPSSSM.

Hello, Steve
Thank you some much for your response. Though, I wasn’t clear, I didn’t have any control of how the task was started.

Here is the scenario of the application.
Program a (non – DB2) calls program b which is a DB2 program.
When program b, upon executing it's first SQL, calls the DSNHLI module. Because my load library proceeds before any DB2 library, the DSNHLI module encountered is an alias of my utility module.
Though, I figured out how to handle the first time logic, but I was baffled with the “at end of process” logic.

Basically, this utility is just an interceptor any SQL calls. In actuality, I’m simply borrowing the concept from the previous company I worked at where they used a vendor product called Smart/RRSAF which allow them to run their DB2 batch programs with regular JCL (which no special calls embed in the code).

Actually, I believe I made progress. As a kludge, I’ve discovered if one were to traverse up the previous save areas, eventually I encountered the root save area prior to returning to the OS (or end of task). Basically, I carefully added a “Hook” where my clean up logic is called. Then I return control back to the root caller, while preserving the general purpose registers as they were.
I've tested this assembler module in both "debug" mode and without debug. It appears to work (well at least not blow up).