TURNOVER for iSeries (TURNOVER for IBM i) solves this with elegant precision, turning your multi-environment chaos into a traceable, auditable trail of evolution.

It's time to break down how TURNOVER tracks versions at a high level, zoom into the mechanics (archiving, cross-referencing, worklists, and forms), and wrap with a practical example: promoting from DEV through three test environments to PROD. Whether you're knee-deep in RPGLE modernizations or just dipping toes into ALM (Application Lifecycle Management), this'll show why TURNOVER isn't just a tool, it's your SDLC guardian. Let's navigate the levels.

High-Level Overview: Version Tracking in TURNOVER

TURNOVER treats software versions as a living history, captured and propagated through a structured promotion pipeline. At its heart, it uses promotion levels (PLs) logical stages (e.g., Level 1: DEV, Level 5: PROD) that map to your environments, each with defined libraries, rules, and workflows.

Changes start as "requests" (e.g., bug fixes or features), evolve into worklists of objects (source code, programs, files), and promote level-by-level via automated forms. 

Along the way, TURNOVER maintains version integrity by:

• Archiving snapshots: Saving prior versions before overwrites, stored in a central IBM i database for recovery.
• Dependency mapping: Cross-referencing objects to auto-include related items (e.g., a changed PF requires recompiling dependent LFs and RPGs).
• Status and audit logging: Updating task statuses (e.g., "IN-DEV" to "DONE") and logging every action for traceability.
• Version control integration: Optional ties to SVN or stream files for hybrid setups, ensuring sync across IBM i and multi-platform code.

This isn't mere file copying, it's intelligent propagation: each promotion verifies, compiles, and documents, reducing errors and enabling rollbacks. The result? A single source of truth where you can query any version's lineage, impacts, and approvals, all while enforcing compliance (SOX, GDPR, etc.)

The Mechanics: How TURNOVER Keeps Versions in Check

TURNOVER's version tracking shines through four interlocking components.

Here's the breakdown:

1. Archiving: Your Safety Net for Previous Versions

• How it Works: Before installing a new version at a level, TURNOVER archives the existing source (and optionally objects) from the "to" library. This happens in the promotion form's cleanup phase, via a secondary batch job that saves copies to a secure repository (e.g., TURRLOGR files in TURNDATA lib). You define archive rules in the application setup: e.g., keep 3 copies of source per object, tagged with timestamps and level details.
• Version Tracking Benefit: Each archive is a full snapshot, queryable for diffs or restores. Rollback? Just restore from the archive, so no hunting lost files!
• Pro Tip: Set *YES for source archiving at PROD levels; optional for lower tests to save space.

2. Cross-Referencing (X-Ref): Dependency Detective

• How it Works: TURNOVER builds a cross-reference file (e.g., APDEMO for your app) during setup, scanning relationships (e.g., PF → LF → RPG usage). When building a promotion form, it auto-checks X-Ref (*YES parameter) and adds missing dependents e.g., changing a PF pulls in all using programs. Rebuild X-Ref post-restore or promotion (Option 20) to keep it fresh.
• Version Tracking Benefit: Ensures the exact version of dependents promotes together, preventing "works in DEV, breaks in TEST" horrors. Impact analysis (Option 15) shows lineage: "This RPG v2.1 depends on LF v1.3."
• Integration Note: Pairs with tools like ABSTRACT for deeper field-level refs.

3. Worklists: The Central Version Dashboard

• How it Works: Created from project tasks (Option 20 on Work with Tasks), worklists list objects across all levels in a Programmer Worklist Manager (PWM) view. Columns track status (e.g., Obj/Src presence, Checkout), form readiness, and next actions (e.g., Option 21: Checkout from PROD to DEV). Filters (F17: *DEV or Level 3) and session defaults (F18: Auto-X-Ref) let you slice views. Time logging (F22) and status updates (Option 25) tie back to tasks.
• Version Tracking Benefit: Visualizes version flow e.g., see APRPG001 v1.0 in DEV, v1.1 pending in TEST1. Integrates with PDM/RDi for seamless edits.

4. Forms: The Promotion Engine

• How it Works: Forms (built via Option 46 on worklist) automate the handoff: copy source/objects, compile, set authorities, then cleanup (delete from prior level, archive, check in). Copy forms forward (Option 43) to propagate e.g., Level 1 form to Level 2, auto-adding X-Ref deps. Run (Option 47: submits to QBATCH), approve if gated (Option 48), and log (F14: WRKSBMJOB). Pre/post commands add custom steps (e.g., data sync).
• Version Tracking Benefit: Each form run stamps a new version iteration, with logs detailing changes (e.g., "Installed v2.0 over v1.9"). Supports timed jobs for off-hours PROD pushes.

