Heh, my RPG guy (who I've never met... all my stories are through the project lead) is
fond of saying "I can do that, but it'll dim the lights". It's become quite the nice
little catch phrase around the office. :-)
b
Ted Schrader wrote:
At risk of bending the thread off topic a bit, here are my two cents:
I've run into the same situation at my workplace, as well.
Fortunately, our web applications are mostly reporting or entail very
simple transactions. The way I understand it, the 400 is such a
different animal that RPG programs don't really have to worry about
commitment control as long as the 400 folks mind the system messages.
Furthermore, to "turn on" journaling and commitment control means
modifying all the RPG code that touches the files/tables involved to
issue the RPG equivalent of commit and rollback, a significant
undertaking. So, it's not going to happen.
With that said, the 400 never seems to flake out. The only mangled
transactions I've had to deal with have always stemmed from malformed
SQL on the web side (i.e. my fault).
In an earlier thread, Ben mentioned that his SQLMaps sometimes invoke
stored procedures which, in turn, invoke RPG programs. This may be an
avenue to encapsulate extensive transactions and push it down to the
400-level. Our web apps are invoking 400 programs directly via the
iSeries Toolbox for Java API, which I would like to have changed to
stored procedure calls instead.
Cheers,
Ted
On 25/02/06, Ben Munat <[EMAIL PROTECTED]> wrote:
Huh. And here I thought the RPG contractor on the project I've been working on
was just a
crazy old "mainframe guy"... So, life without transactions is just par for the
course on
the AS400? Seems whacked to me......
b
Jeff Butler wrote:
I think that's a good lead. Most AS/400 tables are not journalled and
do not support transactions. Try using the EXTERNAL transaction manager
which will turn off all transaction processing in iBATIS - maybe it will
make a difference.
BTW - the AS/400 terms for transactions are "commitment control" and
"journalling". Ask the AS/400 folks in your shop if they've these
things - my guess is probably not.
Jeff Butler
On 2/24/06, *Eric Blue* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi Davis,
Do you have autocommit enabled by default? Trying Googleing 'db2
"not valid for operation"'. I noticed quite a few references to an
error message like this due to journaling/commit/rollback problems.
On 2/24/06, *Davis Chapman* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
I'm running into a perplexing problem. I'm trying to replace a
homegrown DOA
with iBatis in an application running against DB2 on an AS/400.
All of my
selects are running fine. But when I try to run an Insert
statement, I get
the following error:
Caused by: java.sql.SQLException: [SQL7008] ECEP in T0MD618D not
valid for
operation.
Caused by: com.ibatis.common.jdbc.exception.NestedSQLException :
I've double checked everything I can think of. I'm connecting
with the
correct credentials, etc. I've used iBatis extensively in other
projects
with lots of success, but this has me baffled. Any ideas what
could be
wrong?
Thanks,
Davis Chapman
