Baan 3GL

Baan 3GL is the lower-level of the two programming languages built into Baan Tools, the development environment that ships with the Baan ERP suite and its successor, Infor LN. It is a procedural, C-derived language: functions, block structure, familiar control flow, and a main entry point in program scripts. Its counterpart, Baan 4GL, is the language most Baan developers actually write, describing sessions and reports declaratively in terms of lifecycle events. 3GL sits underneath — the language for library code, for computation-heavy routines, and, notably, the language the 4GL toolchain generates into before anything is compiled.

That dual role is what makes 3GL interesting. It is simultaneously a language humans write and an intermediate representation the platform emits. Almost nobody encounters it as a general-purpose tool; you meet it because you are extending an ERP system that has been running someone’s factory for twenty-five years.

History and Origins

Jan Baan founded the company that bears his name in 1978 in Barneveld, in the Netherlands, initially offering financial and administrative consulting rather than software. According to accounts of the company’s early years, his first program was written in BASIC on a Durango F-85. Software gradually became the business, and with his brother Paul, Jan Baan built what was widely regarded as one of the leading enterprise resource planning vendors of the 1990s.

The language lineage begins in the 1980s, when Baan moved its applications onto Unix. The company wrote in C, and alongside it developed an in-house language commonly referred to as Baan-C, whose syntax was reportedly closer to BASIC than to C despite the name. Out of that pairing came the two languages that Baan Tools would eventually expose to customers and implementation partners: a C-flavoured procedural language, and a much higher-level event-driven language for building the screens and reports that make up an ERP application.

The metadata commonly attached to Baan 3GL gives 1978 as its year, and that date is best understood as marking the founding of the company and the beginning of its in-house language work rather than the release of a language called “3GL.” The name itself is a retronym of sorts — it exists to distinguish the C-like layer from the 4GL that runs on top of it, and that distinction only became meaningful once Baan Tools was a product customers programmed against, which happened with Triton in the late 1980s.

Triton’s commercial trajectory carried the language with it. Baan won Boeing in 1994 in a deal widely reported at the time as a serious challenge to SAP’s dominance, went public in 1995, and shipped Baan IV in the mid-1990s and BaanERP — usually called Baan V — in 1998. Around the same period, an accounting controversy over how license revenue had been recognized collapsed the stock. Invensys bought the company in 2000, sold it to SSA Global in 2003, and Infor acquired SSA Global in 2006. Through four owners and three product names, the Tools programming model survived essentially intact. Code written for Baan IV is recognizably the same language as code written for Infor LN today.

Design Philosophy

Baan Tools is built on a premise that was unusual in its era and looks prescient now: the ERP application should be written against an abstract machine, not against an operating system. Baan’s runtime, the bshell, is a process virtual machine. Application code compiled from 3GL and 4GL targets the bshell rather than any particular Unix or Windows. The practical consequence is that the same application objects run across the platforms Baan and Infor have supported without being rebuilt per platform, and that porting the suite to a new environment is largely a matter of porting the shell.

This shapes 3GL in a specific way. It looks like C, but it is not C. There is no direct filesystem-and-syscall surface in the way a systems programmer would expect; capabilities are provided through the Tools function libraries, which are the sanctioned interface to the database, the user interface, the message system, and the environment. 3GL is C-shaped access to a managed enterprise runtime, not C.

The second design commitment is the data dictionary. Baan applications do not hard-code the type and length of a database field in application source. They declare variables using domains — named types defined once in the dictionary and shared across every table and screen that uses them. When a field’s definition changes, code that declared against the domain follows automatically. For a system whose defining characteristic is that customers extend it and then live with those extensions for decades, this is arguably the single most important thing about the language.

Third: the language is deliberately not the primary way you write an application. 3GL exists so that 4GL can be high-level. The division of labour is explicit in Infor’s own development guidance, which describes 4GL as the standard language for sessions, data access layers, UI scripts, and reports, and positions 3GL for library DLLs, low-level access, and performance-critical computation. Most Baan developers, across the platform’s whole history, have worked almost entirely in 4GL.

Key Features

C-derived procedural structure. Functions, local and global scope, conditionals, loops, and a main function in a program script that holds the session’s functionality — the comparison Baan’s own documentation draws is directly to C. A 3GL session, unlike a 4GL one, has no standard script generated for it; the program script is the whole program.

