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.
These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.