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 <[EMAIL PROTECTED]
> 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
> >
> >
> >
>
