Programming on IBM i: sources, ILE, RPG and SQL

· 2 min read · Software

Reviewed on Verified on IBM i 7.5

Log in to save

Programming on IBM i is a trade with rules of its own, and nearly all of them have a reason that is written down nowhere: you learn by watching somebody work, and when that somebody retires the reason leaves with them.

This guide writes down what is usually handed on by word of mouth. Where the code lives, how it becomes a program, what separates a module from a service program, why the same file can be read in two completely different ways, and how to work out where something broke when the close is stuck at seven in the morning.

Who it is for

Anyone arriving from other languages. RPG is not the problem: the syntax takes a week. The problem is everything around it — source held inside a file, compilation producing an object, activation groups, the difference between reading a file record by record and querying it in SQL. People arriving from Java or Python know how to write code and do not know where to put it.

Anyone who has worked here for years. Much of this guide is familiar ground to long-time programmers on the platform, but not all of it: the chapters on ILE, embedded SQL and modernisation touch things many shops never adopted — not because they were weighed and rejected, but because they were never discussed.

What it is not

It is not an RPG course. There are no exercises, and syntax appears only where it explains a concept. Anyone after the language statement by statement will find IBM's documentation, which is complete and well made on this — it is just in English, and it assumes the context this guide tries to give.

Nor is it a manifesto about modernisation. Code that has run in production for twenty years is not technical debt by virtue of being old: it is capital that has stopped costing money. The modernisation chapter is about changing the parts worth changing, not about rewriting everything.

How it is organised

It starts with where the code lives and how it becomes a runnable object, because that is the step that confuses outsiders most. Then the two languages you actually meet, RPG and CL. Then data, which on this platform can be described in two ways and read in two ways. Then the part used most and taught least: working out where something broke. And finally how to change software without stopping it, and what tools the work is done with today.

Read the chapters in order the first time. After that they stand on their own.

Note

this guide assumes you know what a library is and how the library list works. If those are new terms, the systems guide covers that ground, and the two paths cross often: many problems that look like programming problems are environment problems.

Chapters in this guide

  1. Where the code lives Source lives inside a file, compiling produces an object, and there is no project directory. The first obstacle for anyone arriving from outside.
  2. ILE: modules, programs and service programs What genuinely changes between CRTBNDRPG and the module-plus-program pair, what a service program is for, and why activation groups cause damage when nobody chose them.
  3. RPG: from columns to free-form Why old code is written in columns, what genuinely changed with free-form, and how to live with two forms of the same language in one application.
  4. CL: the language that holds the rest together Not a second-class language: it launches the batch work, handles the errors and talks to the system. And it is the one nobody was ever properly taught.
  5. DDS and SQL: two ways of describing data The same file is both a physical file and a table. When to stay with DDS, when to move to SQL, and what it costs not to decide.
  6. SQL inside programs How to write SQL inside RPG, why SQLCODE zero does not mean everything went well, and where injection hides on this platform too.
  7. When it breaks: errors and debugging How to read an RPG error, how to get into the debugger on a job that is not yours, and how to stop a program dying silently at three in the morning.
  8. Modernising without rewriting Old code is not technical debt by virtue of being old. What is worth changing, in what order, and how an existing program is exposed to the rest of the world.
  9. The tools the work is done with today SEU does not understand fully free-form RPG, and that alone says where the trade has got to. What is actually used to write code on this platform.
#programmazione #rpg #ile #sql
← Back to blog

You might also like

Comments

No comments yet. Be the first to comment!

You need an account to comment. Log in · Sign up