Telon: a code generator priced on capacity you may not be using.

Telon is a Broadcom (CA) application generator: a development tool that turns high level design specifications into COBOL, COBOL II, Enterprise COBOL, or PL/I source for batch, CICS, and IMS environments. It spans design entry, code generation, testing, and maintenance, and it built a large share of the line of business applications still running in older insurance, banking, and government estates. The product remains actively maintained, but it lives in a legacy development niche, and many of the applications it generated are now in maintenance mode rather than active generation, which is the crux of its licensing.

Telon is licensed on processor capacity, historically in MIPS and increasingly in MSU as Broadcom (CA) aligns the portfolio to the MSU metric. The charge tracks the capacity of the environment Telon is authorized to run on. On a Broadcom Mainframe Consumption Licensing (MCL) arrangement the model moves toward measured MSU consumption against a committed baseline, reconciled annually through True Forward. Because Telon is a development tool rather than a runtime, the central sizing question is where code is still actively generated, since the generated COBOL and PL/I runs as standard compiled programs that do not themselves require Telon to execute.

The first cost driver is the licensed capacity relative to where Telon is actually used to generate code, a gap that tends to be wide in legacy estates where the applications are stable and generation activity has dwindled. The second is the renewal uplift: Broadcom (CA) renewals commonly carry annual escalators, so even a quiet Telon footprint can see the bill climb unless the uplift is capped. The third is the bundle effect, where Telon rides a shared consumption commitment alongside more active products, lifting its share for reasons unrelated to development activity. The footprint question dominates the others.

Telon exposure turns on the difference between where it is licensed and where generation actually happens. Common traps we see at pattern level:

For a legacy generator, the footprint and the baseline carry the negotiation. The five levers that pay:

Telon sits in a category where the credible move is usually freezing or retiring the generation capability rather than swapping tools. Because the generated COBOL and PL/I runs as standard programs, an estate that has stopped active generation can in principle maintain the source directly and reduce or retire the Telon footprint, treating the generated code as ordinary application source going forward. That is a real, often underused lever. Wholesale replacement with another generator is rarely worthwhile for stable applications, and full modernization off the generated code is a multi year program, not a renewal tactic. The practical alternative is honest footprint reduction, not a like for like substitute.