webMethods EntireX
API enablement of COBOL programs is easy with EntireX. Learn how EntireX helps you as an IT-professional to salvage those COBOL treasures without having to install any EntireX components on the mainframe. Read on to see an overview of the possible zero footprint scenarios with EntireX 10.3.
By Jürgen Lind, Director, Product Management, Adabas & Natural, and
Bernhard Fricke, Senior Software Specialist, EntireX Development, Software AG
Scenario
Imagine you are running business-critical COBOL applications on a backend system like IBM® z/OS®, z/VSE® or AS/400®. At the same time the rest of the world is talking about digital economies, API enablement and API management, whileREST interfaces are the architectural choice of today.
With EntireX you can easily merge the world of COBOL and the REST-driven API economy.
Yet how can you do that without increasing impact on the mainframe or backend system?
How can you avoid additional organizational costs?
How can you save time for installation and configuration on the backend system?
The answer is Zero backend footprint integration. Read how EntireX helps you as an IT-professional to exploit your COBOL resources without any additional installation on your backend systems.
Zero footprint API enablement
The following illustration (Fig. 1) gives an overview of zero footprint scenarios which EntireX supports for various host systems. As you can see, nothing is installed on the backend host system – all processing is done off-host. The component involved at runtime is the webMethods Integration server with the EntireX Adapter installed therein.
Fig. 1: Calling COBOL from a REST client with zero backend footprint
Developing this scenario with EntireX is easy when following these 3 phases: 1 extract the server interface of the COBOL Server; 2 generate IS Service, IS Connection and optionally REST resources; 3 Test IS Service or REST client to COBOL (Fig.1).
Preparing your backend system for zero footprint
To use zero footprint, you need to prepare your backend system. Make sure the following components are set-up:
- For CICS®: CICS and the CICS ECI port
- For IMS™: IMS MPP online system and IMS Connect
- For AS/400®: IBM i Host Integration Server
For detailed information on how to prepare the backend systems for zero footprint, please refer to Components and Features of EntireX > EntireX Adapter in the EntireX documentation:
Fig. 2: EntireX Documentation EntireX Adapter
Zero footprint with arbitrary RPC Clients
A typical architecture for accessing COBOL with zero footprint from environments other than webMethods Integration Server consists of: RPC client, EntireX Broker, and RPC Server. To develop the scenario, use the following steps: 1 extract the COBOL server; 2 generate an RPC client with an EntireX Wrapper e.g. Java, C#, DCOM, etc.; 3 to test, use the appropriate EntireX RPC Server: CICS ECI, IMS Connect or AS/400 (Fig 3.).
Fig. 3: Calling COBOL from arbitrary RPC clients with zero backend footprint
For detailed information on the RPC Server used in zero footprint scenarios, please refer to Components and Features of EntireX > RPC Server and Listener in the EntireX documentation; for EntireX Wrappers, see Developer Tools > Software AG Designer > Scope respectively.
Fig. 4 EntireX Documentation: RPC Servers, RPC Listeners and EntireX Wrappers
So in summary…
EntireX is the right product for you if your backend is being administered by a different organizational unit or a third-party company. It allows you to call COBOL with zero footprint on the backend. This means no EntireX component whatsoever is installed on the system where the COBOL programs are executed. Once configured, zero footprint also means no further maintenance.
On top of that, as most of the processing is done off-host, zero footprint with EntireX helps with keeping your backend costs to a minimum.
With EntireX, zero backend footprint is available for AS/400, z/VSE and z/OS – including CICS and IMS.
Glossary of terms
*CICS * – IBM's mainframe transaction container
*DFHCOMMAREA * – classic parameter area used by CICS programs, data length limited to 32K bytes
*CICS ECI * – Call DFHCOMMAREA CICS programs via TCP/IP from outside CICS;
*IMS * – Another IBM mainframe transaction system including a hierarchical database
*IMS Connect * – On-host application enabling connections to IMS via TCP/IP
*AS/400 * - IBM midrange computer system; also known as iSeries, System i
*IBMi * – Operating system for AS/400; also known as OS/400, I5/OS
*On-host * – backend system like z/OS
*Off-host processing * – workload on a non-backend system like Windows or UNIX
Related articles
- “Mainframe Integration made easy”. TECHniques, April 2016 (Issue 2).
- “How to call webMethods Integration Server from COBOL – mainframe outbound”. TECHniques, October 2016 (Issue 4).
- “How to call COBOL from webMethods Integration Server”. TECHniques, April 2017 (Issue 2).
- “How to shape a call to COBOL from webMethods Integration Server – the modern way”. TECHniques, January 2018 (Issue 1).
- “How to call COBOL on IBMi(AS/400) from Integration Server“. TECHniques, July 2018 (Issue 3).
- “Publish your mainframe assets as REST Resources”. TECHniques, October 2018 (Issue 4).
- “EntireX for CICS® Socket Listener - Integration with minimal mainframe footprint”. TECHniques, April 2019 (Issue 2).
Top comments (0)