HealthCheck Configuration Assistant for Decision Runtime for z/OS 

Overview 

Anyone who has worked with Decision Runtime for z/OS (DR4z) knows that a successful installation is only the first milestone. A typical Operational Decision Manager (ODM) runtime within a DR4z environment includes multiple target and working datasets, USS directories, runtime components, and platform dependencies such as DB2.

Although the installation steps are clearly documented, the product consists of many interconnected components. Over time, it is possible to cause the configuration of these components to fall out of sync, making it difficult to maintain a consistent state. Identifying which parts of the installation are no longer aligned can therefore be a time‑consuming and challenging task.

The HealthCheck Configuration Assistant was introduced idenitify when this situation occurs. It gives DR4z administrators a self‑service, automated way to confirm that their environment is complete, consistent, and ready before moving on to rule deployment and runtime operations. By enabling early detection of configuration issues, teams can correct problems proactively, preventing them from impacting runtime behaviour.

Why a HealthCheck Tool Is Needed 

After completing an installation or upgrade, teams typically need quick answers to key questions:

• Are all required datasets and members present?
• Are configuration parameters consistent across libraries?
• Is the runtime aligned with platform requirements for this release?
• Are there latent configuration issues that could surface later?

Traditionally, answering these questions requires manual inspection of multiple datasets, members, and USS paths. This process can take several hours and is prone to human error, particularly under tight deployment schedules. In contrast, running the HealthCheck Configuration Assistant produces a consolidated validation report within minutes, allowing teams to quickly identify and assess any installation mismatches.

Common issues missed during manual validation

Manual checks frequently overlook:

• Version mismatches between DR4z , DB2, and the JVM.
• Missing or partially populated dataset members.
• Configuration drift between target libraries and working datasets.
• JVM heap settings insufficient for production workloads.
• Incomplete USS directory structures with hundreds of required files.

The HealthCheck Configuration Assistant closes this gap by providing a single, repeatable validation step that can be run immediately after installation.

How the HealthCheck Configuration Assistant Works 

The HealthCheck executes a set of automated, read‑only validations across the DR4z installation and produces a consolidated view of environment health.

It focuses on:

• Installation readiness.
• Dataset and configuration consistency.
• Platform compatibility.
• Overall runtime health.

Running the HealthCheck Configuration Assistant 

The HealthCheck is executed using a standard z/OS batch job. The HBRCHECK JCL is shipped with Decision Runtime for z/OS (DR4z) 9.5.0.1 and is available in the target library SHBRJCL

It leverages the existing DR4z Java execution framework and reads configuration from working datasets and release‑specific properties included with the installation.

Prerequisites

Before running the HealthCheck, ensure that the following prerequisites are met:

• DR4z initial configuration of an environment is complete.
• Working datasets are allocated and populated.
• HBRCHECK.properties is configured.
• Java environment is configured (JAVA_HOME set).
• User running the HealthCheck Configuration Assistant has READ access to required datasets.
• The user has write permission to the USS temporary directory used by HealthCheck for log generation.

Getting Started

Step 1: Locate the HealthCheck JCL

The HBRCHECK JCL is shipped in the following locations:

• {HBRHLQ}.*.*.SHBRJCL(HBRCHECK) – Installation library
• {HBRWORKDS}.*.*.SHBRJCL(HBRCHECK) – Working ZRES dataset

Step 2: Customize for your environment

Update the following parameters to match your setup:

• PARMDATASET=YOUR.WORKDATASET.SHBRPARM
• PARAMETERS="YOURSSID SDSFJOBNAME=SDSFOUT"

Step 3: Submit and monitor

Submit HBRCHECK and review the summary results in SYSOUT.

Step 4: Review detailed logs

Check the USS logs for diagnostic details:

• INSTALLATION_CHECK.log
• {SSID}MSTR_HBRPreCheck.log
• DATASET_MEMBERS_DETAILS.txt
• {SSID}MSTR_final.txt (ZRES SDSF job output)

Step 5: Correct issues and rerun

Address any reported issues and rerun the HealthCheck to confirm resolution.

What the HealthCheck Validates 

Output and Reporting 

The HealthCheck produces:

• A high‑level summary in job SYSOUT for quick status checks.
• Detailed diagnostic logs in USS for deeper analysis and troubleshooting.

This dual‑level reporting enables both rapid validation and detailed problem resolution when issues are detected.

Sample HBRCHECK.jcl

//HBRCHECK EXEC PGM=IKJEFT01,REGION=0M,TIME=NOLIMIT

//SYSPRINT DD SYSOUT=*

//STDOUT   DD SYSOUT=*

//STDERR   DD SYSOUT=*

