Connecting Java to IBM i: JDBC, JTOpen, and Flexible Exports with XML, XSLT, JSON, CSV & Markdown

A practical look at a small historical sample project: what zeus-access-400 still demonstrates well, what would be built differently today, and why Java integration on IBM i is more flexible than many people expect.

1. Summary

zeus-access-400 is a small Java CLI example that reads data from an IBM i database via JDBC and exports the results in several formats. The technical core is intentionally simple:

2. Context: A Historical Project with Ongoing Learning Value

zeus-access-400 is no longer an actively maintained production tool. The project remains interesting because it demonstrates a clear architectural idea that is still useful today: data is read from IBM i using Java and JDBC, converted into a neutral intermediate structure, and then flexibly transformed into different target formats.

Small projects have one major advantage: they reveal the idea without too much framework noise. In this case, the project demonstrates three practical points:

• Java can communicate cleanly with Db2 for i on IBM i via JDBC.
• SQL results can be normalized before being written to concrete output formats.
• XSLT can be a lightweight transformation layer when XML is already part of the pipeline.

3. The Core Idea: Query Once, Export Many Ways

Many data export tasks start with a simple request: “Can I get this as CSV?” Soon after that comes: “Can we also have it as JSON?” Then: “Please generate Markdown for the documentation.” And eventually: “A small HTML view would be useful too.”

The naive solution would be to write custom Java code for every single format. That works at first, but it quickly becomes hard to maintain. zeus-access-400 takes a different route:

This is not the perfect answer for every scenario, but as a pattern it is very useful:

• Data retrieval stays separate from presentation.
• New output formats can be added by introducing additional XSLT files.
• The XML intermediate format can be inspected, tested, versioned, and understood easily.
• The concept works locally, on servers, and in IBM i-related environments.

4. Architecture of the Sample Project

The project is small, which makes it easy to read. It does not follow a modern framework-heavy approach, but instead uses a classic Java CLI structure.

5. Data Flow: SQL → ResultSet → XML → Output Format

The actual data flow is simple, which makes it easy to explain.

application.properties
        │
        ▼
JDBC connection to Db2 for i
        │
        ▼
Execute SQL SELECT
        │
        ▼
JDBC ResultSet
        │
        ▼
XML intermediate format
        │
        ├── XSLT → HTML
        ├── XSLT → JSON
        ├── XSLT → JSONL
        ├── XSLT → CSV
        └── XSLT → Markdown

The interesting part is the XML intermediate format. It can contain not only values, but also metadata such as column names and JDBC types. That turns the result into more than just text output — it becomes a structured intermediate representation.

<export>
  <data>
    <property path="CUSTOMER_NO" type="CHAR">
      <value>0004711001</value>
    </property>
    <property path="ORDER_TOTAL" type="DECIMAL">
      <value>1234.56</value>
    </property>
  </data>
</export>

6. Supported Output Formats

The old project demonstrates several target formats. That is exactly what makes it interesting as an example.

7. Configuration and Startup

The historical project uses a simple properties file. For a sample project, that makes the setup easy to understand.

driver=com.ibm.as400.access.AS400JDBCDriver
databaseUrl=jdbc:as400://YOUR_SYSTEM;translate binary=true
username=YOUR_USER
password=YOUR_PASSWORD

xsltpath=./xslt
exportpath=./export

query=SELECT * FROM YOUR_LIB.YOUR_TABLE
exportFormats=html,json,jsonl,csv,md 

The project is built with Maven:

mvn clean package

Startup on Windows:

java -cp "zeus-access-400-1.0-SNAPSHOT.jar;jt400.jar" de.zeus.hermes.AppInitializer application.properties

Startup on Linux, Unix, or IBM i PASE:

java -cp "zeus-access-400-1.0-SNAPSHOT.jar:jt400.jar" de.zeus.hermes.AppInitializer application.properties

8. Why This Is Especially Interesting on IBM i

IBM i is much more than “an old system with a green-screen interface.” On many systems, highly valuable business data lives directly inside Db2 for i. At the same time, there is often a need to make that data available for modern use cases:

• technical documentation of existing tables and views,
• regular data exports for business departments,
• comparison data for modernization projects,
• JSON or CSV files for external systems,
• Markdown reports for Git repositories,
• HTML views for quick inspection and validation.

That said, an export is not the same thing as modernization. It can prepare, document, or support a modernization effort. The real architecture questions remain: Which data may be read? Who is allowed to see it? How are sensitive fields handled? How is the SQL query validated? And how do we make sure the output formats are technically and functionally correct?

9. Limitations of the Old Approach

The project is intentionally small and direct. That makes it pleasant as a learning example. For production-style use, however, several aspects would need to be handled more rigorously.

10. How This Would Be Built More Robustly Today

If this concept were built from scratch today, the direction would be clear: CLI-first, safe by default, traceable execution, deterministic exports, and as little hidden magic as possible.

• Dry-run enabled by default: Without an explicit --execute, no query is actually run.
• Read-only guard: Only read-only SQL statements are allowed.
• Protect secrets: No passwords in logs, manifests, or shell histories.
• Document configuration precedence: CLI overrides environment, environment overrides config, config overrides defaults.
• Make the query source traceable: Clearly identify whether the query came from CLI input, a query file, or a properties value.
• Write a run manifest: Record what was generated, when, and with which output formats.
• Produce deterministic output: Same input, same output — important for tests and diffs.
• Test IBM i-specific edge cases: CCSID, decimal values, date/time fields, leading zeros, and null values.

11. Successor: zeus-ibmi-extract-transform

The modern successor is called zeus-ibmi-extract-transform. It continues the original idea in a more robust direction: read-only SQL extraction from Db2 for i, CLI-first operation, multiple output formats, dry-run by default, and a more complete safety model.

The legacy project remains linked here because it shows the original idea clearly:
zeus-access-400 on GitHub.
For new development, the successor is the better starting point:
zeus-ibmi-extract-transform on GitHub.

12. Conclusion

The real value is not in reusing the old code unchanged. The interesting part is the pattern behind it: separate data retrieval from output generation. That allows one SQL query to become the basis for HTML, JSON, JSONL, CSV, or Markdown.

For today’s IBM i projects, security, configuration, secrets, read-only guards, logging, and large data volumes would need to be handled much more rigorously. The architectural idea, however, remains strong: extract cleanly first, then transform in a controlled way.

Sources