Mainframe Blog

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

Jeremy Hamilton
2 minute read
Jeremy Hamilton
image_pdfimage_print

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 14th Annual BMC Mainframe Survey 2019 reports optimistic trends about the mainframe’s role in emerging and established businesses.
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 blogs@bmc.com.

Run and Reinvent Your Business with BMC

BMC has unmatched experience in IT management, supporting 92 of the Forbes Global 100, and earning recognition as an ITSM Gartner Magic Quadrant Leader for six years running. Our solutions offer speed, agility, and efficiency to tackle business challenges in the areas of service management, automation, operations, and the mainframe. Learn more about BMC ›

About the author

Jeremy Hamilton

Jeremy Hamilton

Jeremy has over 12 years of mainframe technical experience, with 5 of those focusing specifically on Mainframe Cost Optimization. He has served as a technical resource, Product Manager, and now as a Product Account Executive at BMC Software. He regularly speaks on MLC topics for customers, at SHARE and in IBM Systems Magazine webinars.