DSNREXX - Running another DB2 plan - I get a separate LUW-ID

[mikerexx]

I have a REXX that uses DSNREXX to Select data from a DB2 table. It then will call an existing batch program/package that is part of a separate DB2 plan. When I call/start the subsequent plan, I see evidence that another LUW-ID has begun.

I need to control the UOW from the outer REXX code. So, I need 1 LUW.

(The way I know that I get a subsequent LUW-ID is because I got luck/unlucky in that the batch program receives a -911. The source of the contention is the me - the DSNREXX plan that I am initially connected to.)

Keep in mind that I dont care about the -911. I care about using a single LUW for both REXX and the called batch program. For reference, part of the DB2 log is attached:


DSNT376I -DBss PLAN=btchpln WITH 743
CORRELATION-ID=mytsoid
CONNECTION-ID=DB2CALL
LUW-ID=xxx.mmmmmmm.C8AEF0DF5CD1=128132
THREAD-INFO=mytsoid:*:*:*
IS TIMED OUT. ONE HOLDER OF THE RESOURCE IS PLAN=DSNREXX WITH
CORRELATION-ID=mytsoid
CONNECTION-ID=DB2CALL
LUW-ID=xxx.mmmmmmm..C8AEF0D7DD45=128124
THREAD-INFO=mytsoid:*:*:*
ON MEMBER DBss

 

[Schlabb]

That's not possible. Starting a batch job which connects to DB2 always creates a new DB2 thread and thus is a separate Unit Of Work.

You said "I need to control the UOW from the outer REXX code." Why?
And in addition you said "I dont care about the -911." Why?

You SHOULD care about a negative SQL code like this! It says that your program has waited too long for a DB2 resource which has been locked by another task (obviously your own TSO address space).
Concentrate on avoiding this event. Maybe you should have a look at your current REXX program and its DB2 access methods. Do you always use an explicit FOR FETCH ONLY on SQL SELECT statements? Do you use always COMMITs, even if it's a simple SELECT?
If nothing really helps, you could try to disconnect from DB2 before you submit the batch job.

There are 10 types of people in the world: Those who understand binary, and those who don't.

 

[mikerexx]

Schlabb,
Thanks for the reply. I have coded around the problem now. However, to continue the discussion:

The -911 is useful in that it let me know that I got a separte LUW-ID. Let me be more clear on what the code does:
The following is pseudo code:

/* REXX */
...
ADDRESS DSNREXX
...
SELECT * FROM T1
...
ADDRESS TSO
CALL 'HLQ1.HLQ2.EXECLIB(BTCHPGM1)
...
UPDATE T2 SET C1 = 'XXX'...
...
COMMIT

As you can see the Call to BTCHPGM1 is not a "batch job" but only a batch program written in COBOL, linkeditted to ... execlib and bound appropriately to the DB2 subsystem. The reason I said batch is to distiguish it from a CICS program or the like.

So, BTCHPGM1 makes DB2 updates. The REXX makes DB2 updates. The REXX is the driver/caller. So, the UOW should be controlled by the REXX - it has to be controlled by the REXX.

Again, my focus is the need for 1 LUW-ID. If I get 1 LUW-ID, the -911 will not happen.