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.
views:
465answers:
6Not 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.
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
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.
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.
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.
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.