Job Control Language (JCL) utilized on IBM 370 mainframes and Bicep for Microsoft Azure represent two distinct eras of infrastructure and resource management that are decades apart yet share foundational principles. Although they may appear to be entirely different, these technologies exhibit fundamental similarities in their methods for resource definition and management. This analysis examines their interconnections and traces the evolutionary journey from mainframe JCL to contemporary Infrastructure as Code (IaC).

Core Similarities

Declarative Nature

Both JCL and Bicep are declarative languages that allow users to specify “what” they wish to achieve rather than “how” to implement it. In JCL, users declare the programs to execute, the required datasets, and the necessary resources. In a similar manner, Bicep specifies the desired state of Azure resources, along with their configurations and interrelationships.

JCL Example (Declaring a Job Step):

//STEP1    EXEC PGM=SORT
//SORTIN   DD   DSN=INPUT.FILE,DISP=SHR
//SORTOUT  DD   DSN=OUTPUT.FILE,
//         DISP=(NEW,CATLG),
//         SPACE=(CYL,(10,5))

Equivalent Concept in Bicep:

resource storageAccount 'Microsoft.Storage/storageAccounts@2021-06-01' = {
  name: 'mystorageaccount'
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
}

Resource Definition

JCL’s DD (Data Definition) statements outline the resources required for a job, including:

• Storage allocations
• Input/output devices
• Dataset characteristics

Bicep performs a parallel function by defining:

• Azure resources (such as VMs, storage accounts, and networks)
• Resource configurations
• Dependencies and relationships

JCL Dependencies:

//STEP1    EXEC PGM=CREATE
//FILE1    DD   DSN=NEW.FILE,DISP=(NEW,PASS)
//STEP2    EXEC PGM=PROCESS
//INPUT    DD   DSN=*.STEP1.FILE1,DISP=SHR

Bicep Dependencies:

resource storageAccount 'Microsoft.Storage/storageAccounts@2021-06-01' = {
  name: 'mystorageaccount'
  // ... other properties

Parameter Usage

Both languages incorporate parameterization:

• JCL utilizes symbolic parameters and SET statements
• Bicep employs parameters and variables to facilitate dynamic value assignment

JCL Parameter Example:

//MYJOB    JOB (ACCT),'MY NAME'
//         SET INFILE=DATA.SET.NAME
//STEP1    EXEC PGM=MYPROGRAM
//INPUT    DD   DSN=&INFILE,DISP=SHR

Bicep Parameter Example:

param location string = 'eastus'
param storageAccountName string

var storageSku = 'Standard_LRS'

resource storageAccount 'Microsoft.Storage/storageAccounts@2021-06-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: storageSku
  }
}

Job/Deployment Flow Control

Both JCL and Bicep offer mechanisms to control execution:

• JCL includes COND parameters and IF/THEN/ELSE statements
• Bicep employs dependencies and conditional deployments

JCL Conditional Example:

//STEP1    EXEC PGM=PROG1
//IF (STEP1.RC = 0) THEN
//STEP2    EXEC PGM=PROG2
//ELSE
//STEP3    EXEC PGM=PROG3
//ENDIF

Bicep Conditional Example:

param deployHighAvailability bool = true

resource appServicePlan 'Microsoft.Web/serverfarms@2021-02-01' = {
  name: 'myAppServicePlan'
  location: location
  sku: {
    name: deployHighAvailability ? 'P1v2' : 'B1'
    tier: deployHighAvailability ? 'PremiumV2' : 'Basic'
  }
}

Modern Integration Example

The following example illustrates how a contemporary cloud deployment can be compared to a traditional mainframe batch job:

Traditional JCL Batch Job:

//BATJOB   JOB (ACCT),'BATCH PROCESS'
//STEP1    EXEC PGM=SORT
//SORTIN   DD   DSN=INPUT.FILE,DISP=SHR
//SORTOUT  DD   DSN=SORTED.FILE,
//         DISP=(NEW,CATLG),
//         SPACE=(CYL,(10,5))
//STEP2    EXEC PGM=PROCESS,
//         COND=(0,LT,STEP1)
//INPUT    DD   DSN=*.STEP1.SORTOUT,DISP=SHR
//OUTPUT   DD   SYSOUT=A

Equivalent Modern Bicep Deployment:

param location string = 'eastus'
param environmentName string

// Storage for input data
resource storage 'Microsoft.Storage/storageAccounts@2021-06-01' = {
  name: 'batchstorage${environmentName}'
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
}

// Batch account for processing
resource batchAccount 'Microsoft.Batch/batchAccounts@2021-06-01' = {
  name: 'batchaccount${environmentName}'
  location: location
  properties: {
    storageAccountId: storage.id
  }
}

// Function App for output processing
resource functionApp 'Microsoft.Web/sites@2021-02-01' = {
  name: 'processor${environmentName}'
  location: location
  kind: 'functionapp'
  properties: {
    siteConfig: {
      appSettings: [
        {
          name: 'BatchAccountName'
          value: batchAccount.name
        }
        {
          name: 'StorageConnection'
          value: storage.properties.primaryEndpoints.blob
        }
      ]
    }
  }
}

The Evolution Path

Mainframe Era (1960s-1980s)

• JCL emerged as the primary method for defining jobs on mainframes
• Introduced concepts of resource declaration and job scheduling
• Established a precedent for separating resource definitions from application code

Client-Server Transition (1980s-1990s)

• Shell scripts and batch files supplanted JCL in distributed systems
• Maintained similar concepts, albeit with a less formal structure
• Introduced more procedural methods for system configuration

Early Cloud Era (2000s)

• Configuration management tools (e.g., Puppet, Chef) began to emerge
• A resurgence of declarative methodologies
• Introduction of idempotency concepts

Infrastructure as Code Evolution (2010s)

• AWS CloudFormation pioneered the concept of cloud-native IaC
• Terraform introduced a provider-agnostic approach to IaC
• ARM (Azure Resource Manager) templates facilitated native Azure deployment

Modern Cloud-Native Era (2020s)

• Bicep has emerged as a more user-friendly alternative to ARM templates
• Synthesizes lessons learned from previous generations, including:
• Declarative syntax from JCL
• Modern programming paradigms
• Cloud-native capabilities

Key Transformations

From Physical to Virtual

• JCL: Managed physical resources (such as tapes, disks, and printers)
• Bicep: Manages virtual resources (including VMs, containers, and services)

From Single System to Distributed

• JCL: Primarily focused on a singular mainframe environment
• Bicep: Manages distributed cloud resources across various regions

From Static to Dynamic

• JCL: Operated within a relatively static environment, characterized by fixed resources
• Bicep: Functions in a highly dynamic context, featuring auto-scaling and flexible resources

The transition from JCL to Bicep signifies not only a technological evolution but also a philosophical shift. The core principles established by JCL—declarative resource definition, separation of concerns, and structured resource management—have been retained and adapted in modern IaC tools such as Bicep. Despite the significant changes in technologies and capabilities, the fundamental approach to infrastructure definition remains remarkably consistent, underscoring the enduring importance of these core concepts in IT infrastructure management.