Database Modernization Gets A Lift From Midrange Dynamics

October 7, 2014 Dan Burger

Modernization projects in the IBM midrange community are one of the most talked about business decisions that companies are facing. It’s been a difficult problem to solve and has stopped many companies in their tracks as they wrestle with new technologies, investment costs, risk, staffing, and skills. Application modernization has been in the spotlight, but database modernization is quickly gaining recognition. And underlying both aspects of modernization is change management software.

A recent announcement from CMS vendor Midrange Dynamics is an indicator or how the modernization process is possibly evolving to take database modernization into consideration. Its latest enhancements are focused on removing obstacles that have put the brakes on SQL-based database modernization projects.

With Version 7.2 of its MDCMS, Midrange Dynamics is building in capabilities that distinguish it from several of its competitors and from home-grown CMS deployed by many shops that run i on IBM Power Systems.

“Although we have supported SQL development for years, SQL functionality goes even further in V7.2,” says Midrange Dynamics Managing Director Michael Morgan. “This is very helpful for IT teams who are implementing SQL-based functions so they can keep their applications relevant and meet evolving business requirements with ease.”

The inability to easily deploy from a test database environment to a production database environment has stymied companies, some of which are operating without change management and others with change management that do not have this type of capability. The time is right for addressing this issue, Morgan figures. The company is seeing and hearing from IBM i customers that have modernization on their minds. Midrange Dynamics CMS automates application deployment in multi-platform environments as well.

Updated functionality in Version 7.2 includes complete cross-referencing and management of SQL databases and expanded IFS source handling, among other changes.

With MDCMS Version 7.2, developers can cross-reference SQL entities that exist across databases such as constraints, functions, indexes, materialized query tables, procedures, sequences, tables, triggers, and views. It also has the capabilities to use SQL schema naming and to filter and display objects by SQL name or SQL type, as well as to filter and display fields by SQL column name. Source statements used to create the entities, if they exist, can be pulled up from source members or the IFS.

What this means is that developers can use SQL naming rather than system naming. MDCMS handles this internally.

The benefit is that the companies can continue to use old programs while the modernization takes place. There’s no need to recompile programs that are relying on the DDS files. MDCMS generates new DDL-based tables and then creates a logical file over the new DDL tables with the same name as the old physical file. The new logical file has the same records on it. This avoids the negative impact on legacy programs and it allows new programs to go up against the new SQL tables and views and indexes.

“You can have your source reside in IFS or in source members. The source can have a different name than the object, and you can share source across objects. The same source can be used to create multiple objects of different names,” Morgan says.

In short, it reduces the time to deployment and, more importantly, it reduces the risk of application disruption.

The fear of high-risk deployments are a big reason database modernization projects in the planning stages are being on hold. Morgan says MDCMS now reduces that risk and many of the time-related costs that had to be factored into these projects.

“The database modernization tool vendors make the modernization easier to do. The change management makes it easier to deploy. This avoids the step of companies having to re-engineer all their programs to modernize, which adds to the time and risk,” Morgan says.

Expanded data mapping in Version 7.2 supports ongoing modernization efforts for DB2 for i databases. For example, during a database modernization project, the IT team needs to map the data from the old DDS physical file to the new SQL table. With Version 7.2, when developers are working with a physical file or SQL table they can configure the contents to be copied into the modified format of a file.

“This happens automatically as part of the data migration in MDCMS. There are no special steps, post-compile commands, or custom coding (macros) required. You can control–by using an individual file–whether you apply triggers, constraints, etc.,” Morgan explains.

The ease of deployment attribute also takes into account organizations using Subversion (SVN) to manage team source repositories.

MDCMS deployments of changes or deletions can be accomplished from the SVN perspective in Eclipse. This includes tags or a range of trunk revisions. Additionally, if an earlier revision of a file is currently requested in MDCMS, and then updated in SVN, the MDCMS request (or even entire folder structures) can be refreshed.

Also adding the convenience is a customizable escalation process for locked objects.

“Added visibility and automated management of object locks allows for escalated notification and/or rollbacks of unsupervised deployments,” Morgan says. “This ensures organizations can avoid unnecessary surprises the following morning.”

MDCMS can be used with any Eclipse-based development platform, which means it fits with Rational Developer for i and handles deployment in mixed server environments.

As the IBM i community takes a closer look at the modernization picture, Morgan believes change management software will be a major consideration. There are still companies with no change management software and those that do have CMS are often handicapped by limited capabilities, complex software, and the misconception that they are locked in to products that have not evolved.

With that in mind, Midrange Dynamics has taken aim at SoftLanding TurnOver users by offering an automated TurnOver migration product that maps TurnOver projects, tasks, subtasks, promotion requests, historical object deployment information, archived source code, and active checkouts into MDCMS. Morgan claims the product also automatically migrates TurnOver create command overrides for active and historical object requests. It is designed so that migrations can be tested and rolled back with no risk to existing applications.