Japanese Mainframe PoC Offer — Fujitsu GS21 / NEC ACOS / Hitachi OpenTP1
The territory the Western trade press hasn’t yet covered.
Maintenance end-of-life for Japanese-vendor mainframes is concentrating in 2025-2030. If those workloads aren’t handled in time, foreign system integrators will pick up the entire estate. JAVATEL has calibrated the SlimeCOBOL / SlimeNENC family against three Japanese vendors — Fujitsu GS21, NEC ACOS, Hitachi OpenTP1 — and is open to PoC engagements where you bring real source code.
IBM zOS / Burroughs (Unisys) lineage is 99.9995% bit-exact, validated against the NIST CCVS85 501-program suite. The same S1-S9 pipeline applies to all three Japanese vendors; dialect fingerprints are in place, and we are at the step of moving from identification to full conversion via PoC.
Three-vendor coverage status (2026-05-10)
1. Hitachi OpenTP1 / VOS3 Conversion PoC available immediately
Status: CBLEELOG / CBLEETRN / CBLEEMEM recognition + calibrated against 8 OpenTP1 manual UAPs. Within 2-4 weeks of source receipt we deliver a dialect-identification report, a transpiled Java / Rust sample, and a bit-exact verification log.
Why this lands: Bit-exact migration of regional-bank OpenTP1 transactions into Java / Rust, with the CBLEE* APIs reproduced through semantics-preserving wrappers. JEF kanji handling for VOS3 environments runs in parallel.
2. Fujitsu GS21 (NetCOBOL / NetCOBOL Enterprise) PoC engagements open
Status: JEF kanji + Symfoware integration + CBL-EXEC extension fingerprints in place. Identification is complete; PoC moves us into full conversion.
Why this lands: Municipal resident-record / tax / regional-bank-core GS21 assets — we deliver complete GS21 exit with bit-exact correctness and a hash-chain audit. Bring us one source file (50-200 LOC, sensitive data may be masked).
3. NEC ACOS (ACOS-4 / ACOS-2) + ADBS / RIQS II PoC engagements open
Status: NCRP transaction + RIQS II junction file + ADBS fingerprints in place. Identification is complete; PoC moves us into full conversion.
Why this lands: Defense, coast guard, public-sector workloads where Japanese-vendor lock-in is a hard requirement. NCRP-to-Java is, to our knowledge, a world first. ADBS → PostgreSQL is bit-exact, with RIQS II junction files reconstructed via child-table expansion.
What the PoC delivers
| Item | Details |
|---|---|
| 1. Dialect identification report | Your source is run through SlimeCOBOL S1 (FST tokenizer) + S2 (slot IR), producing a classification across 14 dialects (IBM, Burroughs, Unisys, Hitachi, Fujitsu, NEC, etc.) with a confidence score. |
| 2. Transpilation sample (Java / Rust) | 50-200 LOC of your code is transpiled to Java / Rust. The output compiles cleanly with javac / rustc, and runtime output is bit-exact against the original. |
| 3. Round-trip verification | The transpiled code is shown to round-trip back token-exact to the original COBOL — auditors can re-verify "no information was lost in the conversion". |
| 4. Hash-chain audit log | Stage S7 emits a SHA-256 chain over each transpilation step — tamper-evident, suitable for the 30-year retention requirements of pension / health-insurance / defense workloads. |
| 5. Full-engagement quote | From your asset size (KLOC + dialect mix) we propose effort, timeline, and a license model. |
Engagement terms
- Source code is received only after an NDA is in place. We have a confidentiality agreement with our patent attorney’s office; sensitive data may be masked before delivery.
- Recommended sample size: 50-200 LOC (one core processing unit). For larger assets, please extract the key routines.
- Dialect identification only can be done on as little as 1-3 LOC (useful as a first read on the fingerprint match).
- Transpiled output and verification logs are for your internal use only. JAVATEL never trains on, publishes, or redistributes customer source code.
Timeline / pricing
| Stage | Duration | Price |
|---|---|---|
| Dialect identification report only | 3-5 business days | First report free of charge (NDA required) |
| Transpilation sample (50-200 LOC) + bit-exact verification + round-trip proof | 2-4 weeks | Quoted individually. If the engagement progresses to a full contract, the PoC fee is credited against it. |
| Full engagement (entire asset transpilation) | Scales with asset size | Computed from KLOC, dialect mix, and number of target languages. Priced to fully replace per-CPU licensing for Software AG / GS21 / ACOS. |
Software AG Natural / ADABAS PoC available on the same terms
On 2026-05-10 we published SlimeNatural (bit-exact migration of Natural language + ADABAS data to Java + PostgreSQL) as the 8th SlimeNENC product. Banks, insurers, pensions, governments, and defense organizations seeking a clean exit from Software AG’s per-CPU multi-million-USD licensing are welcome on the same engagement terms as this PoC offer — bring 50-200 LOC of Natural source plus one related DDM, and we deliver an identification report in 3-5 business days and a bit-exact transpilation sample (Java + PostgreSQL DDL) in 2-4 weeks. We differentiate from CONNX / ADABAS-to-RDB (data-side only) by handling both the language and the data losslessly in one engagement.
Built on SlimeCOBOL / SlimeNENC family
This PoC offering is built on the SlimeCOBOL base (99.9995% bit-exact, validated against NIST CCVS85 501); stages S2-S5 and S7-S9 are shared with Natural / ADABAS, PL/I, RPG, JCL, MUMPS, and FORTRAN. Details:
- SlimeCOBOL — COBOL → Java / Rust bit-exact transpiler
- SlimeNatural — Software AG Natural / ADABAS → Java + PostgreSQL bit-exact transpiler (★new)
- SlimePL/I — PL/I → Java bit-exact transpiler
- SlimeRPG — RPG → Java bit-exact transpiler
- SlimeFORTRAN — FORTRAN → 9-language Multi-target transpiler
- SlimeJCL — JCL → POSIX shell transpiler
- SlimeMUMPS — Caché ObjectScript → Java
Contact
To request a PoC, submit real source code, or ask for a free dialect-identification report, please use the contact form. Mention "Japanese mainframe PoC" in the subject and we will respond within 3 business days.