Objectstar

Objectstar is the rules language and application environment that Amdahl Corporation launched in 1991 as Huron, renamed ObjectStar in the mid-1990s, and that TIBCO has sold since 2005 as TIBCO Object Service Broker. Its programs are called rules, and each rule is written as a small decision table. Conditions sit in one section, actions in another, and a grid of Y and N marks connects them. The language has no IF ... THEN ... ELSE. Huron was an unusual product: a whole development environment, with its own language, database and workbench, sold by a company best known for building IBM-compatible mainframes. Computer Business Review summed up the message Amdahl wanted developers to take away as “Huron rules; Cobol is dead.”

History and Origins

An Amdahl software project

Amdahl built its business in the 1970s selling plug-compatible alternatives to IBM mainframes. Huron was its attempt to do the same for application software. When Amdahl announced the product in March 1991, it presented Huron as its answer to IBM’s AD/Cycle and claimed it “will have the same effect on the world of software applications as the original 470 IBMulator” had on mainframes.

The system’s architect was Helge Knudsen, the named inventor on Amdahl’s Huron patents, which have a priority date of September 1989. Accounts of how long the product took to build differ. Amdahl told Computer Business Review in 1991 that it had been under development for ten years, while a later Information Age retrospective says it was conceived by a Canadian developer in mid-1985 and took six years to reach market.

The first release ran on IBM-compatible mainframes under MVS. It came with 17 beta sites, mostly in the US and Canada, including the UK Inland Revenue, and it was expensive: single-licence fees ran from $525,000 to $1.4 million depending on system size. By September 1992 Amdahl reported 22 signed customers and 17 more trials, and had shipped versions for its own UTS Unix and for Intel 80486 workstations running SCO Open Desktop.

Antares and the ObjectStar name

In the mid-1990s Huron was developed and marketed by the Antares Alliance Group, a joint venture owned 80% by Amdahl and 20% by Electronic Data Systems (EDS). In July 1995 Antares announced Huron ObjectStar 3.0, which split the system into three tiers: a mainframe data object broker, a server execution environment, and a desktop presentation layer on Windows 3.1, Windows 3.11 and Windows 95. Its marketing vice-president said the “Huron” name would be dropped after the next release because of its mainframe-only connotations. By the time of Amdahl’s 1997 annual report, the product was listed simply as ObjectStar.

Fujitsu, independence and TIBCO

Fujitsu completed its takeover of Amdahl in 1997. According to Information Age, the Antares alliance “fizzled out”, investment stalled, and in April 2003 ObjectStar split from Fujitsu as an independent company, ObjectStar International, with venture capital backing. Amdahl’s Huron patents were reassigned to ObjectStar International in the same period.

On 7 March 2005 TIBCO Software bought substantially all of ObjectStar’s assets for a total of about $21.4 million, according to TIBCO’s SEC filings. TIBCO said the acquisition gave it native integration with CA-IDMS, ADABAS and Model 204 databases, for competing with IBM in mainframe integration. TIBCO renamed the product TIBCO Object Service Broker (OSB).

Design Philosophy

“Not object-oriented”

Despite the later name, Huron was not an object-oriented language. Amdahl said so in 1991, contrasting it with Sapiens’ rule-based, object-oriented mainframe system. The “object” in ObjectStar refers to the MetaStor, a repository in which tables, screens, reports and rules are all stored as objects. Rules are kept in the MetaStor as compiled byte code. TIBCO’s documentation calls it “an active repository”.

A deliberately small language

The language was meant to be small. CBR counted 18 statements in the 1991 Huron Rules Language. Antares described “a set of 17 verbs” in 1995, and TIBCO’s OSB 5.2 documentation says the rules language “contains only 17 verbs and 8 data types”. Most of the system’s power comes from the table abstraction underneath the language rather than from the language itself.

Everything is a table

Huron’s patents describe a table access method that handles all data access. A rule reads and writes tables. Whether a table is stored in Huron’s own data store, in IMS or DB2, on a 3270 screen, or in an import/export file is decided by the table definition, not by the rule. TIBCO describes the result this way: “Data repositories can change without requiring changes to rules code.” According to contemporary press reports, the 1991 release could already reach DB2, IDMS, IMS, VSAM and Model 204, and it used two-phase commit for all transactions.

