1. A thread must be created for each application that needs DB2 for MVS/ESA services. If the application is local, the thread is created when the first SQL statement is executed. If the request comes from a remote client, the thread is created when the client application issues the SQL CONNECT statement. After the thread is created, SQL statements can be executed.
2. When a client application issues an SQL CALL statement, the stored procedure name and the I/O parameters are passed to DB2.
3. When DB2 receives the SQL CALL statement, it searches in the new SYSIBM.SYSPROCEDURES catalog table for a row associated with the stored procedure name. From this table, DB2 obtains the load module associated with and other information related to the stored procedure.
4. Stored procedures are executed in a new address space, the stored procedure address space (SPAS). You can specify a number of task control blocks (TCBs) in this address space available for stored procedures. Each stored procedure is executed under one TCB. After searching the SYSIBM.SYSPROCEDURES table, DB2 searches for an available TCB to be used by the stored procedure and notifies the stored procedure address space to execute the stored procedure.
5. When DB2 notifies the stored procedure address space to execute a stored procedure, the thread that was created for the client application is reused for an execution. This has the following implications:
   • CPU cost is low because DB2 does not create a new thread.
   • Accounting is on behalf of the client application.
   • For static SQL the OWNER of the client program must have execute privilege on the stored procedure package. For dynamic SQL issued by the stored procedure, security is checked against the user of the client program, unless the DYNAMICRULES(BIND) option was specified when binding the package for the stored procedure. No sign-on or connection processing is required.
   • Any processing done by the stored procedure is considered a logical continuation of the client application's unit of work. Thus, locks acquired by the stored procedure are released when the client application commits or rolls back.
6. The stored procedures address space uses the LE/370 product libraries to load and execute the stored procedure. Through the SYSIBM.SYSPROCEDURES you can pass run-ti me i nformation for LE/370 when the stored procedure is executed.
7. Control is passed to the stored procedure along with the input and output parameters. The stored procedure can issue most SQL statements. It also has access to non-DB2 resources.
8. Before terminating, the stored procedure assigns values to the output parameters and returns control to DB2.
9. DB2 copies the output parameters received from the stored procedure to the client application parameter area and returns control to the client application.
10. The calling program receives the output parameters and continues the same unit of work.
11. The client application implicitly or explicitly issues the COMMIT statement. If the client application and the stored procedures used during this execution update at different sites, the two-phase commit protocol is used.