MVSFORUMS.com

[chandhroo]

Could anyone please explain me the situation of using SYNCPOINT in CICS/DB2 programs. To make it clear, there are two programs, Pgm A and B. Pgm A linking B which inserting records into DB2 table and returns back to Pgm A with message error or successful based on SQLCODE. In this situation should we do SYNCPOINT in Pgm B if SQLCODE is ZERO before returning to Pgm A? Will inserted record be permanent available when we come back to Pgm A without issuing SYNCPOINT? I think table changes will become permanent after task completed. Can I assume task completed when control comes back from Pgm B to Pgm A. Hope I don't confuse.

[kolusu]

chandroo,

Yes the record will be available in PGM A even without issuing the syncpoint. The CICS RETURN Command in the linked program ends the task and a commit happens.

But I guess it wouldn't hurt if you had a syncpoint in the linked program also.

Hope this helps....

cheers

kolusu


PS: I am moving this topic to CICS forum as it seems more approriate forum for this question.

[Manas Biswal]

Hi Chandroo,

Just to add to what Kolusu has said, if both your linking programs and linked-to-program are there in the same CICS region, there will be an implicit syncpoint once control is returned back to the calling program and all your DB2 updates will be committed. But if the linking program and the linked-to-program exist on two different CICS system and you are using Distributed Program Link to call the subprogram, be sure to specify SYNCONRETURN in the EXEC CICS LINK command. This will issue an implicit syncpoint in the called program when it has finished executing. If you don't specify SYNCONRETURN, then all updates done by the called subprogram will not be committed until there is a SYNCPOINT in the calling program or the task ends.
SYNCONRETURN is available from CICS/ESA v3.3.

Regards,
Manas

[Bharathi_80]

Hi Manas,

I have a similar issue wherein its a DPL and it seems that we cannot issue a SYNCPOINT command which is linked from a program that resides in some other CICS region. I face a -911 as explained above as I have many transactions running and we do not have a COMMIT(SYNCPOINT)..When SYNCPOINT command with ROLLBACK is executed, an abend AD2Z happens...Can you throw some light on this area...

When I analysed the CICS TRACE...I could see an UPDATE query(without any cursor) failing resulting in -911 which then issues a SYNCPOINT command...Ur suggestions are most welcome...

P.S that we have bound the program with a RELEASE(COMMIT) option.I doubt that no COMMIT is issued and hence each pool waits for the resource and gets timed-out resulting in a -911.The message that I see in DB*MSTR log is as below.

DSNT375I -DBXX PLAN=PLAN0001 WITH
CORRELATION-ID=POOLCPMI0010
CONNECTION-ID=CONN0001
LUW-ID=IBMIN.HDB2DBXX.BDCA65AB583D=118857
THREAD-INFO=DBQULFR:*:*:*
IS DEADLOCKED WITH PLAN=PLAN0001 WITH
CORRELATION-ID=POOLCPMI0007
CONNECTION-ID=CONN0001
LUW-ID=IBMIN.HDB2DBXX.BDCA65AB2817=118836
THREAD-INFO=DBQULFR:*:*:*
ON MEMBER DBXX

Thanks
Bharathi

[Manas Biswal]

Bharathi_80,

From what I could get from your message and logs, your problem seems to be two-fold.
At the DB2 level, there is a deadlock between two competing UOWs. I will not be able to provide much info about the deadlock from the MSTR log that you have provided without any background information. But both the deadlocking UOWs seem to have originated from local plans and are not distributed threads. Check your transaction isolation levels and general transaction control to see where your problem is. Or else provide more details for us to find out the reason for your deadlock.

Now your second problem is a CICS problem because of which you are getting the AD2Z abend. When your UOWs are deadlocking, one of them is being rolled back (the one which has a DROLLBACK value of "ROLLBACK" in the db2e thread) will be attempted to be rolled back. Now when CICS does a SYNCPOINT ROLLBACK, it will try to rollback all the updates right till the calling CICS program executing in some other CICS region (connected via DPL). Basically, when attempting such a SYNCPOINT ROLLBACK, CICS is not able to rollback the updates in the calling CICS program in the other region. This is leading to the AD2Z abend. The most probable reason for this is that you have not specified SYNCONRETURN in the LINK while calling over DPL. Try using SYNCONRETURN and see if that works in resolving the AD2Z abend.

HTH....Regards,
Manas
_________________
There is no path to peace. Peace is the path.
- Mahatma Gandhi (1869-1948)