Key Features

The four-part rule

According to the Huron patents, a rule has four parts, printed with horizontal lines between them:

1. Definition: the rule header (name and parameters) and any local variables
2. Conditions: logical expressions that decide what runs
3. Actions: statements, each numbered under the condition outcomes that trigger it
4. Exception handlers: optional ON blocks

The patent’s simplest example is a function that returns Y or N. The layout below is reconstructed from the patent’s Table 1. The rule tests only divisibility by 4, because it is a teaching example, not a full Gregorian calendar check.

1
2
3
4
5
6
7

LEAPYEAR(YEAR);
------------------------------------------
REMAINDER(YEAR, 4) = 0;          | Y  N
------------------------------------------
RETURN('Y');                     | 1
RETURN('N');                     |    1
------------------------------------------

Each column on the right is one combination of condition outcomes. The numbers under a column give the order in which actions run for that combination. The patent describes a rule as “in effect, an extended case statement.”

Table access and exceptions

The patent’s second example uses several conditions, table lookups and an exception handler. A failed GET raises the GETFAIL exception, which the ON GETFAIL handler catches:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

VALID_DATE(YY, MM, DD);
----------------------------------------------------------
DD <= 0;                                       | Y  N  N
LEAPYEAR(YY);                                  |    Y  N
----------------------------------------------------------
CALL MSGLOG('INVALID DAY ENTERED');            | 1
GET MONTHS WHERE MONTH = MM & LDAYS >= DD;     |    1
GET MONTHS WHERE MONTH = MM & DAYS >= DD;      |       1
RETURN('N');                                   | 2
RETURN('Y');                                   |    2  2
----------------------------------------------------------
ON GETFAIL:
  CALL MSGLOG('INVALID MONTH/DAY COMBINATION');
  RETURN('N');

MONTHS is a table with separate day counts for leap and non-leap years. LEAPYEAR(YY) is called implicitly, simply by using it in an expression.

Statement summary

The statements described in the patent include:

The language also supports assignment by name, which copies every field of one table into the identically named fields of another. It is typically used to move a screen’s fields into a data table. Parameters are passed by value, either positionally or through a WHERE clause naming the parameters.

Runtime architecture

The patents describe Huron as a virtual machine running on MVS, made up of a transaction processor (a virtual stack machine that executes rule byte code), the table access machine, and a table data store server. The kernel was reportedly written in C. Because rules compile to the same byte code everywhere, Antares could promise in 1995 that “any object developed in any Huron system will execute on any other Huron system.” In TIBCO’s terms, this became the split between the Data Object Broker, which manages data and the MetaStor, and the Execution Environment, which runs rules for users.

Evolution

The emphasis of the product shifted over time. Amdahl sold Huron as a complete replacement for COBOL application development. Antares sold ObjectStar as a client/server tool for putting graphical front ends on legacy systems without rewriting them. ObjectStar International and TIBCO sold it mostly as a mainframe integration broker.

Current Relevance

Objectstar is in its final years of support. TIBCO’s support notice for Object Service Broker 6.x (for z/OS and Open Systems) has been extended six times since 2017. The latest revision, dated January 2026, extends support to 31 December 2028 and calls it “the FINAL extension”. No version later than 6.0.0 appears in TIBCO’s support documents.

The organisations still running Objectstar applications are likely to be mostly large mainframe sites that built core systems in Huron or ObjectStar during the 1990s. For them, the end of support is a migration deadline.

Why It Matters

Objectstar is one of the more ambitious products of the 4GL era. Many of its contemporaries added a reporting language on top of an existing database. Huron instead built a single environment in which data, screens and logic were all tables in one repository, and every data store looked the same to the programmer. Its decision-table rule format made the branching logic of business rules explicit and visual on the page.

It is also an example of how a technically ambitious product can be undermined by its business circumstances. A hardware company launched it at mainframe-licence prices just as client/server computing took off, and it then passed through a joint venture, a parent-company takeover and a buyout. Even so, the language has stayed in commercial use for about 35 years, and the original programs still run under TIBCO’s name.