Re: Drop Case API

As I recall REXX SQL runs by default with isolation [there was no SET ISOLATION LEVEL statement in the source]. I wondered if maybe the process was functional, but for lack of a coded COMMIT, then a COMMIT or ROLLBACK must have been issued from the command line in testing it? If it was not under isolation, then one would expect that the coded ROLLBACK is flawed.? For having a ROLLBACK on error but no COMMIT coded for success, that is what led to my posting this inquiry. But additionally I wondered, can a SELECT done FOR UPDATE and WITH NC really allow for the UPDATE WHERE CURRENT OF under isolation? I have never tried nor done that. I suppose as dynamically scrollable, the data is selected or omitted dynamically to avoid any concern for changing data; and of course the specific row from the FETCH is locked to prevent any change by another request.

Here is a PTF for a ROLLBACK for a WITH NC cursor combined with other work under isolation:
http://www-01.ibm.com/support/docview.wss?uid=nas3b38d4626399ff2a886257528005d7a4c

FWiW: If isolation is expected, the setup does not include any noted requirement for establishing logging [journaling] for the TABLE which is required to enable isolation [commitment control].

Also FWiW: I believe the use of RC to reflect the SQL activity is not going to be generally functional as coded & commented. That is, I believe a SavedRC=RC would need to be used after each SQL and then exit using the SavedRC value, since the RC as utilized could reflect the Return Code for activity which was post-SQL.?

Regards, Chuck

Tom Liotta wrote:

<<SNIP>>

It's the SQL that created a small table for testing plus a REXX proc that loops through the table (using SQL) setting a VARCHAR column to Drop Case.

It's a bit more complex than just the small part that does the Drop Case by itself. But you already have your RPG solution, so I might as well go the extra distance.