Kind of like Jzos and DFSORT, Logger, console, datasets.. seems like exposing RRS would be kind of cool.. but is probably down on the list of things to do. Could always write a JNI wrapper(s) for some RRS calls and attempt to standardize it.
Hope the MQSEND does what you need. As a side note, the DB2 Type-4 driver does have XA support for a global transaction.. since v8-ish. Rob Schramm Rob Schramm Senior Systems Consultant Imperium Group On Thu, Apr 10, 2014 at 4:56 PM, Mohammad Khan <[email protected]> wrote: > 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 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
