IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

DB2 table semi-locked even after a COMMIT


IBM Mainframe Forums -> CICS
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
Fumigator

New User


Joined: 08 Nov 2006
Posts: 5

PostPosted: Wed Nov 08, 2006 5:17 am
Reply with quote

Greetings all, thank you for reading my question.

I've written a simple CICS application using COBOL and I use a perform loop to handle user input. A simple version would be this:

Code:

 PROCEDURE-DIVISION.
     PERFORM UNTIL EXIT-FLAG = 'YES'
       
*        send modified data to screen
         PERFORM CICS-BMS-SEND-DATAONLY
             
*        use a recieve command to get user input
         PERFORM CICS-BMS-RECIEVE
             
         EVALUATE TRUE
           WHEN EIBAID = DFHENTER
             PERFORM VALIDATE-FIELDS
           WHEN EIBAID = DFHPF3
             MOVE 'YES' TO EXIT-FLAG
         END-EVALUATE
     END-PERFORM
     .
     
 VALIDATE-FIELDS.
     
     EVALUATE RX-SRCH-KEY-IN
       WHEN 'M'
         PERFORM MODIFY-ROWS
       WHEN 'A'
         PERFORM INSERT-ROWS
     END-EVALUATE
     .
     
 MODIFY-ROWS.
 
     EXEC SQL
         UPDATE TABLE
         BLAH BLAH BLAH
     END-EXEC
     
     IF SQLCODE = 0
         EXEC SQL
             COMMIT
         END-EXEC
     ELSE
         EXEC SQL
             ROLLBACK
         END-EXEC
     END-IF
     .
         
 INSERT-ROWS.
 
     EXEC SQL
         INSERT INTO TABLE
         BLAH BLAH BLAH
     END-EXEC
     
     IF SQLCODE = 0
         EXEC SQL
             COMMIT
         END-EXEC
     ELSE
         EXEC SQL
             ROLLBACK
         END-EXEC
     END-IF
     .
         


I guess I have two questions. The first-- is it a good idea to keep the program alive like this, with a PERFORM UNTIL loop? Other CICS code I've seen Actually exit the program with a RETURN back to the current transaction (with data in the commarea), but I personally hate that concept because it uses GO TOs all over the place, and besides, this particular program does not have its own transaction ID; it is only called (using a XCTL command) from a menu program, so I couldn't figure a way to do the ol' RETURN-- there's no transaction ID to use.

That leads to the second question. The DB2 tables I update and insert inside this loop seem to get locked up to any other update, even with those COMMITS in place. I have encountered this table lock problem with an ad-hoc query while the screen is alive; I haven't done any other testing.

Is there any way I can get around this table lockup issue?[/code]
Back to top
View user's profile Send private message
Fumigator

New User


Joined: 08 Nov 2006
Posts: 5

PostPosted: Wed Nov 08, 2006 5:35 am
Reply with quote

Well I found my own answer.... it's of course Murphy's law that states the longer you spend typing your question in a programming support forum, the more obvious the answer is! icon_biggrin.gif

I just used the SYNCPOINT command and it freed the DB2 resources perfectly.

Though... I'm still curious is there are any problems using the PERFORM UNTIL loop logic as I have done.
Back to top
View user's profile Send private message
UmeySan

Active Member


Joined: 22 Aug 2006
Posts: 771
Location: Germany

PostPosted: Wed Nov 08, 2006 3:01 pm
Reply with quote

Hi !

havin a look on your programm i would prefer the normal method of
programming cics transactions. So that one you hate.

As you do, you are blocking all resources till end of transaction.

I think, better send map and return to yourself. Then receive map and invoke the table-modifications and then return the same way.

Coding this in structured cobol without any go-to is possible, as i did this many times.

Also think of concurrent updates/inserts by other transaktions.

Regards, UmeySan
Back to top
View user's profile Send private message
Fumigator

New User


Joined: 08 Nov 2006
Posts: 5

PostPosted: Wed Nov 08, 2006 8:51 pm
Reply with quote

Thanks for the reply.

I'd agree with you with regards to the concurrent update/insert issue, but I have tried my best to lock the screen up with two screens up running side by side doing updates/inserts, and I can't cause a lockup. As long as having the screen up and running waiting for input doesn't prevent another user from making updates and inserts, I can't see a problem. But, perhaps it's different with 10-20 users actively using the screen?

I'd be OK using a RETURN, but I can't figure out how to return to a program that doesn't have a transaction ID associated with it. Is there a way to issue a RETURN to a program name rather than a transaction ID?
Back to top
View user's profile Send private message
UmeySan

Active Member


Joined: 22 Aug 2006
Posts: 771
Location: Germany

PostPosted: Wed Nov 08, 2006 9:02 pm
Reply with quote

Hi again !

In that case you can return to the Menue. In a ComArea Flag you have to
store where you are comming from and what is the next thing to do.

It's only a thought.

Regards; UmeySan
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> CICS

 


Similar Topics
Topic Forum Replies
No new posts Load new table with Old unload - DB2 DB2 6
No new posts Pulling a fixed number of records fro... DB2 2
No new posts Multiple table unload using INZUTILB DB2 2
No new posts Check data with Exception Table DB2 0
No new posts Dynamically pass table name to a sele... DB2 2
Search our Forums:

Back to Top