|
View previous topic :: View next topic
|
| Author |
Message |
dejunzhu
Active User
Joined: 08 May 2008
Posts: 390
Location: China
|
|
|
|
Everytime I issue a transaction which calls a DB2 subprogram, after successful execution, I view the DB2 table to check the processing result through SPUFI, the screen is locked. But at this time, when I issue " CEMT I TASK(*)' to check if any task is using the table or not, but there is no running tasks.
and after a while, SPUFI returns with SQLCODE -911.
How can this happen? how should I find out the culprit?
WOuld you please give me some hint on this? thanks. |
|
| Back to top |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| CEMT I TASK(*)' to check if any task is using the table or not, but there is no running tasks. |
If your programs are written as pseudo-conversational programs, MOST of the time they will not show up on a CEMT I TAS since when the program is done and does the EXEC CICS RETURN TRANSID the task is completed and hence won't show up. I know CICS hands the work to the DB2 subsystem for processing; I suspect that CEMT I TAS might not show DB2 subsystem activity but I cannot say for sure since it's been a LONG time since I worked on a system running DB2. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
I suspect that spufi is getting a timeout rather than a deadlock.
I also suspect you are locking "things" whren it is not necessary. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
not knowing anything about the tables, the activity or the setup,
insure that you are always using WITH UR in your spufi SELECTs |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
as in batch,
when a cics task requests a db2 service,
the requesting task (batch or cics) is 'suspended', awaiting a return from db2.
db2 will provide a service - for a batch/cics task.
i can think of no time db2 will be performing a service for a non-existent task.
so, if you are receivng a -911,
of which you receive also a reason code and a type of resource code
which you did not bother to share or look/up
which is usually helpful in determining the cause
i would suggest that something else is affecting the DB,
other than your non-existant CICS trans.
just for grins, try the cemt inq before you do the spufi. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
also,
any db2 threads started by a batch/cics tasks
will be terminated when the batch/cics task terminates,
whether it is a commit or rollback depends on what parms the tasks sent to db2.
and sometimes this rollback (or commit) takes a long time.
a good example is a spufi update of a gazillion rows.
if you terminate the spufi session or the tso session supporting the spufi task,
prior to db2 completing the update and commit,
it takes (sometimes) a long time for the tso/ispf session to terminate
and your are allowed to sign back on.
it takes a while for db2 to rollback all the changes and return to tso/ispf
and allow the tso/ispf session to really terminate.
but the above case would still have the transid as active,
until db2 finishes and the cics task terminates. |
|
| Back to top |
|
|
|
|
