You are currently on IBM Systems Media’s archival website. Click here to view our new website.

Bookmark and Share

Recent Posts

Supporting Remote Procedure Calls

November 11, 2013

Editor’s note: This is the third blog entry in a series.

In my previous posts on middleware, I wrote that the Job Entry Subsystem was an early middleware engine whose productivity shell was Job Control Language. I also wrote that CICS and IMS were great early middleware models. These systems contain the foundation for the elements that came later to support client-serving (CS) computing like remote procedure calls (RPC) and many other functions. This is what I will cover in this blog entry.

The RPC is used to invoke a program in another system and that program returns control when it completes. RPC, a well-known CS function, is an extension to the traditional procedure call.

CICS, for example, has a robust PC function and remote system support developed quickly like the distributed program link (DPL). The DPL function makes it possible for an application program running in one CICS region to link to another application program running in a remote CICS region. To compliment DPL, CICS also has transaction routing (enables a terminal in one CICS system to run a transaction in another CICS system), function shipping (permits your application program to access resources in another CICS system), asynchronous processing (helps a CICS transaction to start another transaction in a remote system and optionally pass data to it), distributed transaction processing (supports a CICS transaction to communicate with a transaction running in another system), and the external CICS interface (enables a non-CICS program running in MVS to allocate and open sessions to a CICS system, and to issue DPL requests on these sessions).

Remote database access is used when the application database is on its own server or virtual machine and requests to retrieve data are sent from the application server to the database server. It sounds simple. SQL text can be passed from one server to another then executed. This is the typical early CS implementation. Another way to do this is to have location details stored in the database schema. DB2 uses the CATALOG command to store database location and access information.

Distributed transaction processing was developed to handle situations where CS applications were used to meet more challenging processing requirements involving database updates and multiple coordinated units of work. This approach to transaction processing often requires the use of protocols like SNA LU6.2 and Open DTP’s XA protocol to help the skilled programmer ensure that updates are handled properly.

Message queuing can be used to mask the complexity of different operating environments being employed within the same application. Programs can store data in queues to be used by different programs in the application or the data in queue can be used to trigger new transactions or programs.

Can you comment and add some others to round out my description? If you were picking the top four CS functions, would they be the ones I picked?

These functions supported various CS architectures. I plan to write about them in my next blog entry and discuss them in the context as extensions to enterprise models.

Posted November 11, 2013| Permalink