Skip to main content

Navigating DevOps on IBM z/OS

Develop an effective package management strategy to streamilne DevOps

Develop an effective package management strategy to streamilne DevOps

Software development on the IBM Z® platform has drastically improved since the programming pioneers of the 1960s and 70s, but release times for new versions are still too long. The delay is largely due to a reliance on the outdated waterfall methodology of development, which is characterized by a linear approach where each development phase depends on the completion of the prior phase.

DevOps is an enterprise software development phrase used to define an Agile relationship between development teams and IT operations. DevOps is based on the idea of incremental and iterative development, in which phases within a development lifecycle are revisited repeatedly. This process enforces quicker application development with improved quality.

The process may consist of just one module or one application with many modules or even multiple applications. But only one developer can work on a single module at one time, whereas multiple developers will be involved when considering whole applications. For this approach to work, enterprise-wide communication, documentation and other processes must be agreed upon. 

DevOps on IBM Z and IBM Db2

In the IBM Db2® mainframe world, especially when utilizing change management systems, every module change with SQL also creates:

  • A new DBRM module
  • A new Db2 package version—BINDs are executed, even when the SQL was unchanged
  • Entries in Explain-type tables—when EXPLAIN(YES) was specified in the bind options
  • A new level of the changed application module into a specific level or stage LOAD library 

The new level or stage LOAD library will take on a set position within a concatenated list of LOAD libraries. This allows “testers” to execute the modules versioned for a set stage.

Development Questions

Several questions may come up when implementing Agile-based development methods, such as:

  • How do I know in which stage modules are still required?
  • In which LOAD libraries are they to be found?
  • Which packages or versions are really still required on the Db2 side?
  • How can I be sure I still have the correct DBRM member to match my package version and load module?

To answer these questions, developers must either start developing their own utilities or license powerful vendor utilities to secure an Agile way to be integrated in the DevOps cycles.

Navigating Package Concerns

It’s important to know which packages are needed and which are cluttering your database, affecting performance and availability. To navigate package concerns, build cross references of all module CSECTs and DBRM or package names. This is the initial task for checking which modules should be checked at all. LOAD and DBRM libraries can be located in various ways. The fastest is via z/OS® Catalog Search Interface (CSI) facilities.

These may be partitioned data set (PDS) or partitioned data set extended (PDSE) organized and require rapid processing, especially when the PDSE libraries hold tens of thousands of modules. IEWBUFF facilities can be utilized to de-block the load modules and then scan 24-, 31- and 64-bit applications to ensure consistency. Some modules, especially Java® technology-based ones, can be extremely large and require smart scanning routines.

Why Scan Packages and Modules? 

Why should we scan them and what are we looking for? The magic phrase is “consistency token” (CONTOKEN). At the very beginning of Db2, this was simply an 8-byte character string representing a timestamp similar value. It could be searched for within the application module, which was an easy way to match packages to modules. Unfortunately, today, there are various ways of storing CONTOKENs, and linking packages to corresponding modules is not so easy.

So why check at all? Here’s why:

Application Integrity and Cost

When migrating an application’s set of modules into productive systems, DBRMs and load modules are involved. If they don’t match, the application will not function in your production system. Depending on the frequency of execution and importance of this application, the out times could cause considerable cost.

The lower the number of package versions found in your catalog, the easier you can steer your Db2 and reorganize vital parts of the catalog. This leads to faster Db2 utilities.

Performance Reasons and Cost

BIND execution times, affected by very large common Explain-type tables full of data no longer required compromise performance. The trick is to identify the correct data and keep it. Typically, one SQL statement, when explained, could produce between two and 200 rows, just in the associated PLAN_TABLE. When we consider all available Explain-type tables, one explained statement could result in inserting more than 1,000 lines in up to 25 different tables.

Resolving Concerns and Using Best Practices 

Reducing the size and scope of the Explain tables will help BIND steps use less CPU and improve elapse times and in turn, reduce cost.

Why BIND packages, when the SQL was unchanged? If it is because RUNSTATS values have changed, then explicit BINDs will also have the required effect and change the access path strategy as required by Db2. Saving superfluous BIND steps can return vital CPU capacities previously lost to “runaway” package management. 

When developing a package management strategy, implement the following best practices:

  1. Analyze and perform inconsistency checks on all CONTOKENs—regardless of whether it originates from the Db2 Catalog, a DBRM or within a LOADLIB module
  2. Locate all relevant LOADLIBs and DBRMs, building the base resources to check
  3. Resolve all specified LOADLIBs into module and related CSECT names, together with all BINDer timestamp information
  4. Resolve all DBRM modules and keep all header options for comparison reasons—identifying empty and invalid contents along the way
  5. Build cross reference data sets where package names or Plan-DBRM names match counter-parting LOADLIB and DBRM names
  6. Check inconsistencies and optionally build reports, FREE PACKAGE job input and set condition codes as required
  7. Include a cleanup utility to remove inconsistent or non-required entries in all PLAN_TABLEs and other Explain-type tables
  8. Regenerate DBRM member(s) from the catalog 
  9. Determine whether PACKAGE BINDs can be avoided or should be enforced when access paths improve

DevOps on the IBM Z platform is here. There are a lot of fast-moving pieces, but if you keep these nine things in mind when developing applications, you’ll thank yourself down the road for maintaining a cleaner database environment for better-performing applications. 



IBM Systems Webinar Icon

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