Skip to main content

Introduction to the ICN Tool

Interface Change Notification (ICN) is an IBM internal tool and process used to notify product contacts about impending changes that might have adverse impacts on their products.

Different strips of blue paper of various shades in a row.

Interface Change Notification (ICN) is an IBM internal tool and process used to notify product contacts about impending changes that might have adverse impacts on their products. The ICN owner fills out an ICN template and submits it to the ICN administrator to be scheduled for review during a weekly meeting. During that meeting, the ICN is reviewed by the ICN review team and then approved for distribution to product contacts provided it meets strict criteria for approval. Once approved, the ICN administrator enters the completed ICN form into the tool manually and submits it for distribution to over 100 IBM z/OS® product groups. Each product contact would receive an email containing a link to an Impact Assessment and the ICN. The product contact would read this ICN and fill out the Impact Assessment according to the severity of the effect on their product. For example, if the ICN contains a change incompatible in nature, the product contact would determine if they rely on that change and would indicate that an APAR would be required and mark ‘Impacted’ on the assessment. If they are not impacted by an ICN, the product contact would mark the assessment as “Not Impacted.” This tool is used weekly by over 400 IBMers across the world and is integral to the z/OS development process. 

Journey to Modernization

When I took over the ICN process in 2017, it was immediately apparent that the old ICN tool relied on antiquated technology and would be a maintenance nightmare. The old ICN tool was a conglomeration of multiple Lotus Notes applications each managed by a different set of people which made enhancements and problem analysis especially difficult. After about a year of listening to user pain points and experiencing many myself I decided it was time for a change. 
   
Several of my colleagues and I came up with requirements to alleviate these pain points in a manner that allows the tool to be more flexible, maintainable, scalable, efficient and modern. We knew we from the start we wanted the new tool to be web-based and utilize frameworks that were popular in the industry and well documented online. One of the key facets of this modernization effort was taking advantage of Docker containers. Containers are a lightweight mechanism for packaging up the application and all of its dependencies and abstract it away from its environment. Containerizing the application made it portable and allowed us to easily deploy it in virtually any target environment whether it be in the cloud, in a private data center, or on our personal computers.   

Taking Advantage of zCX 

When deciding where to host our application, we came across a recently released solution on z/OS 2.4 called IBM z/OS Container Extensions (zCX). zCX is a content solution that allows users to deploy Linux® applications as Docker containers on z/OS as part of a z/OS workload. This is incredibly useful when developing applications that use tools which were designed to run on Linux or Linux-like environments. It enables users to access the Docker command line on a z/OS LPAR and performs similar to running docker in any other Linux setting. This is perfect for deploying REST applications, such as the ICN tool, which is packaged in separate Docker containers. We currently use four Docker containers that make up our application. One container runs Node.js and starts the actual server, another runs CouchDB for our production database, another CouchDB container based on the same image for our test database, and a container that acts as a Jenkins agent which enables our continuous integration pipeline. These containers are all based on the s390x/ubuntu:18.04 docker image.
       
 
Using specific Docker options, we can expose ports on these containers that enables them to interact with one another. REST API requests go to our Node server which then contacts the CouchDB database to access the stored information. In general, zCX is straightforward to work with. If you're familiar with the Docker CLI, application deployment should be a breeze. The only caveat is that you're working with s390x images. This means that if you already have existing Docker files that were used in an x86 environment, they will likely have to be altered so that they can run on s390x. Fortunately there is a GitHub repository [[LINK: https://github.com/linux-on-ibm-z/dockerfile-examples ]] that houses a good amount of already ported s390x Dockerfiles for popular tools. For us, getting set up on zCX was as easy as taking a Docker file, making some slight modifications to it, then running “Docker build” and “Docker run” commands.

Deploying Containerized Applications With zCX

Using Docker containers has enabled us to speed up the development time of new features and bug fixes for the ICN tool from weeks to days. Our continuous integration pipeline pulls our new code from git, runs our automated regression bucket, and deploys the updated application on the zCX server. zCX is great for anyone who wants to deploy a containerized application on an s390x system. It's simple, easy to use and doesn't require any extra steps when compared to a regular Docker environment. I would recommend it to anyone who has prior Docker experience, or someone who wants to learn Docker for the first time.
IBM Systems Webinar Icon

View upcoming and on-demand (IBM Z, IBM i, AIX, Power Systems) webinars.
Register now →