Unanswered: Locks aquired for calling a subroutine w/package
I've got a little academic question concerning locking in DB2 z/OS.
We're running a 3rd party software that in some situations runs a batch that for some reasons we can't discuss does not issue any COMMIT. This software is somewhat database independent and so it does have it's own transaction control.
In some cases this batch receives an SQL -904 with reason code 00C90096, and then starts its own backout. Since no lock is freed the first access receives the same error. In this situation the software calls another subroutine with its own package that shall issue an EXEC-SQL ROLLBACK END-EXEC. only. The Package contains several statements, but the programmer swears a holy oath that in this specific condition only the ROLLBACK will be issued.
After calling the subroutine the batch receives another -904/00C90096 trying to lock some off the catalog's skeleton tables.
Since the application ends with CC=16 DB2 after the lase SQLCODE, DB2 executes an implicit COMMIT and saves inconsistent data.
The 3rd party now claims that DB2 was unable to execute the ROLLBACK by some defaults in out installation. We shall fix them and the ROLLBACK will work in this situation.
This situation is a little beyond normal DB2 knowledge. As far as I understand DB2 (after 18 years) there are some locks necessary to open the package. Obviously there is no difference between "User Locks" needed for coded statements and "internal locks" used to open e.g. plans and packages. I can't find any installation values to change this - inspite of increasing the maximum number of locks what will not be useful because the number will be finite in any way. Since the batch is run in out "rush hour" with the most online activity of the day a "ALTER TABLESPACE LOCKSIZE TABLESPACE" before running the batch isn't acceptable, too.
So my question:
Did anyone experience a similar situation?
Am I right that in case of a -904/00C90096 there is no chance of calling a subroutine with own package, even for a ROLLBACK?
I think that an EXEC SQL ROLLBACK END-EXEC. instead of the CALL.... will work, but I would need some Redbook or other literature to proof that...