Still yet another way to do this is something called "Oracle Access Manager for CICS." (Google that and you should find some references at oracle.com.) This is a piece of code that lets you write standard CICS programs in just about any programming language you wish and use standard EXEC SQL statements to get to Oracle.
That said, I saw the word "batch" in the original question, so I wanted to offer a possible caution. IBM's billing department will love you dearly if what you're trying to do is, first, move data from VSAM or DB2 z/OS to Oracle on another server, then access said data remotely, especially in a high intensity sort of way like batch. If you do something like that CICS and z/OS have to work much harder, because you've now stretched the path length for all your data access. You've also greatly complicated your disaster recovery, security, workload management, and other non-functional requirements fulfillment. It's always a good idea to examine data access locality effects on your workloads and make sure that, if possible, the data are stored in workload-appropriate places. (I do seem to recall one case a colleague looked at that estimated a threefold increase in CICS and z/OS capacity if a particular customer moved data from DB2 to Oracle in this manner, but obviously this depends on your particular workloads.) Sometimes you don't get the option to put data in the most "appropriate" places, but if you do get the choice that's a good thing. To complicate matters further, note that Oracle has versions for both z/OS and Linux on z, both of which offer varying shorter data access paths than, say, Oracle running on a separate UNIX or Windows server. Moreover, your Oracle licensing should be cross-platform and should include rights to those versions. All that said, in technical terms Oracle Access Manager for CICS apparently gets the job done just fine, but "architecture matters," so please do consider that as often as possible. And I'll toss in yet another couple possibilities: MQ (solo) or Message Broker (possibly without MQ in the path). The former should be pretty obvious. The latter path could be using the CICS Node available with Message Broker for z/OS and, to Oracle, the WebSphere Adapter for JDBC or Broker's in-build database adapter. (I'm not sure which would be "better.") This sort of ESB approach should be less about programming and more about flexible integration. Lots and lots of options. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [EMAIL PROTECTED] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
