Hi Jose Manuel,

To add to the other responses, IBM has worked very hard to make DB2/400
equivalent to or better than DB2 on other boxes, and it is as or more
compliant with the SQL standard in comparison to other RDBMSes. For most
purposes, you can treat it exactly that way, always watching out for
historical (or current) programmer non-SQL savvy code and constructions.

If you are fortunate enough to be creating or importing new databases on
the AS/400, create an SQL collection and use that as the table container
rather than normal libraries. It will save some manual handling of
journaling and auto-creates expected metadata structures.

I assume you don't have anyone there who could answer "Does the AS/400
have a relational database?" I'd suggest either hiring someone or using a
trusted outside resource. You don't have to have a DBA on the AS/400, but
one of my biases is that programmers should know data, and you'll definitely
have fewer headaches and better performance with someone who understands
SQL, relational databases and AS/400 idiosyncrasies.

As a side note to everyone, Stanford University is offering a free
online Introduction to Databases course this fall. See:

In relation to JDO v. JPA:

I have a bias here as well and it will show in a moment. But, objective
data (I'm always happy to be corrected) is that the vendors were enthused
about JDO (because it made their life easier,) but it never really made a
big splash among developers. You should consider that JDO developers will
be more difficult to find in an area where many developers don't have a good
understanding of relational databases anyway. Before people start yelling
at me, dig into relational theory a little first. When was the last time
you discussed tuples with the staff?

My bias is that SQL is a standard and works inside and outside of Java.
So I've never understood the point of learning a new mini-language for
queries. While you don't *have* to use JPQL in JPA, it's usually the path
of least resistance (like you can write OO code in any language, but is the
discipline there to do it without built in support?) The good news is that
JPA is a standard, so it's not going away, but I often see mailing list
questions (I'm on a lot of mostly JUG mailing lists) that imply JPA may be a
70% or 80% solution; that is, it's great until something different pops up.
My free advice (worth every penny) is to have someone on staff (or, again, a
trusted outside resource ) knowledgeable in SQL and JDBC as a fallback.

From all of that, you can probably tell that my bias would be towards
something like iBatis, which is now MyBatis at:


which helps but doesn't get in the way.

Just another suggestion,

Joe Sam

Joe Sam Shirah - www.conceptgo.com
conceptGO - Consulting/Development/Outsourcing
(904) 302-6870
Java Filter Forum: www.ibm.com/developerworks/java/
Just the JDBC FAQs: www.jguru.com/faq/JDBC
Going International? www.jguru.com/faq/I18N
Que Java400? www.jguru.com/faq/Java400

-----Original Message----- From: MANUEL FIDALGO SICILIA
Sent: Friday, August 19, 2011 5:34 AM
To: java400-l@xxxxxxxxxxxx
Subject: JDO vs JPA

Dear all,

Foremost, I would like to say that I'm new to the AS/400 world so sorry
if I ask stupid things...

At work we are using v6r1m0 and we would to write some Java programs
using the AS/400 as database.

The problem comes when deciding what persistence engine to use: I can't
see clearly if the AS/400 is relational or non-relational and I would
like to know which should be better JPA or JDO. I know some people use
JPA but I'm wondering if it is not better to use JDO which has support
for both relational and non-relational and if JPA will have performance
problems because it is made for relational.

So what do you think? JDO or JPA? Or maybe just jdbc!

Thanks in advance!

Jose Manuel

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.