IBM

IBM's Information Management System, or IMS, is a high-speed database and transaction manager used on mainframe computers. Originally built in the 1960s for the Apollo moon landing to track rocket parts, it helps large banks, airlines, and retailers handle millions of quick daily tasks safely.

IMS remains the backbone of some of the world's most critical systems: powering 72% of Fortune Global 500 banks, processing up to 100,000 transactions per second, and maintaining 99.9999999% availability (just 30 milliseconds of downtime per year)!

When you install a new version of your Mac or iPhone software, you usually just download it from Apple's servers and it installs automatically. IVP, or Installation Verification Program, is the enterprise equivalent: it makes sure a new install is configured correctly and ready to use.

It runs a series of checks to verify that a new IMS system (i.e. a database) is configured properly and functioning as expected. This program has looked and worked the same since the start of IMS over 60 years ago. As part of the modernization of the whole platform's software, my team and I worked on giving IVP a brand new UI.

Below is a look at some of the "green screen" interfaces; the screens IVP used before the redesign. They are text-based, monospace, and rely on cryptic keyboard commands rather than modern UI conventions.

We started by mapping the flow of IVP. As you can see, even this setup process alone – before the actual IMS database system is involved – is quite complicated.

IVP runs in four phases:

• Initialization: select initial parameters
• Variable Gathering: define variables and settings
• File Tailoring: place the variables into jobs
• Execution: run the jobs

This structure is a holdover from a decades-old process, a direct reflection of the legacy of IBM's mainframe software.

To better understand how IVP worked, and to familiarize ourselves with the process, we dissected each screen, state, and panel the terminal could render, then rebuilt each one as a modern 1:1 equivalent using proper UI components and Carbon (IBM's design system).

The second part of my internship was revamping this lengthy installation process from the ground up. Coming in as an intern with no prior history with IVP – but with the knowledge from Part 1 – turned out to be an advantage: we could bring a fresh approach to a decades-old system.

Another team had been building a tool called Configuration as Code: a YAML file that holds every parameter an IMS system needs to import. It became the middleware that let us glue the pieces together.

What does the YAML file look like?

A YAML file (YAML Ain't Markup Language) is a plain-text format that uses indentation and key-value pairs to encode data.

For example:

• imsid: IMS1 (line 5) is a setting: the variable imsid is assigned the value IMS1.
• - member_name: DFSPB001 (line 17) is an array item: the - marks it as one entry in a list, and the parameters indented beneath it belong to that specific item

# -*- coding: utf-8 -*-# (c) Copyright IBM Corp. 2025 vars:  imsid: IMS1  ims_hlq: IMSTESTL.IMS1ims:  ims_id: "{{ vars.imsid }}"  ims_sys_hlq: IMSV15  ims_hlq: "{{ vars.ims_hlq }}"  ims_type: DB/DC  ims_unit: SYSALLDA  ims_target_user: IBMUSER   ims_proclib:    members:      - member_name: DFSPB001        config:          dynamic_terminal_auto_logoff_time: 1440          aoi_buffer_pool_upper_limit: 2047M          aoi_type2_security_settings: false          : R          appc_enablement: false          appc_security_setting: F          ims_vtam_appl_id_for_rsr: APPL7          automatic_restart_manager_registration: false          dynamic_terminal_auto_signoff_time: 1440          automatic_restart: false          dedb_maximum_buffer_size: 0          coordinator_controller_convert_abend_on_cancel: false

Updated flow

Configuration as Code fundamentally changed how we approached IVP. Instead of guiding users through hundreds of inputs, the system now revolves around a single, reusable configuration YAML file. This leads to a shorter flow that starts with the YAML import/discovery, moves to editing the parameters, and ends with running the jobs – all in one place.

First, the user lands on the Configuration Center screen. From there, they can choose to create a new system, test an existing one, or if they really want to, go through the legacy IVP process instead. Once they hit "Create," there are 3 ways to do continue:

• Discover an existing IMS system and clone it
• Use an official IBM template to start from
• Upload their own configuration file

One of the last things I did was to identify usecases for integrating AI (from IBM's watsonx.ai) into the configuration flow. Here are a few examples:

AI configuration assistant

Users ask questions in natural language and receive contextual explanations without leaving the setup flow.

IVP is a genuinely complex system, and reading pages of documentation wasn't enough. Throughout the whole summer, regularly leaning on more experienced devs on the team was very helpful and also helped us see things from their point of view.

Another lesson that stuck with me: legacy behavior matters more than I expected, and trust from long-time IVP users takes real work to earn. During our three client calls, engineers were initially skeptical of trading their whole process for a new web interface. They were less resistant to the change itself and more concerned with how their day-to-day would be affected. We listened closely, and looking back, several of the concerns they raised became actual features in the final product.