Rocket® DataEdge

Hi there, We're running a market research study to understand how organizations like yours are thinking about AI for mainframe and mission-critical environments. We’d love to hear from you.Specifically, we're hoping to learn:What challenges you're hoping AI can help solve How your organization approaches AI governance, security, and data sharing Where you see the biggest opportunities for AI in operations and modernization What capabilities should guide the future of Rocket EVA and our broader AI offeringsThe survey takes about 15 minutes, and your input will directly shape our product strategy, roadmap, and future investments.As a thank-you, the first 30 respondents will receive a $50 gift card, sent via Sendoso to the email you provide.Take the survey hereThanks in advance for sharing your perspective. We're looking forward to learning from your experience.

The customer I am working with has been struggling with RDRS v6.1 in a z/VSE environment for well over a year without being able to actually get the product into production for various reasons--though many issues are being resolved successfully.  The biggest remaining reason is the performance (or lack thereof) for RDRS CDC in capturing batch VSAM changes and sending them down to DB2/LUW on the network side.Initially we were told that the problem was slow TCP/IP transmissions.  We resoled that with a 900+% improvement.  But my observations, while monitoring large batch update jobs, are that CDC isn’t even *starting* to download accumulated VSAM changes until up to 5 minutes *after* the update job has ended!  Thus, even if that batch job didn’t overflow the 1G total dataspace available for the pool, follow-on batch update jobs would--resulting in “TVS066E Data Lost”.Then, we were finally told that RDRS v6.1 is not intended to keep up with the rate at which we are generating VSAM changes

Shift 4: Change-Resilient Pipelines — Meaning changes break AI faster than BI Why this shift matters: Even when RDRS correctly replicates schema changes (including DDL where supported), AI fails when change meaning, compatibility, and consumer impact are not explicitly managed—making change resilience a critical practitioner responsibility beyond CDC mechanics.Make Change Boring: Contracts, Versions, and Zero SurprisesBI complains when schemas change. AI hallucinates confidently when meanings change.Both are bad. One is sneakier.What RDRS contributes:Replicates DDL changes where supported (L1) Preserves change order and integrity at the mechanics level (L1) Ensures changes are not silently dropped during replication (L1)That’s it — and that’s enough.Minimum change resilience per Tier‑1 feed (L2)Document grain + keys + delete semantics (yes, really) Publish a simple change policy (who approves, timeline) Define evolution rules (new columns/type changes/renames) Version breaking changes

Shift 3: Sovereignty by Design — AI + Replicated Data Without Controls is the Fast Track to Compliance FinesCDC makes data accessible. AI makes it usable.That combo is powerful—and dangerous—without guardrails because you’ve just turned sensitive data into something that can be searched, summarized, and repeated everywhere—in seconds.What RDRS contributesSecure, controlled data movement (L1) Explicit source → target paths (L1)RDRS provides the mechanics of controlled data movement (L1); defining what is allowed, where data may land, and under what conditions is a practitioner responsibility outside of RDRS (L2). That responsibility is enforced through a small set of explicit sovereignty controls for AI‑critical feeds.Minimum sovereignty controls (Tier‑1 / AI-critical)Classify the feed (Public/Internal/Confidential/Restricted + PII flags) Enforce masking/tokenization downstream where required Ensure audit logging + retention exists at the target Define an exception/break-glass processPr

