CICS DB2 query Interface (like DSNC) but SPI

The enhanced CICS-DB2 thread purge is also satisfied by CICS Transaction Server for z/OS V5.5 which is GA today December 14th 2018.
The issue if needing an api to get the DB2 token so as to cancel a DB2 thread has been solved a different way. DB2 returns the thread token to CICS when a create thread is issued. CICS uses this during task purge or forcepurge. If CICS detects a DB2 request is in progress at the time of the task purge, it will use the DB2 thread token to issue a IFI cancel thread request to DB2 (using a command thread) to cancel the DB2 thread before purging the CICS task.

The enhanced CICS-DB2 thread purge is also satisfied by CICS Transaction Server for z/OS V5.5 which is announced today 2nd October 2018 and which has a planned availability date of 14th December 2018.
The issue if needing an api to get the DB2 token so as to cancel a DB2 thread has been solved a different way. DB2 returns the thread token to CICS when a create thread is issued. CICS uses this during task purge or forcepurge. If CICS detects a DB2 request is in progress at the time of the task purge, it will use the DB2 thread token to issue a IFI cancel thread request to DB2 (using a command thread) to cancel the DB2 thread before purging the CICS task.

For more information see the CICS TS V5.5 announcement letter https://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/2/897/ENUS218-352/index.html&request_locale=en

The issue if needing an api to get the DB2 token so as to cancel a DB2 thread has been solved a different way. DB2 returns the thread token to CICS when a create thread is issued. CICS uses this during task purge or forcepurge. If CICS detects a DB2 request is in progress at the time of the task purge, it will use the DB2 thread token to issue a IFI cancel thread request to DB2 (using a command thread) to cancel the DB2 thread before purging the CICS task. This is available via apar PI98569 on CICS TS 5.1, 5.2, 5.3 and 5.4

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Transaction Processing
Product - CICS Transaction Server

For recording keeping, the previous attributes were:
Brand - WebSphere
Product family - Transaction Processing
Product - CICS Transaction Server

It's becoming a larger issue on purging tasks in DB2, from CICS.

We have an automatic task purger; and have excluded DB2 tasks from force purge.

Had one the other day, ran 18 hours in DB2; the purger tried to purge normal; could not do so RC=13.

In the past, the automatic purger knocked DB2 out several times in the past; causing he DB2 subsystem to abend. So we removed the force purge.

How do you get the Task DB2 THREAD ID in a CICS policy function, to issue a DB2 CANCEL THREAD via MVS Console?

If hung in DB2, would not come back to CICS, For example a Stored Procedure. One SQL request could cause a process to run a long time in DB2; looping. One SQL FETCH could result in a DB2 page fetch condition where it does not return to CICS.

We do have a program with a huristic to evaluate long running tasks and in most cases detect a hung task on a DB2 thread. According to the IBM documentation, the safest way to cancel the thread is thru a DB2 CANCEL THREAD command.

If it is now safe to purge / force purge a task in CICS without the risk of abending DB2, will this be reflected in the CICS manual? We don't want to risk abending DB2, which has happened several times in the past when issuing purge / Force Purge from CICS.

Thanks, Steve.

Reply received from customer by email.

Hi Steve,
We have for many years supported forcepurge from the CICS side (even from the time when the attach was owned by DB2). In the pre OTE days that resulted in the CICS-DB2 Attach detaching the subtask TCB. Now we use OTE L8 TCBs it results in a asynchronous mvs abend for the TCB. Whilst in theory you could catch DB2 in a 'must complete' window and cause an outage, those windows are pretty small and have smaller over the years.
Latterly we have also supported purge across the RMI for DB2, as well as forcepurge. The same asynchronous mvs abend results.

So yes, whilst the absolute safest is to cancel the thread from the DB2 side, there are plenty of people who do so from the CICS side.

Comments ?

Regards,
John Tilling

Also, as a for example a single SQL doing hundreds of millions of page fetches, in DB2, but not coming back to CICS. Or a stored procedure, executing in DB2 and not coming back to CICS.... neither could be purged from CICS side, but need a cancel thread.

The issue may not be a loop in CICS, going to and from DB2. Some requests need a cancel thread in DB2. This can't be issued from CICS unless using the 3270 screen oriented transaction. A task can be purged in CICS, but it's still running in DB2, The task would not be coming back to CICS, for instance if a purge were issued the purge would be deferred RC=13. If a cancel thread is issued in DB2, then task would end.

I figure to be able to inquire on task in DB2, getting the thread ID etc; issue a cancel thru and API or via automations to DB2,

In re-evaluating this requirement, we would like to ask if the policy function introduced in CICS TS 5.1 would satisfy this ? Its a case of where the loop is. If the application is looping issuing SQL commands then you can set a policy in CICS so that after so many SQL requests the transaction would be abended.

This is something we'd like to look into for a future release.