I'm not expecting JZOS to have any such capabilities, it does what it set out to do and does it well. I only mentioned it describe my program environment. What I do expect is that a programming platform would allow a programmer to make use of the facilities / features that the platform offers e.g. the system can perform I/O, a program should be able to request it or RRS can coordinate two phase commit between different resource managers, a program should be able to use that capability. What I expected from my question was something like "you can do that by doing this and that, see such and such manuals for details" or "java does not offer a way to do this however it can be done in assembler, refer to ..." or "you can't do that unless you get a license and sign an NDA" or "that's ibm's secret sauce and no one is allowed to touch it" or "you don't know what you are talking about, first read up on ... to reduce your ignorance" and I'd have been thankful for it. I consider it perfectly fine for someone to suggest an alternative solution / architecture and reasons for their preference. But to insist on such suggestions after I have expressed my lack of interest in them is pretty odd and I did not expect it. No matter what merits these other alternatives have they have one demerit which overrides them all - being unwanted. And just for the record neither I nor my employer sell any software so the reference to lock in is totally irrelevant. As for substandard code I do admit to writing it, in fact I have written quite a lot of it but remember with all the people writing such code one of them once in a while comes up with something better than the official quality code. And just for that reason I'm a strong supporter of "right to write substandard code" :) By the way a little more digging around did uncover a solution - a db2 function (MQSEND) that writes to a MQ queue where db2 leverages RRS to coordinate commit and rollback. And you don't have to have a transaction manager to use it, even a lowly batch program can do so.
Mohammad On Thu, 10 Apr 2014 06:42:10 -0500, John McKown <[email protected]> wrote: >I don't want to put words in Mohammad's mouth, but from what I gather, he >simply would like JZOS itself to have RRS capabilities. But that is _not_ >what it is designed to do. JZOS, to my limited understanding, is designed >as a way to easily run Java programs in a batch job. Wanting RRS >capabilities in JZOS would be similar to being upset that Language >Environment does not come with RRS capabilities built in. > > >On Thu, Apr 10, 2014 at 1:15 AM, Peter Ondruška <[email protected]> wrote: > >> :-) actually, Mohammad, you have received answers to make your (work) life >> easier (and deliver results); in the end it is your decision which way to >> go. >> >> >> On 10 April 2014 06:19, Timothy Sipples <[email protected]> wrote: >> >> > Mohammad Khan writes: >> > >Nice argument and something not unexpected of a salesman. >> > >> > Now it's (inaccurate) ad hominem attacks? Gee, thanks. >> > >> > How about debating the merits of the arguments instead of (inaccurately) >> > attacking the messenger? The merits are considerable. I'm not the only >> one >> > who recommended a transaction manager in this very same discussion. In my >> > experience users are getting increasingly frustrated with software >> > developers writing (usually substandard) code to replicate existing >> > functions well implemented in popular, standard application environments. >> > Not every problem ought to be solved as a programming exercise. Unless >> > perhaps a software vendor is trying to sell a lifetime of customer >> > dependency on their uniquely implemented code and associated maintenance >> > services. (Aren't ad hominem attacks fun?) >> > >> > Even so, after providing that important context, I directly answered your >> > questions with two candidates for non-transaction manager solution >> > approaches. A simple thank you is optional but would be appropriate in >> the >> > circumstances, in my view. >> > >> > >> > >> -------------------------------------------------------------------------------------------------------- >> > Timothy Sipples >> > VCT Architect Executive (Based in Singapore) >> > E-Mail: [email protected] >> > ---------------------------------------------------------------------- >> > For IBM-MAIN subscribe / signoff / archive access instructions, >> > send email to [email protected] with the message: INFO IBM-MAIN >> > >> >> >> >> -- >> S pozdravem * Mit freundlichen Grüßen * Sincerely, >> >> Peter Ondruška >> Česká spořitelna, a.s. >> >> CEN 8650_04, tým řešitelské centrum pro Operations >> Antala Staška 32/1292, Praha 4, 140 00 >> mobile: +420 724 500 286 >> mailto: [email protected] >> http://www.csas.cz >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO IBM-MAIN >> > > > >-- >There is nothing more pleasant than traveling and meeting new people! >Genghis Khan > >Maranatha! <>< >John McKown > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
