Re: browse question
Title: Message One potential trick, but not one I'm seriously recommending - on every msg you browse, also do a get under syncpoint, but don't commit. When you restart the browse, the msgs you've already browsed/got would not be visible (but you might have a large unit of work outstanding!). Oh well, at least we all know that you have to be far more careful with browse than maybe we realised. Shame that the reality of the implementation doesn't match what intuition tells you it means. Best wishes Darren - Original Message - From: Miller, Dennis To: [EMAIL PROTECTED] Sent: Wednesday, October 13, 2004 6:37 PM Subject: Re: browse question I'm with you. Browsing is a simple concept and it should work as intuitively expected. It should not be fraught with gotcha's or pitfalls and should not precipate yet another bag of programming tricks.Frankly, given what we know now, I'm at a loss for a programming trick that even solves the problem and would be interested in hearing if anyone has one.You mentionarbitrarily restarting the browsecursor (and I've considered it's variant--always using browse first). But how do youthen avoid thepotential ofbrowsing the same message more than once ina logical pass of the queue? Consider a simple model with the CICS bridgebrowsing the queue and initiating a CICS transaction for each message. I understand, that ultimately we can onlyconsumeeach message once. But how do we structure things so that we reliably don't attempt to consumethe samemessage more than once? When the browse cursor restarts, there is no way to distinquish messages that have been browsed from those that have been skipped by the previous pass of the queue. How can we be surewe don't havepending transactionsdesignated to process messages that get picked up in the subsequent pass? I find it quite disconcerting that an unqualified browse next can return 2033 when there are still messages on the queue. On a brighter note, I seriously doubt we have the same issue with destructive reads; if we do, it's time to pack it in. regards, Dennis -Original Message-From: Darren Douch [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 13, 2004 3:46 AMTo: [EMAIL PROTECTED]Subject: Re: browse question Restarting the browse becomes essential rather than 'merely' good practice once you've read the manual, otherwise you'll certainly end up with messages only getting processed at application restart which is unlikely to be desirable! But yes, with a busy queue you might never go back to the start, so you have to restart the browse after some arbitrary number of msgs, just in case there are some you've missed. Didn't realise browsing was as tricky as this... better go and check that destructive reads don't work in the same way! Regards Darren - Original Message - From: Miller, Dennis To: [EMAIL PROTECTED] Sent: Tuesday, October 12, 2004 10:24 PM Subject: Re: browse question Yikes.I think it is a good practice to routinely restart the browse firstafter you get tothe end. However, this has much broader implications. The extreme case would be a very busy queue that seldom empties? Then you have unattended messages at the top of the queue while those near the bottom are getting worked. Or, suppose app A and app B, running concurrently, each put2 messages within a unitof work and App C is browsing the messages. Then you could have something like this: Aputs msg 1 B puts msg 2,3 and commits C browses2,3 (note: msg 1 is skipped because it is not committed yet) A puts msg 4 and commits C browses 4 C gets 2033 and restarts browse cursor C browses 1 In this example, the put order is 1,2,3,4 but the get order is 2,3,4,1. Messages 1 is retrieved out of sequenceeven though all conditions for sequential retrieval are being met! And that's assuming you deliberately restart the browse cursor. Fail to do that and msg 1 gets stranded.It gives me pause to rethink the practicality of browsing -Original Message-From: Darren Douch [mailto:[EMAIL PROTECTED] Sent: Monday, October 11, 2004 5:15 AMTo: [EMAIL PROTECTED]Subject: browse question Found this in the manuals... so no need for you all to go digging around now :) Uncommitted messages An uncommitted message is never visible to a browse; the browse cursor skips past it. Messages within a unit-of-work cannot be browsed until the unit-of-work is
Re: browse question
I would question WHY you would be browsing a queue with the characteristics as has been mentioned here. Why would you browse a queue that is the target of a fee-ing frenzie. If there are so many messages being delivered to the queue, no one taking message off of it that you run the risk of never hitting the bottom, then maybe your solution is not the correct one. If you are browsing, you would expect to bottom out sonner or later, most likly sooner. If that is not your expectation so you can reissue the browse with FISRT the process should be implemented another way. All feeder and no consumer is a database. bobbee From: Darren Douch [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: browse question Date: Thu, 14 Oct 2004 11:19:27 +0100 MessageOne potential trick, but not one I'm seriously recommending - on every msg you browse, also do a get under syncpoint, but don't commit. When you restart the browse, the msgs you've already browsed/got would not be visible (but you might have a large unit of work outstanding!). Oh well, at least we all know that you have to be far more careful with browse than maybe we realised. Shame that the reality of the implementation doesn't match what intuition tells you it means. Best wishes Darren - Original Message - From: Miller, Dennis To: [EMAIL PROTECTED] Sent: Wednesday, October 13, 2004 6:37 PM Subject: Re: browse question I'm with you. Browsing is a simple concept and it should work as intuitively expected. It should not be fraught with gotcha's or pitfalls and should not precipate yet another bag of programming tricks. Frankly, given what we know now, I'm at a loss for a programming trick that even solves the problem and would be interested in hearing if anyone has one. You mention arbitrarily restarting the browse cursor (and I've considered it's variant--always using browse first). But how do you then avoid the potential of browsing the same message more than once in a logical pass of the queue? Consider a simple model with the CICS bridge browsing the queue and initiating a CICS transaction for each message. I understand, that ultimately we can only consume each message once. But how do we structure things so that we reliably don't attempt to consume the same message more than once? When the browse cursor restarts, there is no way to distinquish messages that have been browsed from those that have been skipped by the previous pass of the queue. How can we be sure we don't have pending transactions designated to process messages that get picked up in the subsequent pass? I find it quite disconcerting that an unqualified browse next can return 2033 when there are still messages on the queue. On a brighter note, I seriously doubt we have the same issue with destructive reads; if we do, it's time to pack it in. regards, Dennis -Original Message- From: Darren Douch [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 13, 2004 3:46 AM To: [EMAIL PROTECTED] Subject: Re: browse question Restarting the browse becomes essential rather than 'merely' good practice once you've read the manual, otherwise you'll certainly end up with messages only getting processed at application restart which is unlikely to be desirable! But yes, with a busy queue you might never go back to the start, so you have to restart the browse after some arbitrary number of msgs, just in case there are some you've missed. Didn't realise browsing was as tricky as this... better go and check that destructive reads don't work in the same way! Regards Darren - Original Message - From: Miller, Dennis To: [EMAIL PROTECTED] Sent: Tuesday, October 12, 2004 10:24 PM Subject: Re: browse question Yikes. I think it is a good practice to routinely restart the browse first after you get to the end. However, this has much broader implications. The extreme case would be a very busy queue that seldom empties? Then you have unattended messages at the top of the queue while those near the bottom are getting worked. Or, suppose app A and app B, running concurrently, each put 2 messages within a unit of work and App C is browsing the messages. Then you could have something like this: A puts msg 1 B puts msg 2,3 and commits C browses 2,3 (note: msg 1 is skipped because it is not committed yet) A puts msg 4 and commits C browses 4 C gets 2033 and restarts browse cursor C browses 1 In this example, the put order is 1,2,3,4 but the get order is 2,3,4,1. Messages 1 is retrieved out of sequence even though all conditions for sequential retrieval are being met! And that's assuming you deliberately restart the browse cursor. Fail to do that and msg 1 gets stranded. It gives me pause to rethink the practicality of browsing -Original Message-
Re: JPMorganChase Co looking for MQ Systems Talent - respond directly to sender
Don't woory. I am the last one to throw stones. Been there!! Done that!! Hope the job goes well! bobbee From: Christopher Warneke [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: JPMorganChase Co looking for MQ Systems Talent - respond directly to sender Date: Wed, 13 Oct 2004 15:47:00 -0700 My apologies for the spam - I had thought that I'd cut/pasted the requiter's JPChase email address before sending out the resume. Thank you, Chris --- Robert Broderick [EMAIL PROTECTED] wrote: HEY We got his telephone numbermaybe we should ALL call him and tech him! (tee hee hee) bee-oh-dubble-bee-dubble-egh From: Christopher Fryett [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: JPMorganChase Co looking for MQ Systems Talent - respond directly to sender Date: Wed, 13 Oct 2004 12:54:21 -0500 Resume too long. I can only read upto 2 pages ;-) Please respond to the person directly not the list server. Christopher Warneke christopher_g_wa To [EMAIL PROTECTED] [EMAIL PROTECTED] Sent by: cc MQSeries List [EMAIL PROTECTED] Subject n.AC.AT Re: JPMorganChase Co looking for MQ Systems Talent 10/13/2004 11:22 AM Please respond to MQSeries List [EMAIL PROTECTED] n.AC.AT My resume is attached... --- Melissa Greenwood [EMAIL PROTECTED] wrote: - Dear Listers, Due to the large number of critical projects in our systems infrastructure group, JPMorganChase Co is currently looking for highly talented WebSphere MQ systems programmers and admins. This position will support MQ on both Mainframe and UNIX (AIX and Solaris) platforms. The ideal candidate has 5+ years of hands-on experience implementing and supporting MQSeries in a large sysplex shop environment and strong interpersonal skills. Full-time positions based in Columbus, Ohio. Competitive compensation package and great benefits, including relocation assistance. If you are interested in exploring this opportunity, please send your confidential resume in MS Word format to: Melissa Greenwood IT Recruiter JPMorganChase Co. 614-213-6670 e-mail: Melissa_J_Greenwood at BankOne dot com -- ___ Sign-up for Ads Free at Mail.com http://www.mail.com/?sr=signup Instructions for managing your mailing list subscription are provided inthe Listserv General Users Guide available at http://www.lsoft.comArchive: 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 _ Don t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ 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 _ Get ready for school! Find articles, homework help and more in the Back to School Guide! http://special.msn.com/network/04backtoschool.armx 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
Workflow Default Viewer?
Title: Workflow Default Viewer? I have a default MQ Workflow Web Client installation. We want to modify the ListViewer.jsp to load a specific worklist by specifying it in the jsp. If you go to the list of lists view under Admin the Worklist displayed at the top will be defaulted when the ListViewer.jsp gets loaded. I do not know how to change this so that I can specify my own worklist to load by default. It also seems that the default worklist does not filter properly. Only after you change the list by selecting it from the dropdown box does the filtering start working. Can somebody please help? __ For information about the Standard Bank group visit our web site www.standardbank.co.za__Disclaimer and confidentiality note Everything in this e-mail and any attachments relating to the official business of Standard Bank Group Limited is proprietary to the group. It is confidential, legally privileged and protected by law. Standard Bank does not own and endorse any other content. Views and opinions are those of the sender unless clearly stated as being that of the group. The person addressed in the e-mail is the sole authorised recipient. Please notify the sender immediately if it has unintentionally reached you and do not read, disclose or use the content in any way.Standard Bank can not assure that the integrity of this communication has been maintained nor that it is free of errors, virus, interception or interference.___
Capture message rates
What is the most efficient way to capture the rate that messages arrive in a queue. Ideally, I would like to be able to capture these metrics in an hourly basis. Exists come to mind, but not sure where to start since I have never coded an exit. If that is, indeed, the place to start, can someone point me to any samples? Thanks. Tony This electronic message transmission contains information from a member company of Westfield Group which is privileged, confidential or otherwise the exclusive property of the intended recipient or that member company of Westfield Group. This information is intended for the use of the individual or entity that is the intended recipient. If you are not the designated recipient, please be aware that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this electronic transmission in error, please notify us by telephone at 1.800.243.0210, extension 2153, or by electronic e-mail ([EMAIL PROTECTED]) and promptly destroy the original transmission.
[no subject]
SET MQSERIES NOMAIL De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender direct te informeren door het bericht te retourneren. The information contained in this message may be confidential and is intended to be exclusively for the addressee. Should you receive this message unintentionally, please do not use the contents herein and notify the sender immediately by return e-mail.
Re: Capture message rates
The following is from the MQ System Setup Guide: Ihave also attached a canned report I receive each day that may help. 4.1.6.2 Using Performance Reporter for OS/390 Copyright IBM Corp. 1993, 2000 Topic lines 1 to 15 of 15 You can use Performance Reporter for OS/390 to interpret RMF and SMF records. Performance Reporter for OS/390 is an IBM licensed program (program number 5695-101) that enables you to manage the performance of your system by collecting performance data in a DB2 database and presenting the data in a variety of formats for use in systems management. Performance Reporter can generate graphic and tabular reports using systems management data it stores in its DB2 database. It includes an administration dialog, a reporting dialog, and a log collector, all of which interact with a standard DB2 database. This is described in the Performance Reporter for OS/390 Administration Thank You, Richard Esposito CICS Systems [EMAIL PROTECTED] (973) 793-2177 From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]Sent: Thursday, October 14, 2004 9:22 AMTo: [EMAIL PROTECTED]Subject: Capture message rates What is the most efficient way to capture the rate that messages arrive in a queue. Ideally, I would like to be able to capture these metrics in an hourly basis. Exists come to mind, but not sure where to start since I have never coded an exit. If that is, indeed, the place to start, can someone point me to any samples? Thanks. TonyThis electronic message transmission contains information from a member company of Westfield Group which is privileged, confidential or otherwise the exclusive property of the intended recipient or that member company of Westfield Group. This information is intended for the use of the individual or entity that is the intended recipient. If you are not the designated recipient, please be aware that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this electronic transmission in error, please notify us by telephone at 1.800.243.0210, extension 2153, or by electronic e-mail ([EMAIL PROTECTED]) and promptly destroy the original transmission. ---BeginMessage--- Title: MQ Message Report BUNDLE CONTENTS FOR RPT1 --- BMXG003D MQ MESSAGE REPORT --- 10/14/2004 --- 1 PAGES --- 61 LINES .../BMX/D2MX003D --- VER 15 RPT1.TXT Description: RPT1.TXT ---End Message--- *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. ***
Re: MQ tcp/ip errors.
Hi Toni, I saw your thread at mqseries.net and assume your problem is still alive. I often saw this error in a system with a channel over WAN. HBINT was set to 10 because of very short TCP/IP settings. It wasn't up to us to change these values. Maybe it's the same in your system. I think, HBINT or TCP/IP timeouts lower than 30 seconds are not useful in a WAN. We could live with this behavior, the channel alway started on retry. Other reasons for this error: - not enough resources ( cpu, ... ) - all kind of network problems (cable, switch, router ... ) - high load in the network ( I remember, we had a problem every time when the system backup had started ) Gunter Am Dienstag, den 12.10.2004, 13:22 -0700 schrieb Tony Boggis: Env: Solaris 5.8, WMQ 5.3 (CSD05) We have an annoying situation where we are periodically receiving tcp/ip errors in the MQ error logs. This causes our cluster channels to terminate [abnormally]. It's a transient error, because the channel immediately retries and successfully restarts and everything continues on it's merry way. In most cases we are getting error code 11 from a select. This (as far as my research finds) maps to the socket error EAGAIN, or something like insufficent resources. But I have been unable to find much more detailed information as the causes and cures. --- 09/07/04 11:11:12 AM AMQ9213: A communications error for TCP/IP occurred. EXPLANATION: An unexpected error occurred in communications. ACTION: The return code from the TCP/IP(select) [TIMEOUT] 10 seconds call was 11 (X'B'). Record these values and tell the systems administrator. - amqccita.c : 3075 --- 09/07/04 11:11:12 AM AMQ: Channel program ended abnormally. EXPLANATION: Channel program 'TO.AS1' ended abnormally. ACTION: Look at previous error messages for channel program 'TO.AS1' in the error files to determine the cause of the failure. - amqrccca.c : 804 I am at a loss as to why these errors are occurring since I am unable to find any matching events in the Solaris system error logs. Since the errors do not occur with any predictability, running a packet sniffer is difficult because within 30 seconds we can generate megabytes of data and don't have enough available storage for the generated log files. Can anyone offer any insight as to what might cause these errors and how we might go about preventing them? All of our MQ apps connect directly to the local queue manager, so there are no client (or Server Connection) channels in use. The only channels are CLUSSDR/CLUSRCVR channels between cluster members and it is these channels that are periodically interupted. I don't (at this time) see this as any sort of bug in MQ. As far as I can tell, MQ is simply responding to an error from a socket api call and shutting down the channel to prevent data loss. A few seconds later (based on the retry attributes) the channel is successfully restarted. Regards, tonyB. 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
Unexpected channel terminations on Solaris when channel exits are used.
If you see this, it could be caused by the patch level of the Solaris linker. We had a crit. sit. at a customer which after much tracing (truss as well as MQ traces) we narrowed down a segv in dlclose().This was happening on Solaris 8, and the customer had patch level 109147-24 for the linker. Applying 109147-27 resolved the problem even though the docs for the patch didn't show any fixes for dlclose(). So if you have channel exits and you get FDCs for Probe Id :- RM487001 Component :- rriChannelTerminate Major Errorcode :- rrcE_CHANNEL_TERMINATED then you should check that you have at least this patch level applied to the Solaris linker (there's almost certainly an equivalent patch level for Solaris 9, but I don't know the number). Regards, David C. Partridge Technical Products Director Primeur Security Services Tel: +44 (0)1926 511058 Mobile: +44 (0)7713 880197 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
MQ Series IMS Bridge EBCDIC to ASCII Conversion
Hi All ! We are working on a Java application running on a UNIX box(Sun solaris) which needs to communicate with the MF. The options taken for the intercommunicationwas using WSMQ with the IMS Bridge on the MF.We need to lookup for some data from the Mainframe. After some efforts we got through the authentication phase. We are however stuck, with the data conversions. The char or text data looks okay, but our pipes '|' are getting converted to [ when seen on the application on Mainframe. When the pipes come from the Mainframe, they appear as ! marks on the UNIX box. We are using CCSID 850 and 500 on the UNIX box and the MF respectively. (I tried with many more CCSID on the UNIX box, but to no avail). Below is a sample response from the application on the MF. The !sshould have been|s. IIH TMQSTR ?w 1 ??SACHIN1!!COBITS!!L1!0016!!100019990!1!20020202!!AAALAST!621!!AAAHOMEMEMBE!HOME!19700101!M!AAALAST!AAAFIRST!M!!12345!!089!!!0.0!!0.0!0.!!!N!!G!!HOSI!001!002!003!004!005!1.0!2.0!3.0!4.0!5.0!0.0!0.0!0.0!0.0!0!!21.0!12.0!12.0!67.0!9!1BEGIN_RESP_BLOCK0.00!0.00!0.00!0.00!0.00!0.00!0.00!0.00!!!0.00!0.00!!END_RESP_BLOCK!BEGIN_ERROR_BLOCK!1!0016!ITC226!1!1!BEGIN_CLAIM_RSN_CD!5!!BEGIN_LINE_RSN_CD!30!!BEGIN_CLAIM_RSN_CD!5!!BEGIN_LINE_RSN_CD!3END_ERROR_BLOCK! Also attached herewith is a sample of what we are using. Any inputs to resolve this would be of a great help. thanks regards Sachin IMSBridge.java Description: Binary data
Re: MQ Series IMS Bridge EBCDIC to ASCII Conversion
Sachin You probably need the MVS CCSID to be 37 (the newer default) NOT 500. Rich Nath, Sachindra [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 10/14/2004 11:32 AM Please respond to MQSeries List To:[EMAIL PROTECTED] cc:(bcc: Richard Jackson/DTCC) Subject:MQ Series IMS Bridge EBCDIC to ASCII Conversion Hi All ! We are working on a Java application running on a UNIX box(Sun solaris) which needs to communicate with the MF. The options taken for the intercommunication was using WSMQ with the IMS Bridge on the MF. We need to lookup for some data from the Mainframe. After some efforts we got through the authentication phase. We are however stuck, with the data conversions. The char or text data looks okay, but our pipes '|' are getting converted to [ when seen on the application on Mainframe. When the pipes come from the Mainframe, they appear as ! marks on the UNIX box. We are using CCSID 850 and 500 on the UNIX box and the MF respectively. (I tried with many more CCSID on the UNIX box, but to no avail). Below is a sample response from the application on the MF. The !s should have been |s. IIH TMQSTR ?w 1 ??SACHIN1!!COBITS!!L1!0016!!100019990!1!200 20202!!AAALAST!621!!AAAHOMEMEMBE!HOME!19700101!M!AAALAST!AAAFIRST!M!!12345!!089!!!0.0!!0.0!0.!!!N!!G!!HOSI !001!002!003!004!005!1.0!2.0!3.0!4.0!5.0!0.0!0.0!0.0!0.0!0!!21.0!12.0!12.0!67.0!9!1BEGIN_RESP_BLOCK!!! !0.00!0.00!0.00!0.00!0.00!0.00!0.00!0.00!!!0.00!0.00!!END_RESP_BLOCK!BEGIN_ERROR_BLOCK!1!0016!ITC226!1!1!BEGIN _CLAIM_RSN_CD!5!!BEGIN_LINE_RSN_CD!30!!BEGIN_CLAIM_RSN_CD!5!!BEGIN_LINE_RSN_CD!3END_ERROR_BLOC K! Also attached herewith is a sample of what we are using. Any inputs to resolve this would be of a great help. thanks regards Sachin IMSBridge.java Description: Binary data
Re: MQ Series IMS Bridge EBCDIC to ASCII Conversion
Hi Richard, Thanks for the prompt response. This is one thing on the cards, and we have posted a request to the MainFrame MQ Adminfor it. I have a few further queries. We have a lot of other non ims queues under the same queue manager. We dequeue the messages from these queues using the MQGMO_CONVERT setting the MVS CCSID as 37 from the dequeuing application (and things work fine). Will changing theCCSID effect these queues ? The doubts wrt IMS is, who will call the CONVERT here ? As the message is dequeued by the Bridge and passed on to the actual IMS Application. Is there a setting for the IMS Bridge, where we could state for a conversion ? thanks regards Sachin -Original Message-From: Richard Jackson [mailto:[EMAIL PROTECTED]Sent: Thursday, October 14, 2004 9:26To: [EMAIL PROTECTED]Subject: Re: MQ Series IMS Bridge EBCDIC to ASCII ConversionSachin You probably need the MVS CCSID to be 37 (the newer default) NOT 500. Rich "Nath, Sachindra" [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 10/14/2004 11:32 AM Please respond to MQSeries List To: [EMAIL PROTECTED] cc:(bcc: Richard Jackson/DTCC) Subject:MQ Series IMS Bridge EBCDIC to ASCII ConversionHi All ! We are working on a Java application running on a UNIX box(Sun solaris) which needs to communicate with the MF. The options taken for the intercommunication was using WSMQ with the IMS Bridge on the MF. We need to lookup for some data from the Mainframe. After some efforts we got through the authentication phase. We are however stuck, with the data conversions. The char or text data looks okay, but our pipes '|' are getting converted to [ when seen on the application on Mainframe. When the pipes come from the Mainframe, they appear as ! marks on the UNIX box. We are using CCSID 850 and 500 on the UNIX box and the MF respectively. (I tried with many more CCSID on the UNIX box, but to no avail). Below is a sample response from the application on the MF. The !s should have been |s. IIH b :Tb %MQSTR ?wb ; 1 ??b %SACHIN1!!COBITS!!L1!0016!!100019990!1!20020202!!AAALAST!621!!AAAHOMEMEMBE!HOME!19700101!M!AAALAST!AAAFIRST!M!!12345!!089!!!0.0!!0.0!0.!!!N!!G!!HOSI!001!002!003!004!005!1.0!2.0!3.0!4.0!5.0!0.0!0.0!0.0!0.0!0!!21.0!12.0!12.0!67.0!9!1BEGIN_RESP_BLOCK0.00!0.00!0.00!0.00!0.00!0.00!0.00!0.00!!!0.00!0.00!!END_RESP_BLOCK!BEGIN_ERROR_BLOCK!1!0016!ITC226!1!1!BEGIN_CLAIM_RSN_CD!5!!BEGIN_LINE_RSN_CD!30!!BEGIN_CLAIM_RSN_CD!5!!BEGIN_LINE_RSN_CD!3END_ERROR_BLOCK! Also attached herewith is a sample of what we are using. Any inputs to resolve this would be of a great help. thanks regards Sachin
Re: Capture message rates
One way is to use the ResetQueueStatistics PCF command, which is especially useful on distributed systems where there are no SMF records. Just send the command once per some interval (e.g. one hour) and it reports back the number of messages enqueued and dequeued for requested queue(s) plus HighQDepth since the last reset. You can then calculate the rate as it also reports TimeSinceLastReset. You only get a message count, not byte count, so if you're looking for message size info you'll need something else. The PCF command is easy to use - much, much more so than an exit - and efficient. The only drawback I've seen is the interaction with the Queue-Service-Interval event but if you aren't using that event (very good chance you're not) then everything is fine. hth, marty [EMAIL PROTECTED] wrote: What is the most efficient way to capture the rate that messages arrive in a queue. Ideally, I would like to be able to capture these metrics in an hourly basis. Exists come to mind, but not sure where to start since I have never coded an exit. If that is, indeed, the place to start, can someone point me to any samples? Thanks. Tony 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: MQ Series IMS Bridge EBCDIC to ASCII Conversion
Sachin All the appl with MQGMO_Convert will be affected if the CCSID changes. I'm not familiar with the IMS Bridge. Only way to tell is to test... Hopefully the apps only use A-z,0-9 :-) Rich Nath, Sachindra [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 10/14/2004 12:17 PM Please respond to MQSeries List To:[EMAIL PROTECTED] cc:(bcc: Richard Jackson/DTCC) Subject:Re: MQ Series IMS Bridge EBCDIC to ASCII Conversion Hi Richard, Thanks for the prompt response. This is one thing on the cards, and we have posted a request to the MainFrame MQ Admin for it. I have a few further queries. We have a lot of other non ims queues under the same queue manager. We dequeue the messages from these queues using the MQGMO_CONVERT setting the MVS CCSID as 37 from the dequeuing application (and things work fine). Will changing the CCSID effect these queues ? The doubts wrt IMS is, who will call the CONVERT here ? As the message is dequeued by the Bridge and passed on to the actual IMS Application. Is there a setting for the IMS Bridge, where we could state for a conversion ? thanks regards Sachin -Original Message- From: Richard Jackson [mailto:[EMAIL PROTECTED] Sent: Thursday, October 14, 2004 9:26 To: [EMAIL PROTECTED] Subject: Re: MQ Series IMS Bridge EBCDIC to ASCII Conversion Sachin You probably need the MVS CCSID to be 37 (the newer default) NOT 500. Rich Nath, Sachindra [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 10/14/2004 11:32 AM Please respond to MQSeries List To:[EMAIL PROTECTED] cc:(bcc: Richard Jackson/DTCC) Subject:MQ Series IMS Bridge EBCDIC to ASCII Conversion Hi All ! We are working on a Java application running on a UNIX box(Sun solaris) which needs to communicate with the MF. The options taken for the intercommunication was using WSMQ with the IMS Bridge on the MF. We need to lookup for some data from the Mainframe. After some efforts we got through the authentication phase. We are however stuck, with the data conversions. The char or text data looks okay, but our pipes '|' are getting converted to [ when seen on the application on Mainframe. When the pipes come from the Mainframe, they appear as ! marks on the UNIX box. We are using CCSID 850 and 500 on the UNIX box and the MF respectively. (I tried with many more CCSID on the UNIX box, but to no avail). Below is a sample response from the application on the MF. The !s should have been |s. IIH b :Tb %MQSTR ?wb ; 1 ??b %SACHIN1!!COBITS!!L1!0016!!100019990!1!200 20202!!AAALAST!621!!AAAHOMEMEMBE!HOME!19700101!M!AAALAST!AAAFIRST!M!!12345!!089!!!0.0!!0.0!0.!!!N!!G!!HOSI !001!002!003!004!005!1.0!2.0!3.0!4.0!5.0!0.0!0.0!0.0!0.0!0!!21.0!12.0!12.0!67.0!9!1BEGIN_RESP_BLOCK!!! !0.00!0.00!0.00!0.00!0.00!0.00!0.00!0.00!!!0.00!0.00!!END_RESP_BLOCK!BEGIN_ERROR_BLOCK!1!0016!ITC226!1!1!BEGIN _CLAIM_RSN_CD!5!!BEGIN_LINE_RSN_CD!30!!BEGIN_CLAIM_RSN_CD!5!!BEGIN_LINE_RSN_CD!3END_ERROR_BLOC K! Also attached herewith is a sample of what we are using. Any inputs to resolve this would be of a great help. thanks regards Sachin
WBIMB CVS
We set up our CVS repository and are attempting to move code to it. If we have a project in the Brooker toolkit which has code (esql, mapping, message flow, etc) we get an error SHARING the project into CVS. BUT, if we first create the project (EMPTY), SHARE (ie Import) it into CVS it will add it. We then have to check it out as a project and can add the code files to it throught the toolkit development windows and add them back to CVS through the SHARING option. Is this the method for adding code files under a project or can you add a project, code file and all, to CVS at one time. bobbee _ Don t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ 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
WBIMB CVS
BTW, CVS is running on Windows. _ Is your PC infected? Get a FREE online computer virus scan from McAfee. Security. 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
need help finding MQCHT_SENDER
I have the following include files in my C program, but the constant MQCHT_SENDER can't be found: cmqc.h cmqcfc.h cmsqbc.h Does anyone know where it is?
Re: need help finding MQCHT_SENDER
Title: Message cmqxc. -Original Message-From: Rick Tsujimoto [mailto:[EMAIL PROTECTED] Sent: Thursday, October 14, 2004 3:21 PMTo: [EMAIL PROTECTED]Subject: need help finding MQCHT_SENDERI have the following include files in my C program, but the constant MQCHT_SENDER can't be found: cmqc.h cmqcfc.h cmsqbc.h Does anyone know where it is?
Re: need help finding MQCHT_SENDER
#include cmqc.h #include cmqxc.h Rick Tsujimoto [EMAIL PROTECTED]To: [EMAIL PROTECTED] .CANON.COMcc: Sent by: MQSeries List Subject: need help finding MQCHT_SENDER [EMAIL PROTECTED] 10/14/2004 04:21 PM Please respond to MQSeries List I have the following include files in my C program, but the constant MQCHT_SENDER can't be found: cmqc.h cmqcfc.h cmsqbc.h Does anyone know where it is? 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
fix pack CSD04 for WBIMB
We're about to install this fix pack, but I wanted to check with the group to see if anyone's run into any trouble or would have a suggestion or two regarding anything to look out for. Thanks, -Patrick. 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: fix pack CSD04 for WBIMB
No problems here with CSD4. It contained my fix for nested stylesheets includes (XMLTransformation node) as well Alan Patrick Reeder [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 15/10/2004 07:49 AM Please respond to MQSeries List [EMAIL PROTECTED] To [EMAIL PROTECTED] cc Subject fix pack CSD04 for WBIMB We're about to install this fix pack, but I wanted to check with the group to see if anyone's run into any trouble or would have a suggestion or two regarding anything to look out for. Thanks, -Patrick. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This email is intended for the named recipient only. It may contain information which is confidential, commercially sensitive, or copyright. If you are not the intended recipient you must not reproduce or distribute any part of the email, disclose its contents, or take any action in reliance. If you have received this email in error, please contact the sender and delete the message. It is your responsibility to scan this email and any attachments for viruses and other defects. To the extent permitted by law, Zurich and its associates will not be liable for any loss or damage arising in any way from this communication including any file attachments. We may monitor email you send to us, either as a reply to this email or any email you send to us, to confirm our systems are protected and for compliance with company policies. Although we take reasonable precautions to protect the confidentiality of our email systems, we do not warrant the confidentiality or security of email or attachments we receive.
Re: browse question
Bobbee, Well, I suppose one would expect to bottom out sooner or later. The later part is the problem. Even if it's only 10 seconds later, that translates to a pretty long turn-around time for somebody. The other consideration is the out-of-sequence implication. I don't consider that much of an issue because I long ago learned not to rely on msg sequence and have work arounds to deal with it. My dilemma in this case is that I'm stuck without a work around. I can't tell you how many times I've advised an SIL solution and how many times that implementation has involved a browse cursor to identify messages that need attention. Now I discover this gaping design flaw with multi-message requests. Give me some ideas or line up to help scrape the egg off my face. Regards, Dennis -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Thursday, October 14, 2004 4:24 AM To: [EMAIL PROTECTED] Subject: Re: browse question I would question WHY you would be browsing a queue with the characteristics as has been mentioned here. Why would you browse a queue that is the target of a fee-ing frenzie. If there are so many messages being delivered to the queue, no one taking message off of it that you run the risk of never hitting the bottom, then maybe your solution is not the correct one. If you are browsing, you would expect to bottom out sonner or later, most likly sooner. If that is not your expectation so you can reissue the browse with FISRT the process should be implemented another way. All feeder and no consumer is a database. bobbee From: Darren Douch [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: browse question Date: Thu, 14 Oct 2004 11:19:27 +0100 MessageOne potential trick, but not one I'm seriously recommending - on every msg you browse, also do a get under syncpoint, but don't commit. When you restart the browse, the msgs you've already browsed/got would not be visible (but you might have a large unit of work outstanding!). Oh well, at least we all know that you have to be far more careful with browse than maybe we realised. Shame that the reality of the implementation doesn't match what intuition tells you it means. Best wishes Darren - Original Message - From: Miller, Dennis To: [EMAIL PROTECTED] Sent: Wednesday, October 13, 2004 6:37 PM Subject: Re: browse question I'm with you. Browsing is a simple concept and it should work as intuitively expected. It should not be fraught with gotcha's or pitfalls and should not precipate yet another bag of programming tricks. Frankly, given what we know now, I'm at a loss for a programming trick that even solves the problem and would be interested in hearing if anyone has one. You mention arbitrarily restarting the browse cursor (and I've considered it's variant--always using browse first). But how do you then avoid the potential of browsing the same message more than once in a logical pass of the queue? Consider a simple model with the CICS bridge browsing the queue and initiating a CICS transaction for each message. I understand, that ultimately we can only consume each message once. But how do we structure things so that we reliably don't attempt to consume the same message more than once? When the browse cursor restarts, there is no way to distinquish messages that have been browsed from those that have been skipped by the previous pass of the queue. How can we be sure we don't have pending transactions designated to process messages that get picked up in the subsequent pass? I find it quite disconcerting that an unqualified browse next can return 2033 when there are still messages on the queue. On a brighter note, I seriously doubt we have the same issue with destructive reads; if we do, it's time to pack it in. regards, Dennis -Original Message- From: Darren Douch [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 13, 2004 3:46 AM To: [EMAIL PROTECTED] Subject: Re: browse question Restarting the browse becomes essential rather than 'merely' good practice once you've read the manual, otherwise you'll certainly end up with messages only getting processed at application restart which is unlikely to be desirable! But yes, with a busy queue you might never go back to the start, so you have to restart the browse after some arbitrary number of msgs, just in case there are some you've missed. Didn't realise browsing was as tricky as this... better go and check that destructive reads don't work in the same way! Regards Darren - Original Message - From: Miller, Dennis To: [EMAIL PROTECTED] Sent: Tuesday, October 12, 2004 10:24 PM Subject: Re: browse question Yikes. I think it is a good practice to routinely restart the browse first after you get to the
