What the terms mean, how the pieces fit together, and where a generated RPG or COBOL program comes from
CA 2E (Synon) has its own vocabulary, and most explanations of it either assume you already know it or bury it inside instructions for a specific task. This post is the orientation I'd want before starting any task: what a model is, what's inside it, and how the pieces relate to the RPG or COBOL that eventually comes out.
It's a companion to my CA 2E compile reference. That post deals with what happens once you're compiling generated source. This one stays a level above that, at the design layer.
None of the library, model, function or field names here are real. The concepts make sense without real names, and the real ones aren't mine to publish.
A model is a database of your application, not a folder of programs
If you're coming from hand-written RPG or COBOL, this is the biggest adjustment: a CA 2E model isn't source code. It's structured data that describes an application, including which files exist, which fields they have, which functions work on them and what each function is supposed to do. It's stored in the product's own repository, not as members in a source file. You don't browse it the way you'd browse QRPGLESRC. You browse it through menus that query the repository, such as display this function, display this file, or show everything that uses this field.
Source code comes after the model. A generator reads the model and writes RPG or COBOL into a source member. If you edit that generated member directly, you've edited the output, not the thing that produces it, and the next time someone generates that function your edit is overwritten without any warning.
That one fact explains most of the friction people run into when they approach CA 2E with a "how do I fix this program" mindset.
The three menus, and why they're split
The main menu is divided by audience before anything else: a Designer menu, a Programmer menu and a User menu. The split reflects three different jobs that, on a hand-written system, tend to blur into "whoever's editing the source."
Designer work happens in the model: defining files, fields and functions, and writing the logic inside a function (the action diagram, covered below). This is where the business rule is actually written, and it doesn't depend on the target language. Nothing at this level is RPG or COBOL yet.
Programmer work is generating and compiling: turning what the designer defined into source and building it. Compile troubleshooting happens at this level.
User work is running the finished application. It doesn't matter much for conversion work, but it's worth knowing about, because it's the menu path an end user sees, and it's usually where a support ticket starts before it gets traced back to the model.
If someone hands you a "broken COBOL program," the fix could be at any of these three levels, and each needs different tools. Working out which level you're at before you start saves a lot of time.
A function is the unit of logic, and there are several types
A function is the model's version of a callable piece of behavior. Roughly, though not exactly, one function becomes one generated program. What makes a CA 2E function different from an ordinary RPG procedure is that it has a type, and the type decides which generator template produces its source.
The common types you'll see:
- Functions that create, change or delete a database row. These are driven almost entirely by the model's definition of the file and need very little custom logic, because this kind of behavior is what the generator does by default.
- Functions that run custom logic against existing objects. This is where a person actually writes an action diagram, because the behavior isn't standard create/change/delete.
- Functions that call an external program or another generated function. These are wrappers that connect generated pieces together, or connect to something outside the model.
- Functions that produce a display or report instead of changing the database.
The type tells you where the interesting logic is. A create/change/delete function is rarely worth reading closely, because it does what every other function of that type does. A custom-logic function is where the actual business rule lives. It's also the one most worth reading in the model rather than in the generated source, because the model version is shorter and states the intent directly instead of through RPG operation codes.
The action diagram is where the rule actually lives
Inside a custom-logic function is an action diagram: an indented, structured statement of the logic, with conditions, loops, database reads and writes, and calls to other functions. It's written in the model's own notation rather than in any target language. It gets generated as RPG or COBOL depending on the function's target language, but the action diagram itself stays the same whichever target you pick.
This changes what "the rule" means. Take an order-picking function. Which lines are eligible, what order they're taken in, and what gets written when a line is picked are all stated in the action diagram. The generated RPG or COBOL is one rendering of that, in one language, with that language's habits added on top. If you want to know what a generated program is supposed to do, rather than working it out from operation codes, the action diagram is the more direct source, and it's usually shorter.
The action diagram also quietly stops being the source of truth as soon as someone edits the generated member instead. The generator doesn't know that happened. The next generation reverts the change without warning, because as far as the model is concerned, nothing changed. If you're converting programs and fixing them as you go, Fix It in the Model or Fix It in the Source? covers how to decide which copy is the master.
Access paths are how a function reaches data
A function's action diagram reads and writes data through access paths. An access path is the model's way of choosing which file, and which key order, a piece of logic uses. A file can have several access paths, much like a physical file with several logical files over it, and each one can expose a different set of fields and a different key sequence.
This matters for one specific reason that comes up again and again: an access path doesn't have to include every field in the underlying file. A field can exist on the file without being part of the format a given access path exposes, and logic that reads through that access path can't see the field, whatever the rest of the model assumes about the file. That's a fact about the data layer, not a generator bug, and it's the same whether the function targets RPG or COBOL. The generator can only use what the access path actually carries.
Where generated source lands
Generating a function doesn't change the model's own libraries in any way you'd notice by browsing them. The generator writes into a separate library that exists to hold generated source, usually named as a variation of the model's name. That's where you look for the actual RPG or COBOL member after generation, whether or not the compile afterwards worked.
A function can have readable generated source sitting in that library while its compiled object doesn't exist yet, or doesn't work. Generating and compiling are separate steps with separate outcomes.
A compact glossary
- Model: the repository that describes an application: files, fields, functions and their logic. It isn't source code.
- Function: the model's unit of behavior. Its type decides what kind of source it generates.
- Action diagram: the statement of a function's logic in the model's own notation, independent of the target language.
- Access path: a specific way of reading a file (which fields, which key order) that a function's logic goes through. It doesn't necessarily expose every field in the file.
- Target high-level language: the language a function generates into. It's set per function, not for the whole model.
- Generate: produce source from the model. It doesn't compile anything.
- Create: compile generated source into an object. It can run together with generation or separately.
- Generation library: the separate library, paired with the model, that holds the source a generate step produces.
- Designer, Programmer and User menus: the three audiences the product's menus are divided between, roughly matching writing the logic, generating and building source, and running the result.
Jaya Krushna Mohapatra is a Warehouse Management Systems Architect focused on enterprise integrations, IBM i modernization, and scalable backend systems.
Top comments (0)