Together, these create an immutable chain: Request → Worklist (v1 draft) → Form Run (v1.1 compiled) → Archive (v1.0 saved) → Next Level.

Real-World Example: DEV to Three Test Environments to PROD

Let's apply this to a mid-sized RPGLE app (e.g., "FOODAPP" for inventory management). Setup: 5 PLs Level 1: DEV (DEVLIB), Level 2: TEST1 (TST1LIB, integration), Level 3: TEST2 (TST2LIB, QA), Level 4: TEST3 (TST3LIB, UAT), Level 5: PROD (PRODLIB). X-Ref file: FOODXREF. A change request: Fix bug in PF FOODPF01 (add field) and dependent LF FOODLF01 + RPG FOODRPG01.

• DEV (Level 1: Initial Versioning):
  • Create worklist from task (Option 20). Checkout FOODPF01/LF01/RPG01 from PRODLIB to DEVLIB (Option 21 tracks as "v1.0 → v1.1 draft").
  • Edit/compile in DEVLIB (Options 32/36). X-Ref (Option 15) confirms deps; add if missed.
  • Build Level 1 form (Option 46: lists objects, status READY). Run (Option 47): Copies/compiles to TST1LIB, deletes from DEVLIB, updates task to "IN-TEST1". Archive? Optional here (rule: *NO).
• TEST1 (Level 2: Integration Test):
  • After unit tests, filter worklist to Level 2 (F17). Copy Level 1 form (Option 43: Auto-adds any new X-Ref deps, e.g., a display file using the LF).
  • Approve (Option 48: QA signoff). Run form: Installs v1.1 to TST1LIB (over v1.0), compiles, status "FIN-OK". Cleanup archives TST1LIB's prior v1.0 source, deletes from TST1LIB post-validation?
• TEST2 (Level 3: QA Test):
  • Post-integration, copy Level 2 form to Level 3. X-Ref rebuild (Option 20) if schema tweaks. Run: Promotes v1.1 to TST2LIB, archives prior, task to "IN-QA". Logs show version diffs (e.g., "Field added: NEWQTY").
• TEST3 (Level 4: UAT Test):
  • Business users test; copy Level 3 form. Multi-approval (dev + stakeholders). Run: v1.1 to TST3LIB, full dep scan ensures no breaks. Archive v1.0 from TST3LIB; status "IN-UAT".
• PROD (Level 5: Go-Live):
  • Final signoff. Copy Level 4 form to Level 5 (adds all deps). Timed submit (off-hours). Run: Installs v1.1 to PRODLIB (archives v1.0 source/objects keep 3 copies), compiles, sets *PUBLIC *USE auth. Cleanup: Deletes from all test libs, checks in source, task to "DONE". Query archives for v1.0 rollback if needed.

End result: Full traceability e.g., PWM shows FOODRPG01 v1.1 live in PROD, with logs linking back to the original request. Total cycle: 1–2 weeks, vs. manual's error-prone months.

Visualizing the 5 TURNOVER Promotion Levels: An Infographic Overview

IBM i change management pros, if the ASCII flowchart from before left you craving something more polished, I've got you covered. To bring those 5 promotion levels: DEVELOPMENT (PL1: Initial coding), DEV B (PL2: Peer review), TSTA (PL3: Integration testing), TSTB (PL4: UAT/system testing), and PROD (PL5: Live deployment) to life, here's an illustrative infographic adapted from a standard software deployment pipeline. This image captures the sequential flow, testing gates, and impacts, mirroring TURNOVER's structured promotions where each level builds on the last with archiving, X-Ref checks, and approvals.

Think of it as your TURNOVER pipeline in pixels: starting in dev chaos, refining through tests, and landing in prod glory. I've mapped the stages closely e.g., DEV B aligns with QA, TSTA/TSTB with staging/UAT to highlight the progression.

Final Thoughts: Level Up Your Versions Today

TURNOVER's version tracking isn't flashy it's bulletproof, turning promotions into a versioned pipeline that scales with your team. From archiving safeguards to X-Ref smarts, it keeps your IBM i apps evolving without the dread of "oops, wrong version."