Rocket DevOps, MX, API, iCluster® – Solutions for IBM i™

Faster, More Stable Monitoring for Hybrid EnvironmentsA new enhancement in the iCluster Web Console delivers quicker dashboards, greater stability, and seamless operation when your systems span on-premises and IBM Cloud.OverviewKeeping a clear, real-time view of your data replication and system health is essential — especially when your environment stretches across multiple locations. This release introduces a significant enhancement to how the iCluster Web Console gathers and displays monitoring information: the **Decentralized API**.The result is a monitoring experience that is noticeably faster, more stable under heavy use, and purpose-built for hybrid environments where some systems run on-premises and others run in IBM Cloud.BackgroundWhat is the Decentralized API?The iCluster Web Console relies on background services (APIs) to collect monitoring and replication-group information from each system in your cluster and present it in the dashboard. In the past, all of that information

When multiple objects become out of sync within a replication group, administrators rely on activation processes to restore synchronization and return affected objects to a healthy state. While activation is designed to bring all eligible objects back into sync, the order in which objects are processed can have a direct impact on how quickly recovery progress becomes visible.  Consider a group containing several out-of-sync objects of varying sizes. If a large object is activated first, smaller objects must wait until that larger object has been processed -even when those smaller objects could have been synchronized much sooner.  With iCluster Web 9.4.1, administrators can now use Sort by Size (Ascending) when activating all out-of-sync objects for a replication group. This new option provides additional control over activation sequencing by allowing smaller objects to be processed before larger ones. The Challenge: Recovery Order MattersWhen a replication group contains multiple out-o

Sync checks are an important part of maintaining replication confidence in an iCluster environment. Sync checks help administrators validate that source and target systems remain synchronized and help identify potential discrepancies before those discrepancies become operational concerns.  Full sync checks remain a core part of replication validation. Full sync checks provide comprehensive verification across a replication group and help administrators maintain confidence that source and target systems remain aligned.  As replication groups grow, however, the number of objects included in a sync check can grow as well. In some situations, administrators may want to focus validation efforts on the objects that have changed recently rather than validate every object in a group. With iCluster Web 9.4.1, administrators can now take advantage of Priority Audit Sync Check, a capability that focuses synchronization validation on recently modified objects. Instead of checking every object in a

Replication environments are built around one simple goal: keeping source and target systems synchronized. When an object falls out of sync, administrators need a reliable way to restore consistency while minimizing disruption to ongoing replication activities.  For physical files, the traditional approach is often to refresh the entire object. While effective, this can require significant processing for large files—even when only a small portion of the data has actually changed.  With iCluster Web 9.4.1, administrators now have access to Smart Diff Refresh, a new physical file refresh method that compares source and target data and repairs only the portions that differ. Rather than replacing the entire file, Smart Diff focuses on the changes that matter. The Challenge: Not Every Out-of-Sync File Requires a Full RefreshWhen a physical file becomes out of sync, administrators have several refresh methods available to restore synchronization. These methods are proven and reliable, but la

Sync checks are an important part of maintaining replication confidence in an iCluster environment. By validating that source and target systems remain synchronized, they help administrators identify potential discrepancies before they become operational concerns.  Users can rely on scheduled sync checks to perform this validation automatically. Once configured in the iCluster engine, these schedules run according to their defined timing, helping ensure that synchronization is regularly verified without manual intervention.  As the number of replication groups and scheduled validation activities grows, administrators often need a convenient way to review existing schedules, check their status, examine execution history, and perform routine schedule maintenance.  With iCluster Web 9.4.1, administrators can now view and manage sync checks that were scheduled in the iCluster engine directly from the web interface. The new Sync Check Scheduler provides a centralized view of these schedules

The Blind Spot in Every iCluster RefreshIf you've ever kicked off a refresh for a large object and wondered, "Is this going to take 10 minutes or 3 hours?", you're not alone. Until now, iCluster gave you no way to know. There's no duration in the event log, no historical reference, and no way to plan based on past experience.That creates real problems:Scheduling refresh operations is pure guesswork. You risk running multi-hour refreshes during business hours. There's no data-driven basis for batching or sequencing refreshes.What ChangediCluster now logs the actual refresh duration for every object 100 MB or larger, directly to the Event Log on your backup node automatically, after each refresh completes. This works across both Save/Restore and Record-by-Record refresh methods, and covers all object types - databases, programs, IFS files, documents, and more.No guessing. No surprises. Just real numbers from real refreshes.Why This MattersPlan with confidence - Know whether your refresh