Shift 2: Standardize Bulk and CDC Patterns— Because AI at Scale Can’t Live on Bespoke FeedsIf Every Feed Is Special, None of Them Are ReliableAI doesn’t scale on bespoke feeds. It scales on repeatable patterns and a predictable operating model.Pick 2–3 RDRS-supported pattern familiesInitial bulk load followed by continuous CDC Capture once, replicate to multiple targets  Continuous synchronization/coexistence patterns RDRS supports these replication patterns, but selecting which patterns are allowed and enforcing consistency across teams are practitioner responsibilities outside of RDRS. That consistency is enforced through an explicit feed‑level contract (L2)*.Standardize the “AI-ready contract” per feed (minimum)Keys + delete semantics Tier + SLAs (lag + correctness) Owner + on-call Validation bundle What changes trigger versioning Kill click-ops: Use RDRS REST API for light orchestration: automate routine tasks you currently click through in the dashboard (health/status checks, proc

Shift 1: Make CDC Trustworthy (SLAs + Validation) — Because AI Hates “Maybe Data”If your only metric is “job running,” your AI is training on hope and good intentions.So let’s start with the right signals. RDRS gives you deep operational information:Process status and lifecycle (L1) Latency, throughput, and replication statistics (L1) Error and failure reporting (L1)Trust starts by putting these on the scoreboard.Start with a handful of SLAs you can actually measure, then back them up with target-side validation that catches problems before your users (or your AI). These are the minimums to move from “it’s running” to “it’s reliable.”SLAs (pick 3–5): Defining and operating to these SLAs is a practitioner responsibility (L2); RDRS provides the signals needed to measure them.P95 end-to-end lag ≤ X minutes (AI use cases usually need tighter) Success rate ≥ Y% Apply errors ≤ Z/day Process restarts/day Time above lag thresholdThese are RDRS‑observable metrics.Target-Side Validation (Not Per

This series is written for data integration pipeline owners and practitioners who leverage Rocket Data Replicate and Sync (RDRS). While RDRS plays a critical role in that journey by providing high‑fidelity, observable replication mechanics, trusted enterprise data integration requires more than replication alone. It requires clear ownership, repeatable patterns, explicit contracts, operational guardrails, and disciplined interfaces with downstream platforms. It’s about everything it takes to deliver reliable, always‑on data integration at scale beyond “it worked in the demo.”To keep responsibilities clear, the series explicitly distinguishes between:What RDRS provides (replication mechanics, telemetry, and control surfaces) What data integration and CDC pipeline owners must define and operate around RDRS to make outputs trustworthy What is implemented downstream using non‑RDRS platforms and toolsEach post covers one of five shifts:Operational Trust: knowing what’s late, broken, or fall

Why are Data Integration Practitioners Feeling the Ground Shift?If your job includes being on call, you’ve already learned an important rule:Anything that only works in the demo will eventually page you.Usually at 2:47am…right after a “minor” upstream change…with the extremely helpful alert message:“job running”AI hasn’t changed that rule. It just made the blast radius bigger.Most AI failures don’t explode loudly. They quietly deliver outputs built on late, partial, or misunderstood data—and do it with complete confidence. When someone finally asks “can we trust this?”, the answer usually traces back to the same place it always has: The data pipelines everyone assumed were fine.Because you’re responsible for CDC-powered data integration and, unless you operate (or manage) Rocket® Data Replicate and Sync (RDRS) specifically—this should feel uncomfortably familiar. AI isn’t creating new problems. It’s dragging existing ones into the spotlight.This post isn’t a checklist or a tutorial. It

Rocket DataEdge just hit its one-year mark. The press release says “momentum,” “validation,” and “AI-ready.” Cool. But if you’re the person who owns pipelines, SLAs, access tickets, and the occasional 2 a.m. “why is the feed red?” message, the real question is: What changes for me?First: What does DataEdge do?In a nutshell, it makes all your data arrive while it still matters. DataEdge is an enterprise data integration platform built for the reality most of us live in:Core transactional data still lives on mainframe / legacy systems. Analytics, apps, and ML want that data in cloud / lakes / warehouses. The current solution is often a pile of ETL jobs, extra copies, and tribal knowledge.The value prop is: Deliver governed, near-real-time access to critical data across hybrid environments without melting the mainframe or creating 14 new “golden copies” no one can explain.Industry recognition: Should you care?DataEdge got nods from IDC (Vendor to Watch), Gartner (Honorable Mention), and s

If your saved view name reads like a filing cabinet label, no one clicks it. Microcopy is your growth hack: name it like a button people want to press.The formula (keep it simple)Name pattern: [Emoji] [Job to be done] — [Scope or threshold] (Audience if needed) One‑liner: “Why this view exists” in one sentence. Action + payoff.Naming rules that earn clicksLead with the job, not the noun. Action beats category. Keep it under ~30 characters. Truncated names don’t get love. Use consistent emojis. Pick 6–8 and stick to them. Scope it. Add “>30d,” “High,” or “This Week” so expectations are clear. If it’s personal, say so. “(Me)” or “My Queue” prevents confusion.Your emoji shortlist (use sparingly)🔎 find/triage 🚩 risk/attention ✅ done/clean 🧹 cleanup/dedupe 💤 stale/aging 📥 imports ⚙️ ops/system 🧪 test/sandboxBefore/after names with one-linersBefore: Potential Duplicates After: 🧹 Needs Merge — High Why: Highest confidence dupes first; clear 5 in 5 minutes. Before: Validation Errors

Everyone’s racing on AI and analytics. Almost no one is feeding those engines with the best fuel they own—mainframe truth. That’s your opening. With DataEdge replication and synchronization (RDRS under the hood), you stream the good stuff from core to cloud without breaking prod, pin the lag graph near zero, and turn downstream teams into raving fans.Why you should careMainframe data isn’t “legacy”; it’s ground truth. When it lands in your lakehouse, warehouse, or Kafka streams, models get sharper and dashboards stop guessing. Execs don’t want slides; they want secure, explainable feeds that don’t spike MIPS or trigger audits. DataEdge is built for that job. You own the how. DataEdge is you kit to move it, serve it, and prove it — safelyWhat to build (and ship) with RDRSLog‑based Change Data Capture (CDC) pipelines: Capture mainframe Db2 changes and deliver to Kafka, cloud/object storage, lakehouse, or warehouses. Be surgical—tables, columns, and row filters only. Dev/test refresh on a