Welcome to another edition of Talsco Weekly

IBM i Briefs: 🕯️ The IBM i user group a search engine can’t replace. 📉 IBM’s slow quarter isn’t IBM i’s story.
AI: 🔍 AI is worst at reviewing its own code. 🔧 The IBM i tool built on the multi-model idea.
Career: 🎙️ To explain IBM i, be a tour guide.
Development: 🐝 The BOB feature that saves what retires.
Database: ✂️ Stop parsing qualified job names by hand.
ERP: 🔄 The ERP goes live. Then the real test starts.
Leadership: 🎯 The 90% of AI value that isn’t the tech.
Learning: 🔌 The RPG skill that connects IBM i to everything. 🔗 Know IBM i and this, and you close the gap.
Modernization: 🔀 The COBOL-to-Go trap you plan for first.
Did You Know: 💡 IBM i is probably in the path when you use an ATM.

IBM i Briefs

🕯️ The IBM i user group a search engine can’t replace

After 41 years, the Toronto User Group has closed. TUG built something a support ticket never could: a room where you overhear a fix you did not know to search for, and meet the person who needs exactly the thing you just solved.

Its members recall one hour on service entry points worth a whole three-day conference, hearing straight from the people who wrote the RPG compiler.

Why did it close? Succession. Nobody stepped up to carry four decades forward.

Our Take: Read this as an ending and you miss half the story. The community is not only shrinking. It is changing shape. The same body that published this farewell, COMMON, is pushing into new regions and formats: Latin America, India, virtual sessions, on-demand libraries, and its NAViGATE program now embedded inside IBM TechXchange.

The local, volunteer-run chapter is the model under strain. The global, digital, in-person-when-it-counts model is the one growing. TUG closing and COMMON expanding are the same story told from two ends.

📉 IBM’s slow quarter isn’t IBM i’s story

IBM shares have been soft since its last quarter, when revenue came in at $17.16 billion against a $17.46 billion estimate. Growth of just over one percent year on year has the market asking whether the AI and hybrid-cloud bets are paying off fast enough.

That is the headline. It is worth remembering it is a headline about a $220 billion conglomerate, not about the platform you run.

IBM the corporation and IBM i the platform are not the same story, and a slow quarter for one does not move the other.

The IBM i Angle: Your ATMs still clear, your batch still runs, your Db2 for i tables do not care what the stock did today. The platform’s health is measured in uptime and workloads, not quarterly revenue.

AI

🔍 AI is worst at reviewing its own code

A model’s blind spots follow it from writing to reviewing.

Someone ran roughly a thousand buggy AI-written pull requests through two frontier models and found something odd. Each model caught more bugs in the other model’s code than in its own.

The reason is the interesting part. The kinds of mistakes a model tends to make are the same kinds it tends to miss on review. Its blind spots follow it from writing to reviewing.

One model goes wide and flags everything. The other goes deep and stays quiet. Neither is a safe grader of its own work.

Our Take: This is the case against betting everything on one model. If AI wrote it, a different model should review it, and a human should still be in the loop.

That is a real signal for how the IBM i role is changing. Tools like Bob put AI in the workflow. The skill that matters next is not loyalty to one model. It is knowing how to orchestrate several and check their work.

That is the IBM i architect of the future. And that idea is already showing up in IBM i-native tooling.

🔧 The IBM i tool built on the multi-model idea

An agentic platform that runs several models against each other.

Right on cue, here is an IBM i-native take on the same principle.

CoderFlow, from Profound Logic, is an agentic coding platform for enterprise systems. It runs across RPG, COBOL, and 5250, plus modern stacks, inside your own infrastructure.

The part that fits the research: it runs multiple models in parallel, compares their output, and picks the validated result. Agents run the full build, test, and fix loop, and a developer approves the outcome.

I spoke with an executive at Profound Logic recently, and the vision was clear. The developer stops writing and debugging line by line and starts orchestrating agents and reviewing verified work.

Career

🎙️ To explain IBM i, be a tour guide

Knowing the platform isn’t the same as selling it.