Rocket iCluster Group Splitting for Replication:As replication environments grow, so does complexity. Over time, a single replication group can end up handling everything—from small reference tables to massive, high‑traffic data files. When that happens, performance tuning, monitoring, and maintenance become harder than they need to be.To address this, we’re introducing Replication Group Splitting—a feature designed to give you more control as your data grows.Break Up What’s Slowing You Down:Replication Group Splitting will allow you to separate selected large or high‑impact files into their own replication group, while keeping everything fully synchronized. Instead of managing one oversized group, you’ll be able to organize replication around how your data is actually used.You can create a new group for these files or continue adding to an existing split group over time—making reorganization incremental, not disruptive.Designed with Real‑World Systems in Mind:This feature is being bui

The speed of publishing, performance, in the Rocket MX (Modern Experience) workbench (fka LegaSuite workbench) has been reported to be slower in versions 10.6.0, 10.6.1, 10.6.2 and 10.6.3 than before.The cause of this is the transition to Java 21, which has additional validations when working with COM control, which can impact the performance significantly.This will be resolved in version 10.6.4.For versions 10.6.0-10.6.3 there is a solution too,  the following settings in the LegaSuite ini should be added:-XX:+UnlockDiagnosticVMOptions -XX:GuaranteedSafepointInterval=0 -XX:+UseZGC -XX:+ZGenerationalThe Legasuite.ini file can be found in the installation folder of the workbench.This file can, by default, be found on the following locations:Version Path 10.6.0 C:\Program Files\Rocket Software\LegaSuite Workbench for 64-bit\10.4150.0.0\legasuite.ini 10.6.1 C:\Program Files\Rocket Software\LegaSuite Workbench for 64-bit\10.4159.0.0\legasuite.ini 10.6.2 C:\Program Files\Rocket S

There is no question that the development landscape changed with the advent of git – the free, lower-case, “git” command-line source control tool that Linus Torvalds threw together over a couple of weekends, has created a multi-billion dollar enterprise uppercase “Git” cloud empire dominated by GitHub; nine years ago Microsoft paid a staggering price to take over those millions of git repos­­—not so much as a direct money-maker, but rather as the ultimate training tool for OpenAI, which in turn helps to make their AI Copilot assistant as powerful as it is today.Even with all that power, AI tooling like Copilot is likely to never replace dedicated DevOps software; even if it is true that you can do very powerful “DevOps-like” development, there are two very important points to remember:git is Source Control, it is not Version Control AI is non-deterministic and largely statelessIn simple terms, source control is all about maintaining (primarily) text files, and to that extent git can do

The ChallengeRefresh operations are a critical part of iCluster replication. They move full object copies from source to target, and for large environments the time and bandwidth they consume directly impacts replication windows and recovery readiness.Until now, iCluster offered four compression options for SAVRST refresh processing — *NO, *YES, *MEDIUM, and *HIGH — all based on the traditional IBM i compression algorithms. While effective, these options left performance on the table, especially on modern Power hardware.What ChangediCluster now supports *ZLIB compression to accelerate refresh operations and improve replication efficiency for IBM i environments.The new *ZLIB option is added directly to the existing Object Compression setting in iCluster System Values (DMSETSVAL), which previously supported *NO, *YES, *MEDIUM, and *HIGH. This makes adoption straightforward — customers can enable *ZLIB compression using the same familiar system-value configuration they already know.One se

The Silent Performance Killer in Your iCluster Environment — and How AI Tuner Fixes ItIn the world of IBM i high availability, there is a silent performance killer that most teams don't notice until it's too late: replication group imbalance.If you're running iCluster, you know the drill. You set up your replication groups, everything looks green, and you move on. But over time, workloads shift. A database file that used to be quiet suddenly becomes the heart of your operation, processing thousands of transactions an hour.The problem? That high-traffic file is often stuck in a group with dozens of smaller objects. The replication engine spends all its energy on that one massive file while everything else sits in line. This creates latency — the dangerous gap between a change on your source system and its arrival on the target. In a disaster recovery scenario, that gap is the difference between a smooth failover and losing hours of critical data.The Old Way: Manual, Painful, and SlowDia

We're experimenting with JavaScript in MX Web 10.6.1 to see if we can eventually replace some of our Rocket script. A simple test case right now is prompting a field on a screen, collecting the code/description records from the subfile on the popup window that the prompt triggers, and using that data to populate a dropdown widget. That's really easy to do with Rocket script, and I use "PanelUpdateEnable(0)" to suppress panel updates so the whole process happens transparently to users. The mechanics of this are easy enough with the client-side JavaScript library, but I can't find a way to use JavaScript to suppress display of the popup window while this is running. Is there a way to do this? Rocket script and JavaScript don't seem to interact smoothly, so I'd rather not jump back and forth between them within a single process. I opened a support ticket for this question as well but am posting here in case anyone else has encountered this situation or has any tips or tricks to share. 

