0

I am trying to expose Mainframe files for more dynamic use from both COBOL programs and external programs in Java.

My reading shows that I can configure COBOL to use a JDBC connection. This may be just configuration in the JCL but I assume it is more of a preprocess.

I also found the JzOS libraries will give access to the VSAM datastores themselves from JAVA.

So technically I think this is possible but could not find a single post on it. I know this is getting to be an edge case but I like the idea that Calcite will expose these as standard JDBC object.

Thoughts ? Issues ? Concerns ?

Mr-H
  • 21
  • 1
  • What do you mean by "more dynamic use" of mainframe files? Are "external programs written in Java" running on some non-mainframe platform? Where are you reading you can "configure COBOL to use a JDBC connection"? – cschneid Dec 12 '17 at 15:19
  • Java programs are running off the Mainframe, and I know we could expose the CRUD operations as WS or REST services but the JDBC model has an appeal too. – Mr-H Dec 12 '17 at 15:45
  • The more dynamic part is that we/I want to make a replication process that sends updates to RDBMS and CLOUD data stores back to the VSAM files with many tables, object stores, going to many VSAM files (mapped but still a lot of them). – Mr-H Dec 12 '17 at 15:47
  • If your VSAM files are really simple, don't forget that z/OS has an NFS Server that can make files available to a wide range of other platforms. Also, there are several vendors with "VSAM transparency" over databases, and most of these will give you your choice of VSAM, SQL and JDBC access to the same data...we did a project over CA's Datacom database like this and it worked quite well - legacy apps used the VSAM transparency, new mainframe apps used SQL, and remote apps used JDBC. There are plenty of other databases that can do this too. – Valerie R Dec 21 '17 at 19:33

2 Answers2

1

Please understand there is a big difference between...

  • what is technically possible
  • what is allowed in your shop
  • what is likely to provide a robust and maintainable solution given your requirements

These are three very different things. Some of us have life experiences that make us reticent about answering questions regarding what is technically possible absent any mention of what is allowed in your shop or what the actual business requirement is that is being solved.

Mainframes have been around for over half a century, and many shops have standard solutions to technical problems. Sometimes the solution is "don't do that, and here's what we do instead." Working against the recommendations of your technical staff, or your shop standards, is career limiting.

Okay, boilerplate out of the way.

VSAM is not a DBMS. It has some of the characteristics of a DBMS but it isn't one itself.

The sharing requirements may give you a headache. VSAM files are defined with a SHAREOPTIONS parameter indicating how many processes can simultaneously read and write. Keep in mind that defining these liberally means each application must control serialization of writes and all applications are collectively responsible for data integrity.

Consider that applications will be written outside your control and knowledge by people who do not understand there are other applications reading/writing from/to these VSAM datasets.

I would approach this by providing access via a web service. Not simple CRUD, but business-specific functions SOA-style. CICS is your friend.

Consider using a DBMS on the mainframe instead of VSAM files.

Please try to avoid the inner-platform effect.

Also, this Q&A may be of interest.

cschneid
  • 10,237
  • 1
  • 28
  • 39
  • Well yo uare quickly getting to the root of the problem (which I appreciate). My goal is to move the VSAM datasets into a DBMS but there are so many of them, and they are so intertwined that I don't have the liberty of moving all related connections in one shot. My plan is to move the "Write" and then one way replicate back to the VSAM read-only datasets for a period of time. If I can't find a way to semi-dynamically replicate back to the VSAM files then I am only left with having the "Write" programs update both and then revisit them again later. I really don't like this as an option. – Mr-H Dec 12 '17 at 16:34
  • I'm not familiar with mainframe environments, but I am familiar with Calcite (I'm the original author). @mr-h I don't think your instincts are too far off base. VSAM is not a DBMS, but Calcite can make files look like a DBMS. Therefore, rather than writing COBOL logic to extract from the files, you can write SQL queries. One caveat is that Calcite's file adapter doesn't handle VSAM files - you'd have to add that support. – Julian Hyde Dec 14 '17 at 01:30
  • @JulianHyde That "Calcite can make files look like a DBMS" is known, that "VSAM is not a DBMS" is an important consideration. In order to make such a design work, serious analysis of available SHAREOPTIONS must be done. My contention is that, in order for the VSAM files to be shared so that the system functions as intended, an unacceptable risk to data integrity will be taken. That Calcite can make access to the VSAM files easier is not in question. The question is how to provide access to the VSAM files in a manner preserving data integrity. – cschneid Dec 14 '17 at 13:59
0

Rocket Software have a data virtualization product that exposes flat files, VSAM, IMS data bases via JDBC. IIRC, you can also access mainframe data sources using the MongoDB wire protcol. I think you can use it free and have to pay for support but that may only be when using it with Apache Spark on z/OS.

David Crayford
  • 571
  • 1
  • 3
  • 10