View previous topic :: View next topic
|
Author |
Message |
Fumigator
New User
Joined: 08 Nov 2006 Posts: 5
|
|
|
|
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 |
|
|
Fumigator
New User
Joined: 08 Nov 2006 Posts: 5
|
|
|
|
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!
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 |
|
|
UmeySan
Active Member
Joined: 22 Aug 2006 Posts: 771 Location: Germany
|
|
|
|
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 |
|
|
Fumigator
New User
Joined: 08 Nov 2006 Posts: 5
|
|
|
|
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 |
|
|
UmeySan
Active Member
Joined: 22 Aug 2006 Posts: 771 Location: Germany
|
|
|
|
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 |
|
|
|