Docker based deployment of Raincode Batch Container
Version 6.0.136.0
Raincode Crossbow
Raincode Crossbow is a consistent release of the entire Raincode product line, covering compilers, emulators and ancillary tools.
In practice, Raincode Crossbow is designed with three driving forces:
-
A focus on performance across the board:
-
The internal computation engine for non-binary numeric data types (display numeric or packed decimals) has been entirely overhauled, resulting in performance improvements that can go up to a factor of 5 (depending on the level of dependence on these non-binary data types)
-
The file I/O layer has been optimized to ensure the best possible performance when dealing with indexed or sequential files
-
RadaR is a revolutionary solution to run batch steps 5 to 10 times faster, without changing the application source code or even the JCL they are called from
-
The Visual Studio plugin now runs the heaviest debugging operations asynchronously, thereby dramatically improving response time and the overall user experience, even when debugging programs with hundreds of active variables
-
The views generated to access VSAMSql and IMSql data using plain SQL DML statements have been optimized dramatically
-
-
Updated .NET platform support running both on Linux and on Windows, on virtual machines or in containers, on the cloud, on laptops or servers managed on premise.
-
Consolidation of the product suite, allowing all Raincode software to be built and upgraded synchronously, thereby avoiding the headaches that come from multiple products that follow different (and sometimes, incompatible) release cycles.
Version 6.0
In addition to the above description, Raincode Crossbow v6.0 (see release notes) is a technical release that includes the following:
-
Support for .NET 10.0 and SQL Server 2025 across the board.
-
The Visual Studio plugin now supports Visual Studio 2022 and 2026, with improved support for JCL debugging.
-
Support for the File-AID JCL utility.
-
Support for TLS encryption on QIX and IMS TN3270 terminal servers.
-
Removal of support for .NET Framework and .NET 6.0.
-
Removal of support for Microsoft Host Integration Server (HIS) for Db2.
-
Removal of 32-bit support.
1. Raincode Batch Container Deployment
1.1. Introduction
This document describes a Docker Compose-based deployment of containers mimicking a Mainframe Batch Environment. It details the services involved, their configuration, networking, and end-to-end job execution steps. It shows a possible pattern for the cloud-based deployment of Raincode JCL and demonstrates how batch jobs are submitted, executed, and monitored, either from the command-line or the web-based Raincode Console.
1.2. Objectives
The objectives of the demo detailed below are:
-
Executing jobs using Raincode JCL REST API
-
Viewing the jobs, their statuses and their outputs in the Raincode Console
-
Using standard Raincode Console UI capabilities of sorting, filtering and paging through the jobs and their outputs
-
Viewing the job logs, as stored on a shared file system.
1.3. Technical details
The demo setup consists of multiple Docker containers working together to process batch jobs.
The block diagram below shows its major components and their interactions.
1.3.1. Job Flow
This section details the steps that are being executed, according to the block diagram above.
Batch jobs can be submitted to the system through two mechanism:
-
Automated, through an External Scheduler
| The External Scheduler can be AutomateNow, Control-M or Tivoli, or any other scheduler that supports REST APIs to submit batch executions. |
-
Manual, through the Dispatcher’s Web Interface.
| For the limited context of this demo, the Swagger REST API is used. Any compatible REST API can be used instead, as the system is flexible and is not limited to a specific API implementation. |
After that, the job has been submitted, an entire machinery starts to ensure it is executed.
-
All batch requests (whether automated or manual) are ultimately sent to the Dispatcher REST API. In turn, the Dispatcher performs a number of actions:
-
Validation and registration of the batch request
-
Storage of execution metadata and status in the Redis database
-
-
At the same time, one or more Batch Runner instances wait for incoming jobs to execute.
-
They continously scan the Redis database
-
They pick up new jobs as they appear, execute them, or cancel running jobs if that’s what the REST API specifies.
-
| In this demo, Azure Storage for the catalog is used. It could be any type of shared storage, such as a NAS, a SAN, or any other mass storage system. |
-
The Raincode Console provides a Web-based interface that can be used to:
-
Read job information from the Redis database
-
View the status of jobs, their logs, and the content of the catalog.
-
1.3.2. Generated Artefacts
The demo generates several artefacts:
-
Several compiled COBOL programs
-
Docker images for:
-
The Batch Dispatcher
-
One or more Batch Runners to actually take incoming job requests, and execute them
-
The Raincode Console (UI for monitoring and control of jobs)
-
A file browser (to inspect batch input and output files)
-
A Redis database instance is embedded in the dispatcher. However, one can redirect the requests to another existing instance if deemed preferable.
-
You can generate these Docker images using the compose.yml file located in the dotnet/runtime/BatchContainers directory.
This Docker Compose file sets up a full Raincode batch processing environment with several containers working together.
The batchdispatcher service acts as the central coordinator, exposing a REST API and hosting a local Redis instance to store the job state. Batch jobs submitted via the Raincode Console are registered in Redis and picked up by the testrunner service, which continuously checks the Redis database, executes the jobs, and reads inputs, writes outputs and logs to a shared filesystem mounted at /mnt.
The raincodeconsole provides a web-based UI for monitoring and managing batch executions, while the filebrowser service exposes the shared filesystem over HTTP, allowing users to inspect the SYSOUT files produced by the JCL executions. All these services run on the same Docker bridge network, allowing them to communicate using service names. They also share a common volume to ensure consistent access to batch data.
You can run multiple instances (replicas) of the batch runner service by updating the compose.yml file accordingly. Just update the replicas value from 1 to the desired number of instances.
The following section provides a detailed, step-by-step guide for obtaining and configuring each component.
1.4. Prerequisites
-
Docker Desktop
-
Working COBOL compiler on the path
The COBOL compiler used to compile programs must be the same as, or newer than, the version used in the Batch Runner Docker image.
1.5. Steps
In a developer command prompt, perform the following steps:
-
Build and prepare COBOL programs needed for the demo:
-
Change directory to dotnet\runtime\BatchContainers\scripts\COBOL
-
Run the build command.
-
This will compile the COBOL programs and generate all the necessary DLLs and copy them to the directory dotnet\runtime\BatchContainers\scripts\runner_local_data\DLLs.
-
Build all necessary Docker images:
-
Change directory to dotnet\runtime\BatchContainers
-
Run the build command.
-
-
Start the necessary containers (shown in the figure Block Diagram) and run the demo:
-
Change directory to dotnet\runtime\BatchContainers
-
Run docker compose up.
-
| Make sure Docker is running in the background so that all Docker-related files and services function properly. |
2. Batch Container
After running docker compose up, the containers named batchcontainers appear in Docker Desktop as shown below.
When you click batchcontainers, Docker Desktop expands the stack and shows the individual services that are started by the compose file.
These typically include:
-
filebrowser: Provides access to the file system inside the container. Lets you view JCL files, source programs, job outputs, logs and configuration files.
-
batchdispatcher: Responsible for scheduling and dispatching batch jobs.
Additional details have been provided in the section Batch Dispatcher API.
-
raincodeconsole: Web-based interface for interacting with the Raincode runtime.
-
testrunner: The environment where JCL jobs are executed. When you connect to the testrunner via the Raincode Console, the JCL execution screen opens. This simulates a mainframe-style batch processing environment.
Each of these runs as a separate container but works together as part of the batch execution environment.
3. Batch Dispatcher API and Raincode Console
Open the Batch Dispatcher Swagger interface. Locate the POST/JobDispatch endpoint and click on it to expand the details. Then select Try it out to enable the request parameter input field.
In the jclname field, enter Hello and click Execute.
The Execute action sends a request to the Batch Dispatcher service to run the corresponding hello.jcl job. The system will submit the JCL file for execution and will process the job through the batch environment and generate the required output.
All generated files will be created in the mounted directory defined in the compose.yml file. (Because this directory is mounted as a Docker volume), the output files will be accessible inside the Docker container and on your local machine.
Once the execution is complete, open raincodeconsole from Docker Desktop to verify the generated files. In the container view, click on 8051:80 (raincodeconsole) to launch the Raincode Console in your web browser.
After the console opens:
-
Connect to testrunner (Batch)
-
Click on the Jobs
You will be redirected to a page displaying the details of all executed JCL jobs.
On this page, you can see the status and summary for each job. If you click a Job Name, you will open a file browser view with detailed info about that JCL, similar to how mainframe job outputs and datasets are shown.
