views:

465

answers:

6

I tagged this question "impossible" because after a lot of googling, i have not find any trace\reference to a possible answer. I'm asking if there is some way\dirtytrick (possibly cheap) to access Microsoft Sql Server from z/OS mainframe (COBOL programs) and have the result in 3270 terminal emulation; i know that 3270 is a pretty old system, but in bank CED, is still very popular.

+1  A: 

Not as such - 3270 emulators are connecting to an IBM mainframe. In order to get at data from a SQL server database on a mainframe, you would have to write a program running on the mainframe that reads data from the SQL server DB. This would require you to have driver software running on the mainframe. You might be able to find a third party that makes this type of thing, but it is likely to be quite expensive.

If you need to put together a report or something combining data from a mainframe system with external data sources it may be easier to get the data off the mainframe and do the integration elsewhere - perhaps some sort of data mart.

An alternative would be to extract thd data you want from the SQL Server database and upload it to the mainframe as a flat file for processing there.

ConcernedOfTunbridgeWells
Thanks, what we usually do is duplicate sql server tables on db2 keeping them synched through nightly batch jobs..or as you said, extract data from sql and db2 and process the integration elsewhere.I was just curious if there some way to avoid these techniques.
systempuntoout
+2  A: 

If you have 3270 terminal emulation, what terminals are you using? PC's?

One interesting hack is using a Cisco router to do on the fly 3270 to vanilla TCP conversion, and then writing a simple TCP proxy for your SQL Server procedures

TFD
Hi TFDYes, we are using PC's.Is that hack feasible in a bank production environment?Useless to say that connection with db2 has to keep working :) .
systempuntoout
YMMV but it has been used by a large commercial bank in production at least once to my knowledge. If you have PC, why not have them go direct to SQL?
TFD
The correct scenario is "mainframe connects to both db2\sql and integrates data for the clients".
systempuntoout
Yes, but that's not the question you asked. There are plenty of ways a mainframe can access SQL Server, there are simple CICS to OLEDB adapters for instance
TFD
Some banks are using transaction switches to migrate some transactions off the mainframe and onto PC server clusters. This is just an advanced form of the Cisco hack
TFD
I've corrected the question :).
systempuntoout
A: 

It depends on what you are actually trying to do. My reading of your question is that you want to have a mainframe based process access an SQL Server database, and then do something with the result, probably involving a 3270 terminal.

If you can use Unix System Services, you can compile a TDS library like FreeTDS and then use a C program to do what you want with the result. If you want to get more complex, you can run the connection from the native z/OS environment by compiling the code with IBM C, SAS C or Dignus C/C++. I can recommend Dignus and I have used it to build code that interacts with other languages on z/OS. The Dignus headers and runtime library have (from memory) some FreeBSD lineage which helps to simplify porting.

Using this approach you can get a load module that you can call from some other part of your system to do the work, you can link the code with other parts of your system, or you can just submit a job and get the output.

If you want to use Java, you can use something like jTDS and write Java code to do what you need. I haven't used Java on z/OS, so I can't offer specific advice there, but I have used jTDS on other platforms and I've been happy with the result.

Update:

You can export a C function as an entry point to a load module and then call that from Cobol. The C/C++ implementation needs to deal with Cobol data structures; they are well defined and predictable so that isn't a problem. Depending on how flexible you need things to be, you could compile the query into the C code and just have a function which executed a predefined query and had an interface for retrieving the result, or you could have something more complex where the query was provided from the Cobol program.

I have used this approach to provide API functions to Adabas/Natural developers and it worked well. The Dignus compiler has a mechanism for callers to provide a handle to a runtime library so that you can manage the lifetime of the C runtime environment from the calling program.

For a C/C++ developer, that should be fairly straightforward. If your developers are all Cobol developers, things could be a bit more tricky.

The gateway approach is possible, and I'm sure there are gateway products around, but I can't recommend one. I have seen crappy ones that I wouldn't recommend, but that doesn't mean that there isn't a good one somewhere.

For completeness, I'll mention the possibility of implementing the TDS protocol in Cobol. Sounds like cruel and usual punishment, though.

janm
Thanks for your answer.I have slightly modified the question because programs need to be coded in Cobol.Sorry if i've taken Cobol language for granted.
systempuntoout
No problem. You can call C/C++ from Cobol without problems; the calling conventions are well defined on z/Os.
janm
Good answer and cheap solution too; unluckily we don't have C\C++ developers.
systempuntoout
A: 

As dirty hacks go, have you thought about creating a simple HTTP or TCP server that returns a .csv of the table data that you need?

This means your client only needs a simple HTTP/TCP client to access the data rather than a database client library.

mythz
A: 

Here is a possiblity if you are writing COBOL programs that are running in CICS.

First, wrap your SQL Server database stored procedure with a web service wrapper. Look at devx.com article 28577 for an example.

After that, call your new SQL Server hosted web service using a CICS web service call.

Last use standard CICS BMS commands to present the data to the user.

Appliation Development for CICS Web Services

Chuck
A: 

Just get the JDBC driver to access the MS-SQL server. You can then subclass it and use it in your Cobol program and access the database just as if you were using it from Java.

Once you get your results, you can present them via regular BMS functions.

No dirty hacks or fancy networking tricks needed. With IBM Enterprise Cobol, you really can just create a Java class and use it as you would in the Java space.

Joe Zitzelberger