A year ago, Rob Willis was a corporate trainer few people had heard of. Then he posted a hundred short videos in a hundred days breaking down what makes great speakers land, went viral, and landed on Simon Sinek’s podcast.

Where he learned it is the good part. He gave free walking tours in Berlin, where nobody pays up front and anyone can walk away the moment you bore them. People vote with their feet.

The tour taught him how to hold a room. The person who knows the most is rarely the one who persuades, and a few small, learnable habits decide whether a pitch gets forgotten or repeated.

Our Take: Not about IBM i, and entirely about IBM i. When we present the platform to a board or a new CFO, we default to lecturer: specs, uptime, decades of reliability. The better model is the tour guide. Your job is getting them from point A to point B, keeping them with you the whole way, making them care before they wander off.

We know IBM i is powerful. Most of us, myself included, are only average at guiding anyone else to see why. The tech was never the hard part. The story is.

Development

🐝 The BOB feature that saves what retires

The honest, everyday view of AI on legacy RPG.

A developer who uses IBM BOB every day on legacy RPG gives the honest version, upside and downside.

Point BOB at a 30-year-old fixed-format program and you get a readable summary in minutes, not half a day. It flags the classic IBM i foot-guns fast.

The quiet killer feature is knowledge preservation. BOB reads the actual source, pulls out the business rules nobody documented, and captures them before the person who understands them retires.

The downside is honest too. It still hallucinates, so you review everything. It modernizes syntax, but cannot tell you whether a 20-year-old rule still makes sense.

Our Take: Yes, we write about BOB a lot. Here is why. We feel the same way. AI on IBM i is not hype, it is a genuine disruption, and the developers leaning in are pulling ahead.

The ones who jumped on are learning everything they can right now.

Database

✂️ Stop parsing qualified job names by hand

New Db2 for i functions do the splitting for you.

Every IBM i developer has taken a qualified job name apart by hand. Number, user, and job name, jammed together as 865917/SIMON/QPRTJOB, pried apart with LOCATE_IN_STRING and patience.

The latest Technology Refreshes end that. IBM i 7.6 TR2 and 7.5 TR8 add Db2 for i functions that do the split for you. JOB_NAME, JOB_NUMBER, and JOB_USER each return one part. JOB_NAME_DETAILS returns all three at once.

They live in SYSTOOLS and run anywhere you can run SQL, including in a WHERE clause to filter by user.

ERP

🔄 The ERP goes live. Then the real test starts.

A new system only pays off when behavior changes.

A CIO makes a point every ERP shop has lived. The project can hit every launch milestone and still miss the business outcome.

The system going live is not the win. The win is when people actually stop running the old process. When the side spreadsheets get retired and the legacy reports get shut off.

His hardest lesson is the honest one. When users drift back to the old way, you have to tell two things apart. Is the new process genuinely broken, or is the old habit simply easier?

Our Take: Here is the question the article dances around. If your people keep going back because the old way was easier, ask whether the old way was also still working. That is not a reason to skip modernizing. It is a reason to be sure why you are.

IT can configure and support any new system. The business owns whether people adopt it. Buy-in has to come from the very top, and a business process owner, not IT, has to own adoption, training, and the call on every exception.

Rolling out an ERP or modernization change and worried adoption will stall? Let’s talk. Book a call.

Leadership

🎯 The 90% of AI value that isn’t the tech

CEOs see AI’s value. Execution is the hard part.

A new BCG study drops a number worth pinning up. Just 10 percent of AI value comes from the algorithms. The rest is data and, mostly, changing how people actually work.

That reframes the whole problem. Nearly nine in ten CEOs now see real value from AI, but the barrier to scaling it is not technical. It is execution: redesigning workflows, roles, and accountability. Few have done it. Only a small share tie AI to a clear financial number.

Our Take: The same execution gap shows up in the IBM i space, at the top. Look one level down, though. Developers, architects, and admins are already leaning in, wiring AI into real work in a dozen ways.

That is the quiet story. The execution the boardroom is still planning is happening at the keyboard.

