Steve, your testing is backed up by the manuals. For distributed platforms: If an application disconnects (MQDISC) while a global unit of work is still active, the unit of work is committed. If, however, the application terminates without disconnecting, the unit of work is rolled back as the application is deemed to have terminated abnormally.
You also asked: "If so, can anyone think of any reasons why the MQGET might not be > rolled back when the application ends." Yes, on Z/os it would be different. >From the App Prog Guide: Except on z/OS batch with RRS, if a program issues the MQDISC call while there are uncommitted requests, an implicit syncpoint occurs. If the program ends abnormally, an implicit backout occurs. On z/OS, an implicit syncpoint occurs if the program ends normally without first calling MQDISC. . . . If a CICS application issues the MQDISC call, no implicit syncpoint is taken. If the application closes down normally, any open queues are closed and an implicit commit occurs. If the application closes down abnormally, any open queues are closed and an implicit backout occurs. -----Original Message----- From: Paul Clarke [mailto:[EMAIL PROTECTED] Sent: Friday, June 11, 2004 8:53 AM To: [EMAIL PROTECTED] Subject: Re: MQ Rollback Steve, In general I would always suggest that applications explicitly issue MQBACK or MQCMIT call since there are slight differences in behaviour on different platforms. However, what you say is true. An MQDISC will implicitly commit the transaction if possible. It is described in the Usage Notes of the Application Programming Reference, a. If the application issues the MQDISC call before ending: For a queue-manager-coordinated unit of work, the queue manager issues the MQCMIT call on behalf of the application. The unit of work is committed if possible, and backed out if not. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley MQSeries List <[EMAIL PROTECTED]> wrote on 11/06/2004 11:08:29: > A client has a problem where his MQ application is failing but he > says the MQ updates are not rolling back. I'm sure he's got > something wrong in his code but before I berate him I just want to > confirm my understanding and ask if there are any known issues. > > If an application (WIN2K) gets a message using MQGMO_SYNCPOINT and > then issues a MQDISC (but no preceding MQCMIT) the MQGET is > committed. If on the other hand it just ends normally but does not > issue a MQCMIT or MQDISC) the MQGET is rolled back. > > I've tried this using the API Exerciser in First Steps and it seems > to confirm this. > > 1) Is this correct ? > 2) If the Win2K application runs as a Windows service does it still > work the same ? > > If so, can anyone think of any reasons why the MQGET might not be > rolled back when the application ends. > > TIA > > Steve. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
