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

BY

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.

Related posts:

12th Annual Mainframe Survey Results


The BMC annual mainframe survey is a key indicator of the future health and viability of the mainframe—and this year’s report busts 5 common myths about the platform.

Download Now ›

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

Share This Post


Jeremy Hamilton

Jeremy Hamilton

Jeremy Hamilton is a technical Software Consultant for BMC’s Mainframe Cost Optimization Suite (R4). He has over 9 years’ experience in the software industry, primarily in the technical sales role. He started his career as a physicist for IBM Research before moving into the mainframe software world. At IBM he worked with many large corporations and government agencies, and wrote three IBM Redbooks regarding the IBM Application Development Tools. In his current role, he works with various customers to educate, consult, and implement the R4 solutions, as well as drive enhancements for the products. Jeremy has a Masters in Information Systems from Santa Clara University, and an American Indian Science and Engineering Society (AISES) Sequoyah Fellow.