|
View previous topic :: View next topic
|
| Author |
Message |
Binop B
Active User
Joined: 18 Jun 2009
Posts: 407
Location: Nashville, TN
|
|
|
|
Hi All,
Would like to know if locking a record in CICS can be continued even after the REWRITE statement is executed.
Scenario:
We are trying to migrate the current system to CICS. In the current system there is logic like this ..
- Read a record and hold it
- Rewrite the record and keep holding the record
- Rewrite the record
Is this possible in CICS ?
At present ...
We tried to use the READ UPDATE option but the statement is erroring out at the second REWRITE with a EIBRESP2 code of 47. Also, due to other requirements we are having the TOKEN option along with the UPDATE.
Thanks in advance ... |
|
| Back to top |
|
 |
Garry Carroll
Senior Member
Joined: 08 May 2006
Posts: 1193
Location: Dublin, Ireland
|
|
|
|
| Quote: |
- Read a record and hold it
- Rewrite the record and keep holding the record
- Rewrite the record
|
That seems an unusual way to process. The REWRITE will release the lock, as you have seen, so your choices would seem to be to re-READ the record for UPDATE to establish a second lock. This will not prevent some other task getting the record in the intervening period between first REWRITE and second READ, so you might implement (and enforce) an enqueue mechanism around the pairs of READ/REWRITEs to prevent accesses by other tasks.
Garry. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
| AFAIK, you'll have to read the record for update again after doing the first rewrite. |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
ENQ/DEQ would be another method, although any program which accesses this file would have to participate.
For CICS, you could use the ENQ/DEQ API's.
Bill |
|
| Back to top |
|
|
Ronald Burr
Active User
Joined: 22 Oct 2009
Posts: 293
Location: U.S.A.
|
|
|
|
Out of curiosity,
If you have no intention of letting any other process access the record you are rewriting (twice) until after the SECOND rewrite, why are you rewriting it the first time? Consider,
a) after the first rewrite, you don't want any other process to access the updated record, and
b) the process actually DOING the rewrite HAS the record in storage between the first rewrite and the second rewrite.
Why not just eliminate the first rewrite? The record will remain locked until you issue the (previously second) rewrite. |
|
| Back to top |
|
|
Binop B
Active User
Joined: 18 Jun 2009
Posts: 407
Location: Nashville, TN
|
|
|
|
Thanks all for your guidance ... 
Since this feature is not directly possible, we are now looking into the suggestion given by Ronald. Analyzing the programs to see if the first rewrite can be skipped and futher more, if there are any other situations like this ...
Will post in case of any new findings....  |
|
| Back to top |
|
|
Binop B
Active User
Joined: 18 Jun 2009
Posts: 407
Location: Nashville, TN
|
|
|
|
@Ronald
| Quote: |
| If you have no intention of letting any other process access the record you are rewriting (twice) until after the SECOND rewrite, why are you rewriting it the first time? |
As mentioned in my first post, we are doing a migration. Fortunately or unfortunately...  ... this logic is already present and supported in the current system ... We were looking into the possiblities of simulating this in CICS. |
|
| Back to top |
|
|
|
|
