ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Butler" <jeffgbut...@gmail.com>
Subject Re: Problem with Insert
Date Sat, 25 Feb 2006 21:22:15 GMT
AS/400 is a system that I have a long history with, and great respect for -
so maybe I can shed some light on the topic.

AS/400 was based on S/38 - the first system from IBM to have an integrated
relational database database.  It was one of the first commercial systems to
be object based, and it also included a virtual machine long before Java was
even a glimmer in Gosling's eyes.  The system has a very advanced
architecture - perhaps still the most advanced commercial system available.
It grew out of an IBM research project that was intended to find a suitable
replacement for the 360 series - the real mainframes.  If it hadn't been for
IBM protecting the cash cow of their mainframe sales (and that pesky
backwards compatibility guarantee), the S/38 and AS/400 could have possibly
eclipsed those systems altogether - it's that much better. (I used to do
technical sales support for AS/400 long ago - can you tell?)

These days we can hardly concieve of a relational database without SQL - but
they are in fact two seperate technologies.  The AS/400 has a long legacy of
RPG and COBOL based apps that have to run on it.  RPG and COBOL are more
attuned to ISAM like operations (read by key, read next, read by relative
record number, etc.).  So even though the system is integrated with a fully
functional relational database, most AS/400 programmers do not use SQL,
declarative referential integrity,  automatic transactions, etc.  They still
need to deal with the same issues we do, they just do them in different ways
and they use different terminology.

 When I first started programming PCs, I was shocked at how primitive they
are - no multi programming support, no protection, very easy to crash the
system, very few system services, etc.  It seemed like going back to the
dark ages.  Things are better now of course, marginally.  Even now when
I train AS/400 folks to use Java and the web, the usual first reaction is
this - "is this really progress?".  I think it's a fair question.

Anyway, to the questions at hand.  AS/400 administrators can turn on
journalling (transaction support and logging) without any change to existing
programs.  This would have the effect of autocommit=true in Java.  There are
performance implications of journalling - hence the hesitation of some
AS/400 administrators to do it.  Of course, there are performance
implications with this in all databases, it's just that we don't usually
think about it in these terms because we don't have the option of turning it
off in most databases.

Commitment control must be programmed - just like transactions must be
programmed in Java.  We're fortunate to have something like iBATIS that
handles it all for us automagically.  Maybe I should work on iBATIS for
RPG?  On second thought, no.

BTW - do you know the definition of "legacy"?  Legacy is something that
actually works. I like that joke.  :-)

Jeff Butler


On 2/25/06, Ted Schrader <tschrader@gmail.com > 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 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* < 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
> > >
> > >
> > >
> >
>

Mime
View raw message