Schedule icon
SubmitJob icon
Return icon
Switch icon
Log icon
SlackIncomingWebhook icon

Cobol AS/400 Job Submission Compliance Gate

Gate IBM i COBOL batch job submissions on returned message severity and alert Slack on critical messages or connection failure.

Categories
DataInfrastructure

SBMJOB returning without an exception does not mean the submission was clean; IBM i can still hand back high-severity system messages that a script checking only the exit code would never see. This blueprint submits a batch job on a schedule, inspects every returned message for severity at or above a threshold, and pages Slack the moment one crosses it or the system cannot be reached at all.

How it works

  1. submit_batch_job (io.kestra.plugin.cobol.SubmitJob) submits as400_program from as400_library to as400_job_queue via SBMJOB and captures the IBM i system messages returned during submission. allowFailure: true means a connection or authentication failure still lets the flow continue instead of aborting.
  2. classify_submission_health (io.kestra.plugin.core.debug.Return) checks whether outputs.submit_batch_job.messages is defined; if not, UNREACHABLE. Otherwise it runs a jq filter counting messages whose severity is at or above message_severity_threshold, returning CRITICAL when that count is above zero, HEALTHY otherwise.
  3. route_by_submission_health (io.kestra.plugin.core.flow.Switch) branches on that string: HEALTHY logs a quiet confirmation, CRITICAL pages Slack with the job identity, UNREACHABLE pages Slack separately, and defaults logs the raw outcome.
  4. log_audit_status records a status line on every run regardless of branch, so the execution history is a continuous submission-health trend.
  5. The errors block pages Slack separately if the flow itself fails outright.
  6. The as400_compliance_gate_schedule trigger polls every 6 hours with explicit input overrides, shipped disabled: true until you point it at a real IBM i system.

What you get

  • A scheduled, message-level health check for IBM i batch submissions with zero custom JTOpen code.
  • A three-way status output (HEALTHY / CRITICAL / UNREACHABLE) you can chart or gate other flows on.
  • A Slack page naming the exact job identity and library/program behind a high-severity message.
  • A separate failure channel for the gate flow itself, plus a standing audit log line per run.

Who it's for

  • Operations teams running legacy COBOL batch workloads on IBM i (AS/400) who want an orchestrator-side check beyond a bare exit code.
  • Platform teams bridging mainframe-adjacent batch scheduling into a modern orchestrator's execution history and alerting.

Why orchestrate this with Kestra

A cron-triggered SBMJOB from a shell script tells you nothing once the command returns. This flow keeps every submission and every returned message in the execution history, turns the severity check into a typed output other flows can depend on, and gives you a Switch branch to grow into real remediation (resubmitting, paging the on-call operator, opening a ticket) without rewriting the check itself.

Prerequisites

  • Network access to a real IBM i (AS/400) system with a valid user profile; this plugin connects via IBM's JTOpen library over the standard AS/400 host server ports. There is no open-source Docker image that emulates IBM i, so this blueprint cannot be tested against a free local container the way most other blueprints can; test it against a real or licensed virtual IBM i instance.
  • The target library, program, and job queue must already exist on that system.
  • A Slack incoming webhook for the critical and unreachable alerts.

Secrets

  • IBM_I_HOST: hostname or IP address of the IBM i system.
  • IBM_I_USER: IBM i user profile to authenticate with.
  • IBM_I_PASSWORD: password for that user profile.
  • SLACK_WEBHOOK_URL: Slack incoming webhook used for the critical alert, the unreachable alert, and the flow-failure alert.
  • OSS note: if your Kestra instance reads secrets from environment variables instead of a secrets backend, set SECRET_IBM_I_HOST, SECRET_IBM_I_USER, SECRET_IBM_I_PASSWORD, and SECRET_SLACK_WEBHOOK_URL as base64, for example echo -n "<your-host>" | base64.

Quick start

  1. Add the IBM_I_HOST, IBM_I_USER, IBM_I_PASSWORD, and SLACK_WEBHOOK_URL secrets.
  2. Set as400_library, as400_program, and as400_job_queue to a real, low-risk program you can submit repeatedly.
  3. Run the flow once and confirm status reads HEALTHY.
  4. Enable as400_compliance_gate_schedule.

How to extend

  • Parse specific IBM i message IDs (for example known escape message prefixes) instead of a blanket severity threshold, for a more precise classification.
  • Add a follow-up task that queries job status after submission, instead of only inspecting the messages returned at submission time.
  • Store the job identity (jobName/jobNumber/jobUser) in a KV store to cross-reference against a later completion check.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.