| View previous topic :: View next topic |
| Author |
Message |
Fumigator
Beginner
Joined: 13 Nov 2006
Posts: 2
Topics: 1
Location: Utah
|
 Posted: Tue Nov 14, 2006 11:25 am Post subject: Any problems putting send/receive inside a PERFORM loop? |
 |
|
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
EXEC CICS
SYNCPOINT
END-EXEC
ELSE
EXEC SQL
ROLLBACK
END-EXEC
EXEC CICS
SYNCPOINT 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
EXEC CICS
SYNCPOINT
END-EXEC
ELSE
EXEC SQL
ROLLBACK
END-EXEC
EXEC CICS
SYNCPOINT ROLLBACK
END-EXEC
END-IF
.
|
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 can't just call a RETURN-- there's no transaction ID to use. I could return back to the menu transaction with a field in the commarea directing control immediately back to the program, but that seems like the long way of doing things.
The SYNCPOINT seems to free any resources-- I was able to run multiple screens at once and update/insert at will from any of the screens, so it doesn't appear to me that this method locks up any resources.
Can anyone tell me why this is a bad idea?[/code] |
|
| Back to top |
|
 |
Fumigator
Beginner
Joined: 13 Nov 2006
Posts: 2
Topics: 1
Location: Utah
|
| Posted: Wed Nov 22, 2006 10:25 am Post subject: |
|
|
Wow, no one has an opinion on this? That must be a good sign... it really does seem to work great in test but you never know what can happen when users climb all over it...
Thanks anyway, the silence actually gives me my answer  |
|
| Back to top |
|
|
haree_amrid
Beginner
Joined: 21 Dec 2005
Posts: 9
Topics: 3
Location: INDIA
|
| Posted: Wed Nov 29, 2006 5:22 am Post subject: |
|
|
Usage of syncpoint will free the resources.
But I am having a small correction for your code. There is no need to use commit in a cics-db2 program. This is because if you issue a EXEC CICS SYNCPOINT command, it will internally issue a commit on DB2 resource manager as CICS is the transaction manager & also I hope we will get an error message if we do a commit in a Online-DB2 program. |
|
| Back to top |
|
|
|
|
|
FAQ
Search
Quick Manuals
Register
Profile
Log in to check your private messages
Log in
