Crossworlds MQConnector and data conversion
Hi, Iam using MQConnector to get messages from a queue and populate a BO. Message is put by an RPG pgm on AS/400 , contains a string data, zoned decimal and packed decimal. I get a number format exception. How does the data conversion happen with MQConnector? This is what the doc has to say The connector has no control of the character set (CCSID) or encoding attributes of data in MQMessages. Because data conversion is applied as the data is retrieved from or delivered to the message buffer, the connector relies upon the IBM MQSeries implementation of JMS to convert data (see the IBM MQSeries Java client library documentation). Accordingly, these conversions should be bi-directionally equivalent to those performed by the native MQSeries API using option MQGMO_CONVERT. The connector has no control over differences or failures in the conversion process. The connector can retrieve message data of any CCSID or encoding supported by MQSeries without additional modifications. To deliver a message of a specific CCSID or encoding, the output queue must be a fully-qualified URI and specify values for CCSID and encoding. The connector passes this information to MQSeries, which (via the JMS API) uses the information when encoding data for MQMessage delivery. Often, lack of support for CCSID and encoding can be resolved by downloading the most recent version of the IBM MQSeries Java client library from IBM s web site. If problems specific to CCSID and encoding persist, contact CrossWorlds Technical Support to discuss the possibility of using an alternate Java Virtual Machine to run the connector. Have you tried doing this , what is the version of java , MQ Classes for java required for this to work? Do you Yahoo!? The New Yahoo! Shopping - with improved product search
Putting MQRHF2 header using MQ Classes for Java
Hi , Is it possible to put MQRFH2 header using MQ classes for Java. Class ,MQMessage has properties and methds that only manipulate MQMD. Is it possible WITHOUT using MQ JMS. Thanks In Advance Do you Yahoo!? The New Yahoo! Shopping - with improved product search
Crossworlds MQConnector and data conversion
Hi, Iam using MQConnector to get messages from a queue and populate a BO. Message is put by an RPG pgm on AS/400 , contains a string data, zoned decimal and packed decimal. I get a number format exception. How does the data conversion happen with MQConnector? This is what the doc has to say The connector has no control of the character set (CCSID) or encoding attributes of data in MQMessages. Because data conversion is applied as the data is retrieved from or delivered to the message buffer, the connector relies upon the IBM MQSeries implementation of JMS to convert data (see the IBM MQSeries Java client library documentation). Accordingly, these conversions should be bi-directionally equivalent to those performed by the native MQSeries API using option MQGMO_CONVERT. The connector has no control over differences or failures in the conversion process. The connector can retrieve message data of any CCSID or encoding supported by MQSeries without additional modifications. To deliver a message of a specific CCSID or encoding, the output queue must be a fully-qualified URI and specify values for CCSID and encoding. The connector passes this information to MQSeries, which (via the JMS API) uses the information when encoding data for MQMessage delivery. Often, lack of support for CCSID and encoding can be resolved by downloading the most recent version of the IBM MQSeries Java client library from IBM s web site. If problems specific to CCSID and encoding persist, contact CrossWorlds Technical Support to discuss the possibility of using an alternate Java Virtual Machine to run the connector. Have you tried doing this , what is the version of java , MQ Classes for java required for this to work? Do you Yahoo!? The New Yahoo! Shopping - with improved product search
Dan Maslar/COR/PARKER is out of the office.
I will be out of the office starting 10/08/2003 and will not return until 10/14/2003. I will respond to your message when I return. - "PLEASE NOTE: The preceding information may be confidential or privileged. It only should be used or disseminated for the purpose of conducting business with Parker. If you are not an intended recipient, please notify the sender by replying to this message and then delete the information from your system. Thank you for your cooperation." 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
Re: SYNCPOINT behaviour
Oops, seems like I must go to the Bahamas this year instead of the conference but you must admit, for some of you it was also a learning experience and it did open up some of the "thinking cells", especially for those of you in the northern hemisphere nearing your winter sleep Thanks again for all the other insights around this topic as well. Francois van der Merwe Senior IT Specialist: IBM MQSeries Certified Specialist, Solutions Expert & Developer IBM, Cape Town, South Africa +27 (0)82 556 9467 / +27 (0)21 402 5597 [EMAIL PROTECTED] Stefan Sievert <[EMAIL PROTECTED]To: [EMAIL PROTECTED] TMAIL.COM> cc: Sent by: MQSeriesSubject: Re: SYNCPOINT behaviour List <[EMAIL PROTECTED] N.AC.AT> 08/10/2003 04:56 Please respond to MQSeries List Ha! Office Space what a gem (and one of my favorites)! Strongly recommended for everyone who hasn't seen it. I bet you can relate to it in some way or the other. I like the scene where they beat up the peripherals best... :-) Make sure that somebody has a camera to document the post-it ambush, I would love to see it! Sorry to digress ;-) >From: "Wyatt, T. Rob" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: SYNCPOINT behaviour >Date: Tue, 7 Oct 2003 15:36:23 -0500 > >I say we stock up on those new super-sticky Post-It Notes and ambush him at >the conference! >http://images.amazon.com/images/P/6305508550.01.LZZZ.jpg > >-- T.Rob > >-Original Message- >From: Robert Broderick [mailto:[EMAIL PROTECTED] >Sent: Tuesday, October 07, 2003 3:38 PM >To: [EMAIL PROTECTED] >Subject: Re: SYNCPOINT behaviour > > >Do we get him now Or wait till the conference??? > > >bee-oh-dubble-bee-dubble-egh > > > >From: Francois Van der Merwe1 <[EMAIL PROTECTED]> > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: Re: SYNCPOINT behaviour > >Date: Tue, 7 Oct 2003 17:42:07 +0200 > > > >Hi Everybody > >The original poster of this question again. Thanks for all the responses > >etc. From time to time I help our training guys out and then I give some > >of the MQ training classes. For one, it breaks my routine a little bit, >I > >learn to know my customers a little better and it gives me a chance to >see > >if there is anything new in the training manuals. And then sometimes I > >actually prepare for the class and even try out some of the new things. > > > >In the latest MQ15 (MQ Admin I) training manuals (dated June 2003) there > >was this "one liner" stating that you can get a syncpoint message from >the > >queue even before the commit only if done in the same UOW. Now I thought > >this was a mistake, so I whipped out my favourite C compiler and I >changed > >amqsput0 a little bit to emulate that behaviour. And I must admit I was > >VERY surprised to see that it works exactly like that. So, the message >was > >not available, but true, you can get it back in the same UOW. > > > >I was still a bit sceptical, so that is why I posted the question to the > >group, just to see what the rest of you are saying, and as usual the >group > >did not disappoint me! Great work guys! > > > >So I do not know if it was always like that or if it was never in the > >training manual or if I just did not give any attention to it but > >presto, I learned something new! > > > >Have fun! > > > >Francois van der Merwe > >Senior IT Specialist: IBM MQSeries Certified Specialist, Solutions Expert >& > >Developer > >IBM, Cape Town, South Africa > >+27 (0)82 556 9467 / +27 (0)21 402 5597 > >[EMAIL PROTECTED] > > > > > > > > > > Robert Broderick > > <[EMAIL PROTECTED]To: > >[EMAIL PROTECTED] > > OTMAIL.COM> cc: > > Sent by: MQSeries Subject: Re: SYNCPOINT > >behaviour > > List > > <[EMAIL PROTECTED] > > .AC.AT> > > > > > > 07/10/2003 13:08 > > Please respond to > > MQSeries List > > > > > > > > > >Yee of little faith! > > > > > > >From: John Scott <[EMAIL PROTECTED]> > > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > > >To: [EMAIL PROTECTED] > > >Subject: Re: SYNCPOINT behaviour > > >Date: Tue, 7 Oct 2003 08:53:46 - > > > > > >I'll come clean and admit that I had to knock up a quick combination of > > >amqsput/amqsget to find out the real answer... > > > > > >Regards > > >John Scott > > >IBM Certified Specialist - MQSeries > > >Argos Ltd > > > > > > > > >-Original Message- > > >From: Neil Casey [mailto:[EMAIL PROTECTED] > > >Sent: 07 October 2003 03:32 >
Re: SYNCPOINT behaviour
Ha! Office Space what a gem (and one of my favorites)! Strongly recommended for everyone who hasn't seen it. I bet you can relate to it in some way or the other. I like the scene where they beat up the peripherals best... :-) Make sure that somebody has a camera to document the post-it ambush, I would love to see it! Sorry to digress ;-) From: "Wyatt, T. Rob" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: SYNCPOINT behaviour Date: Tue, 7 Oct 2003 15:36:23 -0500 I say we stock up on those new super-sticky Post-It Notes and ambush him at the conference! http://images.amazon.com/images/P/6305508550.01.LZZZ.jpg -- T.Rob -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 07, 2003 3:38 PM To: [EMAIL PROTECTED] Subject: Re: SYNCPOINT behaviour Do we get him now Or wait till the conference??? bee-oh-dubble-bee-dubble-egh >From: Francois Van der Merwe1 <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: SYNCPOINT behaviour >Date: Tue, 7 Oct 2003 17:42:07 +0200 > >Hi Everybody >The original poster of this question again. Thanks for all the responses >etc. From time to time I help our training guys out and then I give some >of the MQ training classes. For one, it breaks my routine a little bit, I >learn to know my customers a little better and it gives me a chance to see >if there is anything new in the training manuals. And then sometimes I >actually prepare for the class and even try out some of the new things. > >In the latest MQ15 (MQ Admin I) training manuals (dated June 2003) there >was this "one liner" stating that you can get a syncpoint message from the >queue even before the commit only if done in the same UOW. Now I thought >this was a mistake, so I whipped out my favourite C compiler and I changed >amqsput0 a little bit to emulate that behaviour. And I must admit I was >VERY surprised to see that it works exactly like that. So, the message was >not available, but true, you can get it back in the same UOW. > >I was still a bit sceptical, so that is why I posted the question to the >group, just to see what the rest of you are saying, and as usual the group >did not disappoint me! Great work guys! > >So I do not know if it was always like that or if it was never in the >training manual or if I just did not give any attention to it but >presto, I learned something new! > >Have fun! > >Francois van der Merwe >Senior IT Specialist: IBM MQSeries Certified Specialist, Solutions Expert & >Developer >IBM, Cape Town, South Africa >+27 (0)82 556 9467 / +27 (0)21 402 5597 >[EMAIL PROTECTED] > > > > > Robert Broderick > <[EMAIL PROTECTED]To: >[EMAIL PROTECTED] > OTMAIL.COM> cc: > Sent by: MQSeries Subject: Re: SYNCPOINT >behaviour > List > <[EMAIL PROTECTED] > .AC.AT> > > > 07/10/2003 13:08 > Please respond to > MQSeries List > > > > >Yee of little faith! > > > >From: John Scott <[EMAIL PROTECTED]> > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: Re: SYNCPOINT behaviour > >Date: Tue, 7 Oct 2003 08:53:46 - > > > >I'll come clean and admit that I had to knock up a quick combination of > >amqsput/amqsget to find out the real answer... > > > >Regards > >John Scott > >IBM Certified Specialist - MQSeries > >Argos Ltd > > > > > >-Original Message- > >From: Neil Casey [mailto:[EMAIL PROTECTED] > >Sent: 07 October 2003 03:32 > >To: [EMAIL PROTECTED] > >Subject: Re: SYNCPOINT behaviour > > > > > >Hi Peter, > > > >your description matches my expectations (I replied earlier), but does >not > >match what Bobbee and John said. > > > >So, I fired up the MQ API excerciser to try it out. > > > >Sure enough, and to my complete surprise, the first MQGET (prior to the > >commit) is able to return the message. After the first commit the queue >is > >empty again because the message has already been removed. I could not >find > >anywhere in the manuals that describes this behaviour, but it is what MQ > >does. All the manual says is that a commit makes the message available to > >OTHER threads. I guess you could read into that that the message is >always > >available in its own thread. That turns out to be the case anyway. > > > >So the question was not as straightforward as I assumed, and produced an > >interesting learning experience, for me at least. > > > >Regards, > > > >Neil Casey. > > > > > >|-+--> > >| | "Potkay, Peter M | > >| | (PLC, IT)" | > >| | <[EMAIL PROTECTED]| > >| | RTFORD.COM>| > >| |
Re: Installing WMQ 5.2 on Solaris 8
IC35242 - Error message AMQ5615 occurred when trying to issue CRTMQM commands after installing CSD05. Its fixed in CSD 7. http://www-1.ibm.com/support/docview.wss?uid=swg1IY33347 Scott -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Antony Boggis Sent: Tuesday, October 07, 2003 9:06 PM To: [EMAIL PROTECTED] Subject: Installing WMQ 5.2 on Solaris 8 My sysadmin has installed the WMQ package on a Solaris box and has followed the prereqs in the "Getting Started" manual. The kernel params are more than sufficient: [from 'sysdef -i'] * * IPC Messages * 4096 max message size (MSGMAX) 4096 max bytes on queue (MSGMNB) 50 message queue identifiers (MSGMNI) 1024 system message headers (MSGTQL) * * IPC Semaphores * 1424 semaphore identifiers (SEMMNI) 32868 semaphores in system (SEMMNS) 16384 undo structures in system (SEMMNU) 100 max semaphores per id (SEMMSL) 128 max operations per semop call (SEMOPM) 600 max undo entries per process (SEMUME) 32767 semaphore maximum value (SEMVMX) 16384 adjust on exit max value (SEMAEM) * * IPC Shared Memory * 4294967295 max shared memory segment size (SHMMAX) 1 min shared memory segment size (SHMMIN) 1124 shared memory identifiers (SHMMNI) 2048 max attached shm segments per process (SHMSEG) * The user (and group) 'mqm' exist and the package was installed with no errors (NOT the DCE option). When running crtmqm, I get the following: The system could not load the module '/opt/mqm/lib/amqzfu' for the installable service 'AuthorizationService' component 'MQSeries.UNIX.auth.service'. The system return code was 536895861. The Queue Manager is continuing without this component. MQSeries queue manager created. Setup completed. AMQ5615: Default objects cannot be created: CompCode = 2 Reason = 2035. As far as I can tell, the config on this machine (in terms of directories, sym-links and file/group ownership) is identical. For completeness, here's the AMQERRO1.LOG: # cat AMQERR01.LOG 10/07/03 04:44:55 PM AMQ5008: An essential MQSeries process 23837 cannot be found and is assumed to be terminated. EXPLANATION: 1) A user has inadvertently terminated the process. 2) The system is low on resources. Some operating systems terminate processes to free resources. If your system is low on resources, it is possible it has terminated the process so that a new process can be created. ACTION: MQSeries will stop all MQSeries processes. Inform your systems administrator. When the problem is rectified MQSeries can be restarted. --- 10/07/03 04:44:55 PM AMQ6184: An internal MQSeries error has occurred on queue manager TEST. EXPLANATION: An error has been detected, and the MQSeries error recording routine has been called. The failing process is process 23834. ACTION: Use the standard facilities supplied with your system to record the problem identifier, and to save the generated output files. Contact your IBM support center. Do not discard these files until the problem has been resolved. --- 10/07/03 04:44:55 PM AMQ5008: An essential MQSeries process 23837 cannot be found and is assumed to be terminated. EXPLANATION: 1) A user has inadvertently terminated the process. 2) The system is low on resources. Some operating systems terminate processes to free resources. If your system is low on resources, it is possible it has terminated the process so that a new process can be created. ACTION: MQSeries will stop all MQSeries processes. Inform your systems administrator. When the problem is rectified MQSeries can be restarted. --- and some of the generated FDC file: # more AMQ23834.0.FDC +--- --+ | | | MQSeries First Failure Symptom Report | | = | | | | Date/Time :- Tuesday October 07 16:44:55 PDT 2003 | | Host Name :- vdpsusftdf01 (SunOS 5.8) | | PIDS :- 5765B75 | | LVLS :- 520 | | Product Long Name :- MQSeries for Sun Solaris 2 (Sparc) | | Vendor:- IBM | | Probe Id :- ZX005025 | | Application Name :- MQM | | Component :- zxcProcessChildren | | Build Date:- Dec 11 2002 | | CMVC level:- p520-CSD06G | | Build Type:- IKAP - (Production) | | UserID:- 1002 (aboggis) | | Program Name :- amqzxma0_nd | | Process :- 00023834 | | Thread:- 0001 | | QueueManager :- TEST | | Major Errorcode :- zrcX_PROCESS_MISSING | | Minor Errorcode :- OK | | Probe Type:- MSGAMQ5008 | | Probe Severity:- 2 | | Probe Description :- AMQ5008: An essential MQSeries process 23837 cannot be | | found and is assumed to be terminated. |
Re: Installing WMQ 5.2 on Solaris 8
When you run crtmqm, did you doing it with su - mqm? Por favor, responda a MQSeries List <[EMAIL PROTECTED]> Enviado por: MQSeries List <[EMAIL PROTECTED]> Destinatarios: [EMAIL PROTECTED] CC: Asunto: Installing WMQ 5.2 on Solaris 8 Clasificación: My sysadmin has installed the WMQ package on a Solaris box and has followed the prereqs in the "Getting Started" manual. The kernel params are more than sufficient: [from 'sysdef -i'] * * IPC Messages * 4096 max message size (MSGMAX) 4096 max bytes on queue (MSGMNB) 50 message queue identifiers (MSGMNI) 1024 system message headers (MSGTQL) * * IPC Semaphores * 1424 semaphore identifiers (SEMMNI) 32868 semaphores in system (SEMMNS) 16384 undo structures in system (SEMMNU) 100 max semaphores per id (SEMMSL) 128 max operations per semop call (SEMOPM) 600 max undo entries per process (SEMUME) 32767 semaphore maximum value (SEMVMX) 16384 adjust on exit max value (SEMAEM) * * IPC Shared Memory * 4294967295 max shared memory segment size (SHMMAX) 1 min shared memory segment size (SHMMIN) 1124 shared memory identifiers (SHMMNI) 2048 max attached shm segments per process (SHMSEG) * The user (and group) 'mqm' exist and the package was installed with no errors (NOT the DCE option). When running crtmqm, I get the following: The system could not load the module '/opt/mqm/lib/amqzfu' for the installable service 'AuthorizationService' component 'MQSeries.UNIX.auth.service'. The system return code was 536895861. The Queue Manager is continuing without this component. MQSeries queue manager created. Setup completed. AMQ5615: Default objects cannot be created: CompCode = 2 Reason = 2035. As far as I can tell, the config on this machine (in terms of directories, sym-links and file/group ownership) is identical. For completeness, here's the AMQERRO1.LOG: # cat AMQERR01.LOG 10/07/03 04:44:55 PM AMQ5008: An essential MQSeries process 23837 cannot be found and is assumed to be terminated. EXPLANATION: 1) A user has inadvertently terminated the process. 2) The system is low on resources. Some operating systems terminate processes to free resources. If your system is low on resources, it is possible it has terminated the process so that a new process can be created. ACTION: MQSeries will stop all MQSeries processes. Inform your systems administrator. When the problem is rectified MQSeries can be restarted. --- 10/07/03 04:44:55 PM AMQ6184: An internal MQSeries error has occurred on queue manager TEST. EXPLANATION: An error has been detected, and the MQSeries error recording routine has been called. The failing process is process 23834. ACTION: Use the standard facilities supplied with your system to record the problem identifier, and to save the generated output files. Contact your IBM support center. Do not discard these files until the problem has been resolved. --- 10/07/03 04:44:55 PM AMQ5008: An essential MQSeries process 23837 cannot be found and is assumed to be terminated. EXPLANATION: 1) A user has inadvertently terminated the process. 2) The system is low on resources. Some operating systems terminate processes to free resources. If your system is low on resources, it is possible it has terminated the process so that a new process can be created. ACTION: MQSeries will stop all MQSeries processes. Inform your systems administrator. When the problem is rectified MQSeries can be restarted. --- and some of the generated FDC file: # more AMQ23834.0.FDC +-+ | | | MQSeries First Failure Symptom Report | | = | | | | Date/Time :- Tuesday October 07 16:44:55 PDT 2003 | | Host Name :- vdpsusftdf01 (SunOS 5.8) | | PIDS :- 5765B75 | | LVLS :- 520 | | Product Long Name :- MQSeries for Sun Solaris 2 (Sparc) | | Vendor:- IBM | | Probe Id :- ZX005025 | | Application Name :- MQM | | Component :- zxcProcessChildren | | Build Date:- Dec 11 2002 | | CMVC level:- p520-CSD06G | | Build Type:- IKAP - (Production) | | UserID:- 1002 (aboggis) | | Program Name :- amqzxma0_nd | | Process :- 00023834 | | Thread:- 0001 | | QueueManager :- TEST | | Major Errorcode :- zrcX_PROCESS_MISSING | | Minor Errorcode :- OK | | Probe Type:- MSGAMQ5008 | | Probe Severity:- 2 | | Probe Description :- AMQ5008: An essential MQSeries process 23837 cannot be | | found and is assumed to be terminated. | | Arith1:- 23837 5d1d | | | +-+ M
Installing WMQ 5.2 on Solaris 8
My sysadmin has installed the WMQ package on a Solaris box and has followed the prereqs in the "Getting Started" manual. The kernel params are more than sufficient: [from 'sysdef -i'] * * IPC Messages * 4096 max message size (MSGMAX) 4096 max bytes on queue (MSGMNB) 50 message queue identifiers (MSGMNI) 1024 system message headers (MSGTQL) * * IPC Semaphores * 1424 semaphore identifiers (SEMMNI) 32868 semaphores in system (SEMMNS) 16384 undo structures in system (SEMMNU) 100 max semaphores per id (SEMMSL) 128 max operations per semop call (SEMOPM) 600 max undo entries per process (SEMUME) 32767 semaphore maximum value (SEMVMX) 16384 adjust on exit max value (SEMAEM) * * IPC Shared Memory * 4294967295 max shared memory segment size (SHMMAX) 1 min shared memory segment size (SHMMIN) 1124 shared memory identifiers (SHMMNI) 2048 max attached shm segments per process (SHMSEG) * The user (and group) 'mqm' exist and the package was installed with no errors (NOT the DCE option). When running crtmqm, I get the following: The system could not load the module '/opt/mqm/lib/amqzfu' for the installable service 'AuthorizationService' component 'MQSeries.UNIX.auth.service'. The system return code was 536895861. The Queue Manager is continuing without this component. MQSeries queue manager created. Setup completed. AMQ5615: Default objects cannot be created: CompCode = 2 Reason = 2035. As far as I can tell, the config on this machine (in terms of directories, sym-links and file/group ownership) is identical. For completeness, here's the AMQERRO1.LOG: # cat AMQERR01.LOG 10/07/03 04:44:55 PM AMQ5008: An essential MQSeries process 23837 cannot be found and is assumed to be terminated. EXPLANATION: 1) A user has inadvertently terminated the process. 2) The system is low on resources. Some operating systems terminate processes to free resources. If your system is low on resources, it is possible it has terminated the process so that a new process can be created. ACTION: MQSeries will stop all MQSeries processes. Inform your systems administrator. When the problem is rectified MQSeries can be restarted. --- 10/07/03 04:44:55 PM AMQ6184: An internal MQSeries error has occurred on queue manager TEST. EXPLANATION: An error has been detected, and the MQSeries error recording routine has been called. The failing process is process 23834. ACTION: Use the standard facilities supplied with your system to record the problem identifier, and to save the generated output files. Contact your IBM support center. Do not discard these files until the problem has been resolved. --- 10/07/03 04:44:55 PM AMQ5008: An essential MQSeries process 23837 cannot be found and is assumed to be terminated. EXPLANATION: 1) A user has inadvertently terminated the process. 2) The system is low on resources. Some operating systems terminate processes to free resources. If your system is low on resources, it is possible it has terminated the process so that a new process can be created. ACTION: MQSeries will stop all MQSeries processes. Inform your systems administrator. When the problem is rectified MQSeries can be restarted. --- and some of the generated FDC file: # more AMQ23834.0.FDC +-+ | | | MQSeries First Failure Symptom Report | | = | | | | Date/Time :- Tuesday October 07 16:44:55 PDT 2003 | | Host Name :- vdpsusftdf01 (SunOS 5.8) | | PIDS :- 5765B75| | LVLS :- 520| | Product Long Name :- MQSeries for Sun Solaris 2 (Sparc) | | Vendor:- IBM| | Probe Id :- ZX005025 | | Application Name :- MQM| | Component :- zxcProcessChildren | | Build Date:- Dec 11 2002| | CMVC level:- p520-CSD06G| | Build Type:- IKAP - (Production)| | UserID:- 1002 (aboggis)
Encoding / Conversion of message data
I have a customer who is sending data that has the British pound symbol in it. When I receive it on my queue manager, it is preceded by a capital "A" with a ^ on top of it (hex 3D 22). It is not intended to be there, and the customer claims they are not sending it. The CCSID in the message header is 819, and the encoding is 546. See the example below. 63 74 3D 22 C2 A3 22 20 ct="£" Now the plain text Not that I think this matters, but it is coming across a client channel to a WebSphere MQ 5.3 queue manager on AIX Any Ideas? Bill Anderson Senior Systems Analyst SITA Atlanta, GA 770-303-3503 (office) 404-915-3190 (cell) [EMAIL PROTECTED] http://www.mconnect.aero/ 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
Re: SYNCPOINT behaviour
Hello All, But isn't this an expected behavior of any reasonable transaction? Let us say, you are doing something to some SQL database. You can make an INSERT TABLE INTO someTable, then you can use the results in SELECT statement or subclause in subsequent operations inside the same transaction. Otherwise, life would be too unfair. Or, say, you insert two values with same value of a unique primary key field in two sequential INSERTS inside the transaction. Should it only fail on COMMIT because second INSERT must not see the results of the previous one? Not so. If that were the case, the transaction support would not be transparent at all for the client. I mean that normally the client of any transactional system must only throw in a bunch of BEGIN TRANSACTION, COMMIT and ABORT or ROLLBACK operation to make a prevously non-transactional system transactional but must not change the application's logic in a non-obvious way. Otherwise, for a task heavily relying on a state of the resource it changes, making changes transactional would become next to impossible. Or just imagine a task of optimizing a SQL statement leading to breaking it into two using a temporary table under "show no changes" semantics of a transaction. To summarize, (IMHO, of course) a transaction in a commonly used sense of this word must always isolate changes only from "an outside world" for it to see "all or nothing" type of changes, but not from the task performing the transaction. Just my 2c, Pavel "Wyatt, T. Rob" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] MERICA.COM> cc: Sent by: MQSeries Subject: Re: SYNCPOINT behaviour List <[EMAIL PROTECTED] C.AT> 10/07/2003 04:36 PM Please respond to MQSeries List I say we stock up on those new super-sticky Post-It Notes and ambush him at the conference! http://images.amazon.com/images/P/6305508550.01.LZZZ.jpg -- T.Rob -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 07, 2003 3:38 PM To: [EMAIL PROTECTED] Subject: Re: SYNCPOINT behaviour Do we get him now Or wait till the conference??? bee-oh-dubble-bee-dubble-egh >From: Francois Van der Merwe1 <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: SYNCPOINT behaviour >Date: Tue, 7 Oct 2003 17:42:07 +0200 > >Hi Everybody >The original poster of this question again. Thanks for all the responses >etc. From time to time I help our training guys out and then I give some >of the MQ training classes. For one, it breaks my routine a little bit, I >learn to know my customers a little better and it gives me a chance to see >if there is anything new in the training manuals. And then sometimes I >actually prepare for the class and even try out some of the new things. > >In the latest MQ15 (MQ Admin I) training manuals (dated June 2003) there >was this "one liner" stating that you can get a syncpoint message from the >queue even before the commit only if done in the same UOW. Now I thought >this was a mistake, so I whipped out my favourite C compiler and I changed >amqsput0 a little bit to emulate that behaviour. And I must admit I was >VERY surprised to see that it works exactly like that. So, the message was >not available, but true, you can get it back in the same UOW. > >I was still a bit sceptical, so that is why I posted the question to the >group, just to see what the rest of you are saying, and as usual the group >did not disappoint me! Great work guys! > >So I do not know if it was always like that or if it was never in the >training manual or if I just did not give any attention to it but >presto, I learned something new! > >Have fun! > >Francois van der Merwe >Senior IT Specialist: IBM MQSeries Certified Specialist, Solutions Expert & >Developer >IBM, Cape Town, South Africa >+27 (0)82 556 9467 / +27 (0)21 402 5597 >[EMAIL PROTECTED] > > > > > Robert Broderick > <[EMAIL PROTECTED]To: >[EMAIL PROTECTED] > OTMAIL.COM> cc: > Sent by: MQSeries Subject: Re: SYNCPOINT >behaviour > List > <[EMAIL PROTECTED] > .AC.AT> > > > 07/10/2003 13:08 > Please respond to > MQSeries List > > > > >Yee of little faith! > > > >From: John Scott <[EMAIL PROTECTED]> > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: Re: SYNCPOINT behaviour > >Date: Tue, 7 Oct 2003 08:53:46 - > > > >I'll come clean and admit that I had to knock up a quick combination of > >am
Re: SYNCPOINT behaviour
I say we stock up on those new super-sticky Post-It Notes and ambush him at the conference! http://images.amazon.com/images/P/6305508550.01.LZZZ.jpg -- T.Rob -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 07, 2003 3:38 PM To: [EMAIL PROTECTED] Subject: Re: SYNCPOINT behaviour Do we get him now Or wait till the conference??? bee-oh-dubble-bee-dubble-egh >From: Francois Van der Merwe1 <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: SYNCPOINT behaviour >Date: Tue, 7 Oct 2003 17:42:07 +0200 > >Hi Everybody >The original poster of this question again. Thanks for all the responses >etc. From time to time I help our training guys out and then I give some >of the MQ training classes. For one, it breaks my routine a little bit, I >learn to know my customers a little better and it gives me a chance to see >if there is anything new in the training manuals. And then sometimes I >actually prepare for the class and even try out some of the new things. > >In the latest MQ15 (MQ Admin I) training manuals (dated June 2003) there >was this "one liner" stating that you can get a syncpoint message from the >queue even before the commit only if done in the same UOW. Now I thought >this was a mistake, so I whipped out my favourite C compiler and I changed >amqsput0 a little bit to emulate that behaviour. And I must admit I was >VERY surprised to see that it works exactly like that. So, the message was >not available, but true, you can get it back in the same UOW. > >I was still a bit sceptical, so that is why I posted the question to the >group, just to see what the rest of you are saying, and as usual the group >did not disappoint me! Great work guys! > >So I do not know if it was always like that or if it was never in the >training manual or if I just did not give any attention to it but >presto, I learned something new! > >Have fun! > >Francois van der Merwe >Senior IT Specialist: IBM MQSeries Certified Specialist, Solutions Expert & >Developer >IBM, Cape Town, South Africa >+27 (0)82 556 9467 / +27 (0)21 402 5597 >[EMAIL PROTECTED] > > > > > Robert Broderick > <[EMAIL PROTECTED]To: >[EMAIL PROTECTED] > OTMAIL.COM> cc: > Sent by: MQSeries Subject: Re: SYNCPOINT >behaviour > List > <[EMAIL PROTECTED] > .AC.AT> > > > 07/10/2003 13:08 > Please respond to > MQSeries List > > > > >Yee of little faith! > > > >From: John Scott <[EMAIL PROTECTED]> > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: Re: SYNCPOINT behaviour > >Date: Tue, 7 Oct 2003 08:53:46 - > > > >I'll come clean and admit that I had to knock up a quick combination of > >amqsput/amqsget to find out the real answer... > > > >Regards > >John Scott > >IBM Certified Specialist - MQSeries > >Argos Ltd > > > > > >-Original Message- > >From: Neil Casey [mailto:[EMAIL PROTECTED] > >Sent: 07 October 2003 03:32 > >To: [EMAIL PROTECTED] > >Subject: Re: SYNCPOINT behaviour > > > > > >Hi Peter, > > > >your description matches my expectations (I replied earlier), but does >not > >match what Bobbee and John said. > > > >So, I fired up the MQ API excerciser to try it out. > > > >Sure enough, and to my complete surprise, the first MQGET (prior to the > >commit) is able to return the message. After the first commit the queue >is > >empty again because the message has already been removed. I could not >find > >anywhere in the manuals that describes this behaviour, but it is what MQ > >does. All the manual says is that a commit makes the message available to > >OTHER threads. I guess you could read into that that the message is >always > >available in its own thread. That turns out to be the case anyway. > > > >So the question was not as straightforward as I assumed, and produced an > >interesting learning experience, for me at least. > > > >Regards, > > > >Neil Casey. > > > > > >|-+--> > >| | "Potkay, Peter M | > >| | (PLC, IT)" | > >| | <[EMAIL PROTECTED]| > >| | RTFORD.COM>| > >| | Sent by: MQSeries | > >| | List | > >| | <[EMAIL PROTECTED]| > >| | AC.AT> | > >| | | > >| | | > >| | 07/10/2003 12:00 | > >| | Please respond to | > >| | MQSeries List | > >| | | > >|-+--> > > > > > >---
Re: Question on MA0C (Pub/Sub)
We have a simple pub/sub model using three machines: Publisher SUN Broker NT Subscriber SUN Both the Publisher and Subscriber are JMS applications using the TCF. All machines have MQSeries 5.3 CSD 4 (ok WebSphere), and all messages are persistent and the subscriber is using durable subscriptions. I have two questions: When publishing to our own STREAM QUEUE, we do not have a problem. The durable subscriber can connect and retrieve the messages. However, when the subscribing application stops and restarts some time later and tries to re-subscribe using the unique id (as it did before), it fails as the unique id is already in use. Therefore the subscribing application is locked out. When the DEFAULT STREAM queue is used for publications, the subscriber does not have any problems.Can someone shed any light on this please? Where can I find information regarding what JMS is doing under the covers during the publish event and subscribe event. During the publish event it appear the JMS under the covers is sending a message to the broker to establish if the broker is running and that the channels are running. If this 'check' fails then the publish message is not sent. Where can I go to get information on how JMS works with pub/sub Thanks in advance Fez Barnard. -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Wyatt, T. RobSent: Monday, October 06, 2003 2:42 PMTo: [EMAIL PROTECTED]Subject: Re: Question on MA0C (Pub/Sub) Fez, We have it working outside of JMS in several places. Within JMS we have seen problems with duplicate publications and inability to support multiple subscribers. We currently are working several ETR's with IBM and they've sent us some e-fixes. Unfortunately, the guy on our team who has been working this is on vacation for the week so I'm unable to give you a whole lot more detail. One thing that was passed on to me was that Dick Hamilton at IBM was working this with us and made comments to the effect that he was surprised at how little documentation there is on the JMS implementation of Pub/Sub. I'll dig around and see if I can find the ETR numbers for you. -- T.Rob -Original Message-From: Fez [mailto:[EMAIL PROTECTED]Sent: Sunday, October 05, 2003 8:20 PMTo: [EMAIL PROTECTED]Subject: Question on MA0C (Pub/Sub) Hi everyone, I posted a question on MA0C a while back with no response. Can I have a show of hands of how many have actually installed MA0C and got it working. We are having a few teething problems understanding what goes on under the covers when publishing and subscribing using JMS via the Topic Connection Factory. Regards Fez Barnard.
Re: 2018 error
Bill: It is possible that the programmer was just lucky and was accessing the memory location of the handle when calling MQCONNX originally, but in reality he/she probably has a "wild" pointer. If he/she is doing a MQCONN(X) in another function the Hconn needs to be accessible to the other MQ calls. If the Hconn is not within scope for the other MQ calls to get a hold of more than likely you are getting the 2018 as expected. Changing code is a nasty thing, but what is worse is finding out the simple change caused a ripple effect. And what is even worse is knowing that you made a common 'C' coding error ;-) I would suggest checking the code, verifying that the Hconn is available and not getting trashed, remove existing objects and recompile. Chris P.S. If you have code snippet that would help also. |-+> | | "Bill Anderson" | | | <[EMAIL PROTECTED]| | | TA.AERO> | | | Sent by: | | | "MQSeries List" | | | <[EMAIL PROTECTED]| | | n.AC.AT> | | || | || | | 10/07/2003 02:30 | | | PM | | | Please respond to| | | "MQSeries List" | | || |-+> >--| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: 2018 error | | | >--| Thanks Rodger, I'll pass that along. I do think its unlikely though because such a problem would most likely have also occurred using MQCONNX. Remember NO logic changes were made to the code, just a simple substitute of MQCONN for MQCONNX. Cheers Bill Anderson Senior Systems Analyst SITA Atlanta, GA 770-303-3503 (office) 404-915-3190 (cell) [EMAIL PROTECTED] http://www.mconnect.aero/ Roger Lacroix <[EMAIL PROTECTED]To: [EMAIL PROTECTED] ALWARE.BIZ> cc: Sent by: MQSeries Subject: Re: 2018 error List <[EMAIL PROTECTED] C.AT> 10/07/2003 02:02 PM Please respond to MQSeries List Hi, Usually, I get that error when I forget to save the connection handle. Is the "hconn" a local variable in the subroutine that does the connect to the queue manager? If so, you need to define it outside of the subroutine. Either, make it a global variable (dangerous!!) or pass the address of the "hconn" variable to the subroutine. HTH. later Roger... Quoting Bill Anderson <[EMAIL PROTECTED]>: > One of the programmers I work with is trying to recompile a C program to > connect to a queue manager as a server rather than a client. I told him > what library to link to and explained that most likely all he would not > have to make any changes to the code. Well, I was wrong. He was using > MQCONNX to avoid having to rely on environmental variables to connect. That > of course caused him problems. My next suggestion was to simply comment out > the MQCONNX stuff and replace it with a simple MQCONN call. Now he is > getting a 2018 on his MQOPEN (bad handle). I doubt this could be a logic > problem ie, inadvertently doing an MQDISC prior to the open, because none > of the logic changed from the old code. Just a "simple" change from MQCONNX > to MQCONN > > Any ideas? > > That's the last time I start a conversation with the words "All ya goa do > is" > > > Cheers > > Bill Anderson > Senior Systems Analyst > SITA Atlanta, GA > 770-303-3503 (office) > 404-915-3190 (cell) > [EMAIL PROTECTED] > http://www.mconnect.aero/ > 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
Re: SYNCPOINT behaviour
Do we get him now Or wait till the conference??? bee-oh-dubble-bee-dubble-egh From: Francois Van der Merwe1 <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: SYNCPOINT behaviour Date: Tue, 7 Oct 2003 17:42:07 +0200 Hi Everybody The original poster of this question again. Thanks for all the responses etc. From time to time I help our training guys out and then I give some of the MQ training classes. For one, it breaks my routine a little bit, I learn to know my customers a little better and it gives me a chance to see if there is anything new in the training manuals. And then sometimes I actually prepare for the class and even try out some of the new things. In the latest MQ15 (MQ Admin I) training manuals (dated June 2003) there was this "one liner" stating that you can get a syncpoint message from the queue even before the commit only if done in the same UOW. Now I thought this was a mistake, so I whipped out my favourite C compiler and I changed amqsput0 a little bit to emulate that behaviour. And I must admit I was VERY surprised to see that it works exactly like that. So, the message was not available, but true, you can get it back in the same UOW. I was still a bit sceptical, so that is why I posted the question to the group, just to see what the rest of you are saying, and as usual the group did not disappoint me! Great work guys! So I do not know if it was always like that or if it was never in the training manual or if I just did not give any attention to it but presto, I learned something new! Have fun! Francois van der Merwe Senior IT Specialist: IBM MQSeries Certified Specialist, Solutions Expert & Developer IBM, Cape Town, South Africa +27 (0)82 556 9467 / +27 (0)21 402 5597 [EMAIL PROTECTED] Robert Broderick <[EMAIL PROTECTED]To: [EMAIL PROTECTED] OTMAIL.COM> cc: Sent by: MQSeries Subject: Re: SYNCPOINT behaviour List <[EMAIL PROTECTED] .AC.AT> 07/10/2003 13:08 Please respond to MQSeries List Yee of little faith! >From: John Scott <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: SYNCPOINT behaviour >Date: Tue, 7 Oct 2003 08:53:46 - > >I'll come clean and admit that I had to knock up a quick combination of >amqsput/amqsget to find out the real answer... > >Regards >John Scott >IBM Certified Specialist - MQSeries >Argos Ltd > > >-Original Message- >From: Neil Casey [mailto:[EMAIL PROTECTED] >Sent: 07 October 2003 03:32 >To: [EMAIL PROTECTED] >Subject: Re: SYNCPOINT behaviour > > >Hi Peter, > >your description matches my expectations (I replied earlier), but does not >match what Bobbee and John said. > >So, I fired up the MQ API excerciser to try it out. > >Sure enough, and to my complete surprise, the first MQGET (prior to the >commit) is able to return the message. After the first commit the queue is >empty again because the message has already been removed. I could not find >anywhere in the manuals that describes this behaviour, but it is what MQ >does. All the manual says is that a commit makes the message available to >OTHER threads. I guess you could read into that that the message is always >available in its own thread. That turns out to be the case anyway. > >So the question was not as straightforward as I assumed, and produced an >interesting learning experience, for me at least. > >Regards, > >Neil Casey. > > >|-+--> >| | "Potkay, Peter M | >| | (PLC, IT)" | >| | <[EMAIL PROTECTED]| >| | RTFORD.COM>| >| | Sent by: MQSeries | >| | List | >| | <[EMAIL PROTECTED]| >| | AC.AT> | >| | | >| | | >| | 07/10/2003 12:00 | >| | Please respond to | >| | MQSeries List | >| | | >|-+--> > > > --- >---| > | >| > | To: [EMAIL PROTECTED] >| > | cc: >| > | Subject: Re: SYNCPOINT behaviour >| > > > --- >---| > > > > >I assume Q1 is empty at this point. > > > > >empty buffer2 >buffer2 is empty > > > >Set text "MQ Rules" to buffer1 >buffer2 is empty > > > >Open Queue Q1 > > > >Set PutMessageOptions to PMO_SYNCPOINT > > > >Put buffer1
Re: How to manually set the MQ userid from a JMS client app..
Thanks Roger! I was looking at the JMSX methods using code completion in WSAD, but
since it doesn't show manually set fields, i.e. "xxx", "yyy"...I was stumped.
Thanks again,
Brian
-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Roger
Lacroix
Sent: Tuesday, October 07, 2003 2:16 PM
To: [EMAIL PROTECTED]
Subject: Re: How to manually set the MQ userid from a JMS client app..
Here you go:
((Message)outMessage).setStringProperty("JMSXUserID", "FRED");
later
Roger...
Quoting "McCarty, Brian" <[EMAIL PROTECTED]>:
> Does anyone know how to manually set the user id in the MQ header when using
> the JMS API? Normally it just takes the user id from the user that is
> putting the message, but I need to manually set it to an ID that is valid on
> the mainframe (i.e. RACF) rather than the distributed WAS id that it is
> coming from.
>
> Thanks in advance for any advice.
>
> B
>
> Brian M. McCarty
> USAA, Senior Systems Programmer
> 210.913.1678
> WMQ(I) Specialist/Solutions Expert
> e-business Solution Advisor/Designer/Technologist
>
> 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
>
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
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
Re: 2018 error
Thanks Rodger, I'll pass that along. I do think its unlikely though because such a problem would most likely have also occurred using MQCONNX. Remember NO logic changes were made to the code, just a simple substitute of MQCONN for MQCONNX. Cheers Bill Anderson Senior Systems Analyst SITA Atlanta, GA 770-303-3503 (office) 404-915-3190 (cell) [EMAIL PROTECTED] http://www.mconnect.aero/ Roger Lacroix <[EMAIL PROTECTED]To: [EMAIL PROTECTED] ALWARE.BIZ> cc: Sent by: MQSeries Subject: Re: 2018 error List <[EMAIL PROTECTED] C.AT> 10/07/2003 02:02 PM Please respond to MQSeries List Hi, Usually, I get that error when I forget to save the connection handle. Is the "hconn" a local variable in the subroutine that does the connect to the queue manager? If so, you need to define it outside of the subroutine. Either, make it a global variable (dangerous!!) or pass the address of the "hconn" variable to the subroutine. HTH. later Roger... Quoting Bill Anderson <[EMAIL PROTECTED]>: > One of the programmers I work with is trying to recompile a C program to > connect to a queue manager as a server rather than a client. I told him > what library to link to and explained that most likely all he would not > have to make any changes to the code. Well, I was wrong. He was using > MQCONNX to avoid having to rely on environmental variables to connect. That > of course caused him problems. My next suggestion was to simply comment out > the MQCONNX stuff and replace it with a simple MQCONN call. Now he is > getting a 2018 on his MQOPEN (bad handle). I doubt this could be a logic > problem ie, inadvertently doing an MQDISC prior to the open, because none > of the logic changed from the old code. Just a "simple" change from MQCONNX > to MQCONN > > Any ideas? > > That's the last time I start a conversation with the words "All ya goa do > is" > > > Cheers > > Bill Anderson > Senior Systems Analyst > SITA Atlanta, GA > 770-303-3503 (office) > 404-915-3190 (cell) > [EMAIL PROTECTED] > http://www.mconnect.aero/ > > 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 > 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 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
Re: How to manually set the MQ userid from a JMS client app..
Here you go:
((Message)outMessage).setStringProperty("JMSXUserID", "FRED");
later
Roger...
Quoting "McCarty, Brian" <[EMAIL PROTECTED]>:
> Does anyone know how to manually set the user id in the MQ header when using
> the JMS API? Normally it just takes the user id from the user that is
> putting the message, but I need to manually set it to an ID that is valid on
> the mainframe (i.e. RACF) rather than the distributed WAS id that it is
> coming from.
>
> Thanks in advance for any advice.
>
> B
>
> Brian M. McCarty
> USAA, Senior Systems Programmer
> 210.913.1678
> WMQ(I) Specialist/Solutions Expert
> e-business Solution Advisor/Designer/Technologist
>
> 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
>
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
How to manually set the MQ userid from a JMS client app..
Does anyone know how to manually set the user id in the MQ header when using the JMS API? Normally it just takes the user id from the user that is putting the message, but I need to manually set it to an ID that is valid on the mainframe (i.e. RACF) rather than the distributed WAS id that it is coming from. Thanks in advance for any advice. B Brian M. McCarty USAA, Senior Systems Programmer 210.913.1678 WMQ(I) Specialist/Solutions Expert e-business Solution Advisor/Designer/Technologist 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
Re: 2018 error
Hi, Usually, I get that error when I forget to save the connection handle. Is the "hconn" a local variable in the subroutine that does the connect to the queue manager? If so, you need to define it outside of the subroutine. Either, make it a global variable (dangerous!!) or pass the address of the "hconn" variable to the subroutine. HTH. later Roger... Quoting Bill Anderson <[EMAIL PROTECTED]>: > One of the programmers I work with is trying to recompile a C program to > connect to a queue manager as a server rather than a client. I told him > what library to link to and explained that most likely all he would not > have to make any changes to the code. Well, I was wrong. He was using > MQCONNX to avoid having to rely on environmental variables to connect. That > of course caused him problems. My next suggestion was to simply comment out > the MQCONNX stuff and replace it with a simple MQCONN call. Now he is > getting a 2018 on his MQOPEN (bad handle). I doubt this could be a logic > problem ie, inadvertently doing an MQDISC prior to the open, because none > of the logic changed from the old code. Just a "simple" change from MQCONNX > to MQCONN > > Any ideas? > > That's the last time I start a conversation with the words "All ya goa do > is" > > > Cheers > > Bill Anderson > Senior Systems Analyst > SITA Atlanta, GA > 770-303-3503 (office) > 404-915-3190 (cell) > [EMAIL PROTECTED] > http://www.mconnect.aero/ > > 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 > 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
2018 error
One of the programmers I work with is trying to recompile a C program to connect to a queue manager as a server rather than a client. I told him what library to link to and explained that most likely all he would not have to make any changes to the code. Well, I was wrong. He was using MQCONNX to avoid having to rely on environmental variables to connect. That of course caused him problems. My next suggestion was to simply comment out the MQCONNX stuff and replace it with a simple MQCONN call. Now he is getting a 2018 on his MQOPEN (bad handle). I doubt this could be a logic problem ie, inadvertently doing an MQDISC prior to the open, because none of the logic changed from the old code. Just a "simple" change from MQCONNX to MQCONN Any ideas? That's the last time I start a conversation with the words "All ya goa do is" Cheers Bill Anderson Senior Systems Analyst SITA Atlanta, GA 770-303-3503 (office) 404-915-3190 (cell) [EMAIL PROTECTED] http://www.mconnect.aero/ 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
Need you help with Errors in the Event Viewer!!!!
Hi All, Our platform is WMQ 5.3 CSD 04 on W2K. Qmgr QM18U is a cluster member (QM18MACHINE). Qmgrs . REPOS1U and REPOS2U are a full repositories of the cluster. We have currently 4 full repositories. We will eventually replace the other 2 old full repositories with these new (REPOS1U and REPOS2U) full repositories leaving us with only 2 full repositories. QM18U still has its clussdr pointing to one of the old full repositories. We are seeing the following errors on the event viewer of the server QM18MACHINE (hosting qmgr QM18U). Any ideas what might be causing these errors? Any help would be much appreciated. Thanks in advance, Ruzi Event Type: Information Event Source: WebSphere MQ Event Category: None Event ID: 9545 Date: 10/7/2003 Time: 9:24:17 AM User: N/A Computer: QM18MACHINE Description: The description for Event ID ( 9545 ) in Source ( WebSphere MQ ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. The following information is part of the event: 0, 0, TO.REPOS2U, , , 9545, 0, 0. --- note: in the above error TO.REPOS2U is the CLUSRCVR on REPOS2U -- Event Type: Information Event Source: WebSphere MQ Event Category: None Event ID: 9001 Date: 10/7/2003 Time: 9:23:46 AM User: N/A Computer: QM18MACHINE Description: The description for Event ID ( 9001 ) in Source ( WebSphere MQ ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. The following information is part of the event: 0, 0, TO.QM18U, 2660(2128), , 9001, 0, 0. --- note: in the above error TO.QM18U is the CLUSRCVR on QM18U --- Event Type: Error Event Source: WebSphere MQ Event Category: None Event ID: 9208 Date: 10/7/2003 Time: 9:09:28 AM User: N/A Computer: QM18MACHINE Description: The description for Event ID ( 9208 ) in Source ( WebSphere MQ ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. The following information is part of the event: 10054, 10054, QM18MACHINE (172.25.18.31), TCP/IP, (recv), 20009208, 2746, 2746. 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
Re: MQCIH Data conversion
We had the same requirement last year. In our case, our 390 box was running at 100% constantly and we were looking for ways to offload processing. The performance engineer was saying that conversion was a relatively expensive operation. We assumed we could turn conversion on sender off and use MQGMO_CONVERT...Surprise! We eventually ditched the CIH header and run under the default CKBP transaction, but I never heard a satisfactory reason as to why the CICS header wasnt supported for conversion. Scott -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of David C. Partridge Sent: Tuesday, October 07, 2003 10:02 AM To: [EMAIL PROTECTED] Subject: Re: MQCIH Data conversion As far as I know the MQCIH is only used by the CICS bridge code on 390, and the only reason that its a supported format on the other platforms is so that they can SEND messages to a 390 system running the CICS bridge. So, why do you want or need to convert an MQCIH to local encoding and character set representation on the distributed platform? Is this a broker related thing? Cheers, Dave -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of John M Hammond Sent: 07 October 2003 13:32 To: [EMAIL PROTECTED] Subject: MQCIH Data conversion I just discovered (to my astonishment) that IBM does not support data conversion on the MQCIH on distributed platforms. We're raising a request to get this corrected but that will clearly take time. Is anyone aware of a Vendor product that can do the necessary conversion (on Solaris specifically). I'm also looking into building my own data conversion exit, but was hoping to find something ready to go without me doing much work :-) We currently use CONVERT(YES) on our sender channels out of the mainframe, but want to move away from it. Thanks, John John M Hammond Data Center: Middleware Household International 100 Mittel Drive Wood Dale, IL 60191 Phone: (630) 521-4339; Pager: (866) 237-0985 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 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 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
Re: Message Broadcast Capability
Hi, No, that feature does not exist. I wrote a C program called MMX (Message Multiplexer) to do just that (it even maintains the MQMD context). I have used it on almost ever platform (Unix, Windows, OS/390, etc..). It can multiplex a message up to 99 different queues. The program, including full source code, is available at my web site: http://www.capitalware.biz/sample_mqseries.html#ccode Regards, Roger Lacroix Capitalware Inc. Quoting Rob Schwartz <[EMAIL PROTECTED]>: > Hello All!! > > I have an application that needs to the same message to several destinations. > Obviously, I could code the message generation process to simply write > messages to multiple remote queues and have a series of channels connecting > to the destinations that would allow the messages to be delivered to the > destinations. Since the same message needs to be delivered, I was wondering > if there might be some form of "broadcast" capability whereby an application > program would write a message to a single queue and MQSeries itself would > ensure delivery of that message to multiple destinations. > > I realize that parts of this application might be suited to using the > MQSeries client on the destination machines to pull messages from a > centralized MQSeries server. The challenge I see in doing this is the > cleanup of messages on that central server...When should the message be > deleted and how can we be sure messages are not read more than once? > > Any comments or suggestions are greatly appreciated. > > Thanks In Advance!!! > Rob > > 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
RC 2025
I run MQ 5.3 for z/OS. I recently saw my IDMS logs filled with MQ RC=2025's. IDMS eventually had to be recovered. I know what my IDFORE and IDBACK are set to my MQ parms but I hadn't seen them tripped before. Has anyone had experience diagnosing 2025 or should I just increase my IDFORE and IDBACK values in MQ? Thank, All. -- Confidentiality Note: This message is intended for use only by the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. Thank you. Visit us online at our award-winning www.clevelandclinic.org for a complete listing of Cleveland Clinic services, staff and locations from one of the country's leading hospitals. == 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
Re: Message Broadcast Capability
Distribution List works great, and also Pub/Sub. These should satisfy your requirements. Chris |-+> | | "Rob Schwartz" | | | <[EMAIL PROTECTED]| | | S.COM> | | | Sent by: | | | "MQSeries List" | | | <[EMAIL PROTECTED]| | | n.AC.AT> | | || | || | | 10/07/2003 01:35 | | | PM | | | Please respond to| | | "MQSeries List" | | || |-+> >--| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Message Broadcast Capability | | | >--| Hello All!! I have an application that needs to the same message to several destinations. Obviously, I could code the message generation process to simply write messages to multiple remote queues and have a series of channels connecting to the destinations that would allow the messages to be delivered to the destinations. Since the same message needs to be delivered, I was wondering if there might be some form of "broadcast" capability whereby an application program would write a message to a single queue and MQSeries itself would ensure delivery of that message to multiple destinations. I realize that parts of this application might be suited to using the MQSeries client on the destination machines to pull messages from a centralized MQSeries server. The challenge I see in doing this is the cleanup of messages on that central server...When should the message be deleted and how can we be sure messages are not read more than once? Any comments or suggestions are greatly appreciated. Thanks In Advance!!! Rob 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
Re: SYNCPOINT behaviour
Although the capability is there to pull a message from a queue under the same UOW, the real question/situation is why would you? I don't think to date that I have come across a situation where I needed to pull the same message from the queue under a UOW. Any ideas? |-+> | | "Francois Van der| | | Merwe1" | | | <[EMAIL PROTECTED]| | | BM.COM> | | | Sent by: | | | "MQSeries List" | | | <[EMAIL PROTECTED]| | | n.AC.AT> | | || | || | | 10/07/2003 10:42 | | | AM | | | Please respond to| | | "MQSeries List" | | || |-+> >--| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: SYNCPOINT behaviour | | | >--| Hi Everybody The original poster of this question again. Thanks for all the responses etc. From time to time I help our training guys out and then I give some of the MQ training classes. For one, it breaks my routine a little bit, I learn to know my customers a little better and it gives me a chance to see if there is anything new in the training manuals. And then sometimes I actually prepare for the class and even try out some of the new things. In the latest MQ15 (MQ Admin I) training manuals (dated June 2003) there was this "one liner" stating that you can get a syncpoint message from the queue even before the commit only if done in the same UOW. Now I thought this was a mistake, so I whipped out my favourite C compiler and I changed amqsput0 a little bit to emulate that behaviour. And I must admit I was VERY surprised to see that it works exactly like that. So, the message was not available, but true, you can get it back in the same UOW. I was still a bit sceptical, so that is why I posted the question to the group, just to see what the rest of you are saying, and as usual the group did not disappoint me! Great work guys! So I do not know if it was always like that or if it was never in the training manual or if I just did not give any attention to it but presto, I learned something new! Have fun! Francois van der Merwe Senior IT Specialist: IBM MQSeries Certified Specialist, Solutions Expert & Developer IBM, Cape Town, South Africa +27 (0)82 556 9467 / +27 (0)21 402 5597 [EMAIL PROTECTED] Robert Broderick <[EMAIL PROTECTED]To: [EMAIL PROTECTED] OTMAIL.COM> cc: Sent by: MQSeries Subject: Re: SYNCPOINT behaviour List <[EMAIL PROTECTED] .AC.AT> 07/10/2003 13:08 Please respond to MQSeries List Yee of little faith! >From: John Scott <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: SYNCPOINT behaviour >Date: Tue, 7 Oct 2003 08:53:46 - > >I'll come clean and admit that I had to knock up a quick combination of >amqsput/amqsget to find out the real answer... > >Regards >John Scott >IBM Certified Specialist - MQSeries >Argos Ltd > > >-Original Message- >From: Neil Casey [mailto:[EMAIL PROTECTED] >Sent: 07 October 2003 03:32 >To: [EMAIL PROTECTED] >Subject: Re: SYNCPOINT behaviour > > >Hi Peter, > >your description matches my expectations (I replied earlier), but does not >match what Bobbee and John said. > >So, I fired up the MQ API excerciser to try it out. > >Sure enough, and to my complete surprise, the first MQGET (prior to the >commit) is able to return the message. After the first commit the queue is >empty again because the message has already been removed. I could not find >anywhere in the manuals that describes this behaviour, but it is what MQ >does. All the manual says is that a commit makes the messa
Re: Message Broadcast Capability
Rob, Have a look at the distribution list capability within WebSphere MQ itself. While not available on z/OS; is does work on all of the distributed platforms. I have used this myself with several clients to "broadcast" messages. Even those with z/OS based queue managers can send a single message to distributed queue manager and have it construct the distribution list. The distribution list can contain the name of up to 256 queue and queue manager name combinations. If you require more than 256 destinations you will have to construct multiple lists. Rob Schwartz wrote: Hello All!! I have an application that needs to the same message to several destinations. Obviously, I could code the message generation process to simply write messages to multiple remote queues and have a series of channels connecting to the destinations that would allow the messages to be delivered to the destinations. Since the same message needs to be delivered, I was wondering if there might be some form of "broadcast" capability whereby an application program would write a message to a single queue and MQSeries itself would ensure delivery of that message to multiple destinations. I realize that parts of this application might be suited to using the MQSeries client on the destination machines to pull messages from a centralized MQSeries server. The challenge I see in doing this is the cleanup of messages on that central server... When should the message be deleted and how can we be sure messages are not read more than once? Any comments or suggestions are greatly appreciated. Thanks In Advance!!! Rob -- Regards, Thomas DunlapChief Technology Officer[EMAIL PROTECTED] Themis, Inc.http://www.themisinc.com1 (800) 756-3000
Re: MQSERIES Digest - 6 Oct 2003 to 7 Oct 2003 (#2003-283)
nodigest - Original Message - From: "Automatic digest processor" <[EMAIL PROTECTED]> To: "Recipients of MQSERIES digests" <[EMAIL PROTECTED]> Sent: Tuesday, October 07, 2003 7:00 AM Subject: MQSERIES Digest - 6 Oct 2003 to 7 Oct 2003 (#2003-283) 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
Re: MQCIH Data conversion
Ya, I noticed the same problem with MQIIH messages too when I implemented support in MQ Visual Edit. It is really strange that IBM didn't implement the conversion for these message formats. I have a very basic (one size fits all) EBCDIC to ASCII conversion table that I was going to use. But a proper MQ conversion (CCSID & Encoding) is what is needed. later Roger... Quoting John M Hammond <[EMAIL PROTECTED]>: > I just discovered (to my astonishment) that IBM does not support data > conversion on the MQCIH on distributed platforms. We're raising a request > to get this corrected but that will clearly take time. > > Is anyone aware of a Vendor product that can do the necessary conversion > (on Solaris specifically). I'm also looking into building my own data > conversion exit, but was hoping to find something ready to go without me > doing much work :-) > > We currently use CONVERT(YES) on our sender channels out of the mainframe, > but want to move away from it. > > Thanks, > John > > John M Hammond > Data Center: Middleware > Household International > 100 Mittel Drive > Wood Dale, IL 60191 > Phone: (630) 521-4339; Pager: (866) 237-0985 > > 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 > 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
Re: SYNCPOINT behaviour
Hi Everybody The original poster of this question again. Thanks for all the responses etc. From time to time I help our training guys out and then I give some of the MQ training classes. For one, it breaks my routine a little bit, I learn to know my customers a little better and it gives me a chance to see if there is anything new in the training manuals. And then sometimes I actually prepare for the class and even try out some of the new things. In the latest MQ15 (MQ Admin I) training manuals (dated June 2003) there was this "one liner" stating that you can get a syncpoint message from the queue even before the commit only if done in the same UOW. Now I thought this was a mistake, so I whipped out my favourite C compiler and I changed amqsput0 a little bit to emulate that behaviour. And I must admit I was VERY surprised to see that it works exactly like that. So, the message was not available, but true, you can get it back in the same UOW. I was still a bit sceptical, so that is why I posted the question to the group, just to see what the rest of you are saying, and as usual the group did not disappoint me! Great work guys! So I do not know if it was always like that or if it was never in the training manual or if I just did not give any attention to it but presto, I learned something new! Have fun! Francois van der Merwe Senior IT Specialist: IBM MQSeries Certified Specialist, Solutions Expert & Developer IBM, Cape Town, South Africa +27 (0)82 556 9467 / +27 (0)21 402 5597 [EMAIL PROTECTED] Robert Broderick <[EMAIL PROTECTED]To: [EMAIL PROTECTED] OTMAIL.COM> cc: Sent by: MQSeries Subject: Re: SYNCPOINT behaviour List <[EMAIL PROTECTED] .AC.AT> 07/10/2003 13:08 Please respond to MQSeries List Yee of little faith! >From: John Scott <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: SYNCPOINT behaviour >Date: Tue, 7 Oct 2003 08:53:46 - > >I'll come clean and admit that I had to knock up a quick combination of >amqsput/amqsget to find out the real answer... > >Regards >John Scott >IBM Certified Specialist - MQSeries >Argos Ltd > > >-Original Message- >From: Neil Casey [mailto:[EMAIL PROTECTED] >Sent: 07 October 2003 03:32 >To: [EMAIL PROTECTED] >Subject: Re: SYNCPOINT behaviour > > >Hi Peter, > >your description matches my expectations (I replied earlier), but does not >match what Bobbee and John said. > >So, I fired up the MQ API excerciser to try it out. > >Sure enough, and to my complete surprise, the first MQGET (prior to the >commit) is able to return the message. After the first commit the queue is >empty again because the message has already been removed. I could not find >anywhere in the manuals that describes this behaviour, but it is what MQ >does. All the manual says is that a commit makes the message available to >OTHER threads. I guess you could read into that that the message is always >available in its own thread. That turns out to be the case anyway. > >So the question was not as straightforward as I assumed, and produced an >interesting learning experience, for me at least. > >Regards, > >Neil Casey. > > >|-+--> >| | "Potkay, Peter M | >| | (PLC, IT)" | >| | <[EMAIL PROTECTED]| >| | RTFORD.COM>| >| | Sent by: MQSeries | >| | List | >| | <[EMAIL PROTECTED]| >| | AC.AT> | >| | | >| | | >| | 07/10/2003 12:00 | >| | Please respond to | >| | MQSeries List | >| | | >|-+--> > > > --- >---| > | >| > | To: [EMAIL PROTECTED] >| > | cc: >| > | Subject: Re: SYNCPOINT behaviour >| > > > --- >---| > > > > >I assume Q1 is empty at this point. > > > > >empty buffer2 >buffer2 is empty > > > >Set text "MQ Rules" to buffer1 >buffer2 is empty > > > >Open Queue Q1 > > > >Set PutMessageOptions to PMO_SYNCPOINT > > > >Put buffer1 into Q1 >buffer2 is still empty, queue depth is increased by 1, message is not >available since it is not commited. > > > >Set GetMessageOptions to GMO_SYNCPOINT >buffer2 is empty > > > >Get into buffer2 from Q1 >buffer2 is empty, because the MQGET threw a 2033, as there were no
Message Broadcast Capability
Hello All!! I have an application that needs to the same message to several destinations. Obviously, I could code the message generation process to simply write messages to multiple remote queues and have a series of channels connecting to the destinations that would allow the messages to be delivered to the destinations. Since the same message needs to be delivered, I was wondering if there might be some form of "broadcast" capability whereby an application program would write a message to a single queue and MQSeries itself would ensure delivery of that message to multiple destinations. I realize that parts of this application might be suited to using the MQSeries client on the destination machines to pull messages from a centralized MQSeries server. The challenge I see in doing this is the cleanup of messages on that central server... When should the message be deleted and how can we be sure messages are not read more than once? Any comments or suggestions are greatly appreciated. Thanks In Advance!!! Rob
Re: Problem with CICS, CKBR
The correlid for the first message in a Unit of work for the CICS bridge must be MQCI_NEW_SESSION and message ids must be unique Bob Buxton Websphere MQ for zOS Development MP 211, IBM Hursley, Winchester SO21 2JN, UK Ext 248193, External (+44)01962-818193 [EMAIL PROTECTED] - Message from Madhukar Babu Mukkala <[EMAIL PROTECTED]> on Tue, 7 Oct 2003 18:29:47 +0530 - Subject: Problem with CICS, CKBR Hi, We are using MQ Series Version - 2.1 On MVS - OS/390 R 2.9.0 We have a bridge queue with the following properties: Name: SYSTEM.CICS.BRIDGE.QUEUE Put Enabled : Y Get Enabled : Y Permit Shared Access: Y Default Shared Option : E (Exclusive) Index Type : None Trigger Type: F (First) Trigger Set : Y Process Name: CICS1_BRIDGE Initiation Queue: CICS01.INITQ Initiation Queue Properties are - Name: CICS01.INITQ Put Enabled : Y Get Enabled : Y Permit Shared Access: Y Default Shared Option : E (Exclusive) Index Type : None Process Defined as - Process name : CICS1_BRIDGE Application type : CICS Application ID : CKBR User data : AUTH=LOCAL,WAIT=20 We have a CKTI instance running and monitoring the above Initiation Queue. This was verifyed by looking into the status displayed by CKQC transaction. At that time we also checked the currently running CICS transactions and found that CKBR is not running. However, when the first message is put into the bridge queue (SYSTEM.CICS.BRIDGE.QUEUE), the message is taken away from the bridge queue and CKBR transaction is started. This is verifyed again by looking into the CICS tasks currently executing. We are putting this message into the queue using a batch COBOL program. In this program, we are setting the following values to MQMD. MQMD-FORMAT : MQFMT-CICS MQMD-ENCODING : 785 MQMD-MSGID : MQMI-NONE MQMD-CORRELID : MQCI-NONE MQMD-REPLYTOQ : 'SARMAD' MQMD-REPLYTOQMGR: 'MQA1' The CKBR transaction is supposed to run a CICS DPL program, which we specify in the MQ message being passed to the bridge queue, and return a result to the Reply to Queue. (We are sending the program name and commarea data as part of message body to the bridge queue.) CKBR transaction is picking the first message from the queue but is not returning any message to the Reply to Queue. Also, it is not picking further messages from the queue. What could be the problem? Any APARs etc? Thanks and Regards, Madhukar. 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
Cluster Workload Mgmt
Hi, I am trying to develop a workload exit to override the default behaviour. I want the local instance of the cluster queue to be treated as just another cluster queue, so that I can get rid of the gateway queue manager, which could cause the performance. QM1 and QM2 have C1.CQ shared as cluster Queues in cluster CL1. If I connect thro' QM1 or QM2 and put messages to C1.CQ, I want the messages to be put in a round-robin fashion on QM1 and QM2 C1.CQ queues. Is this possible ? Is it possible to make the workload exit intelligent, so that the exit identifies if the messages are already workload balanced or not ?? To do this, would it require my exit to have the logic of remembering whether the messages are workload balanced or not ? Will it be a better choice of having a random number generated from 1 - MQWXP->DestinationCount, to choose the destination ? What are the issues that I should take care, few I could think of is the priority we might have assigned to the channel, QMGR status etc... Would appreciate any thoughts. Thanks Hariharan
ZOS locks directory
There is a directory on the ZOS for the WMQI broker named /var/wmqi/brokername/locks the files are File MQSeriesIntegrator2BrokerResourceTableLockSemaphore File wmqi2RetainedPubsTableLockSemaphore When the broker comes down it cleans up the files in this directory. If not, it cannot come up. I look but cannot find documentation on this. Has anyone read this and where it is?? bobbee _ Help protect your PC. Get a FREE computer virus scan online from McAfee. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 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
Re: MQCIH Data conversion
As far as I know the MQCIH is only used by the CICS bridge code on 390, and the only reason that its a supported format on the other platforms is so that they can SEND messages to a 390 system running the CICS bridge. So, why do you want or need to convert an MQCIH to local encoding and character set representation on the distributed platform? Is this a broker related thing? Cheers, Dave -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of John M Hammond Sent: 07 October 2003 13:32 To: [EMAIL PROTECTED] Subject: MQCIH Data conversion I just discovered (to my astonishment) that IBM does not support data conversion on the MQCIH on distributed platforms. We're raising a request to get this corrected but that will clearly take time. Is anyone aware of a Vendor product that can do the necessary conversion (on Solaris specifically). I'm also looking into building my own data conversion exit, but was hoping to find something ready to go without me doing much work :-) We currently use CONVERT(YES) on our sender channels out of the mainframe, but want to move away from it. Thanks, John John M Hammond Data Center: Middleware Household International 100 Mittel Drive Wood Dale, IL 60191 Phone: (630) 521-4339; Pager: (866) 237-0985 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 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
Re: Max Channels
MaxChannels and MaxActiveChannels are global parameters. They specify the maximum values regardless of how many listeners you have running or indeed use inetd. There is no MQ parameter which limits the number that can connect to a single listener. In 5.3 you can have a single listener to handle all your inbound channels regardless of how many there are. In this case the connection is farmed out to a pool of channel processes. There are parameters to control how many are farmed out to each process but we don't document them 'cos in general you don't need to know. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley Ruzi R <[EMAIL PROTECTED]To: [EMAIL PROTECTED] M> cc: Sent by: MQSeriesSubject: Re: Max Channels List <[EMAIL PROTECTED] N.AC.AT> 07/10/2003 13:26 Please respond to MQSeries List Sid, >if you run 5 > listners and you have MaxChannels set to 1000 does > that mean there are 5000 > channels available (assuming server is capable of > handling that many in > bound connections). I believe (someone will correct me if I am wrong) the numbers that are set for MAxChannels and MAxActiveChannels are for a single port. So, in your example, you will have max 5000 channels. Best regards, Ruzi --- [EMAIL PROTECTED] wrote: > Howdy again, > > Does each listener contribute to the total > MaxChannels value or if you run 5 > listners and you have MaxChannels set to 1000 does > that mean there are 5000 > channels available (assuming server is capable of > handling that many in > bound connections). > > Thanks > > Sid > > > > -Original Message- > From: Ruzi R [mailto:[EMAIL PROTECTED] > Sent: Monday, 6 October 2003 8:55 PM > To: [EMAIL PROTECTED] > Subject: Re: Max Channels > > > MaxActiveChannel needs to be at least 2500 (assuming > the server can handle this many connections). > > Best regards, > > Ruzi > --- [EMAIL PROTECTED] wrote: > > G'Day all, > > > > I have about 500 clients all trying to connect at > > about the same time and > > transfer data from one of my MQ server (NT4 > mqv5.1), > > each client is running > > 5 threads with their own connection, so my > question > > is this. > > > > Is 500 clients and 5 threads each = 2500 > > connections? > > Does Max Channel need to be at least 2500 ? > > > > > > Sid > > > > 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 > > 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 > > 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 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 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
Problem with CICS, CKBR
Hi, We are using MQ Series Version - 2.1 On MVS - OS/390 R 2.9.0 We have a bridge queue with the following properties: Name: SYSTEM.CICS.BRIDGE.QUEUE Put Enabled : Y Get Enabled : Y Permit Shared Access: Y Default Shared Option : E (Exclusive) Index Type : None Trigger Type: F (First) Trigger Set : Y Process Name: CICS1_BRIDGE Initiation Queue: CICS01.INITQ Initiation Queue Properties are - Name: CICS01.INITQ Put Enabled : Y Get Enabled : Y Permit Shared Access: Y Default Shared Option : E (Exclusive) Index Type : None Process Defined as - Process name : CICS1_BRIDGE Application type : CICS Application ID : CKBR User data : AUTH=LOCAL,WAIT=20 We have a CKTI instance running and monitoring the above Initiation Queue. This was verifyed by looking into the status displayed by CKQC transaction. At that time we also checked the currently running CICS transactions and found that CKBR is not running. However, when the first message is put into the bridge queue (SYSTEM.CICS.BRIDGE.QUEUE), the message is taken away from the bridge queue and CKBR transaction is started. This is verifyed again by looking into the CICS tasks currently executing. We are putting this message into the queue using a batch COBOL program. In this program, we are setting the following values to MQMD. MQMD-FORMAT : MQFMT-CICS MQMD-ENCODING : 785 MQMD-MSGID : MQMI-NONE MQMD-CORRELID : MQCI-NONE MQMD-REPLYTOQ : 'SARMAD' MQMD-REPLYTOQMGR: 'MQA1' The CKBR transaction is supposed to run a CICS DPL program, which we specify in the MQ message being passed to the bridge queue, and return a result to the Reply to Queue. (We are sending the program name and commarea data as part of message body to the bridge queue.) CKBR transaction is picking the first message from the queue but is not returning any message to the Reply to Queue. Also, it is not picking further messages from the queue. What could be the problem? Any APARs etc? Thanks and Regards, Madhukar. 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
MQCIH Data conversion
I just discovered (to my astonishment) that IBM does not support data conversion on the MQCIH on distributed platforms. We're raising a request to get this corrected but that will clearly take time. Is anyone aware of a Vendor product that can do the necessary conversion (on Solaris specifically). I'm also looking into building my own data conversion exit, but was hoping to find something ready to go without me doing much work :-) We currently use CONVERT(YES) on our sender channels out of the mainframe, but want to move away from it. Thanks, John John M Hammond Data Center: Middleware Household International 100 Mittel Drive Wood Dale, IL 60191 Phone: (630) 521-4339; Pager: (866) 237-0985 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
Re: Max Channels
Sid, >if you run 5 > listners and you have MaxChannels set to 1000 does > that mean there are 5000 > channels available (assuming server is capable of > handling that many in > bound connections). I believe (someone will correct me if I am wrong) the numbers that are set for MAxChannels and MAxActiveChannels are for a single port. So, in your example, you will have max 5000 channels. Best regards, Ruzi --- [EMAIL PROTECTED] wrote: > Howdy again, > > Does each listener contribute to the total > MaxChannels value or if you run 5 > listners and you have MaxChannels set to 1000 does > that mean there are 5000 > channels available (assuming server is capable of > handling that many in > bound connections). > > Thanks > > Sid > > > > -Original Message- > From: Ruzi R [mailto:[EMAIL PROTECTED] > Sent: Monday, 6 October 2003 8:55 PM > To: [EMAIL PROTECTED] > Subject: Re: Max Channels > > > MaxActiveChannel needs to be at least 2500 (assuming > the server can handle this many connections). > > Best regards, > > Ruzi > --- [EMAIL PROTECTED] wrote: > > G'Day all, > > > > I have about 500 clients all trying to connect at > > about the same time and > > transfer data from one of my MQ server (NT4 > mqv5.1), > > each client is running > > 5 threads with their own connection, so my > question > > is this. > > > > Is 500 clients and 5 threads each = 2500 > > connections? > > Does Max Channel need to be at least 2500 ? > > > > > > Sid > > > > 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 > > 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 > > 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 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
64 Bit Sun or Win2K?
Anyone have an idea when 64 bit MQSeries will be available on Sun or Win2K. No word from IBM directly when posed the question... Donald S. Murray The TD Waterhouse Group, Jersey City, NJ MQSeries Systems Engineer Desk- 201-369-8624 Cell- 908-256-9296 <>
Re: SYNCPOINT behaviour
Yee of little faith! From: John Scott <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: SYNCPOINT behaviour Date: Tue, 7 Oct 2003 08:53:46 - I'll come clean and admit that I had to knock up a quick combination of amqsput/amqsget to find out the real answer... Regards John Scott IBM Certified Specialist - MQSeries Argos Ltd -Original Message- From: Neil Casey [mailto:[EMAIL PROTECTED] Sent: 07 October 2003 03:32 To: [EMAIL PROTECTED] Subject: Re: SYNCPOINT behaviour Hi Peter, your description matches my expectations (I replied earlier), but does not match what Bobbee and John said. So, I fired up the MQ API excerciser to try it out. Sure enough, and to my complete surprise, the first MQGET (prior to the commit) is able to return the message. After the first commit the queue is empty again because the message has already been removed. I could not find anywhere in the manuals that describes this behaviour, but it is what MQ does. All the manual says is that a commit makes the message available to OTHER threads. I guess you could read into that that the message is always available in its own thread. That turns out to be the case anyway. So the question was not as straightforward as I assumed, and produced an interesting learning experience, for me at least. Regards, Neil Casey. |-+--> | | "Potkay, Peter M | | | (PLC, IT)" | | | <[EMAIL PROTECTED]| | | RTFORD.COM>| | | Sent by: MQSeries | | | List | | | <[EMAIL PROTECTED]| | | AC.AT> | | | | | | | | | 07/10/2003 12:00 | | | Please respond to | | | MQSeries List | | | | |-+--> >--- ---| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: SYNCPOINT behaviour | >--- ---| I assume Q1 is empty at this point. > > >empty buffer2 buffer2 is empty > > >Set text "MQ Rules" to buffer1 buffer2 is empty > > >Open Queue Q1 > > >Set PutMessageOptions to PMO_SYNCPOINT > > >Put buffer1 into Q1 buffer2 is still empty, queue depth is increased by 1, message is not available since it is not commited. > > >Set GetMessageOptions to GMO_SYNCPOINT buffer2 is empty > > >Get into buffer2 from Q1 buffer2 is empty, because the MQGET threw a 2033, as there were no available messages on the queue. > > >Commit buffer2 is empty, queue depth is still 1, but now the message is available. > > >Get into buffer2 from Q1 buffer2 contains a pearl of wisdom proclaiming that "MQ Rules". Bobbee finally now knows what he wants his new tattoo to say. > > >Commit > > >end -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Monday, October 06, 2003 4:22 PM To: [EMAIL PROTECTED] Subject: Re: SYNCPOINT behaviour AA!!! I like your last sentence and was thinking that too.but I thought we were being theoretical here (like when the kid asks his father the difference between "Fantasy and Reality") I have noticed that we have not heard from the poster of this fine question. Are they sitting back giggling while me and you swing it out on a technical intellectual level. (cause the person I'm paying to keep up my end has to go home and drink a beer! hahaha). bobbee Now for something completely different. I have a OS390 broker that is abending and the abend file, while not saying much, sez "SEMCTL". Anybody??? >From: John Scott <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: SYNCPOINT behaviour >Date: Mon, 6 Oct 2003 18:10:11 - > >Putting shared handles aside for a second, the HCONN is only valid on >the "smallest unit of execution" which in most cases is a thread rather >than a process. > >So if you try multiple connects on the same thread, you'll get a >MQRC_ALREADY_CONNECTED *warning*. However, the HCONN value returned >will be >the same as the originally returned HCONN (2002 is a warning, not a >failure). This would mean the same UOW and being able to get an uncommitted >put from the same UOW. On another thread, you get a different HCONN >value returned. This would mean no getting of your uncommitted message. > >I am not 100% sure what would happen if you used shared handles (I've >not actually tried them yet). I would expect that two separate HCONNs >on the same thread would have two different units of work and so would >operat
Re: SYNCPOINT behaviour
Neil, Experience with MF processes lead me to some conjecture on this situation. In CICS, at least, you can access the data coordinated within the LUW prior to the commitment of the LUW. When (we) were suggesting a solution I'm sure (we) were thinking in BIG BLUE terms. I resemble a SMURF because of association bee-oh-dubble-bee-dubble-egh From: Neil Casey <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: SYNCPOINT behaviour Date: Tue, 7 Oct 2003 13:31:57 +1000 Hi Peter, your description matches my expectations (I replied earlier), but does not match what Bobbee and John said. So, I fired up the MQ API excerciser to try it out. Sure enough, and to my complete surprise, the first MQGET (prior to the commit) is able to return the message. After the first commit the queue is empty again because the message has already been removed. I could not find anywhere in the manuals that describes this behaviour, but it is what MQ does. All the manual says is that a commit makes the message available to OTHER threads. I guess you could read into that that the message is always available in its own thread. That turns out to be the case anyway. So the question was not as straightforward as I assumed, and produced an interesting learning experience, for me at least. Regards, Neil Casey. |-+--> | | "Potkay, Peter M | | | (PLC, IT)" | | | <[EMAIL PROTECTED]| | | RTFORD.COM>| | | Sent by: MQSeries | | | List | | | <[EMAIL PROTECTED]| | | AC.AT> | | | | | | | | | 07/10/2003 12:00 | | | Please respond to | | | MQSeries List | | | | |-+--> >--| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: SYNCPOINT behaviour | >--| I assume Q1 is empty at this point. > > >empty buffer2 buffer2 is empty > > >Set text "MQ Rules" to buffer1 buffer2 is empty > > >Open Queue Q1 > > >Set PutMessageOptions to PMO_SYNCPOINT > > >Put buffer1 into Q1 buffer2 is still empty, queue depth is increased by 1, message is not available since it is not commited. > > >Set GetMessageOptions to GMO_SYNCPOINT buffer2 is empty > > >Get into buffer2 from Q1 buffer2 is empty, because the MQGET threw a 2033, as there were no available messages on the queue. > > >Commit buffer2 is empty, queue depth is still 1, but now the message is available. > > >Get into buffer2 from Q1 buffer2 contains a pearl of wisdom proclaiming that "MQ Rules". Bobbee finally now knows what he wants his new tattoo to say. > > >Commit > > >end -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Monday, October 06, 2003 4:22 PM To: [EMAIL PROTECTED] Subject: Re: SYNCPOINT behaviour AA!!! I like your last sentence and was thinking that too.but I thought we were being theoretical here (like when the kid asks his father the difference between "Fantasy and Reality") I have noticed that we have not heard from the poster of this fine question. Are they sitting back giggling while me and you swing it out on a technical intellectual level. (cause the person I'm paying to keep up my end has to go home and drink a beer! hahaha). bobbee Now for something completely different. I have a OS390 broker that is abending and the abend file, while not saying much, sez "SEMCTL". Anybody??? >From: John Scott <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: SYNCPOINT behaviour >Date: Mon, 6 Oct 2003 18:10:11 - > >Putting shared handles aside for a second, the HCONN is only valid on the >"smallest unit of execution" which in most cases is a thread rather than a >process. > >So if you try multiple connects on the same thread, you'll get a >MQRC_ALREADY_CONNECTED *warning*. However, the HCONN value returned will be >the same as the originally returned HCONN (2002 is a warning, not a >failure). This would mean the same UOW and being able to get an uncommitted >put from the same UOW. On another thread, you get a different HCONN value >returned. This would mean no getting of your uncommitted message. > >I am not 100% sure what would happen if you used shared handles (I've not >actually tr
Re: SYNCPOINT behaviour
Put it right next to "Arnie for Gov" From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: SYNCPOINT behaviour Date: Mon, 6 Oct 2003 22:00:02 -0400 I assume Q1 is empty at this point. > > >empty buffer2 buffer2 is empty > > >Set text "MQ Rules" to buffer1 buffer2 is empty > > >Open Queue Q1 > > >Set PutMessageOptions to PMO_SYNCPOINT > > >Put buffer1 into Q1 buffer2 is still empty, queue depth is increased by 1, message is not available since it is not commited. > > >Set GetMessageOptions to GMO_SYNCPOINT buffer2 is empty > > >Get into buffer2 from Q1 buffer2 is empty, because the MQGET threw a 2033, as there were no available messages on the queue. > > >Commit buffer2 is empty, queue depth is still 1, but now the message is available. > > >Get into buffer2 from Q1 buffer2 contains a pearl of wisdom proclaiming that "MQ Rules". Bobbee finally now knows what he wants his new tattoo to say. > > >Commit > > >end -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Monday, October 06, 2003 4:22 PM To: [EMAIL PROTECTED] Subject: Re: SYNCPOINT behaviour AA!!! I like your last sentence and was thinking that too.but I thought we were being theoretical here (like when the kid asks his father the difference between "Fantasy and Reality") I have noticed that we have not heard from the poster of this fine question. Are they sitting back giggling while me and you swing it out on a technical intellectual level. (cause the person I'm paying to keep up my end has to go home and drink a beer! hahaha). bobbee Now for something completely different. I have a OS390 broker that is abending and the abend file, while not saying much, sez "SEMCTL". Anybody??? >From: John Scott <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: SYNCPOINT behaviour >Date: Mon, 6 Oct 2003 18:10:11 - > >Putting shared handles aside for a second, the HCONN is only valid on the >"smallest unit of execution" which in most cases is a thread rather than a >process. > >So if you try multiple connects on the same thread, you'll get a >MQRC_ALREADY_CONNECTED *warning*. However, the HCONN value returned will be >the same as the originally returned HCONN (2002 is a warning, not a >failure). This would mean the same UOW and being able to get an uncommitted >put from the same UOW. On another thread, you get a different HCONN value >returned. This would mean no getting of your uncommitted message. > >I am not 100% sure what would happen if you used shared handles (I've not >actually tried them yet). I would expect that two separate HCONNs on the >same thread would have two different units of work and so would operate the >same as two separate threads/processes with their own HCONNs. > >This is all assuming that the return codes from the calls indicate success >and that the original code snippet had all the checking removed to easy >readability - rather than having Francois post the entire amqsput/amqsget >samples combined... > >The next question I have (well another guy in the office I asked) is why >would you want to put a message under syncpoint and then get it again in >the >same UOW?? > >Regards >John Scott >IBM Certified Specialist - MQSeries >Argos Ltd > >PS. What does TCB stand for? Is the an OS/390 thing? > > >-Original Message- >From: Robert Broderick [mailto:[EMAIL PROTECTED] >Sent: 06 October 2003 16:29 >To: [EMAIL PROTECTED] >Subject: Re: SYNCPOINT behaviour > > >Your right John, BUTtoday I am a purest (and I know someone >else >would get to the point!!) > >Also, If you try to connect to a QMGR twice from inside the same >task/process don't you get a return code indicating "MQRC_ALREADY_CONNECTED > 2002". So the alternate HCONN would have to be performed from >another task/process. That then would follow the normal rules for syncpoint >processing > > >bee-oh-dubble-bee-dubble-egh > > > >From: John Scott <[EMAIL PROTECTED]> > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: Re: SYNCPOINT behaviour > >Date: Mon, 6 Oct 2003 15:45:32 - > > > >Isn't the fundamental question that Francois is asking is whether MQ > >makes a message put under syncpoint available if an attempt to get the > >message is performed within the SAME unit of work (i.e. before the work > >is committed)? > > > >The answer is yes. Thus if you put a message under syncpoint, you can > >get the message before a commit, if you use the same HCONN and specify > >MQGMO_SYNCPOINT on your get. If you use another HCONN, or don't use > >MQGMO_SYNCPOINT, then the message is not available. > > > >Regards > >John Scott > >IBM Certified Specialist - MQSeries > >Argos Ltd > > > > > >-Original Message- > >From: Robert Broderick [mailto:[EMAIL PROTECTED] > >Sent: 06 October 2003 13:24 > >To: [EMAIL PRO
Re: SYNCPOINT behaviour
I'll come clean and admit that I had to knock up a quick combination of amqsput/amqsget to find out the real answer... Regards John Scott IBM Certified Specialist - MQSeries Argos Ltd -Original Message- From: Neil Casey [mailto:[EMAIL PROTECTED] Sent: 07 October 2003 03:32 To: [EMAIL PROTECTED] Subject: Re: SYNCPOINT behaviour Hi Peter, your description matches my expectations (I replied earlier), but does not match what Bobbee and John said. So, I fired up the MQ API excerciser to try it out. Sure enough, and to my complete surprise, the first MQGET (prior to the commit) is able to return the message. After the first commit the queue is empty again because the message has already been removed. I could not find anywhere in the manuals that describes this behaviour, but it is what MQ does. All the manual says is that a commit makes the message available to OTHER threads. I guess you could read into that that the message is always available in its own thread. That turns out to be the case anyway. So the question was not as straightforward as I assumed, and produced an interesting learning experience, for me at least. Regards, Neil Casey. |-+--> | | "Potkay, Peter M | | | (PLC, IT)" | | | <[EMAIL PROTECTED]| | | RTFORD.COM>| | | Sent by: MQSeries | | | List | | | <[EMAIL PROTECTED]| | | AC.AT> | | | | | | | | | 07/10/2003 12:00 | | | Please respond to | | | MQSeries List | | | | |-+--> >--- ---| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: SYNCPOINT behaviour | >--- ---| I assume Q1 is empty at this point. > > >empty buffer2 buffer2 is empty > > >Set text "MQ Rules" to buffer1 buffer2 is empty > > >Open Queue Q1 > > >Set PutMessageOptions to PMO_SYNCPOINT > > >Put buffer1 into Q1 buffer2 is still empty, queue depth is increased by 1, message is not available since it is not commited. > > >Set GetMessageOptions to GMO_SYNCPOINT buffer2 is empty > > >Get into buffer2 from Q1 buffer2 is empty, because the MQGET threw a 2033, as there were no available messages on the queue. > > >Commit buffer2 is empty, queue depth is still 1, but now the message is available. > > >Get into buffer2 from Q1 buffer2 contains a pearl of wisdom proclaiming that "MQ Rules". Bobbee finally now knows what he wants his new tattoo to say. > > >Commit > > >end -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Monday, October 06, 2003 4:22 PM To: [EMAIL PROTECTED] Subject: Re: SYNCPOINT behaviour AA!!! I like your last sentence and was thinking that too.but I thought we were being theoretical here (like when the kid asks his father the difference between "Fantasy and Reality") I have noticed that we have not heard from the poster of this fine question. Are they sitting back giggling while me and you swing it out on a technical intellectual level. (cause the person I'm paying to keep up my end has to go home and drink a beer! hahaha). bobbee Now for something completely different. I have a OS390 broker that is abending and the abend file, while not saying much, sez "SEMCTL". Anybody??? >From: John Scott <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: SYNCPOINT behaviour >Date: Mon, 6 Oct 2003 18:10:11 - > >Putting shared handles aside for a second, the HCONN is only valid on >the "smallest unit of execution" which in most cases is a thread rather >than a process. > >So if you try multiple connects on the same thread, you'll get a >MQRC_ALREADY_CONNECTED *warning*. However, the HCONN value returned >will be >the same as the originally returned HCONN (2002 is a warning, not a >failure). This would mean the same UOW and being able to get an uncommitted >put from the same UOW. On another thread, you get a different HCONN >value returned. This would mean no getting of your uncommitted message. > >I am not 100% sure what would happen if you used shared handles (I've >not actually tried them yet). I would expect that two separate HCONNs >on the same thread would have two different units of work and so would >operate the >same as two separate threads/processes with their own HCONNs. > >This is all assuming that the return codes from the calls indicate >success and that the original code snip
Re: Reason Codes
Title: Reason Codes Hi There, This is plain vanilla MQSERIES -Original Message-From: Emile Kearns [mailto:[EMAIL PROTECTED]Sent: 07 October 2003 09:00To: [EMAIL PROTECTED]Subject: Re: Reason Codes What is your setup, plain vanilla MQSeries or is WMQI involved? -Original Message-From: Bryan Baynes - CPX Mngd Services SDC [mailto:[EMAIL PROTECTED] Sent: 07 October 2003 08:35 AMTo: [EMAIL PROTECTED]Subject: Reason Codes Hi List, Where will I find the meaning of the reason code "65537", found in the = DEAD LETTER HEADER?? Thanks. Bryan Baynes Tel: (011) 322-5607 Mailto:[EMAIL PROTECTED] Any views expressed in this message are those of the individual sender, and T-Systems South Africa (Pty) Ltd accepts no liability therefore, except where the sender specifically states them to be those of T-Systems South Africa (Pty) Ltd. Although this message has been scanned for the possible presence of computer viruses prior to despatch, T-Systems South Africa (Pty) Ltd cannot be held responsible for any viruses or other material transmitted with, or as part of, this message.
Re: Reason Codes
Title: Reason Codes What is your setup, plain vanilla MQSeries or is WMQI involved? -Original Message- From: Bryan Baynes - CPX Mngd Services SDC [mailto:[EMAIL PROTECTED] Sent: 07 October 2003 08:35 AM To: [EMAIL PROTECTED] Subject: Reason Codes Hi List, Where will I find the meaning of the reason code "65537", found in the = DEAD LETTER HEADER?? Thanks. Bryan Baynes Tel: (011) 322-5607 Mailto:[EMAIL PROTECTED] Any views expressed in this message are those of the individual sender, and T-Systems South Africa (Pty) Ltd accepts no liability therefore, except where the sender specifically states them to be those of T-Systems South Africa (Pty) Ltd. Although this message has been scanned for the possible presence of computer viruses prior to despatch, T-Systems South Africa (Pty) Ltd cannot be held responsible for any viruses or other material transmitted with, or as part of, this message.
