On average, a software developer spends 30–50% of their working time testing program changes and performing conversion or modernization work.

And that doesn’t even include the working hours of the users, who usually have to test these changes as well.

By automating tests for any type of IBM i application—including legacy RPG and COBOL applications (RPG-II, RPG-III, etc.), you can not only reduce these costs by up to 86%, but also gain additional peace of mind, as the expertise of your developers and users can be incorporated into these tests, ensuring that it remains permanently documented and traceable for future generations.

Wouldn’t it be nice if, after making changes to a critical batch process, you could go to bed at night with peace of mind?

IBM Bob is making a lot of headlines, and many developers and decision-makers are asking themselves: When does IBM Bob make sense, and when doesn’t it? What should you keep in mind when using it? What are the costs involved? What data is processed, and where? What else is out there? What alternatives are available, and what do they look like? And so on.

In our online event “To Bob or Not to Bob,” we’ll address all these topics and questions.

My team and I attended the world’s largest IBM i event, Common PowerUp 26 in New Orleans, during the last week of April.
There, Bob & Co. was THE hot topic alongside Visual Studio Code for IBM i.

Find out firsthand what’s new with Bob.

The AI team at i and me has been working intensively for years with a wide variety of AI tools and areas of AI.

In doing so, we have already created numerous custom solutions, developed various tools, and tested numerous tools on the market.