0 Replies Latest reply on May 16, 2017 1:33 PM by Donald Zeunert

    A Free Way to Reduce Mainframe MLC costs when Your Peak Occurs in a Batch Window

    Donald Zeunert

      A Free Way to Reduce Mainframe MLC
      costs when Your Peak Occurs in a Batch Window

       

      MLC Cost Reduction –
      Time is Money

      For many z/OS shops, CPC 4HRA peaks are driven by
      the batch workload. BMC’s Intelligent Capping is a good option to reduce MSUs
      & MLC costs. However, when capping, there are times when the workload cannot
      complete in time to meet your SLAs. If the duration of batch work can be
      shortened, then capping becomes an option. There are many good ways to reduce
      batch window duration, including by using MainView Batch Optimizer or BMC’s faster
      database utilities. In this blog, however, I’ll describe a great built-in z/OS function
      that can help you reduce your batch window.

       

      The Bigger You Are,
      the Harder MSUs Fall

      Did you know? z/OS data centers that run many
      LPARs can improve production batch job throughput by using enhancements that
      were added to z/OS version 2.2 (October, 2015). If your mainframe MLC bill is
      being driven by a batch peak, or you have other batch window issues, these enhancements
      may be of interest to you. 

       

      Some of the JES2 MAS performance improvements in
      z/OS 2.2 are automatic; others require manual enablement.  If you still run z/OS 2.1, potential MLC
      savings might be a reason to consider speeding up the migration.

       

      Job Throughput Improvements

      Both z/OS enhancements help you accomplish higher
      job throughput by reducing delays from JES2 MAS (Multi-Access Spool) checkpoint
      contention, in the following ways:

      • Reduced Job Delays
      • Reduced throughput delays

       

      Reduced Job Delays
      from JES2 Spool

      Recent processor speed increases make it easier
      for batch jobs to exceed the pool of spool space that each LPAR allocated
      between checkpoints.  IBM recognized this
      issue and increased the amount of spool space that was acquired by each LPAR by
      300% in JES2 (z/OS 2.2). Each LPAR now allocates 1024 spool track groups into a
      local pool (BLOB) for jobs to use between checkpoint ownership. Numerous LPARs
      in the JESplex or slower Coupling Facility (long distance links) cause this to
      be a greater issue.

       

      Reduced Throughput
      Delays via JES2 Checkpoint Auto Tuning

      Even if you have spent time manually tuning your
      JES2 checkpoint parameters, you will probably benefit from this new optional
      functionality. The feature can dynamically tune the HOLD and DORMANCY values based
      on the current environment, providing better throughput than current static
      values.  This new feature, checkpoint
      auto tuning, is turned OFF by default. You can dynamically enable or disable it
      with console commands after all LPARs in the MAS are running at the z/OS 2.2
      level.