UC4

UC4 script is the proprietary procedural scripting language embedded in the UC4 Automation Engine (now marketed by Broadcom as Automic Automation). Rather than a general-purpose programming language, it is a domain-specific language for enterprise workload automation: it configures, parameterizes, and controls batch jobs, workflows, file transfers, and event processing across heterogeneous IT landscapes. Scripts written in UC4 script live inside the “objects” that the Automation Engine executes, generating the concrete commands (JCL, shell, or platform-native instructions) that ultimately run on target agents.

Because it is tied to a commercial product line rather than an open standard, UC4 script is largely unknown outside the operations and scheduling teams that rely on it. Within those teams, however, it has been a workhorse for decades, gluing together the batch processing of banks, telecoms, manufacturers, and universities.

History & Origins

From SBB Software to UC4

The lineage of UC4 script begins not with a language but with a company. SBB Software was founded in Austria in 1985 by Franz Beranek. In 1996 the company introduced one of the early heterogeneous job schedulers — a scheduler designed to coordinate work across different operating systems rather than a single platform. That scheduler and the object model around it are the direct ancestors of what became the UC4 Automation Engine.

In March 2004, SBB Software renamed itself UC4 Software, and the “UC4” brand — along with its Automation Engine and the scripting language used to configure it — became established in the enterprise scheduling market. It is from this period that the language is most accurately dated: while the underlying scheduler predates the UC4 name, the scripting language as it is recognized today took its identity alongside the UC4-branded Automation Engine in the early-to-mid 2000s.

Growth, Acquisitions, and Rebranding

Through the late 2000s and 2010s the product and its language grew substantially, both organically and through acquisition:

• 2007 — UC4 merged with AppWorx, whose Java-based Applications Manager scheduler was integrated alongside the C-based Operations Manager engine.
• 2009 — Version 8.0 of the Automation Engine introduced “rapid automation” technology.
• 2011 — UC4 launched the ONE Automation platform and Automation Engine version 9, extending the product beyond classic job scheduling into application release automation and managed file transfer.
• 2013 — UC4 Software rebranded as Automic Software on July 1, and the scripting language began to be documented under the Automic name (the “AE Script” or “Automation Engine script”).

Into the Broadcom Era

In December 2016, CA Technologies announced it would acquire Automic for approximately 636 million USD; the deal closed on January 19, 2017. When Broadcom acquired CA Technologies in 2018, the Automation Engine and its scripting language moved into Broadcom’s software portfolio, where the product is now sold as Automic Automation. The most recent series, Automic Automation 24.4, was released in May 2025 as the final minor release of the V24 line and notably added an ASK_AI script function for invoking large language models directly from a script.

Design Philosophy

UC4 script is designed around a single purpose: describing and controlling automated work. Several principles follow from that focus.

Scripts Embedded in Objects

UC4 script is not written in standalone source files compiled to a binary. Instead, snippets of script are attached to Automation Engine objects — jobs, workflows, schedules, events, and so on. Each object has script tabs (such as Pre-Process, Process, and Post-Process) whose code runs at specific points in the object’s life cycle on the central engine, shaping the JCL or commands that are then dispatched to agents.

Statements Generate Commands

A defining idea is the split between script lines (which the Automation Engine interprets) and data lines / JCL (which are passed through to the target system). Lines beginning with a colon are script; lines without a colon or comment marker are treated as Job Control Language to be executed on the agent. This lets a single object mix control logic and the payload it produces.

Cross-Platform by Intent

Because the engine’s whole reason for existing was heterogeneous scheduling, the language is deliberately platform-neutral. The same script constructs coordinate work whether the eventual command runs on z/OS, Unix, Linux, Windows, SAP, or a database agent — the platform-specific detail lives in the generated data lines and the agent, not in the control flow.

Key Features

Script Statements and Functions

The language distinguishes two kinds of colon-prefixed elements:

• Script statements are commands that do not return a value, such as :SET, :PRINT, :IF, and :INCLUDE. A statement must begin a line, and each is limited to 1024 characters.
• Script functions manipulate data and return a value; they cannot start a line and must appear on the right-hand side of a statement. Examples include ADD(), SYS_DATE(), and GET_VAR().

1
2
3

:PRINT "Automation Engine"
:SET &SUM# = ADD(2,2)
:PRINT &SUM#

