I was in a meeting with a client earlier today – they were discussing hardware changes, software version control, promotion flow and how to set TURNOVER ALM up. A mix of folks in attendance; a couple of current IBM-i programmers, some old AS400 techies and a host of vocal application managers, with everyone seemingly confused by IBM-i software lifecycle tracking but wanting to know the technical nitty-gritty of how programmers track their RPG, CL source code through the development life cycle. This made the meeting a fairly lively one with differing opinions ranging from “classical AS400 source files rock” to “we should be using git”. It felt chaotic. Not surprising, the Application Lifecycle is a behemoth beast, and you can frequently just see the tip of this iceberg. So, let’s write a blog about TURNOVER in particular, and try to unravel this huge ball of twine.

As an IBM i developer or administrator, you’ve likely faced the challenge of managing evolving codebases across multiple environments, ensuring that a bug fix in development doesn’t unravel production, or that dependencies are synchronized without manual chaos.

IBM i itself provides robust object management and journaling for basic auditing, but for comprehensive software change tracking in a multi-environment setup, tools like TURNOVER Lifecycle Manager elevate the process to enterprise-grade precision. TURNOVER transforms ad-hoc promotions into a traceable, automated pipeline, capturing versions, dependencies, and approvals at every step.

One of my favorite things about TURNOVER is its comprehensive version tracking across promotion levels. If you’ve ever stared at a tangled mess of source code versions scattered across DEV, TEST, and PROD environments, wondering how to untangle the “which one’s live?” nightmare, you’re in good company.

In this blog post, we’ll explore how TURNOVER enables IBM i to track software changes effectively. We’ll cover the high-level mechanics of version tracking across promotion levels, dive into the core components (archiving, cross-referencing, worklists, and forms), and walk through a practical example of promoting changes from a DEV environment through three test stages to PROD.

By the end (hopefully) you’ll see why this approach minimizes risks, ensures compliance, and streamlines your software development lifecycle (SDLC).

The Foundation: Promotion Levels in TURNOVER

TURNOVER organizes change tracking around promotion levels (PLs or sometimes called “Forms”) which are logical stages that map to your IBM i environments, such as DEV, TEST instances and PROD. Each level defines “from” and “to” libraries, rules for compilation and validation, and workflow gates.

Changes originate as requests (e.g., via helpdesk tickets), compile into worklists of objects (source code, programs, files), and promote sequentially via automated forms. This creates an immutable history: every modification is versioned, archived, and linked back to its origin.

Version tracking isn’t just about snapshots, it’s intelligent propagation. TURNOVER uses cross-referencing to detect dependencies (e.g., a changed physical file requires updating logical files and dependent RPG programs), enforces approvals, and logs actions for audits.

Core Mechanics: How Versions Are Captured and Propagated

TURNOVER’s version tracking relies on four integrated components, ensuring consistency across levels:

1. Archiving: Safeguarding Prior Versions

Before overwriting an object at a target level, TURNOVER archives the existing source (and optionally compiled objects) to a secure repository in the TURNDATA library. Archives are timestamped, level-specific, and configurable (e.g., retain 3 copies per object). This enables quick rollbacks restore a prior version without sifting through backups.

2. Cross-Referencing (X-Ref): Mapping Dependencies

A central X-Ref file (e.g., FOODXREF for an app) scans relationships during setup and promotions. When building a form, TURNOVER automatically includes dependents (*YES parameter), preventing incomplete promotions. Rebuild X-Ref after restores to maintain accuracy, with impact analysis revealing version lineages like “RPG v2.1 depends on LF v1.3.”

3. Worklists: Centralized Version Oversight

Worklists, generated from tasks (Option 20), display objects across all levels in the Programmer Worklist Manager (PWM). Columns track status (e.g., checked out, ready), with filters (F17: by level) and time logging (F22). This dashboard visualizes version flows e.g., spot a pending update in TEST before it hits PROD.

4. Forms: Automating the Promotion Pipeline

Forms (built via Option 46) orchestrate handoffs: copy source/objects, compile, set authorities, archive, and cleanup (e.g., delete from prior level). Copy forms forward (Option 43) to propagate changes, adding X-Ref dependencies. Run them interactively or in batch (Option 47), with approvals (Option 48) for gates. Each run stamps a new version iteration in logs, detailing diffs and status updates.

These elements form a chain: Request → Worklist (draft version) → Form Run (compiled version) → Archive (prior version saved) → Next Level.

Visualizing the Pipeline: A multi-level Promotion Flow

To illustrate, consider a multi-level setup: DEVELOPMENT, on to three separate testing environments. Once the ode is tested and approved for production it then promotes to the production layer in those three test environments as then onto the actual PRODUCTION environment for live deployment. The flow is linear, with each promotion verifying, compiling, and documenting.

Here’s a flowchart representation of the pipeline:

Arrows denote form-driven promotions, with X-Ref scans and archives at each step. For hotfixes, you could add parallel paths with emergency overrides.

NOW – imagine this flow with arrows connecting different nodes? It’s flexible to do that! code can be transferred into separate test environments as different version. Only when it goes to production will all the previous layers be cleared up and everything synchronized. Flexibility is the name of the game!

TURNOVER’s approach to tracking software changes on IBM i isn’t about rigid control, it’s about empowering reliable evolution. From archiving safeguards to automated forms, it reduces defects, supports compliance, and scales for multi-system teams.

In a world of rapid updates and hybrid apps, this pipeline ensures your changes land smoothly, every time.