//SYSTSIN  DD *

  BPXBATCH SH +

   cd ${HBR_WORKPATH}; +

   ${HBR_INSTPATH}/executionserver/bin/hbrjava.sh +

   PARMDATASET=${HBR_WORKDS}.SHBRPARM +

   PARMMEMBERS=HBRMSTR HBRCMMN +

   JAVACLASS=com.ibm.rules.hbr.healthcheck.HealthCheck +

   PARAMETERS="${HBR_SSID} SDSFJOBNAME=SDSFOUT"

/*

Note: Replace each placeholder accordingly

${HBR_WORKPATH} → USS working directory

${HBR_INSTPATH} → DR4z installation path

${HBR_WORKDS} → Working dataset HLQ

${HBR_SSID} → Target subsystem ID

Sample High-level summary job output 

=== Validating TLIB datasets ===

TLIB validation PASSED

=== Validating Working Datasets ===

zresType ZRES Working Datasets: OK

zresType ADSZRES Working Datasets: OK

zresType DMOEZRES Working Datasets: OK

zresType WLP Working Datasets: OK

zresType CICS Working Datasets: OK

zresType BATCH Working Datasets: OK

=== Validating USS Paths ===

Validated USS WORKPATH (OK)

ZExecutionServer/lib JARs check OK

ZExecutionServer/bin Scripts check OK

ExecutionServer/lib JARs check OK

ExecutionServer/bin XMLs check OK

ExecutionServer/applicationservers WAR files check OK

Validated USS INSTPATH (OK)

All resources validated successfully.

=== Validating required members for xx.xx.xx.xx.TLIB.SHBRAUTH ===

xx.xx.xx.xx.TLIB.SHBRAUTH validation OK

=== Validating required members for xx.xx.xx.xx.TLIB.SHBRLOAD ===

xx.xx.xx.xx.TLIB.SHBRLOAD validation OK

=== Validating dataset members and HBRINST variables ===

Dataset Member Validation Summary

Total Members Read     : xx

Total Members Compared : xx

Total Key Matches      : xx

Total Key Missing      : xx

Total Key Mismatches   : xx

Dataset member validation PASSED (all required members match)

=== STC JOB SUBMISSION ===

Submitting JCL using BPXWDYN:

submit /tmp/HealthCheck_xx/SDSF.jcl

JOB JOBxxxxx submitted from path

'/tmp/HealthCheck_xx/SDSF.jcl'

JCL submitted successfully.

=== Case1: Check STC output version with ra.xml ===

INSTALLATION CHECK-STC

Version        = 9.x.x.x

HBRHLQ         = xx.xx.xx.TLIB

HBRINSTPATH    = /xx/xx/xx/V9RxMx

ra.xml Version = 9.x.x.x

Result                     = OK

Case1: STC vs ra.xml => OK

DB2 JDBC URL:

jdbc:db2://xx:xxxxx/DSNxx:currentSchema=xx;

=== DB2 VERSION CHECK ===

DB2 Product Name    : DB2

DB2 Product Version : DSNxxxxx

Normalized Version  : 13.1

DB2 version is compatible

=== CHECKING KEY ZRES TABLES ===

RULEAPPS             (rows: 1)

RULESETS             (rows: 1)

RULEAPP_PROPERTIES   (rows: 2)

RULESET_PROPERTIES   (rows: 6)

RULESET_RESOURCES    (rows: 1)

=== JVM VERSION CHECK ===

JVM compatibility key : DRZ.9.x.x.JAVA

System Java           : IBM Semeru 21.x

Compatibility Result  : OK

=== JVM Properties Check ===

Detected Architecture : 64-bit

Configured Min Heap   : 2048 MB

Initial Heap (Xms)    : xx MB

Max Heap (Xmx)        : xxxx MB

Currently Used Heap  : xx MB

PASS: JVM max heap meets or exceeds required minimum.

=== Consolidated Summary ===

Installation Check : OK

DB2 Check          : OK

JVM Check          : OK

Process exited with return code 0

Detailed diagnostic logs screenshots:

Sample Use Cases

Business Value

The HealthCheck Configuration Assistant replaces hours of manual verification with fast, automated checks, delivering measurable benefits:

• Reduced deployment risk.
• Improved system reliability.
• Faster time to readiness.
• Consistent validation across environments.

Operational Benefits

• Confidence – Deploy with certainty.
• Consistency – Same checks in all environments.
• Compliance – Documented validation evidence.
• Knowledge transfer – New team members can validate independently.
• Proactive prevention – Catch issues before they affect users.

Best Practices to run the HealthCheck

Always run after:

• New installation.
• Version upgrade.
• Configuration changes.
• Platform updates (DB2, JVM).
• DR environment sync.

Summary 

The HealthCheck Configuration Assistant for Decision Runtime for z/OS provides a simple, reliable, and repeatable way to confirm that a DR4z environment is complete, consistent, and ready for use.

By automating validation and surfacing actionable diagnostics early, the HealthCheck enables teams to move forward with confidence, reduce operational risk, and maintain stable, predictable runtime behaviour.