Hi,I’m using Client Side JavaScript in version 10.6.1.I created a popup/dialog page with the page name V100_popup.In my main page V200_main, I have a button. When the button is clicked, I need to open the popup page using Client Side JavaScript.Could someone please guide me on how to open a popup/dialog page from Client Side JS in 10.6.1?Thanks

We’re excited to be heading to POWERUp in New Orleans, and we’d love to connect with you there.If you’re attending the conference, be sure to stop by our booth and join one of our sessions to see how we’re helping customers like you drive real outcomes with smarter, more efficient solutions. 📅 Attend Our SessionsOur team will be hosting engaging, customer‑driven sessions focused on:Solving real‑world business challenges Driving faster time to value Enabling scalability, performance, and innovationSession title: Modernizing IBMi Applications - From Monolith to Future-ReadyDate & time: Tuesday April 28, 2026 9:15am - 10:15am CDTLocation: Balcony KSession title: Compliance and Security on i - Automation is the KeyDate & time: Tuesday April 28, 2026 10:45am - 11:45am CDTLocation: Galerie 6Session title: From Core to Catalyst: How IBM i Teams Can Lead the Next Wave of AI-Ready ModernizationDate & time: Tuesday April 28, 2026 1:45pm - 2:45pm CDTLocation: Mardi Gras BallroomSessi

Hello Rocket Team, I hope everything is going well; Where can I find the quarterly Rocket DevOps videos or seminars? I only have the link for Q423 DevOps Customer Enablement. I'd like to see the ones from 2024. Please help me by telling me where I can find them so I can review them. I have some questions about Git integration. These videos might help me. I would appreciate your help about this request. Meet virtually with Cisco Webex. Anytime, anywhere, on any device. Cisco Webex Site remove preview Meet virtually with Cisco Webex. Anytime, anywhere, on any device. Simple, modern video meetings for everyone on the world's most popular and trusted collaboration platform. View this on Cisco Webex Site >

Stay ahead of innovation on IBM i with our Q1 Portfolio Update on‑demand webinar, where we walk you through the latest enhancements across the IBM i portfolio—with live demos that show what’s new in action. This quarter’s update focuses on two key releases:🚀 Rocket DevOps 11.2See how Rocket DevOps continues to accelerate modern IBM i development with powerful new capabilities, including:Test Framework with AI‑driven unit test generation Static Code Analysis to improve code quality and reduce risk Git enhancements that streamline collaboration and CI/CD pipelinesWatch real demos that show how teams can increase speed, quality, and confidence across the development lifecycle.🔄 Continuous Modernization 10.6.2Discover how Continuous Modernization helps modernize IBM i applications while preserving business logic, with new features such as:AI Integration Framework to augment AI services into IBM i business workflows to make them Smart New Observability support for deeper runtime insights

One user has a PC with larger monitors that run at high resolution and when they run a Jwalk client in Full Screen mode it is not proportionally scale. Instead you end up with a relatively small area for the IBM i interface (approx 30%) and a vary large boarder (the remaining 70%)Is there a setting I can adjust to change this to improved the way the Jwalk client scales?We are using Jwalk v42c9 as a locally installed client, with a copy of all the panels stored with it on a Windows 11 PC.  Any advice would be much appreciated.Steve BThe Friendly Techie

Has the RDi plug-in been tested against RDi 9.9 that was released today?I tried installing it and get this error:Cannot complete the install because one or more required items could not be found.Software currently installed: Rocket DevOps for IBM i Team Repository (64-bit) 10.4.0.v202409041507 (com.aldon.team.rdi_64.feature.group 10.4.0.v202409041507)Missing requirement: Rocket DevOps for IBM i in RSE 10.4.0.v202409041507 (com.aldon.RDi75 10.4.0.v202409041507) requires 'osgi.bundle; com.ibm.etools.systems.migration2 0.0.0' but it could not be foundCannot satisfy dependency:From: Rocket DevOps for IBM i Team Repository (64-bit) 10.4.0.v202409041507 (com.aldon.team.rdi_64.feature.group 10.4.0.v202409041507)To: org.eclipse.equinox.p2.iu; com.aldon.RDi75 [10.4.0.v202409041507,10.4.0.v202409041507]