ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Munat <b...@munat.com>
Subject Re: Problem with Insert
Date Sat, 25 Feb 2006 17:29:07 GMT
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. :-)


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 <bent@munat.com> 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
>>the AS400? Seems whacked to me......
>>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* <ericblue76@gmail.com
>>><mailto:ericblue76@gmail.com>> 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* <dchapman@fusionlabs.net
>>>    <mailto:dchapman@fusionlabs.net>> 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

View raw message