# How to Add AI to an IBM i (AS/400) RPG Application Without Moving It > Source: https://netray.co/erp-help/private-ai-layer-ibm-i-rpg-on-prem-architecture > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer A custom RPG system does not need to be rewritten to get AI. Db2 for i already exposes your physical files as SQL tables, journals give you change capture, and stored procedures or Integrated Web Services can call your RPG logic. Read through a replica or read-only profile, describe the cryptic file and field names in a semantic layer, and serve an open-weight model on local GPUs. ## Kind advanced ## System on-prem-apps ## Erp IBM i (AS/400) custom RPG applications ## Module Db2 for i and RPG integration ## Query how to add AI to an IBM i AS/400 RPG application on-prem ## Alternate Queries - AS/400 AI integration without cloud - IBM i Db2 SQL access for LLM - modernize RPG application with private AI ## Applies To IBM i 7.3 and later (row and column access control from 7.2, SQL services in recent Technology Refreshes), RPG III, RPG IV and free-form RPG, DDS or SQL defined files. ## Steps ### Add a private AI layer to a custom IBM i system **Items:** - List the physical and logical files behind the screens and reports users ask about. Use the catalog (QSYS2.SYSTABLES, QSYS2.SYSCOLUMNS) and DSPFD or DSPFFD output to document them. - Create a dictionary of meaning: for each field add the business name, units, code values and date format, using LABEL ON, COMMENT ON, or a separate table. Many fields are CHAR or packed numeric dates such as YYYYMMDD. - Choose the access route: a read-only user profile over JDBC (JTOpen) or ODBC, or a replica fed by remote journaling or a replication product. - Expose reviewed SQL views and parameterized procedures; do not give the model open SQL on the production library. - Where business logic lives only in RPG (pricing, availability), call it through a stored procedure or an Integrated Web Services endpoint instead of re-implementing it. - Mirror security: use separate profiles per user group, and apply row and column access control for sensitive columns. - Run the model on a separate x86 GPU server, with the tool server in the same network zone as the IBM i partition, and log all calls. ## Sections ### Data access paths **Body:** Db2 for i exposes every physical file as an SQL table. The system name can be 10 characters (CUSTMAST, ORDHDR), while SQL names, if present, are longer. Field names are often 6 to 10 characters (CMCUST, OHDATE) and the meaning sits in documentation, field text or someone's head. The catalog in QSYS2 lets you list tables, columns and column text, and IBM i SQL services give you views on objects, jobs and journals. Access from outside is by JDBC (the open-source JTOpen driver), ODBC through IBM i Access, or Mapepire, an open-source SQL server for IBM i. For logic that lives in RPG, you can create SQL stored procedures with EXTERNAL NAME pointing at a program, or expose programs as REST services using Integrated Web Services. Native record-level access does not appear in SQL: if a program applies business rules while reading, SQL on the file will not reproduce them. **Code:** -- Document the schema from the catalog SELECT table_schema, table_name, column_name, ordinal_position, data_type, length, column_text FROM qsys2.syscolumns WHERE table_schema = 'PRODLIB' AND table_name IN ('ORDHDR','ORDDTL','CUSTMAST') ORDER BY table_name, ordinal_position; -- Add meaning that both people and the model can use LABEL ON COLUMN prodlib.ordhdr.ohdate IS 'Order date YYYYMMDD'; -- Read-only view that converts numeric dates CREATE VIEW ai_lib.open_orders AS SELECT ohord AS order_no, ohcust AS customer_no, DATE(TIMESTAMP_FORMAT(DIGITS(ohdate),'YYYYMMDD')) AS order_date, ohstat AS status FROM prodlib.ordhdr WHERE ohstat <> 'C'; ### Reference architecture **Body:** Reference architecture used on every page of this series: (1) a read-only replica or reporting copy of the data, (2) change capture so the index stays current, (3) a retrieval index with the source ACLs stored beside every chunk, (4) a tool server (MCP or plain HTTP) that exposes only approved read actions, (5) an open-weight model served with vLLM or Ollama on local GPUs, (6) an append-only audit log. On IBM i, journaling is the natural change source: Db2 for i journals physical file changes, and remote journaling or a replication tool can feed a replica or an index without touching the application. Because the model server is x86 with GPUs, it sits next to the Power system on the same network, not on it. The tool server connects with JDBC to a read-only profile, serves only named views and procedures, and converts EBCDIC, packed decimal and numeric date fields into clean JSON. A retrieval index covers spool files, PDFs, manuals and the field dictionary you created. The air-gapped variant is the same stack inside the closed network. ### Permissions and write-back **Body:** IBM i security is object-based: library and object authority, user and group profiles, adopted authority in programs, and often application-level menus that restrict users. Menus do not protect SQL. Give the assistant its own low-privilege profiles, one per role group, with authority only to AI-specific views. Row and column access control (RCAC) lets you add permissions and masks on the tables so that a user sees only their own branches or a masked salary column. Write-back goes through the existing application logic, not direct file updates. Call an RPG program through a stored procedure or a web service so validation, locks and audit fields behave as they do from a green screen, require a human approval in your workflow, and log the call. Direct SQL INSERT into an order file bypasses the program's checks and is the quickest way to corrupt data. ### Sizing, rollout and honest limits **Body:** A custom IBM i system for a mid-sized plant often serves 100 to 500 users, with databases from tens of GB to a few TB. Analytical questions run on a replica so they never compete with batch windows. Model load is small: one GPU serving a 7B to 14B model is a common starting point, scaled by concurrent users. Phase one: read-only questions through reviewed views. Phase two: explain and document, such as describing what an RPG program does or what a batch job produces. Phase three: approved actions via stored procedures. Limits: undocumented field names need human effort first, logic hidden in RPG cannot be inferred from tables, and if your only goal is code understanding, IBM's own tooling such as watsonx Code Assistant for i may be enough. ## Pitfalls - Letting the model guess field meanings from names like CMCUST. Build the dictionary first. - Running analytical SQL on the production partition during the batch window. - Assuming SQL equals the application. RPG programs apply rules that raw file reads do not. - Using one powerful profile for the assistant. Use per-role profiles plus RCAC. - Ignoring CCSID and packed or zoned numeric formats, which produce garbled text and wrong numbers. - Writing to files directly with SQL instead of calling the RPG program. ## Ai Angle DataRay and ERPray both rely on a semantic layer over the data, which is the heavy lifting on IBM i: turning short field names and numeric dates into things a user and a model can talk about. Netray builds that layer with your RPG developers, then serves the assistant on your own GPUs. IBM's own tools are worth testing first if your need is limited to code explanation. ## Faq ### Do we need to rewrite the RPG application first? **Answer:** No. Db2 for i exposes the files as SQL tables and journals give you change capture. The work is documenting fields, building reviewed views and calling RPG for logic, not rewriting the application. ### Can the model write SQL against our files? **Answer:** Only against reviewed views or a replica with a low-privilege profile. Cryptic names and numeric dates make free SQL error-prone, so give the model named views and procedures with descriptions. ### How do we call business logic that only exists in RPG? **Answer:** Wrap the program in an SQL stored procedure with EXTERNAL NAME or expose it with Integrated Web Services, then call that from the tool server. This keeps validation and audit behavior identical to the existing screens. ### Is IBM i row and column access control worth using? **Answer:** Yes for sensitive data. RCAC lets Db2 filter rows and mask columns by user or group at the database, so the assistant cannot bypass it through SQL even if a prompt tries. ### Can the model run on the Power system? **Answer:** Practically, run it on a separate x86 GPU server on the same network. The IBM i partition stays focused on the application, and the tool server connects with JDBC. ## Search terms as400 ai integration, ibm i rpg ai, db2 for i sql llm, ibm i jdbc private ai, rpg modernization ai, ibm i rcac security, as/400 chatbot on-prem, ibm i journal change data capture --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json