PowerOn

PowerOn is a proprietary, procedural domain-specific language at the heart of Symitar’s Episys core banking platform — the software that runs day-to-day operations for hundreds of credit unions. It exists for a single purpose: to let credit unions and integrators build custom reports, batch jobs, file-maintenance routines, and applications on top of a core system whose underlying code they are not allowed to touch. A PowerOn program is the sanctioned way to make Episys do something the shipped product doesn’t do out of the box.

Originally called the “Report Generator,” PowerOn gave the language its enduring nickname: custom programs are still referred to as “RepGens” by the developers who write them. What began as a reporting tool grew into a general scripting language for the platform, complete with explicit type declarations, control flow, procedures, and direct access to the core’s account, share, loan, and member records.

History and Origins

PowerOn’s story is inseparable from Symitar Systems, founded in San Diego, California, in 1984 to build core processing software for credit unions. (Most sources give 1984; a few date the founding to 1985.) As Symitar’s core platform — eventually branded Episys — matured, the company needed a way for client credit unions to customize behavior and produce their own reports without modifying, and risking the integrity of, the protected core code.

The answer was the Report Generator, a scripting facility that let institutions describe the data they wanted and the logic to process it. Over time the tool became known as PowerOn, and the programs written in it kept the affectionate label “RepGens.” The exact year PowerOn first appeared is not publicly documented — it is best described as emerging around 1990, well before Symitar changed hands.

That change came in 2000, when Jack Henry & Associates (NASDAQ: JKHY) acquired Symitar in a cash deal worth roughly $44 million, bringing about 237 credit-union clients and the Episys/PowerOn technology — at the time running on IBM RS/6000 hardware — under Jack Henry’s roof. PowerOn has remained a Jack Henry product ever since. In the August 2022 corporate rebrand, Jack Henry folded the Symitar, Jack Henry Banking, and ProfitStars brands into a single identity and renamed the credit-union core “Jack Henry Symitar,” keeping the Symitar name alive.

A note on dates. Because PowerOn is proprietary, several details that are easy to verify for open languages — an exact first-release year, internal version numbers, and the original designers’ names — are not part of the public record. The dates above reflect what is independently documented; where the record is thin, this page says so rather than guessing.

Design Philosophy

PowerOn is built around one organizing idea: iterate over the records of a core banking database and do something with each one. A program declares a target record type — an account, share, loan, name, card, or general-ledger account — and the runtime walks those records, applying the program’s logic and emitting output. This makes PowerOn feel less like a general-purpose language and more like a report-and-batch engine with a programming layer wrapped around it.

Source files are called specfiles, and a program is organized into divisions that run in a fixed conceptual order. Real-world code shows a structure along the lines of:

• TARGET — declares the record class the program iterates over (e.g. ACCOUNT, SHARE, LOAN).
• DEFINE — declares variables, each with an explicit type, before they can be used.
• SETUP — initialization that runs before record processing begins.
• SELECT — filtering logic that decides which records to include.
• PRINT — output produced per record (and via SORT / TOTAL, aggregated output).
• PROCEDURE — reusable subroutines invoked with CALL.

To developers who have seen COBOL or other business languages of its era, this division-oriented layout looks familiar. That resemblance is superficial, however — no public source documents a specific linguistic ancestor for PowerOn, so this page does not claim one.

Key Features

• Explicit static typing. Every variable is declared in a DEFINE block with a specific type. The type system is domain-aware: alongside CHARACTER, NUMBER, FLOAT, DATE, and CODE, PowerOn provides dedicated MONEY and RATE types that reflect its banking purpose, plus an ARRAY modifier.
• Domain-specific literals. Constants are written in forms that match their type — for example, a money literal like $0.00 and a date literal using a --/--/-- style placeholder.
• Colon field access. Fields on a record are read with colon notation, such as ACCOUNT:NUMBER or NAME:SSN, tying the language directly to the core data model.
• Procedural control flow. IF … THEN … ELSE, WHILE, and several FOR forms (FOR EACH, FOR … TO, FOR … WITH) drive logic, with DO … END delimiting blocks. Word operators AND, OR, and NOT are used, and <> means “not equal.”
• Procedures and includes. Reusable logic lives in PROCEDURE name … END blocks invoked via CALL, and code can be shared across files with #INCLUDE.
• Bracketed comments. Comments are enclosed in square brackets — [ like this ].

A minimal PowerOn program — the platform’s equivalent of “Hello, World!” — shows the flavor:

TARGET = ACCOUNT
PRINT TITLE = "HELLO.WORLD"
 PRINT "Hello, world!"
 NEWLINE
END

Even this tiny example declares a TARGET record class, names the output, and ends with END — the same skeleton that scales up to complex reports and batch jobs.

How PowerOn Runs

PowerOn is not a language you compile and run on your own machine. It executes only on the Symitar / Episys host, against a live or test core database. Two interfaces let outside systems trigger PowerOn programs:

• SymConnect, the older TCP-socket interface, where a specfile can use the SYMCONNECT keyword.
• SymXchange, Jack Henry’s SOAP/XML web-services API (general availability announced August 27, 2015). Its PowerOnService / executePowerOn operation runs a specfile and returns the program’s output as a structured set of RGLines.

This arrangement makes PowerOn the platform’s extensibility “escape hatch”: when an integration needs a capability the standard APIs don’t expose directly, the answer is almost always to write a PowerOn specfile and invoke it through SymXchange or SymConnect.

Because the runtime is proprietary, there is no public Docker image, compiler, or interpreter for PowerOn. What does exist publicly is editor tooling: an open-source IDE called RepDev that connects to a real Symitar host, commercial and community VS Code extensions and language servers, and syntax highlighters for several editors. These improve the authoring experience but still rely on a Symitar host to actually execute code.

Current Relevance

PowerOn is very much a living, in-use language — not a historical curiosity. Jack Henry continues to sell and develop the Symitar core platform as its flagship credit-union offering, and new credit-union deals continue to be announced. As long as institutions run Episys, they need PowerOn to customize it, and the job market reflects this: roles for “Symitar PowerOn developers” appear regularly, typically asking for several years of PowerOn experience alongside familiarity with Episys modules and batch-scheduling tools.

Its reach, though, is bounded by its domain. PowerOn lives entirely inside the credit-union core-banking world; you will not encounter it in web development, data science, or general software engineering. That niche is precisely what keeps it valuable — it is a specialized tool that does one important job for a specific, well-defined industry.

Why It Matters

PowerOn is a clear example of a pattern that recurs across enterprise software: a vendor-specific domain language that becomes mission-critical infrastructure for an entire industry. For credit unions on Episys, PowerOn is the difference between a rigid packaged system and one they can shape to their own products, members, and regulators. The accumulated body of “RepGens” at a given institution can represent decades of encoded business rules and compliance logic.

It also illustrates how proprietary languages persist quietly for decades, sustained not by open-source communities or language fashion but by the platforms they serve and the specialists who master them. PowerOn has no public spec, no package registry, and no Docker image — yet it runs unglamorous, essential work at financial institutions every day, a reminder that much of the world’s important code is written in languages most programmers will never see.