2

We have developed an application which runs on the mainframe (z/OS), and it uses CAF, the Call Attach Facility, to talk to DB2/z for storing its data.

Those customers which already have DB2/z (and hence have to pay for it regardless) are not concerned, but there are others who want to use our application without incurring the expense of the database as well.

They have expressed a desire to have our product not use DB2/z, due to the expense. Under z/OS, the licence fees for DB2 are rather high and our application doesn't really need the insane levels of reliability that it provides.

So what they'd like us to do is to run DB2 under either zLinux (SLES/RHEL), or DB2/LUW on a machine totally separate from the mainframe. Or even, though this will probably be harder, in a non-IBM database.

We're looking for a hopefully-minimal-change solution to our code in achieving this. DB2 has all its federated stuff which will allow a program using DB2/z to seamlessly access data on an instance running elsewhere, but this still requires DB2/z and hence won't result in a cost reduction.

What would be the easiest way to shift all the data off the mainframe and allow us to remove the DB2/z dependency completely from our application?

paxdiablo
  • 854,327
  • 234
  • 1,573
  • 1,953
  • I was going to type all the new-user stuff about what types of questions can be asked here and what can't. Even if it were on-topic, it would depend on so many factors internal to your systems and the practices of your company that you'd be lucky to get an answer you didn't waste time on. Find a good Consultant. You have paying customers, I don't think there'll be a cheap way to ensure that they are happy, even if the result of the Consultancy is a low-cost implementation that can reliably make them happy. – Bill Woodger May 29 '14 at 06:10
  • Bill, I wanted to get a feel for the potential solutions before approaching anyone. And I'm not sure why you think this is a request for a tool, library or favourite off-site resource (assuming that's your close vote, of course) - it's a very specific programming question: CAF is very much to do with code and we're looking for a way to do the same thing, _within our program._ It may be that my wording was unclear, I'll try to clarify. – paxdiablo May 29 '14 at 06:34
  • Well, 'twas I. I couldn't select too broad and opinion and choose a product, so I picked one. Any one I had picked could be regarded as "wrong". I'm not a DB2 person, so maybe there is some way it is programming. You want a system running on multiple OSs. With minimal code changes. Possibly multiple database systems, at least different blends of DB2. There can be no useful short amount of code to show. You don't even know where else your Enterprise COBOL for z/OS programs with embedded sql will compile. "What do I use instead of CAF?". Answers could be useful to many, but doesn't mean on-topic – Bill Woodger May 29 '14 at 10:13
  • 1
    This is a question about coding techniques for abstracting the persistence layer in a z/OS application, thus I believe it to be on topic. Questions for OP: What programming language is your application written in; Do you supply your application as OCO? – cschneid May 29 '14 at 11:56
  • @cschneid, it's written in the proprietary PL/X, not dissimilar to PL/1, Pascal, C and those sort of languages. However, we can interface to LE and so on so I'm not sure that the language would matter that much (though I'm happy to provide it). It is shipped as OCO but we can make whatever changes are necessary before shipping, such as using exits and so on, if need be. I was rather hoping there'd be something simple like a "DB2 Connect for z/OS" which would be minimal cost, allowing apps on z to talk to other DB2 platforms (without DB2/z of course). I may be pushing a big rock uphill :-) – paxdiablo May 29 '14 at 12:07
  • I asked about language to see if anything would be precluded, it sounds like not. Unfortunately I know of no product to help you; I believe you are in roll-your-own territory. Would your customers be amenable to sqlite? A z/OS port is in file 897 on cbttape.org. – cschneid May 29 '14 at 22:41
  • How do you turn the SQL statements into executable code? All the DB accesses will be through SQL statements, does that give you an opportunity to pre-/post-/exit- process to provide @NealB's layer without disturbing the existing code? – Bill Woodger May 31 '14 at 10:54

2 Answers2

1

This isn't an answer, just a couple of ideas and observations.

One approach I can think of would be to tier your application into an I/O layer and an application layer. The application would run on Z/os and the I/O layer would run on whatever machine hosts the database. All data access would then be via remote procedure calls over TCP/IP or UDP. This would be a lot of work to set up and configure. Worse yet it may only be appropriate for read-only type operations because managing transaction ACID (Atomicity, Consistency, Isolation, Durability) properties becomes a real nightmare in the face of update operations.

As cschneid pointed out, you could try "rolling your own" database management system using open source; but that too would probably lead to more problems than it solves.

I think your observation about "pushing a big rock uphill" sums it up.

NealB
  • 16,670
  • 2
  • 39
  • 60
1

Building on @NealB's answer, another way to create the layers would be to have no SQL in your application layer, but to call subroutines to accomplish your I/O. You indicate you would be willing to create custom builds, so you could create a set of routines for commonly-asked-for persistence layers.

Call the "database connect" module, which for DB2 on z/OS would do the CAF calls, for DB2 on z/Linux would (say) establish an SSL connection to the DBMS. Maintain a structure in memory with a union of pointers to the necessary data structures to communicate with your DBMS of choice.

FWIW I've seen vendor code that does this, allowing the business logic to be independent of the DBMS implementation. Some shops use VSAM, others DB2, other IMS. The data model is messy, but, sometimes them's the breaks.

cschneid
  • 10,237
  • 1
  • 28
  • 39