Mainframe Blog

The Subsystem Service Model Brings Agility, Efficiency, and Costs Savings to the Mainframe

Jeremy Hamilton
by Jeremy Hamilton
2 minute read

For the computing world, the term “service” has taken on many different forms. Service Orientated Architecture, Software as a Service, and many others have changed the way we view the computer world. In its simplest form, creating a computing service is simply decoupling service consumers from service providers. The service providers and consumers can be housed in disparate systems which are specifically set up to gain cost and performance advantages for their respective function. Single consumers can call upon multiple providers and vice versa to deliver exceptional service levels and cost savings. The Subsystem Service Model now makes this possible on the mainframe!

Example of Service Consumer and Service Provider 1-to-1, and 1-to-many relationships.

The flexibility, agility, and efficacies of a “service oriented” approach have not been realized on the mainframe itself. Often viewed as only a “black box” service provider, most “service” approaches simply “interface” or “wrap” the mainframe computing functions for use by distributed applications.

However, within mainframe LPARs, subsystems are working together with the service consumer and service provider relationship. The service consuming subsystems being the transaction handlers like MQ, CICS, and/or IMS; and service providing subsystems database managers Db2 or IMS which satisfy the data requests made by the transactions. Traditionally, subsystems which call upon one another were collocated on the same LPAR.

Example mainframe environment: 2 LPARs, CICS and Db2 on each.

The Subsystem Service Model extends the “service oriented” approach into mainframe architecture by separating of the transaction manager subsystem (TM) from the database manager subsystem (DB). Transactions coming in from the outside world will process normally through CICS A or CICS B located on LPAR C. BMC’s Subsystem Optimizer will intercept the database calls from CICS, and use XCF communication to route the calls over to a remote a LPAR where corresponding DB2 is running. DB2 would then fulfill the request, and BMC Subsystem Optimizer routes the response back to CICS completing the transaction. No application changes are required for the data request routing so the end user (internal or external) is unaware of the change.

Read more about the Subsystem Service Model in the white paper.

Annual BMC Mainframe Survey

The 13th Annual BMC Mainframe Survey is a key indicator of the future health and viability of the mainframe. See how mainframe attitudes, technologies, and practices are evolving in the digital era.
Download Now ›

These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.

See an error or have a suggestion? Please let us know by emailing

About the author

Jeremy Hamilton

Jeremy Hamilton

Jeremy Hamilton is the Senior Product Manager for BMC’s Mainframe Cost Optimization Suite (R4). Joining BMC in 2013 as a IMS-focused Software Consultant, he then transitioned to the R4 team. In his current role, he sets the strategy and direction for the R4 solution portfolio. His passion is to deliver solutions that solve real-world problems and provide quantifiable value to customers. Jeremy has a Masters in Information Systems from Santa Clara University, and over 10 years of experience in the mainframe world. He is an American Indian Science and Engineering Society (AISES) Sequoyah Fellow, and has written three IBM Redbooks regarding the IBM Mainframe Application Development Tools.