Scalar type set. The Tools languages work with a small set of base types — notably long, double, and string — plus multi-dimensional arrays holding values of those types (the Tools documentation caps the number of dimensions at a small fixed limit). This is a deliberately narrow type vocabulary for a business application language, and it is narrow because domains carry the semantic weight.

Domain-based declaration. Rather than declaring a variable as a raw string of some length, application code declares it against a domain drawn from the data dictionary, inheriting both type and length. This is the mechanism that keeps thousands of customization scripts from breaking when a field is widened.

Embedded SQL. Database access is written directly into the language as select statements terminated by endselect, with the body of the loop — the selectdo section — containing ordinary procedural code. 3GL functions such as message() can be called from inside a select loop, so query and processing logic sit in a single block rather than being split across a cursor API.

The Tools function libraries. The bulk of what 3GL code actually does is call Baan/Infor Tools functions. The reference documentation groups these by context — bshell functions, 4GL library functions, 3GL library functions — and by subject, including events, dynamic SQL queries, and form and form-field operations. Knowing the language is a small part of knowing the platform; knowing the function libraries is most of it.

Position in the toolchain. The 4GL program generators translate labelled 4GL sections such as before.program into functions, producing 3GL source that is then compiled. Reading generated 3GL is a standard debugging technique for developers whose 4GL is behaving unexpectedly.

Evolution

Baan 3GL has evolved less than almost any language of comparable age, and for a defensible reason: its users do not want it to change. The value proposition of the Tools stack is that a customization written against Baan IV in the 1990s remains recognizable, and largely portable, decades later. Infor has extended the surrounding platform substantially — Infor LN Studio provides an Eclipse-based development environment, the data access layer model has gained capabilities like field dependencies that trigger recalculation automatically, and the deployment story now includes cloud-hosted LN — but the 3GL language itself is a stable, conservative core underneath all of that.

What has changed is 3GL’s share of the work. Successive releases have pushed more capability into 4GL and into the DAL, so the situations that genuinely require dropping to 3GL have narrowed. Infor’s current guidance is explicit that most developers work exclusively in 4GL and that this is sufficient for sessions, DALs, UI scripts, and reports. 3GL remains available and remains part of the shipping product; it is simply reached for less often than it once was.

Current Relevance

Baan 3GL is dormant rather than dead, and the distinction matters. There is no open-source implementation, no package ecosystem, no compiler you can install, and no meaningful body of code outside customer ERP installations. You cannot run it on a laptop without an Infor LN licence and environment. By every measure the language-popularity indices use, it registers as nothing at all.

At the same time, Infor LN is a live, supported, actively sold product, and 3GL ships inside it. Infor markets LN primarily to manufacturers in aerospace, automotive, industrial equipment, and high-tech electronics, and Baan-lineage systems reportedly remain in production across those sectors — some on current Infor LN releases, some still on Baan IV or Baan V installations that were commissioned in the 1990s and never migrated. Every one of those systems has customizations, and those customizations are written in Baan Tools. The consulting market for Baan and LN developers is small, specialized, and persistent, and the people in it are frequently maintaining code older than the junior members of their own teams.

The realistic outlook is that 3GL will continue exactly as it is: not growing, not disappearing, quietly compiling.

Why It Matters

Baan 3GL is a good case study in a pattern that recurs throughout enterprise software and is almost invisible from outside it — the proprietary language that exists only inside a product, has no community, no conference, and no GitHub presence, and yet runs a meaningful fraction of the world’s manufacturing.

Three things about it are genuinely worth taking seriously. The first is the bshell: Baan committed to a process virtual machine as the application’s target in the 1980s, well before the JVM made that idea mainstream, and got decades of platform portability out of the decision. The second is domain-based typing against a live data dictionary, which solves the schema-evolution problem for customization code more directly than most modern application frameworks do. The third is the two-language split. Baan did not try to make one language serve both the “describe a screen” and “compute something fast” jobs. It shipped a high-level language for the common case, kept a C-like language underneath for the uncommon one, and generated the former into the latter. That architecture — a productive DSL compiled down to a general-purpose language, both of them first-class and both of them shipped to customers — is a design that the industry has arrived at repeatedly since, usually without knowing that an ERP vendor in Barneveld got there first.