Initiating activity on Oracle, SQL Server, and other platforms from a CA IDMS program or dialog.

book

Article ID: 52819

calendar_today

Updated On:

Products

CA IDMS CA IDMS - Database CA IDMS - ADS

Issue/Introduction

Description:

It is possible to initiate activity on Oracle, SQL Server, or another ODBC-or JDBC-compliant platform from within a CA IDMS program. This document describes the steps required to accomplish this.

Solution:

The basic mechanism to access another database from CA IDMS is using TCP/IP to pass JDBC- or ODBC-compliant SQL statements via that connection. Setting up the TCP/IP line, pterms and lterms are documented in the CA IDMS System Generation manual. However, there is no way to initiate a task on another platform from within IDMS, so this will work only if you have tasks or programs (sometimes called listeners or web services) waiting on the desired platform to receive any communications that may come from IDMS.

Once the TCP/IP line has been defined, the next step is to test issuing calls over the TCP/IP interface from a CA IDMS program or dialog to access data on another database. To do that you will need to issue socket calls from with the program or dialog. In COBOL, this is basically a CALL 'IDMSOCKI' USING... The specific syntax and parms are documented in the r16 CA IDMS Release Summary, section 9.4.3. If a dialog is being used, the documentation for the comparable ADS syntax is in section 9.4.2 of that reference. The calls will require specific structures in the linkage section and procedure division 'using' (which are documented in these sections) along with specific function codes, which are documented in appendix G of this manual.

Many sites initially define TCP/IP lines and are already accepting SQL statements against a CA IDMS database from other platforms, before they proceed to this step of trying to issue TCP/IP socket calls from CA IDMS to access another platform. In that situation, we recommend a pilot or proof of concept application be developed to ensure all the pieces are correctly defined and communicating as the first step in a development effort. If CA IDMS programs already exist with socket calls, then you'll just be expanding the particular functions used by the programs.

The socket calls can also be issued from Assembler & PL/I. There are sample programs written in COBOL, Assembler, and PL/I, and dialogs written in ADS, in the IDMS Callable Services manual, all of which issue socket calls. The examples are for a generic 'listener' program and a TCP/IP client program for each language. Neither has the precise types of socket calls needed to initiate communication with another platform, but they can still be used as a basis for writing programs to issue socket calls to other platforms. Copies of these are also provided as members in your DISTSRC library.

The specific content of the socket call must be tailored to the application designated to receive it. If the communication does not seem to reach the waiting application, obtain a TCP/IP trace. If the trace indicates that no failure was apparent from the TCP/IP side, this means that the connection to the web service went through without error, as did the SEND operation. If no data was received in response to the send, this probably means the packet was malformed from the application's perspective. CA IDMS has no way to determine what a particular web service or listening application is expecting.

In this situation, you should check with the author of this service or receiving application. If it's a home-grown client-written service, then the author should know how to code communications to successfully invoke it. If it's a service provided by a software vendor, then the vendor should provide documentation on the protocol need to communicate with it.

Environment

Release:
Component: IDMS