On Tue, 8 Apr 2014 09:10:06 +0800, Timothy Sipples <sipp...@sg.ibm.com> wrote:
> >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. Nice argument and something not unexpected of a salesman. > 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. And using an transaction manager is the one and only way to achieve this ? > >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. Now that's full blown sales talk ... keep in mind that I am not a (potential) buyer. > All transaction managers provide some level of isolation >between the application environment and underlying subsystems, and that's >helpful, too. A batch program running in its own address space is no less isolated from underlying subsystems than what transaction managers provide. > >The second reason you gave isn't a reason. It's just a restatement of your >currently desired implementation path. May be not for you, technically it is enough of a reason on its own regardless of any other considerations. > >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. So you do admit that these transaction managers do come with a cost and the cost is not insignificant by any definition of the word. Why then are you so adamant that alternative approaches must not be tried ? > 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. All this is based on your assumption while in the actual situation IBM was involved all along and didn't have much to say. > So how about investigating >one of the other transaction managers then? CICS Transaction Server, for >example? And you will have another suggestion ready when that doesn't work well either ? <snip> >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? I have found something else - a db2 function MQSEND, that seems to do the job. Mohammad ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
