Mohammad Khan writes: >My reasons for not using a transaction manager are....
You've listed three arguments. The first argument is that *you* won't be using all the features a major transaction manager offers. To which I'd reply that almost nobody uses all those features for any particular, single program. There is, however, one very important reason you have at this instant: resource management across both DB2 and MQ. A number of transaction managers on z/OS do that very, very well, and you have essentially nothing extra to do to enjoy that benefit except run in the transaction manager. There are other reasons for transaction managers that wouldn't be immediately apparent to you but that are very important to their users. Examples include common application portfolio management (installation, maintenance, lifecycle considerations, etc.), common monitoring procedures, common automation, common security, common problem determination, less overhead (ironically), common I/O and integration paths, and several other considerations. All transaction managers provide some level of isolation between the application environment and underlying subsystems, and that's helpful, too. The second reason you gave isn't a reason. It's just a restatement of your currently desired implementation path. The third reason you gave is that one of the transaction managers you tried didn't seem to work out for some reason. My guess is that somebody was charging the full cost of the entire transaction manager against your one program. That's not how most organizations run their transaction managers. They typically have scores, hundreds, or thousands of programs running in one or a very few instances of their transaction manager(s), and the incremental cost of each program can be lower than spinning up yet another JVM and address space (or spaces), for example. So how about investigating one of the other transaction managers then? CICS Transaction Server, for example? Yes, you can write your own custom code that leverages z/OS Resource Recovery Services (RRS) -- somebody already pointed that out. That also puts you on the path to writing a small, custom transaction manager that others may not find so fabulous. :-) That helps explain why not too many people go into that business. There are already several fabulous, highly evolved transaction managers. You could take a look at the MQ RRS Batch Adapter and see if that path would meet your needs: http://pic.dhe.ibm.com/infocenter/wmqv7/v7r1/topic/com.ibm.mq.doc/fg15140_.htm Or have you looked at using a Java stored procedure in DB2? -------------------------------------------------------------------------------------------------------- Timothy Sipples VCT Architect Executive (Based in Singapore) E-Mail: sipp...@sg.ibm.com ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
