One thing that should be mentioned off the bat is that Oracle has "stabilized" their z/OS database offerings at version 10.2. Oracle on other platforms are at version 11.
You may ask, well why does it matter since we'll be running Oracle on Linux, not z/OS. But that's not entirely true. You still need a client on z/OS to communicate with the server on Linux. I know of two options for doing this. First option: Use Oracle for z/OS client (again, stabilized at version 10.2). We have spoken with Oracle about this and it appears there should be no problems using the 10.2 client on z/OS to communicate with a version 11 server. Any features that would require a version 11 client will not work. Additionally, as Oracle upgrades their server to new versions I couldn't get any guarantees that the version 10.2 client would still be supported for connection to those higher level servers. I imagine that you would also have to recompile all z/OS programs using the Oracle precompiler (Pro*COBOL et al). Second option: Use IBM InfoSphere Federation Server. In this case you would continue to run DB2 for z/OS. You would use DRDA to connect to a Federation Server running on Linux (or UNIX or Windows for that matter). Federation Server would, in turn, connect to your Oracle databases. In this case you would possibly not have to recompile everything, though probably some things. You could, I imagine, continue to use all of your DB2 z/OS tools. With DB2 in the middle I would guess that there would be some functionality that you would lose if it was not supported by Federation Server. I guess a third option would be if your applications were Java you could continue to use JDBC for your client, just using the Oracle JDBC driver instead of the DB2 JDBC driver. In this case I think you would not need either DB2 itself or the regular (non-Java) Oracle client. We are in fact headed toward option 2. Currently we are a VSE shop that uses DB2 on VSE as a client to communication with a DB2 server/Federation Server running on Linux. Currently most of the tables we access from the mainframe are in DB2 itself (on Linux), but we are migrating those tables to Oracle databases and using the Federation Server (which runs "inside" of the DB2 server on Linux) to access them. So far only two tables have been moved, but things are going fine. For us the main reason for going the Oracle route is that all of our J2EE and Windows applications that have been developed over the last 15 years already use Oracle, so the databases are already there. On the other hand there is now DB2/LUW 9.7 which supports lots of Oracle features to encourage migration from Oracle to DB2. I personally am rather interested in this, if only to take out the extra "hop" (Fed Server to Oracle). But since we are a relatively large Oracle shop I'm not sure migration to DB2 really makes sense. Anyway, those are my thoughts. I would love to hear lots of discussion on this topic! Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation Lakewood, CO USA P: 303-235-1403 F: 303-235-2075 On 7/8/2009 at 7:49 AM, in message <blu149-w50516d7912c8f37bac9e08a1...@phx.gbl>, Dave Salt <ds...@hotmail.com> wrote: > A friend of mine develops applications using COBOL and DB2. To save money, > management at his company is considering converting DB2 to Oracle. My friend > is neither for or against the idea, but has some concerns about how this > might affect him. I know nothing about Oracle or z/Linux, so I thought I'd > pass his questions on and see if anyone on this list might be able to help > him: > > 1) Has anyone ever gone through this, and if so did it actually save money? > > 2) Would z/Linux have to be used for application development, and if so how > steep is the learning curve for someone who is used to using ISPF? > > 3) Do existing COBOL/DB2 programs need to be re-compiled; e.g. do any of the > SQL statements have to be changed? > > 4) Would his personal JCL and Spufi libraries need to be converted? For > example, if he has JCL that unloads records from a DB2 table, would he have > to modify it to extract the same records from an Oracle table? > > 5) If conversion is required (whether it be for SQL in COBOL or for Spufi > libraries or JCL libraries etc), are there any vendor tools that can help > with the conversion? > > 6) Would different vendor tools be required for things like editing Oracle > tables versus DB2 tables, and if so do most of the major vendors have tools > available that are comparable to their DB2 tools? > > 7) Any there any tips/tricks/gotchas that anyone might want to pass along? > > Thanks in advance, > > Dave Salt > SimpList(tm) - try it; you'll get it! > http://www.mackinney.com/products/SIM/simplist.htm > > > _________________________________________________________________ > Attention all humans. We are your photos. Free us. > http://go.microsoft.com/?linkid=9666046 > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html >>> The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html