Script Variables

Variables are marked with a leading ampersand (&). A trailing hash (#) is the recommended delimiter so that, for example, &VALUE# and &VALUES# never collide during substitution. Variables can be created implicitly by assignment, or declared explicitly with :DEFINE and an optional data type:

1
2
3
4
5
6

:DEFINE &FILE#, string
:SET &FILE# = "temp.txt"

:SET &ACTIVITY#      = "End"
:SET &ACTIVITY_DATE# = SYS_DATE()
:PRINT "&ACTIVITY# at &ACTIVITY_DATE#"

Explicit types include string, signed, unsigned, and float; numeric :PRINT output is padded (for example ADD(2,2) prints as 0000000000000004 unless formatted).

Arrays

Arrays hold multiple indexed values and are declared with a size via :DEFINE:

1
2

:DEFINE &ARR#, unsigned, 10
:SET &ARR#[5] = 20

Arrays support a large number of elements; uninitialized string fields display as "" and numeric fields as 0.

Control Flow and Includes

The language provides conditional and iterative constructs (:IF / :ELSE / :ENDIF, and process loops such as :PROCESS … :ENDPROCESS), along with :INCLUDE for reusing shared script fragments stored in INCLUDE objects. Reading tabular data — for example the rows returned by an SQL agent — is handled with prepared-form blocks like :BEGINREAD … :ENDREAD.

Comments and Line Continuation

A line beginning with an exclamation mark (!) is a comment and is ignored during processing. Very long statements are continued by ending a line with an underscore (_) and beginning the next line with a colon:

1
2
3

! this is a comment
:SET &LONG# = "first part of a long value that_
:continues on the following line"

Evolution

The scripting language has evolved in step with the Automation Engine’s version history rather than as an independent artifact:

• Version 8 (2009) brought “rapid automation” and expanded agent types, giving scripts more kinds of targets to drive.
• Version 9 / ONE Automation (2011) extended the engine into release automation and managed file transfer, adding script objects and functions for those domains.
• Versions 10–12 (roughly 2014–2019) under the Automic name refined the object model, promptset variables, and REST/web-service integration, broadening what a script could orchestrate.
• Automic Automation 21 and the V24 series (through 2025) modernized the platform (moving to Java 17 as of 24.4, per Broadcom’s release notes) and, in 24.4, introduced the ASK_AI function so scripts can query large language models such as those served by OpenAI, Gemini, or Ollama.

Throughout, backward compatibility of existing script objects has been a strong concern, since customers accumulate large libraries of automation logic that must survive engine upgrades.

Current Relevance

UC4 script remains actively used and supported. As part of Broadcom’s Automic Automation, it underpins production batch and workflow automation in many large enterprises, and Broadcom continues to ship new releases — the V24.4 line is maintained under a support commitment extending to 2029. Official documentation for the scripting language is published on Broadcom’s Automic documentation site, and a practitioner community exists around the product for sharing script objects and best practices.

At the same time, the language sits squarely in the world of commercial, closed-source enterprise tooling. There is no free Docker image or open-source interpreter for UC4 script; it runs only inside a licensed Automation Engine. Third-party vendors even market conversion tools to migrate UC4/Automic scripts to competing schedulers, a sign both of how much automation logic organizations have written in the language and of the lock-in that its proprietary nature creates.

Why It Matters

UC4 script is a good example of a category of languages that are enormously consequential in practice yet almost invisible in mainstream programming discourse: the embedded automation DSL.

1. It runs the batch backbone. For decades, the overnight and inter-system batch processing of banks, insurers, telecoms, manufacturers, and universities has been coordinated by schedulers like UC4 — and the logic that coordinates it is written in this language.
2. It bridges heterogeneous systems. By separating control script from generated data lines, UC4 script let a single tool orchestrate mainframe, Unix, Windows, database, and SAP work long before “cross-platform orchestration” became a marketing phrase.
3. It illustrates the economics of proprietary languages. UC4 script has no standard, no open implementation, and no life outside its engine, yet it has survived four decades of corporate ownership changes — from SBB Software to UC4 to Automic to CA to Broadcom — precisely because the automation written in it is too valuable and too entrenched to abandon.

For anyone studying how software actually gets operated at scale, UC4 script is a reminder that a great deal of the world’s most critical automation is expressed in languages that never appear on a popularity index.