Subscribe
THE DAILY DIGEST

The daily edition.

Essential reading from Rocket Enterprise. Straight to the source.

Archived edition
DAILY EDITION1 story· 2 min read

Exporting live CAS health metrics with OpenTelemetry

Enterprise Server’s COBOL Application Server (CAS) exposes OpenTelemetry metrics at three useful levels:

IN FOCUS

Exporting live CAS health metrics with OpenTelemetry

Enterprise Server’s COBOL Application Server (CAS) exposes OpenTelemetry metrics at three useful levels: [1]

Read the full briefing

Scope: Rocket Enterprise Developer 12.0 for Eclipse (UNIX), using the Linux documentation bundle. Although the bundle covers UNIX deployment, Rocket restricts OpenTelemetry support to Linux x86 and Windows x86. Metrics support begins with version 12.0. Using OpenTelemetry

Enterprise Server’s COBOL Application Server (CAS) exposes OpenTelemetry metrics at three useful levels:

  • Region: queued work requests, connected clients, requested server SEPs, available/used shared memory, shared-memory fragmentation, and uptime.
  • Online tasks: active, executed, failed, timed-out, total-duration, and total-latency counters.
  • Batch jobs: active, executed, failed, timed-out, total-duration, and submission-to-start latency.

These measurements separate current state from accumulated activity. For example, rocketsoftware.es.task.active is an UpDownCounter representing currently active online tasks, while rocketsoftware.es.task.count is a cumulative Counter that includes failed tasks. Likewise, rocketsoftware.es.batch.job.total_latency measures the aggregate time from job submission until job start—not job execution time. This makes it especially useful alongside active-job and job-count metrics when examining batch queueing behavior. COBOL Application Server (CAS) Component

Configuration is file-based. Set MFOTL_CONFIG to the file’s path—for example, export MFOTL_CONFIG=/apps/app_otl.cfg. The file must be UTF-8, is case-sensitive, and contains one name-value pair per line. It is read when the OpenTelemetry subsystem initializes. The important prerequisite is easy to miss: if MFOTL_CONFIG is unset, Enterprise Server generates no telemetry. Configuring OpenTelemetry

A documented minimal OTLP/HTTP metrics pipeline is:

mfotl.metric_exporter=metric_exporter1
mfotl.metric_exporter.metric_exporter1#type=otlp_http
mfotl.metric_exporter.metric_exporter1#url=http://localhost:4318/v1/metrics
mfotl.metric_reader=reader1
mfotl.metric_reader.reader1#exporter=metric_exporter1

The first two lines declare and configure an exporter; the final two declare a reader and attach it to that exporter. Equivalent examples send metrics to standard output or a file. Example OpenTelemetry configuration files

One operational nuance: a metric exporter is not activated merely because its property block exists—its name must appear in mfotl.metric_exporter. Similarly, a reader must be declared before its properties are applied, and its exporter property is mandatory. Reader exports default to every 60,000 ms with a 30,000 ms timeout.

Takeaway: CAS metrics become usable only when the complete chain is present: MFOTL_CONFIG → declared exporter → declared reader → reader-to-exporter association.

Enterprise Developer / Enterprise Server · 12.0 · Linux/UNIX
Documentation references
That’s the briefing.You’ve reached the end of this edition.
More editions

From the archive

View all
Oct 16

ESF auditing is a delivery pipeline, not just an ESCWA checkbox

Oct 15

Fileshare rollforward recovery trades write-time overhead for backup-based recovery

Oct 14

Dynamic CTF changes trace levels without making broad tracing permanent