One caveat. This survey is a couple months old, and in AI that is ages. The numbers have likely moved already.

Leading an IBM i shop through its AI moment? Let’s talk about turning it into real work. Book a call.

Learning

🔌 The RPG skill that connects IBM i to everything

Being AI-ready is more than learning AI tools.

Being AI-ready is not just about learning AI tools. It is about understanding how your applications and data connect to them.

For RPG developers, that bridge is the API. It links IBM i applications, databases, cloud platforms, and AI-powered services into one working system.

Learning to consume and create APIs lets you extend the applications you already run and plug IBM i into the wider technology stack.

That is why API skills belong in every modern RPG developer’s toolkit, and in any serious IBM i modernization plan.

Know your options. “API” is not one thing. Three architectures are worth knowing: REST is the modern default, lightweight JSON over HTTP, simple to consume, and the style most cloud and AI services expect. SOAP is the older, formal option, XML with strict contracts and built-in security, still common in finance and legacy integrations. GraphQL is the newer approach, where the client asks for exactly the data it needs in a single request, which cuts over-fetching on complex data.

New to APIs: start with REST. It is the easiest to read, the easiest to test, and the one most AI services expect.

For the RPG veteran: IBM i already speaks these. Integrated Web Services has handled REST and SOAP for years, and GraphQL rides your open-source stack. The skill is the multiplier, not the platform.

Want to go deeper? There is a self-paced course built for IBM i developers that runs from REST through security, and touches SOAP and GraphQL. Check out an introduction to APIs.

🔗 Know IBM i and this, and you close the gap

The most valuable IBM i pro knows one more thing.

The most valuable IBM i pro is not just the one who knows the platform cold. It is the one who also knows how to connect it to everything else.

That is the idea behind NAViGATE, COMMON’s deep IBM i program running inside IBM TechXchange, October 26 to 29 in Atlanta. One registration gets you both.

The IBM i sessions cover eight tracks:

Database, Security, High Availability, the ground you live on. Then the one that matters most right now: Technologies Integrated with IBM i. AI strategy, and bringing non-i tools into an i-focused system.

Learn that, and you are the person who closes the gap.

New to IBM i: start here to see the whole platform at once, with labs led by IBM experts and certification testing on site.

For the veteran: you have the depth. Spend your time in the integration and AI tracks. That is the edge.

Register through COMMON and save. The COMMON rate is $995, which is $284 under IBM’s price, no membership required. Register here.

Modernization

🔀 The COBOL-to-Go trap you plan for first

A pragmatic COBOL migration target, with one big catch.

COBOL shops weighing a move off the language have a new target to consider: Go.

The pitch is pragmatic. Go compiles to a single binary with no runtime, and its concurrency maps neatly onto the batch jobs that dominate COBOL.

But the guide earns its click with one sharp warning. Go has no native decimal type. COBOL’s packed-decimal money fields default to floating point, which quietly breaks financial math unless you drop in a decimal library.

Our Take: Be honest about the framing. This is written for mainframe COBOL shops, CICS, VSAM, z/OS, not IBM i. But the language decision is the same one a COBOL-on-i shop faces, and the decimal trap applies on any platform.

Did You Know?

💡 Did You Know: IBM i is probably in the path when you use an ATM

Pull cash from an ATM overseas, get a card issued, or send money across a border, and there is a real chance IBM i sits somewhere in that transaction.

Euronet Software Solutions, the software arm of a payments company present in more than 200 countries, built one of the most widely deployed electronic payment platforms ever to run on IBM i, powering card issuing, ATM management, and transaction switching for banks worldwide.

You never see it. That is the point. Quiet, high-volume, always-on work is exactly what the platform was built for. Which is another way of saying it is not going anywhere.

Join

Contact us

If you are an RPG programmer looking to explore opportunities or a client who is looking for a talented IBM i professional, please contact us. We look forward to assisting you.

Do you know of someone who could benefit from Talsco Weekly? If so, please use the social media buttons to spread the word. Thank you!

Talsco Weekly: The IBM i skill that has nothing to do with code