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

I’m playing around with the vs code plug-in and have noticed some VERY odd behaviors.I’m using version 11.1.0 of the plug-in and version 10.4 of RDOi.When I right click on an item in the subset filter and select Create, it submits the compile job but I get a “davidg8 check job or spooled file failed. (Internal error).” message.  A “Error: (SSH) Channel open failure: open failed” message shows up in the output tab of the console. After that message shows up, the PRTFCREATE spool file is displayed but flickers.  If I close the terminal window, the terminal window reappears with the same spool file.  This happens for a while until it finally stops.  I tried to upload a screen capture, but the forum software won’t let me.

We are trying to convert from using RDi (with Aldon) to VS Code (with Rocket DevOps extension) as our IDE. We are able to promote from our DEV to ITG but failed to promote further than that. We cannot promote from ITG to QUA (using both “Promote” and “Request to Promote”). Error is “User can only promote objects that are checked out to their own development environment.”We know that it’s not an Aldon configuration issue because our profiles (using RDi) can promote from ITG to QUA without any issue. From the Rocket DevOps documentation, “Promote” and “Request to Promote” are set to “from a development environment to the next available environment”. So we are assuming that DEV to ITG is only allowed and we have to go to Aldon when we need to promote further than ITG. Are we correct to assume this?

We’re using MX Web 10.6.2 and beginning to implement more client-side JavaScript. I noticed that the publish process creates a <script> tag in the body of “index.html” and inserts all of the project’s client-side JavaScript (that isn’t directly linked with a <script> tag pointing to a file name) into it. The bulk isn’t a problem at the moment though I’m not keen on development team code comments being included. I expect that the bulk will increase substantially as we implement more JavaScript though. Is there a way to run a minify/uglify process over the project’s JavaScript during publishing? I’m thinking of something akin to a pre-build event hook that’s part of some IDEs used for other languages.

The ChallengeDeploying application updates is often a balancing act between delivering changes quickly and minimizing disruption to users.Many organizations prefer to perform deployments during off-hours, such as evenings, weekends, or maintenance windows, when system usage is low. However, deployment teams frequently need to be available at those times to manually execute the deployment process.For environments containing multiple web engines, servlets, and servers, coordinating deployments across all components can become time-consuming and increase the risk of human error.What's NewRocket Modern Experience now includes Deployment Scheduling within the Access and Connectivity Hub.This new capability allows administrators to schedule deployments of:Rocket MX Web applications to engines and servlets Rocket API libraries to serversDeployments can be scheduled for a specific date and time and executed automatically without requiring manual intervention.Scheduling can be configured for:In

A hands-on, six-part video series that takes you from first sign-on to full promotion and deployment — all from your terminal. The RDOe GUI client is great for exploring your repository visually — but when you want to script your workflow, plug into CI/CD, or just work fast without leaving the terminal, the RDOe Command Line (the ald command) is your best friend.In this series we build up your command-line skills one layer at a time. We start from a clean machine, set up a workspace, and walk all the way through daily development, release administration, assemblies, promotion, deployment, and configuration. Every command shown here maps directly to something you already know from the GUI — only now it’s scriptable.Prerequisites: The ald client installed on your machine, a registered Security Server user profile, and network access to your RDOe server. Throughout the demos we use a symbolic link so that ald can be called directly from any directory.  Getting StartedEvery journey starts

The ChallengeWorking with the Integrated File System (IFS) on IBM i is nothing new—but exposing those file operations as APIs has usually meant extra effort. Teams often rely on scripts, custom logic, or external tools just to handle fairly simple read and write use cases.What’s NewRocket API 10.6.3 introduces native IFS support, making it much easier to turn file operations into APIs.Two additions make this possible:IFS Connector – Connects securely to the IBM i file system IFS Microflows – Handle reading and writing files with configurable options like append mode and access controlThere’s also support for mapping the entire request body directly to a microflow, which simplifies writing incoming API request straight to a file.How It WorksThe setup is quick:Create an API library Configure the IFS connector Import and define an IFS microflow (file path, options) Expose it via REST (for example, POST for write) Publish and deployWithin a few steps, file-based operations are available as

The Access And connectivity hub provides an easy way to change configurations for MX Web applications.These configurations can often be adjusted without any downtime. As example, one of our customers asked whether the host system could quickly be changed when there is an outage of an IBM i system as part of their disaster recovery (DR).This short video illustrates how easy this is when using the hub and engines connected to an auto deploy environment. Using the properties of the environment, a setting like engine.EmulatorSystem=<new hostname> will be automatically distributed to all engines connected to this environment when the environment is configured to use Auto deploy. 

We are unable to identify any additional command that would allow us to add the below necessary details for Aldon Task creation.  Client Name  . . . .Client Format  . . .Type of Work . . . .Lead Developer . . .Rework based on DEV QA TESTER  . . . . .Rework Based on QA .Rework based on REQ 

If your internal development process has not changed in the last couple of years (or even worse, if it has not changed since COVID or even Y2K…) then you are probably missing out on two of the most seismic changes in DevOps tooling: Artificial Intelligence (AI) and git.In our last blog, we stated that “AI + git is not equal to DevOps” – i.e. AI and git cannot replace DevOps, but adding AI and git to DevOps can truly be more powerful than anything that existed even just a few years ago.We’ll talk much more about AI in later entries of this blog series, but for now, let’s concentrate on git -  specifically, how Rocket DevOps (RDO) has taken the (notoriously PC-centric) git workflow, and adapted it so that it can address the needs of IBM i development teams.Square Peg in a Round HoleWhen you are using open-source tooling like git on the IBM i, it can often feel like the “Square Peg in a Round Hole” idiom where things “don’t fit quite right”.  The biggest issue is that open-source tooling

Prior to MX Web 10.6.3, support packages retrieved through the A&C Hub included connection details for every active session.In most cases, this session-level data was not required. On engines with hundreds or even thousands of connections, collecting this information could result in very large support package files, increased engine load, and, in some cases, timeouts in the Hub due to the extended collection time.Starting with MX Web 10.6.3, support package generation was limited to engine and backend information only. Session-specific details were no longer included by default.From MX Web 10.6.4 onward, administrators can choose between two options:Retrieve a standard support package from the Engine Instances view, containing engine and backend information. Retrieve a session-specific support package from the Session View when troubleshooting a particular session.This short video demonstrates both procedures and explains the differences between the resulting log files. 

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