I am writing a C program in Unix System Services on a z/OS mainframe. One of the requirements is to get a sequence number from a DB2 database residing on the same mainframe. Not having DB2 Connect available, I'm wondering what my options might be. I can open a socket on port 50000 (the default DB2 port), but, from the IBM documentation I can locate, I am unclear about the rest of the process in this environment.
I have UNIX and DB2 in my background, but I'm just getting my feet wet in the z/OS world, so I'm trying to keep this as straightforward and maintainable as possible.
There is a specific section for ODBC access to DB2/z in the DB2/z 9.1 docs over on publib. Publib should always be the first point of call for any IBM doco.
There's also the DB2/z ODBC PDF.
This is the best way to access DB2/z from C on OE/OMVS/USS (or whatever it's called nowadays). If it was Java, I could probably help out more. The online help was invaluable in getting JREs to talk to the mainframe DB2 (from both USS and PCs) with minimal hassling of our local sysprogs. Of course, it'll be a lot easier with them :-) especially for setting up the z/OS (non-USS) side of things.
Why not use a unix ODBC driver to connect to the database and use the ODBC's sql dialect...it's easy to do...in that way with ODBC the flexibility is there for future maintainability, say switch to a different database provider...see here for an example C code that interacts via ODBC
For C++ I can recommend OTL template library to simplify ODBC interaction. It works with IBM C++ and DB2 for z/OS. Can be used on different platforms.
Link:
Oracle, ODBC and DB2-CLI Template Library
Related
If I have my own DBMS and am developing to ODBC software interface, what would I be working on?
making sure that one can access data from any database through my DBMS, OR
making sure that every database can access data from my database
I did not exactly understand this from the Wikipedia page.
In general, ODBC is the "catchall" driver, meant to work with a wide variety of databases at a basic (lowest common denominator) level. A wide variety of software contains ODBC drivers, so supporting ODBC means providing support for a wide variety of software.
In actual practice, it is more common now to use native drivers for Oracle, SQL Server, etc. ODBC is generally used only when there is no other alternative available.
If you're developing a DBMS I would expect that 'developing to ODBC software interface' means you're creating an ODBC driver. That driver allows applications to query your database, even if they don't know about your particular DBMS. If you like applications such as Excel to use your DBMS, provide an ODBC driver.
I suppose your DBMS could act as a "client" and use another DBMS' ODBC interface to get data or schema information, that doesn't sound like a typical DBMS feature.
The Microsoft link in the Wikipedia article is a bit clearer in my opinion, MSDN has details in you're really interested in developing a driver or a client.
I like the simplicity of SQLite, but by design, it doesn't support concurrent access. The apps I write don't have heavy needs, so I'd like to avoid heavier solutions like MySQL that are more difficult to deploy (remote customers with usually no computer personnel).
Does someone know of a good solution that would offer the following features?
Client available for VB.Net applications
The server itself doesn't have to be a .Net application. Actually, I'd rather a bare-metal server so that it can run even on embedded Linux hosts with less RAM/CPU than regular PC's
Easy install: the client part should either be statically linked inside the client application or be available as a single DLL, and the server should just be a single EXE listening for queries, à la Fossil (http://www.fossil-scm.org)
clients can locate the server on the LAN by broadcasting data picked up by the server, so users don't have to write down the IP address and paste it into each client
open-source, or moderately priced closed-source
I would recommend Firebird SQL http://www.firebirdsql.org
Can be embedded and can work as a separate server. Very little footprint with high capabilities.
Have you considered SQL Server? It scales well from Compact Edition (free, file based), through Express Edition (again, free, but requires installation) and then through the paid-for editions for when your product needs to scale further.
HSQLDB is also very leightweight, and the upcoming 2.0 release supports concurrency in form of MVCC. It is based on Java though, but there is an ODBC connector available.
You may also consider Derby... Its free and open source.
Is there any way (possibly cheap) to access Microsoft Sql Server from z/OS mainframe (COBOL programs) and have the result in 3270 terminal emulation?
I'm aware that 3270 is a pretty old system, but in bank CED, is still very popular.
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.
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
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.
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
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.
You might be able to do something I did in the past. I have written DB2 to MS-SQL COBOL programs/functions that make the MS-SQL table/view SELECT only to DB2. It involved creating a running service on a network server that would accept TCP/IP connections only from the mainframe and use the credentials passed as the user ID/PW used to access the MS-SQL table. It would then issue a select against the table/view and pass the field names list back first with the total number of rows. It would then pass each row, as tab delimited fields, back to the mainframe. The COBOL program would save the field names in a table to be used to determine which routine to use to translate each MS-SQL field to DB2. From the DB2 point of view, it looks like a function that returns fields. We have about 30 of these running. I had to create a MS-SQL describe procedure to help create the initial defines of the field transations for the COBOL program. Also had to create a COBOL program to read the describe data and create the linkage and procedure division commands. One COBOL program for each MS-SQL table/view.
Here is a sample function definition.
CREATE FUNCTION
TCL.BALANCING_RECON(VARCHAR(4000))
RETURNS
TABLE(
SCOMPANY CHAR(6),
PNOTENO VARCHAR(14),
PUNIT CHAR(3),
LATEFEES DEC(11,2),
FASB_4110 DEC(11,2),
FASB_4111 DEC(11,2),
USERAMOUNT1 DEC(11,2),
USERAMOUNT2 DEC(11,2),
USERFIELD1 VARCHAR(14)
)
LANGUAGE COBOL
CONTINUE AFTER FAILURE
NOT DETERMINISTIC
READS SQL DATA
EXTERNAL NAME DB2TCL02
COLLID DB2TCL02
PARAMETER STYLE SQL
CALLED ON NULL INPUT
NO EXTERNAL ACTION
DISALLOW PARALLEL
SCRATCHPAD 8000
ASUTIME LIMIT 100
STAY RESIDENT YES
PROGRAM TYPE SUB
WLM ENVIRONMENT DB2TWLM
SECURITY DB2
DBINFO
; COMMIT;
GRANT EXECUTE ON FUNCTION TCL.BALANCING_RECON TO PUBLIC;
To call the function:
SELECT * FROM
TABLE (TCL.BALANCING_RECON(''
)) AS X;
You would put any MS-SQL filter commands between the quotes.
I've not been asked to update any MS-SQL data so I've not jumpped that hurdle yet.
There is also a database in DB2 that keeps track of the ID/PW and server that has the started task running. This is so if the server becomes overloaded, different selects can be pushed to different servers. Response is quick, even for large tables. Timeout is the same as the 60 deadlock timeout. The transport is primarly IP based. DB2 simly sees the data as an external table reference.
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.
In my company, we use Java for connect to Sql Server.
And a CL call this Java program :)
Very simple...
I found this question here: OLEDB v/s ODBC
Which gave me more information, but did not really answer the question I'm asking, so I shall proceed from there.
I am working in C#. I'll spare you the long story about how I arrived at this conundrum, but basically I'm trying to decide between ODBC and oleDB.
We work with a lot of different clients who have vastly varied Databases (some SQL, some oracle, some something else that I've never heard of and didn't bother to remember the name of)
Now, from what I understand, ODBC is old, and was/is the standard. And now OleDB has come along and... is... different? but accomplishes the same thing (it talks to databases)
Why would I want to use one over the other? ODBC is (according to the above post) cross-platform, which is good, but he offers very little information as to what OleDB offers that ODBC does not.
In my other research, I've found (on the MSDN forums) People saying "use OleDB if you can, if you have to, resort to ODBC" Naturally, three's no reasoning given for this, so I'd like to hear some.
ODBC is a C API for accessing databases. There is a standard for it, it is supported by every major database vendor, it is very well documented, it is cross-platform. OLEDB is a similar interface that uses Microsoft's COM technology instead of the C API. This means that it is only easily useable on platforms that support COM.
At the end of the day, both libraries provide roughly equivalent basic functionality. Indeed, Some OLEDB drivers actually make use of ODBC rather than native database libraries.
So, if you are C# developer, working on Windows, OLEDB is the obvious choice between the two. If you are using C (or C++ not using COM), or need cross-platform support, then ODBC is the better bet.
As a C# developer and because you are accessing many different datasources you should go with OLEDB. I copied the following from this white paper because it gives some hints what to use when:
OLE DB is Not a Replacement for ODBC
The ODBC technology and third-party market have matured to a point at which ODBC is an ideal technology for accessing SQL databases. As a result, an integral part of OLE DB is a new OLE DB driver manager that enables OLE DB consumers to talk to ODBC providers. The following information can guide your choice of which technology to use:
If you are accessing standard relational databases from a non-OLE environment, ODBC is the best choice.
If you want to expose a data interface to non-SQL data, OLE DB is the best choice.
If you are programming in an OLE environment, OLE DB is the best choice.
If want to build interoperable database components, OLE DB is the only choice.
If you're programming in C#, you will not directly use either one. You'll use ADO.NET in some form.
True, the provider that you specify in your connection string may turn out to be an ODBC provider or an OleDB provider, but this will not matter to your code. ADO.NET will both APIs from your view.
We have a system written in C and running under Solaris & Linux that uses the Sybase CT-library to access a Sybase database.
We generate the table-definitions, indexes, stored procedures and C-code from an in-house developed DDL to reduce the amount of work and errors.
We would like to achieve database independence, so we can add (as a first start) Oracle support.
We're thinking about ODBC or ESQL/C, but having no experience with them.
What solution would you suggest (preferably a cheap and easy one, of course). Is it possible to have a single source solution?
I would highly recommend SQLAPI++ (with the downside, perhaps, that it is a C++ library). There is also unixODBC, though I have never used it in code -- only touched upon it while researching for portable database APIs. POCO also provides a uniform, portable API (though, again, in C++) for database operations, but last I checked it, that part of POCO was only in the initial stages of development.
ODBC will help you write a more portable system, but you will have to be careful to develop your SQL properly if you wish to leverage the underlying database, as the SQL itself may well not be 100% portable across databases, even with the different ODBC drivers.
iodbc
http://www.firstsql.com/iodbc/
or unix odbc
http://www.unixodbc.org/
Are probably among the "most portable" choices.
Regards
Friedrich
ODBC is going to give you far more portability options over ESQL/C.
I've been using iODBC to access SQL Server and mysql and have had pretty good results so far. I think it would work for Oracle as well, but that would depend on the ODBC driver and haven't had to try it so far.