Re: data conversion OS300 to AS400
thanks "Potkay, Peter M (ISD, IT)" To: [EMAIL PROTECTED] <[EMAIL PROTECTED]cc: RTFORD.COM>Subject: Re: data conversion OS300 to AS400 Sent by: MQSeries List <[EMAIL PROTECTED] AC.AT> 09/30/2004 04:21 PM Please respond to MQSeries List The ! is one of the characters that CCSID 500 has a problem with for some reason. CCSID 037 is OK with it. What CCSID is your QM on z/OS set to? -Original Message----- From: Randy J Clark [mailto:[EMAIL PROTECTED] Sent: Thursday, September 30, 2004 7:14 PM To: [EMAIL PROTECTED] Subject: data conversion OS300 to AS400 It appears that MQ on the OS390 host side translates an exclamation point (!, hex 5A) to hex BB when sending to AS/400. Is that possible ? The text field containing HAZMAT! which is MQPUT then when you view this text in the message queue over on the AS/400, it's changed to HAZMAT]. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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
data conversion OS300 to AS400
It appears that MQ on the OS390 host side translates an exclamation point (!, hex 5A) to hex BB when sending to AS/400. Is that possible ? The text field containing HAZMAT! which is MQPUT then when you view this text in the message queue over on the AS/400, it's changed to HAZMAT]. 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 manuals
http://www-306.ibm.com/software/integration/mqfamily/library/manualsa/ Nick Dilauro <[EMAIL PROTECTED]To: [EMAIL PROTECTED] >cc: Sent by: MQSeriesSubject: MQ manuals List <[EMAIL PROTECTED] N.AC.AT> 08/09/2004 02:46 PM Please respond to MQSeries List Could someone please direct me to the IBM web page for manuals. I lost my previous links. I tried searching the IBM site, but it's the worst thing I've ever encountered on the Web. 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: Debugging Help on OS/390 Needed
Are they getting with wait for specific message or hoping the first message returned is the one they are waiting on. I hope they are waiting on a specific message retrieving my correlid or something. They better find a way to get rid of expired messages from the applications that returned a message after the wait ended. I forgot the rules for using expiry and do not have time to look it up. I think any browse will delete the expired messages not sure if a get by correlid will do this but it sure seems if they are getting the wrong messages they are not getting by correlid and are hoping for all theings to fall into the proper sequence. I know this is all pretty basic and not what you are asking but maybe it will trigger some other ideas. Jim Ford <[EMAIL PROTECTED]To: [EMAIL PROTECTED] M> cc: Sent by: MQSeriesSubject: Debugging Help on OS/390 Needed List <[EMAIL PROTECTED] N.AC.AT> 07/14/2004 04:15 PM Please respond to MQSeries List One of our less savvy application teams has put together a big, clumsy app that is having problems. It's big and clumsy enough that they are having problems describing it to me. As near as I can tell, they have an MQ-enabled CICS transaction. This transaction does an EXEC CICS LINK to a few subprograms. Those programs in turn LINK to more programs. Or some of them may do one or more synchronous MQ round trips to get information. They say it is about 5 "layers" deep. Problems have surfaced lately where their app is slowing down and/or failing. In some cases info is returned from a different loan than the end user is working on. To try to fix it, they changed a bunch of their get-with-waits to wait longer. Things still fail, but now take longer to fail. So there's obviously some problem in their code, probably where they are losing replies somehow. They, of course, feel they've proven it's an MQ problem, and have dumped it on me. These are all synchronous processes, with non-persistent messages and many dynamic reply queues. It's really difficult to capture any relevant information. Even our CICS monitor isn't much help, because some of these CICS transactions stay up all day and process hundreds of messages. Any tips on how to get my hands on something I can use to debug this? 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: Transaction Names
insightful as always "Miller, Dennis" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] OM> cc: Sent by: MQSeriesSubject: Re: Transaction Names List <[EMAIL PROTECTED] N.AC.AT> 06/23/2004 02:10 PM Please respond to MQSeries List Hmmm...I do believe in the notion that a queue is a (very) special case of a database. However, in this respect I think they are (very) different. Relational tables typically have a formal structure that constrains their content to the purposes for which they were designed. MQ queues (setting aside the MD), have are unstructured, which means their content is comparatively freeform and unrestricted. Theoretically, any queue can contain anything, which begs a tough question about naming queues after what they contain. Take an XMITQ, for example. No one names an XMITQ after what it contains. The closest I can come would be something like: "x.MESSAGES.BOUND.FOR.QMGRx". Or a bridge queue: "x.TRANSACTION.REQUESTS". Or the DLQ: "x.MESSAGES.WITH.NO.PLACE.TO.GO". Or an INITQ: "x.TRIGGER.MESSAGES". Certainly we can (and usually do) assert some discipline over what kind of messages go to which queues. But the urge to name them accordingly is a mindset that can paint you into a corner. Suppose we have yourapp.ORDER.AMENDMENTS and then we want to serve functionality for order creation from the same queue? In your case (RE: YOURAPP.TRANSACTION_NAME) is it not possible for more than one transaction to be served from the same queue? Or what if we need to scale-up and have multiple queues for order amendments? (The subtle point is that, strictly speaking, "yourapp.ORDER.AMENDMENTS.2" is a deviation from the what-it-contains standard, as there is no such thing as an "order.amendments.2"). I offer a third alterntive. Rather than naming queues after what they DO or what they CONTAIN, how about mimicing the style used by MQ developers and naming queues after what they ARE? For example: QMGRx.HISPEED.XMITQ CICSx.BRIDGEQ QMGRx.DEAD.LETTERQ QMGRx.BATCH.INITQ myapp.ERROR.COLLECTIONQ myapp.INBOUND.TRANSFERQ myapp.COMMON.SUBSCRIPTIONQ myapp.SILname.REQUESTQ myapp.username.DYNAM.REPLYQ Instead of: myapp.ORDER.AMENDMENTS use: myapp.programname.REQUESTQ Now, before getting too excited, it's important to understand one more thing. You gave us the paradigm MYAPP.TRANSACTION_NAME -> YOURAPP.TRANSACTION_NAME which is mapped by qremotes/qaliases. The above suggestion pertains only to the QLOCAL definition which is exclusive to the "->YOURAPP" side. I absolutely do not suggest the same convention for the "->MYAPP" side which corresponds to the QREMOTE/QALIASes. Over there, we need a different kind of queue identity convention that is independent of the physical implementation. There, it makes perfect sense to name queues according to content, or more correctly, message structure. I like to think of message structures as defined by "contract". For example, there would be a contract for order amendments (that may involve one or more message formats) and another for order creation. I would go so far as to suggest that each contract be assigned a different QALIAS/QREMOTE name even if they are originally intended for the same queue. Regards, Dennis -Original Message- From: John Scott [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 23, 2004 9:55 AM To: [EMAIL PROTECTED] Subject: Re: Transaction Names Thanks for that little "sound byte" - I like "queues do not do anything". I agree with you. My reasoning is that, like database tables and class names, they're typically named after what they contain, not what they do. You would have an "ORDER_AMENDMENT" table which is used by the "update_order" program to update orders in the database. Likewise, the update_order program would have an instance of the "OrderAmendment" class passed to the "updateOrder" method of an instance of the "Order" class to update the order. Regards John Scott IBM Certified Specialist - MQSeries Argos Ltd -Original Message- From: Randy J Clark [mailto:[EMAIL PROTECTED] Sent: 22 June 2004 18:10 To: [EMAIL PROTECTED] Subject: Re: Transaction Names Our queues are named after what it is - we describe the contents of the queue... because a queue does not "do" anything. John Scott <[EMAIL PROTECTED]
Re: Transaction Names
Our queues are named after what it is - we describe the contents of the queue... because a queue does not "do" anything. John Scott <[EMAIL PROTECTED]To: [EMAIL PROTECTED] .CO.UK> cc: Sent by: MQSeriesSubject: Transaction Names List <[EMAIL PROTECTED] N.AC.AT> 06/22/2004 01:29 AM Please respond to MQSeries List I have already posted this question on mqseries.net, but I wondered if I would get some more responses on the list server... I am not looking for ideas on general MQSeries naming standards, I already have those and there are enough examples in the archives to keep anybody happy. Our queue naming standard is basically APP_NAME.TRANSACTION_NAME. Where APP_NAME is the name of the application that is allowed access to the queue. We use alias/remote queue definitions to wire up MYAPP.TRANSACTION_NAME -> YOURAPP.TRANSACTION_NAME I am now looking in detail at the TRANSACTION_NAME. When I look at the queues we have I see a mixture of TRANSACTION_NAME styles - some of them are named after what the message content is (i.e. ORDER_AMENDMENT) and others are named after what the applications (typically the receiving application) does with the data (i.e. UPDATE_ORDER). Thus we would have a queue called: MYAPP.ORDER_AMENDMENT or MYAPP.UPDATE_ORDER I wanted to canvas whether people preferred the "what it is" over "what it does" or vica-versa. Which style do you use and why? Regards John Scott IBM Certified Specialist - MQSeries Argos Ltd. ** Click here to visit the Argos home page http://www.argos.co.uk The information contained in this message or any of its attachments may be privileged and/or confidential, and is intended exclusively for the addressee. Unauthorised disclosure, copying or distribution of the contents is strictly prohibited. The views expressed may not be official policy, but the personal views of the originator. If you have received this message in error, please advise the sender by using the reply facility in your e-mail software. All messages sent and received by Argos Ltd are monitored for viruses, high-risk file extensions, and inappropriate content. 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: MQ question
I would search the archives but you might try code page 037 I think it is. http://www.mail-archive.com/mqseries%40akh-wien.ac.at/index.html http://www.mqseries.net/phpBB2/ Fred Bohle <[EMAIL PROTECTED]To: [EMAIL PROTECTED] YS.COM> cc: Sent by: MQSeriesSubject: MQ question List <[EMAIL PROTECTED] N.AC.AT> 03/05/2004 03:01 PM Please respond to MQSeries List To the list: I hope you can help me, because Hursley labs will have gone home by now. I am trying to send XML over MQ, and am having a problem with '!' characters. The default CCSID seems to be 500, which is the only codepage I see with square close bracket for x'5A'. Codepage 500 has ! at x'4F'. As a result, clients receive square brackets instead of exclamation points. Do you have any idea why the default is codepage 500? How do others handle sending XML with headers? Fred Bohle NEON Systems, Inc. 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
[no subject]
Wow is this ever a shot gun approach. Blindfold in place? Check. Then ready, aim, fire! Hashim Khan <[EMAIL PROTECTED]To: [EMAIL PROTECTED] COM> cc: Sent by: MQSeriesSubject: List <[EMAIL PROTECTED] N.AC.AT> 03/04/2004 01:56 PM Please respond to MQSeries List Hi There, Is it possible to have an 30 days evalation copy of Seebeyond software so that I can try test it with MQ Thanx in advance __ Do you Yahoo!? Yahoo! Search - Find what you re looking for faster http://search.yahoo.com 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: A novice question--THE SAGA CONTINUES
I may have missed the prior posting but I believe you may need to supply more information before you'll get any meaningful responses. Are your programs using syncpoint, are the messages persistent. Things such as this are important. Could you block more than one row into a message in a message. You mention once all the messages are put to the data Q then the proper program on the mainframe will be triggered via a triggerQ. Why wait till then to start processing the data? If you hold the processing of the data until all the messages have been sent saying MQ processes only 35 messages a second seems hardly fair. "Kinzler, Raymond C" To: [EMAIL PROTECTED] Subject: A novice question--THE SAGA CONTINUES Sent by: MQSeries List <[EMAIL PROTECTED] N.AC.AT> 03/02/2004 11:56 AM Please respond to MQSeries List Hello, Thanks for all the help, by the way. We have been successful in addressing the 2033 errors and are now onto the next stage of our project. Actually, by trying to do this project, we found the aforementioned 2033 problem. Basically, this is what we are trying to do... The applications people want to parse various Excel spreadsheets into text files on a server and pass those files to the mainframe utilizing MQ Series. This seems to suck up a HUGE amount of resources and is very slow. I don't know if it is a setting someplace, the way we are extracting the data, or what it is. The file gets translated into a .TXT file and every 'row' becomes a record on the ECL.DATA.REQUEST queue on the server. Once the LAST row has been PUT on the ECL.DATA.REQUEST queue, a record is written to the trigger queue (ECL.DATA.REQUEST). The proper program is kicked off on the mainframe side which will perform an MQGET on each ECL.DATA.REQUEST record and post that record to a file on the mainframe. That's it. We even tweaked this program to simply perform MQGETs and nothing else to try and achieve maximum throughput. BUT...the absolute best we can process these records is 35 records per second. This is EXTREMELY slow because the user will frequently have upwards of 10,000 rows on the spreadsheet. That comes out to almost five minutes--too long for something like this because the user will exit the web screen before that amount of time (we have very impatient users and most of them, by far, are outside distributors and we have little to no control over their habits. I say this is a BATCH process and should be treated like a BATCH process.. our current MQ process is set up to mimic on-line screens and we would abuse everything if we use it for this process, too. On the other hand, we have a person here who says she knows MQ Series and it works MUCH faster than 35-records-per-second. I agree it seems somewhat slow and it makes sense that we could improve upon it but this process, in general is batch-oriented (in my opinion). Is there anything we can do to increase the throughput? Or should we stick to FTPing the file to a GDG on the mainframe? Many thanks! Ray Kinzler 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: MQ Triggering in CICS
Did you check all the fields in the eib block it seems to me there should be a clue or two in there. I'd look in the EIBTRNID or EIBTRMID first. "DeBlassio, Joe" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] -MINOR.COM> cc: Sent by: MQSeries Subject: Re: MQ Triggering in CICS List <[EMAIL PROTECTED] C.AT> 03/02/2004 05:56 AM Please respond to MQSeries List John, Perform the following CICS RETRIEVE at the beginning of your program and check the RTRANSID. If it contains the value CKTI, then you know that the trigger monitor started your program. EXEC CICS RETRIEVE SET (ADDRESS OF MQTM) LENGTH (LENGTH OF MQTM) RTRANSID (VARIABLE-RTRANSID) RESP (VARIABLE-EIBRESP) END-EXEC. Make sure you include copybook CMQTML in your linkage section. And define the variables in working storage. Good luck, Joe -Original Message- From: Dawson, John [mailto:[EMAIL PROTECTED] Sent: Monday, March 01, 2004 3:19 PM To: [EMAIL PROTECTED] Subject: MQ Triggering in CICS Folks, In a CICS program, how can I tell that the CICS program was started from a MQ trigger? Thanks, John Dawson 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: "Trigger-looping" CICS transaction
subtle very subtle... In other words 'its not a good idea for applications to write directly to the DLQ'. "Potkay, Peter M (PLC, IT)" To: [EMAIL PROTECTED] <[EMAIL PROTECTED]cc: RTFORD.COM>Subject: Re: "Trigger-looping" CICS transaction Sent by: MQSeries List <[EMAIL PROTECTED] AC.AT> 02/23/2004 12:50 PM Please respond to MQSeries List What reason code do they put in the DLH? -Original Message- From: Adiraju, Rao [mailto:[EMAIL PROTECTED] Sent: Monday, February 23, 2004 3:43 PM To: [EMAIL PROTECTED] Subject: Re: "Trigger-looping" CICS transaction As a design principle, we set the following standard to our developers: Every GET should check the back-out count and if it is greater than BOTHRESH (threshold counter) or hardcoded no.of tries (some cases), application should check for BOQNAME and put the message in that queue if specified else put the message in dead-letter queue. This will prevent the never ending retries / triggering. Cheers Rao Adiraju WebSphere MQ Specialist The National Bank of NZ Ltd. Wellington - New Zealand Tel: +64-4-494 4299 Fax: +64-4-802 8509 Mbl: +64-211-216-116 -Original Message- From: Miller, Dennis [mailto:[EMAIL PROTECTED] Sent: 24 February 2004 8:45 AM To: [EMAIL PROTECTED] Subject: Re: "Trigger-looping" CICS transaction I have to step back and re-think what you are really asking. I can hardly imagine a scenario that makes sense to just skip over a bad message. You can either use CICS abend/error handlers to detect errors proactively or catch them after a rollback by checking the backout count (as others have mentioned). But in either case, you usually should shuttle the message off to an error queue. Otherwise, you eventually read all the good messages and end up with the bad message right back at the top of the queue again. Since the triggering mechanism goes to great lengths to re-trigger as long as there are messages still on the queue, you really haven't solved the looping problem until the bad message has been removed. Sometimes a transient condition can cause a message to fail. In other words--the right message at the wrong time. The message has a reasonable chance to work if given another chance later. In that case, it may make sense to put the message back to the triggered queue so it has a chance to try again later. But generally speaking, when you encounter a bad message, consider yourself fortunate to have recognized the error while under program control and do something proactive with the message. I hesitate to even bring this up, but you can browse past a bad message. Your main program could browse through the queue, consuming messages only after they have passed muster and leaving the rest for later. But should your program ever close the queue, it would immediately re-trigger and try to re-work the bad messages. Regards, Dennis -Original Message- From: Chase, John [mailto:[EMAIL PROTECTED] Sent: Friday, February 20, 2004 10:19 AM To: [EMAIL PROTECTED] Subject: "Trigger-looping" CICS transaction Hi, All, No response from thw Web archives server, so apologies if this has been answered recently. Our application folks are testing a program that processes incoming messages, and they are working thru their error-handling routines. In certain circumstances the error routines terminate the CICS transaction without "physically removing" the incoming message from the application queue. Whenever this "early exit" occurs, the same transaction is immediately re-triggered, and since one test situation involved "hard-coding" an error into the program, the same transaction is continually invoked to process the same message as soon as the "previous" transaction terminates. The message queue is defined with trigger-on-first and triggering enabled. Environment is z/OS 1.4, WMQ 5.3.1 and CICS TS 2.2. Anybody have any ideas how we can prevent this "looping" behavior without removing the message from the incoming queue? TIA, -jc- 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 This communication is confidential and may contain privileged material. If you are not the intended recipient you must not use, disclose, copy or retain it. If you have received it in error please immediately notify me by return email and delete the emails. Thank you. Instructions for managing your mailing list su
Re: link listed libraries
http://publibfp.boulder.ibm.com/epubs/pdf/igy3pg00.pdf CALL PROGRAM Making static calls When you use the CALL literal statement in a program that is compiled using the NODYNAM and NODLL compiler options, a static call occurs. CALL 'program' Making dynamic calls When you use the CALL literal statement in a program that is compiled using the DYNAM and the NODLL compiler options, or when you use the CALL identifier statement in a program that is compiled using the NODLL compiler option, a dynamic call occurs. The program name in the PROGRAM-ID paragraph or ENTRY statement must be identical to the corresponding load module name or load module alias of the load module that contains it. In this form of the CALL statement, the called COBOL subprogram is not link-edited with the main program, but is instead link-edited into a separate load module, and is loaded at run time only when it is required (that is, when called). "Bullock, Rebecca (CSC)" To: [EMAIL PROTECTED] <[EMAIL PROTECTED]cc: >Subject: Re: link listed libraries Sent by: MQSeries List <[EMAIL PROTECTED] N.AC.AT> 02/05/2004 01:26 PM Please respond to MQSeries List Dave, I'm not a Cobol person, so I'm not sure off the top of my head. That's one of those things I always have to look up when a programmer stops by with a problem/question. -Original Message- From: Dave Adam [mailto:[EMAIL PROTECTED] Sent: Thursday, February 05, 2004 4:01 PM To: [EMAIL PROTECTED] Subject: Re: link listed libraries Rebecca now I am wondering if CALL 'program'is static and CALL PROGRAM is dynamic Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] A lone amateur built the Ark. A large group of professionals built the Titanic -- "Bullock, Rebecca (CSC)" <[EMAIL PROTECTED]> To: Sent by: MQSeries List [EMAIL PROTECTED] <[EMAIL PROTECTED]> cc: Subject:Re: link listed libraries 02/05/2004 01:32 PM Please respond to MQSeries List Dave, did you remember to refresh LLA? -Original Message- From: Dave Adam [mailto:[EMAIL PROTECTED] Sent: Thursday, February 05, 2004 1:52 PM To: [EMAIL PROTECTED] Subject: link listed libraries to get the QMGR name out of the SYSPlex we put a routine in SYS1.PP.LINKLIB made it a dynamic call in the program but can't seem to get it to work (when I do get it to work, the MQCONN call does not work) now if I concatenate SYS1.PP.LINKLIB in the STEPLIB, all works fine has anyone experienced problems with dynamic calls to programs from link listed libraries Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] A lone amateur built the Ark. A large group of professionals built the Titanic -- ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibit
Re: MQ Usergroup(s) in the Land of Middle Earth
Maybe you should tell us to ignore your message in the subject not in the body of the message. Since you seem to hate out of office replies you should appreciate this recommendation. Heck atleast the out-of-office messages are obvious and are easily deleteable without having to open the message. Next pet peeve to be attacked is message boards where the idiot puts EOM in the body - gee thanks I have to open the post to see 'EOM' these idiots should put the 'EOM' in the subject line. "Adiraju, Rao" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] .CO.NZ> cc: Sent by: MQSeriesSubject: MQ Usergroup(s) in the Land of Middle Earth List <[EMAIL PROTECTED] N.AC.AT> 02/05/2004 12:46 AM Please respond to MQSeries List For those who are NOT in the "Middle Earth" please ignore this message: Is there any MQ Usergroup(s) in New Zealand - I recently moved from "Down under" to "Middle Earth" and is looking forward to catch up with fellow WMQers. Cheers Rao Adiraju WebSphere MQ Specialist The National Bank of NZ Ltd. Tel: +64-4-494 4299 Fax: +64-4-802 8509 Mbl: +64-211-216-116 This communication is confidential and may contain privileged material. If you are not the intended recipient you must not use, disclose, copy or retain it. If you have received it in error please immediately notify me by return email and delete the emails. Thank you. 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: What CCSIDs should I use?
here is a previous string that seems to discuss a problem similar to yours. this link maybe helpful. http://www.mail-archive.com/[EMAIL PROTECTED]/msg12277.html Ruzi R <[EMAIL PROTECTED]To: [EMAIL PROTECTED] M> cc: Sent by: MQSeriesSubject: Re: What CCSIDs should I use? List <[EMAIL PROTECTED] N.AC.AT> 02/02/2004 10:45 AM Please respond to MQSeries List I have done the testing on Win2K servers having WMQ 5.2 or 5.3 with CSD03 and the conversion happened correctly in each case. This means that CSD05 is the culprit. We will open a PMR with IBM. Ruzi --- Ruzi R <[EMAIL PROTECTED]> wrote: > I have an WMQ application that sends character data > from OS/390 (MQ 5.3, CCSID 37) to Win2K (MQ 5.3 > CSD05, > CCSDI 437). VB app on Win2K specifies MQGMO_CONVERT > on > e MQGET. All of the data is converted correctly > except > for the following special characters (which I have > shown in quotes. These characters do not get > translated at all: > > > "<|"CDATA"" --> should be translated as > "" (instead > of > "!!>") > > Can someone help, please? Is there a documentation > that specifies the character-to-character mapping > between the CCSIDs? > > Thanks, > > Ruzi > > > > > > 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: MQ Client - Minimum requirmnet for
first question: Is to ask is does your mainframe have the client attachment facility if not the other issues do not matter. If you do not know if you have the CAF you probably don't. "Nushi M." <[EMAIL PROTECTED]To: [EMAIL PROTECTED] com> cc: Sent by: MQSeriesSubject: MQ Client - Minimum requirmnet for List <[EMAIL PROTECTED] N.AC.AT> 01/09/2004 03:27 PM Please respond to MQSeries List I need to run an MQ client application on Win 2000 to connect to mainframe. What is the minum requirment needed to be installed on the user pc to be able to connect to mainframe. I do not want to install the whole MQ Client files on thier pcs. Only what is required to run the application. Thanks all. Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes 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: Triggering Design Question
How about using a COA (confirmation of delivery report message) Jim Ford <[EMAIL PROTECTED]To: [EMAIL PROTECTED] M> cc: Sent by: MQSeriesSubject: Triggering Design Question List <[EMAIL PROTECTED] N.AC.AT> 12/22/2003 10:40 AM Please respond to MQSeries List I got an interesting triggering dilemma. The short description of the dilemma is that when a message arrives on a Solaris queue, I need to trigger an OS/390 process. The longer description follows... We've purchased Tivoli 8.2, which is allows us to run a unified scheduling system between Unix and OS/390. It runs on OS/390 and lets us schedule jobs on both platforms, manage dependencies between the platforms, etc. But we've got some Solaris queues where we need to get a Solaris job "demanded in" in order to process the messages. With Tivoli, the process of demanding the job must run on the mainframe. I was hoping to just define the mainframe's initq as a remote queue on Solaris. I was thinking that I'd define the process with APPLTYPE(MVS) on Unix, too. Then when a message hit the Solaris queue, a mainframe trigger message would get written, and routed up to OS/390, where our trigger monitor would process it and demand in the job. But as soon as I got going on it I remembered condition 8 for triggering. That is, in order to generate a trigger message the initq queue must be opened for input. And that's impossible in this design. How can I do it? I've dreamed up some complicated solutions, but I'd like to keep it simple, if possible. Note that we do not own the client connection feature on the mainframe, so that's not an option. 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: CCSID problems
At what age did Joe Dimaggio retire?
the answer to that question and your question are the same
037
DiMaggio, Joe
DiMaggio, Joe (Joseph Paul DiMaggio) Â(dÄmÄjÂÄÅÂÂ, âmÃjÂÄÅÂÂ) ,
1914â99,
American baseball player, b. Martinez, Calif. One of the most charismatic
of 20th-century sports figures, "Joltin' Joe" joined the New York Yankees
of the American League in 1936 and quickly rose to stardom, winning the
league's batting title with a .381 average in his fourth season. In a
career interrupted by World War II, the center fielder became the
celebrated epitome of grace and humility. In 1939, 1941, and 1947 he was
the American League's Most Valuable Player, and in 1941 the "Yankee
Clipper" established one of baseball's best-known records by hitting safely
in 56 consecutive games. He retired in 1951 and was elected to the Baseball
Hall of Fame in 1955. His quiet heroics and brief marriage (1954) to
Marilyn Monroe made him an icon of popular culture, although later
biographical study has tended to deflate that status to some degree.
"Ward, Mike"
<[EMAIL PROTECTED]>To: [EMAIL PROTECTED]
Sent by: MQSeriescc:
List Subject: CCSID problems
<[EMAIL PROTECTED]
N.AC.AT>
12/02/2003 12:53
PM
Please respond to
MQSeries List
Hello everyone. I am having a small problem. We are sending messages from
an
OS/390 mainframe to an NT MQseries box. The mainframe version of MQ is 5.3.
The NT version is 5.2.1 with the latest csd. The messages we sometimes send
from the mainframe have special characters such as an ! exclamation point
or
a [ right bracket , a ] bracket or the | pipe character. These do not seem
to be translated correctly on the ascii NT side. Is there anyway that I can
get MQ to do the conversion to the correct character when the read is done?
Any help appreciated.
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
žËk¹Ëb¢{ ¢¹š¨"ž ¨º¹šŠX§‚X¬¶Ë±Êâ¦ØªÞº/‰×Š{ax¸¬¶Ç¼g§z¶¥RÇ°k¢uæ¯j)ZnWš¶m§ÿðÃ
l¡û\¢`+r¯zm§ÿï!Â'§iÆüÄz¸ž±ªÜ+Þ
Re: Error 2087
application B (MQ 5.1 on Sun Solaris). Application B gets the message but
while attempting to replay back the following error occurs
the sending application Qmgr MQ 5.1 needs xmit queue to send back to MQ 5.3
of course defined on MQ 5.1 or the alias as described in a previous note.
The basic solution is a xmit quue to MQ 5.3 to send to MQ 5. 1
Alex Korenfeld
<[EMAIL PROTECTED]To: [EMAIL PROTECTED]
M> cc:
Sent by: MQSeriesSubject: Re: Error 2087
List
<[EMAIL PROTECTED]
N.AC.AT>
11/24/2003 02:53
PM
Please respond to
MQSeries List
Jim
Let me understand if I got it right. Should I double check if in 5.3 qmgr
configuration I have default transmit queue defined?
Since I have two different sender channels using 2 different transmit q I
Didn't defined any default transmit q in qmgr.
But my remote queue in 5.3 qmgr does have transmit queue defined.
Thanks
Alex.
-Original Message-
From: Jim Ford [mailto:[EMAIL PROTECTED]
Sent: Monday, November 24, 2003 4:34 PM
To: [EMAIL PROTECTED]
Subject: Re: Error 2087
If you MQOPEN the ReplyToQ and ReplyToQMgr what actually happens is that an
open is attempted for a transmit queue with the same name as the
ReplyToQMgr. You should check that the 5.3 qmgr does in fact have the
transmit queue defined.
Alex Korenfeld
<[EMAIL PROTECTED]To:
[EMAIL PROTECTED]
M> cc:
Sent by: MQSeriesSubject: Error 2087
List
<[EMAIL PROTECTED]
N.AC.AT>
11/24/2003 04:06
PM
Please respond to
MQSeries List
Hi
Did anybody else have the problem below before?
Scenario 1
Application A (MQ 5.1 on HPUX) send message (replay to queue) to
application B (MQ 5.1 on Sun Solaris). Application B gets message and
replays back without any problem.
Scenario 2
Application A (MQ 5.3 on HPUX) send message (replay to queue) to
application B (MQ 5.1 on Sun Solaris). Application B gets the message but
while attempting to replay back the following error occurs âMQException:
com.ibm.mq.MQException: Completion Code 2, Reason 2087
(MQRC_UNKNOWN_REMOTE_Q_MGR)â. We checked Q manager name and replay to queue
name in the message descriptor and looked absolutely valid.
Any help on this issue would be greatly appreciated.
Thanks
Alex.
-
The information contained in this message is proprietary of Amdocs,
protected from disclosure, and may be privileged.
The information is intended to be conveyed only to the designated
recipient(s)
of the message. If the reader of this message is not the intended
recipient,
you are hereby notified that any dissemination, use, distribution or
copying of
this communication is strictly prohibited and may be unlawful.
If you have received this communication in error, please notify us
immediately
by replying to the message and deleting it from your computer.
Thank you.
-
"{ç~jvxj) ánZvz'v)ÂKI×ijØ
àrÈèfI0zr
-
The informati
MQSeries and LOTUS Notes
If I have a queue on a UNIX Qmgr that I want to get the data out of and put into a LOTUS NOTES document. What are my options for programming languages other than Java ,C and C++. In others does LOTUS itself have a language or some what to interface with a queue managet. 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: data conversion if the channel is doing conversion do I need to set mqmd format to string?
thanks - that is what I thought. I searched the manuals but did not find anything to make me100% certain. "Gutekunst, Brant" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] UNGARD.COM> cc: Sent by: MQSeries Subject: Re: data conversion if the channel is doing List conversion do I need to setmqmd format to <[EMAIL PROTECTED] string? .AC.AT> 11/11/2003 11:42 AM Please respond to MQSeries List You still need to set format to string on the MQPUT. You do not have to specify MQGMO_CONVERT on the MQGET. -Original Message----- From: Randy J Clark [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 11, 2003 2:28 PM To: [EMAIL PROTECTED] Subject: data conversion if the channel is doing conversion do I need to set mqmd format to string? if the channel is doing conversion do I need to set mqmd format to string? Or will it convert the message data anyway? 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 CONFIDENTIALITY NOTICE: This E-Mail transmission may contain confidential or legally privileged information that is intended only for the individual(s)or entity(ies) named in the E-Mail address. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or reliance upon the contents of this E-Mail is strictly prohibited. If you have received this E-Mail transmission in error, please reply to the sender so that arrangements can be made for proper delivery, after which please delete the message from your inbox. Thank you 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
data conversion if the channel is doing conversion do I need to set mqmd format to string?
if the channel is doing conversion do I need to set mqmd format to string? Or will it convert the message data anyway? 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
The syncpoint option is ignored when browsing????????
"The syncpoint option is ignored when browsing" Is this a true statement? "Using the MQOO-BROWSE and not follwing it up with a MQGMO-BROWSE-FIRST, MQGMO-BROWSE-NEXT or MQGMO-BROWSE-MSG-UNDER-CURSOR is wasteful or serves no purpose." Is this a true statement? Wow as you can see I am confused about this Browse 'stuff'. The reason forthis confusion is I saw in a program the statement 'The syncpoint option is ignored when browsing' but yet the programmer is only using the browse open not the browse get options. MQOO-BROWSE. I do not see anywhere where it says just because the queue is opened in BROWSE messages will not be read destructively.It seems to me if the queue is opened for 'browse' and the GET is no syncpoint the messages are still read destructively that is unless a GMO-BROWSE-FIRST or MQGMO_BROWSE-NEXT option is not used for the MQGET. If one of these two GET options is used then I believe the message still is on the queue. I guess I am saying I think the MQOO-BROWSE has no affect on the destructive or not nature of the MQGET and its purpose is solely to create a browse cursor. To me the MQGMO-BROWSE-FIRST and MQGM-BROWSE-NEXT are the options that cause a message to be read nondestructively - not the MQOO-BROWSE option. I have a sneaking suspicion I am wrong. I see is the following in the APR: MQOO_BROWSE Open queue to browse messages. The queue is opened for use with subsequent MQGET calls with one of the following options: MQGMO_BROWSE_FIRST MQGMO_BROWSE_NEXT MQGMO_BROWSE_MSG_UNDER_CURSOR This is allowed even if the queue is currently open for MQOO_INPUT_EXCLUSIVE. An MQOPEN call with the MQOO_BROWSE option establishes a browse cursor, and positions it logically before the first message on the queue; see the Options field described in Chapter 7, MQGMO - Get-message options for further information. This option is valid only for local, alias, and model queues; it is not valid for remote queues, distribution lists, and objects which are not queues. It is also not valid if ObjectQMgrName is the name of a queue manager alias; this is true even if the value of the RemoteQMgrName attribute in the local definition of a remote queue used for queue-manager aliasing is the name of the local queue manager. Seems to me if I open in Browse mode and issue a syncpoint the messages should still be 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
can two processes both get the same message
I want to have mulitple instances of the same long running process executing. I want them NOT to retrieve the same messages - period. For instance if only messages arrives on the queue and I have two processes reading it both waiting for a message will they both retrieve the same message or will one get the message and the other gets nothing. What open options do I use MQOO_INPUT_SHARED The just GET with the GMO-SYNCPOINT 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 data conversion
Wow thanks for your awesome explanation... I am not worthy. "Potkay, Peter M (PLC, IT)" To: [EMAIL PROTECTED] <[EMAIL PROTECTED]cc: RTFORD.COM>Subject: Re: message data conversion Sent by: MQSeries List <[EMAIL PROTECTED] AC.AT> 11/02/2003 07:15 PM Please respond to MQSeries List Conversion happens because you ask for it explicitly, not because the format of the message is set to some value. If you want conversion, the getting app should specify that option on the MQGET call. If that step is not done, there is no conversion attempt, regardless of what the format field is. If the convert option has been requested (either by the getting application (or the channel - ack!)), then the conversion exit called is determined by what is in the format field. If you ask for conversion, and you set the format field to "MQSTR", then you are telling MQ to call the conversion routine for messages of type string. That conversion exit will be able to convert a text string from one code page to another. If you specify the convert option, but the format field is left initialized (no value supplied for format), MQ doesn't know what type of data may be in the buffer, and so it skips the conversion attempt, even though your get option asked for it. You will get a Warning completion code in this case. If the format is a built-in format (like MQSTR), the buffer is passed to the queue-manager's data-conversion service. If the format is not a built-in format, the buffer is passed to a user-written exit which has the same name as the format. If the exit cannot be found, the message is returned unconverted, with completion code MQCC_WARNING and reason code MQRC_FORMAT_ERROR. In other words, you could have a conversion exit called RANDY, and anytime a message came through with a format of RANDY, and you specified convert, your conversion exit RANDY would be called. A polite sending application will always set the format field properly just in case some other app downstream will ask for conversion, unless the sending app specifically does not want conversion. I once had an app that did not know if the next message it was about to get was a PDF file (no conversion needed - binary data) or a text message with the reason why the remote machine did not send the PDF (conversion needed). In this case, the receiving app always asked for convert. If it got a text error message in the MQ message, convert happened and it was happy. If it was a PDF file, convert did not happen because the MQ messages that had PDF files in them had a format of none. (The receiving app coded for the MQCC_WARNING completion code and MQRC_FORMAT_ERROR in these cases and ignored them). As far as could you ever have problems between the AS/400 and the OS/390, I am not sure, but I would say you can. As soon as you send one of the characters that would need conversion, you will see the problem. If you continue down your present course and luckily do not send anything that doesn't happen to need conversion, you are OK. Read Appendix F of the Application Programming Reference Manual. The whole section is on nothing but conversion. Interesting reading about something most of us take for granted - how MQ converts and thus ties all these weird systems together. http://publibfp.boulder.ibm.com/epubs/html/csqzak08/csqzak08tfrm.htm -Original Message- From: Randy J Clark [mailto:[EMAIL PROTECTED] Sent: Friday, October 31, 2003 9:12 PM To: [EMAIL PROTECTED] Subject: message data conversion I have a program that sends data from an OS390 to an AS400 box. It does NOT set any of the field below The default values are Numeric encoding of message data MQMD-ENCODING PIC S9(9) BINARY VALUE 785. Character set identifier of message data MQMD-CODEDCHARSETID PIC S9(9) BINARY VALUE 0. Format name of message data MQMD-FORMAT PIC X(8) VALUE SPACES. I am assuming because both the AS400 and the OS390 are EBCDIC machines and the MQMD-format is not set to STRING no conversion is attempted on the message data area. I am also assuming that even though the code pages between our OS390 and our AS400 are different they are enough the same that so far we are having no problems. Could we ever have problems? Is it a good idea to always specify the MQMD-CODEDCHARSETID and set the format to string if you want MQ to do conversion. If the MQMD-FORMATis not STRING then no conversion is attempted, correct? I always code the following to insure proper conversion of the data portion of the message -do I need to do this? MOVE MQCCSI-Q-MGR TO MQMD-CODEDCHARSETID. MOVE MQENC-NATIVE TO MQMD-ENCODING. MOVE MQFMT-STRING
message data conversion
I have a program that sends data from an OS390 to an AS400 box. It does NOT set any of the field below The default values are Numeric encoding of message data MQMD-ENCODING PIC S9(9) BINARY VALUE 785. Character set identifier of message data MQMD-CODEDCHARSETID PIC S9(9) BINARY VALUE 0. Format name of message data MQMD-FORMAT PIC X(8) VALUE SPACES. I am assuming because both the AS400 and the OS390 are EBCDIC machines and the MQMD-format is not set to STRING no conversion is attempted on the message data area. I am also assuming that even though the code pages between our OS390 and our AS400 are different they are enough the same that so far we are having no problems. Could we ever have problems? Is it a good idea to always specify the MQMD-CODEDCHARSETID and set the format to string if you want MQ to do conversion. If the MQMD-FORMATis not STRING then no conversion is attempted, correct? I always code the following to insure proper conversion of the data portion of the message -do I need to do this? MOVE MQCCSI-Q-MGR TO MQMD-CODEDCHARSETID. MOVE MQENC-NATIVE TO MQMD-ENCODING. MOVE MQFMT-STRING TO MQMD-FORMAT. 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
If MQPUT not under syncpoint what affect does MQCMIT have
If MQPUT not under syncpoint what affect does MQCMIT have sorry for being lazy but I am sure many know off the top of their heads. My guess its useless 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
trigger message persistence
How is it determined or set? 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: Persistence/UOW/syncpoints
thanks for the perfect even I can understand replies and speedy too! "Wyatt, T. Rob" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] MERICA.COM> cc: Sent by: MQSeries Subject: Re: Persistence/UOW/syncpoints List <[EMAIL PROTECTED] C.AT> 10/02/2003 02:09 PM Please respond to MQSeries List Randy, Depends on NPMSPEED parameter, for those versions and platforms that support it. NPMSPEED(FAST) may lose messages. From the manual: If a channel terminates while fast, nonpersistent messages are in transit, the messages may be lost and it is up to the application to arrange for their recovery if required. If the receiving channel cannot put the message to its destination queue then it is placed on the dead letter queue, if one has been defined. If not, the message is discarded. See: http://publibfp.boulder.ibm.com/epubs/html/csqzae09/csqzae090o.htm#HDRFASTSE C and: http://publibfp.boulder.ibm.com/epubs/html/csqzae09/csqzae091m.htm#HDRATTNPM S -- T.Rob -Original Message----- From: Randy J Clark [mailto:[EMAIL PROTECTED] Sent: Thursday, October 02, 2003 4:24 PM To: [EMAIL PROTECTED] Subject: Persistence/UOW/syncpoints If a message is non-persistent and MCA's have a problem sending/receiving the messages and the transmission of the batch was unsuccessful is the batch still on the senders xmit queue or is that batch lost. Or am I confusing to different things syncpoint and persistence and the MCA's use their own syncpoint to handle transmission and if the syncpoint is unsuccessful the messages will remain on the transmission queue 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
Persistence/UOW/syncpoints
If a message is non-persistent and MCA's have a problem sending/receiving the messages and the transmission of the batch was unsuccessful is the batch still on the senders xmit queue or is that batch lost. Or am I confusing to different things syncpoint and persistence and the MCA's use their own syncpoint to handle transmission and if the syncpoint is unsuccessful the messages will remain on the transmission queue 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
Message Persistence.
I am assuming PUT application is using platform default. Message Persistence. If I write to an AliasQ defined with the default persistence of persistent. Then local queue it resolves is defined with a default not persistent. Is the rule the object persistence is from the first queue named and the message will continue to have this persistence through out the life of the message. What about an AliasQ (not persistent) pointing to an RemoteQ (not persistent) to an XmitQ that is defined as persistent. What will the message persistence be. 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: Lost messages
Nick Dilauro <[EMAIL PROTECTED]To: [EMAIL PROTECTED] >cc: Sent by: MQSeriesSubject: Re: Lost messages List <[EMAIL PROTECTED] N.AC.AT> 09/29/2003 03:33 PM Please respond to MQSeries List That's just the default persistence if the application chooses to use it. The application can explicitly set the persistence and the queue has no control over that. Nick -Original Message- From: Joe H. Smith [mailto:[EMAIL PROTECTED] Sent: Monday, September 29, 2003 2:19 PM To: [EMAIL PROTECTED] Subject: Re: Lost messages Yes we are using Sender/receiver pairs between the machines. I have included the screens showing the persistence = *yes. Is this where I should check? Am I missing something somewhere? Thanks in advance for everyone's help! Alias Queue Queue manager name . . . . . . : SDCA_QM Queue name . . . . . . . . . . : FF_AQ_WMS2.UPLOADS.SUN_PIX_P.WD0061 Queue type . . . . . . . . . . : *ALS Text 'description' . . . . . . : AQ220 Put enabled . . . . . . . . . : *YES Default message priority . . . : 0 Default message persistence . : *YES Default binding . . . . . . . : *OPEN Get enabled . . . . . . . . . : *YES Target queue . . . . . . . . . : FF_QRMT_WMS2.UPLOADS.SUN_PIX XMIT Queue Queue manager name . . . . . . : SDCA_QM Queue name . . . . . . . . . . : FF_QXMT_SUN.TO.PRDA_PIX Queue type . . . . . . . . . . : *LCL Text 'description' . . . . . . : QXMT00029 Put enabled . . . . . . . . . : *YES Default message priority . . . : 0 Default message persistence . : *YES Process name . . . . . . . . . : Joan Hughes IT Specialist Phone: 608-827-3523 Fax: 608-662-6523 I am only as strong as the cocktails I drink, the hairspray I use and the friends I have. Jim Wendorf <[EMAIL PROTECTED]To: [EMAIL PROTECTED] MUTUAL.COM> cc: Sent by: MQSeriesSubject: Re: Lost messages List <[EMAIL PROTECTED] n.AC.AT> 09/29/2003 04:05 PM Please respond to MQSeries List I am quessing that you are using sender/receiver channels between the two queue managers. Have you checked that the remote queue definition and the transmit queue have persistent of yes. How do you know that the actual messages being lost have persistent=yes? Jim "Joe H. Smith" To: [EMAIL PROTECTED] <[EMAIL PROTECTED] cc: M> Subject: Lost messages Sent by: MQSeries List <[EMAIL PROTECTED]> 09/29/2003 03:25 PM Please respond to MQSeries List We have a situation that I need help finding the cause. Application A running on Queue manager A on iSeries 5.1 sends messages to Application B running on Queue manager B on iSeries 5. MQ5.2 CSD07 on both machines We have found that when Queue manager B is down for IPL we will loose messages from Application A . These are persistent messages. I am looking for a way to track the messages from point a to point b. This will help prove this is either a MQ problem or a application issue. Joan Hughes IT Specialist (Embedded image moved to file: pic21424.gif) Phone: 608-827-3523 Fax: 608-662-6523 I am only as strong as the cocktails I drink, the hairspray I use and the friends I have. * [This message and its contents have been scanned for viruses] * (See attached file: pic21424.gif) 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: MessageQ
maybe this will help. http://www.mail-archive.com/mqseries%40akh-wien.ac.at/index.html Simon Higgins <[EMAIL PROTECTED]To: [EMAIL PROTECTED] ONNECT.COM> cc: Sent by: MQSeriesSubject: MessageQ List <[EMAIL PROTECTED] N.AC.AT> 09/29/2003 12:39 PM Please respond to MQSeries List Does anyone know what's happened to the version of MessageQ that let you scan the listserv database for MQ problems and their resolution? Is there a way to get to it from http://www.ebizq.net/vintage/messageq? If so then let me know as I used to find it really useful. S Higgins MIddleware Consultant @[EMAIL PROTECTED] 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: Outsourcing - my observations after my trip to India
If you are reducing costs and increasing your profits by reducing costs/wages are you developing markets, creating consumers, and increasing the size of the total economic pie? Or are you cannibalizing for the sake of profits and actually shrinking the size of the total economic pie. Absolutely your company may temporarily become more profitable. One thing that is certain while profits may be up overall pricing power will decrease. All Companies ultimately need disposable income in the hands of consumers. If a company is to grow and have pricing power these consumers need money. Cost reduction is the easy way out. In fact cost reduction is the lowest of the low hanging fruit used to return a company to profitability. The bottom line is LONG TERM growth is only sustainable by developing new markets. It used to be that economic downturns were used to reduce the froth created during the overheated periods of economic expansion. A company would reduce costs - the largest of these savings where always through layoffs, subsequently profits would improve and a company would start to spend these profits on capital improvements and the hiring of new employees. Now what happens if these profits are spent on foreign products and foreign workers. We have the jobless recovery that so many are claiming we are having now. Globalization will over time develop new markets - how much time - is anyones guess. One thing is for sure the effects of the new global economy will be painful to some (the current haves) and enjoyable for others(for the current have nots) . Will globalizing the economy expand the size of the pie or merely reallocate it? How many Mercedes or for that matter Nike cross trainers are those coders in Bangladesh or those assembling the Nike cross trainers buying. This is a highly complex issue. What drives profits. I would say demand I do not subscribe to some of our political leaders supply-side economics BS. I personally believe over time Globalization will be a good thing. However during this time of transition and uncertainty we should all admit no one really knows definitively what the long term effects will be on the US economy. The government while maybe not inacting protectionist legislation should at least monitor the situation and not act as if nothing is going on here. This loss of jobs hits the government doubly hard... all the while the government is spending money on unemployment and at the same time collecting ZERO payroll taxes and ZERO income taxes from the jobs lost. I believe a slow steady as she goes approach maybe the best approach. This would give all those involved time to adjust. Just as any of you that as a youngster grew too rapidly you probably experienced growing pains. The economy may infact if not artificially regulated experience devastating structural affects. We all have seen the madness business's and businessmen are willing to subject themselves, their companies, and their employees lives to - just look back to the craziness of the internet bubble. Capitalism can go a stray directed by greed. So in the mean time government regulation or intervention might just buy enough time for the effects of these uncertain times to become more thoroughly understood - which would not be a bad thein in my opinion. For years through immigration quotas we have regulated the people entering the US job market now through our technology we have open a new can of worms that allows jobs to be lost without physical immigration to just open this door completely has never been what the US has done. Darren Douch <[EMAIL PROTECTED]To: [EMAIL PROTECTED] om> cc: Sent by: MQSeriesSubject: Re: Outsourcing - my observations after my trip to List India <[EMAIL PROTECTED] N.AC.AT> 09/02/2003 02:18 PM Please respond to MQSeries List I'm not a historian but this has been happening since the industrial revolution and probably throughout all human history - industries decline and (hopefully) other things arise to replace them. Britain's textile industry declined as cheap labour in the far east took over, our coal industry declined because it was cheaper to mine it elsewhere, our manufacturing base has been in decline for 20 years, etc, etc. Maybe IT will be the next industry to decline in the West in the face of cheap labour in the East, maybe it wont. That depends upon how much protectionism the West puts in place and whether or not we are satisified with the quality of the work the East does - we're happy with the quality of the Nike trainers they make in Malaysia, so why not the quality of the code they write in Bangdledesh? Yes it's tough on those that
Re: Outsourcing - my observations after my trip to India <-- Attachment History Removed
For years through immigration quotas we have regulated the people entering the US job market. Now through our technology we have opened a new can of worms. This can of worms allows US jobs to be lost without physical immigration. To just open this door completely has never been what the US has done. So I believe to ignore this is truth is not considering the entire truth. We have always had a certain amount of protectionist regulation through immigration quotas. Navin Vali <[EMAIL PROTECTED]To: [EMAIL PROTECTED] IRWAYS.COM> cc: Sent by: MQSeries Subject: Re: Re: Outsourcing - my observations after my trip List to India <-- Attachment History Removed <[EMAIL PROTECTED] C.AT> 09/03/2003 12:44 AM Please respond to MQSeries List Hi Darren, I can't agree more with you You cant eat the Cake and Keep it too some real intelligent observations.. Regards Navin PS: But still " I " think we should stick to technical stuff on this list. Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> To: MQSERIES cc: bcc: Subject: Re: Outsourcing - my observations after my trip to India MessageI'm not a historian but this has been happening since the industrial revolution and probably throughout all human history - industries decline and (hopefully) other things arise to replace them. Britain's textile industry declined as cheap labour in the far east took over, our coal industry declined because it was cheaper to mine it elsewhere, our manufacturing base has been in decline for 20 years, etc, etc. Maybe IT will be the next industry to decline in the West in the face of cheap labour in the East, maybe it wont. That depends upon how much protectionism the West puts in place and whether or not we are satisified with the quality of the work the East does - we're happy with the quality of the Nike trainers they make in Malaysia, so why not the quality of the code they write in Bangdledesh? Yes it's tough on those that lose their jobs, but I thought the US was a lover of free trade and the global economy. Actuall y that's a lie, I didn't think the US was a lover of free trade - they just like it when it suits them. Capitilism is about profits, one half of the profit equation is reducing costs - if companies can get the same goods / labour more cheaply somewhere else then they will. Some will send too many jobs, or the wrong jobs, abroad, will struggle then bring them back, or will fold. Others will get it right and their shareholders will cheer them on. Of course in some respects creating jobs in '3rd world' countries is good - their standard of living increases and makes them better potential markets for western goods and services. Do you want a global economy or not? The answer is 'yes', 'no', or 'just when it suits me'. Obviously, these opinions are just my own... Darren. - Original Message - From: Christopher D. Fryett To: [EMAIL PROTECTED] Sent: Sunday, August 31, 2003 6:38 PM Subject: Outsourcing - my observations after my trip to India -Original Message- From: Christopher D. Fryett Sent: Sunday, August 31, 2003 12:30 PM To: Subject: RE: Outsourcing - my observations after my trip to India Zafar: Thank you for the detailed report you acquired from India. Although I don't completely agree that the outsourcing is 1% of the GDP based on the Indian colleagues I am currently working with right now who say the continued trend will help the 4 primary states of India which a
Re: Ghost Queues - TONIGHT on ART BELL
sorry that is a US only joke... Jim Ford <[EMAIL PROTECTED]To: [EMAIL PROTECTED] M> cc: Sent by: MQSeriesSubject: Ghost Queues List <[EMAIL PROTECTED] N.AC.AT> 09/02/2003 02:59 PM Please respond to MQSeries List While researching a performance problem on a Solaris server, I noticed that the queue manager had over 1,100 temporary dynamic local queues open. I did a "dis ql(amq.*)" to come up with this number. This number steadily increases, but I expect it to drop tonight when some of these processes end. Obviously, someone - or several someones - are opening the model queue for each message, and I'm asking the developers to look into that. But I also see that the /var/mqm/qmgrs//queues directory has over 1,300 "ghost" subdirectories defined.These have names that start with "!!GHOST!" followed by some unique stuff. I think these represent a pool of temporary queues that are created so that model queues can open faster. The number of these things trends up, like the tempdyn queues, but occasionally goes down. I can't find any doc on these ghost queues, though. Can anyone tell me what they are and how they behave? We are on 5.2, CSD 6. 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: MA12 Batch triggering
Wow all this because so far they are unable to get past basically what I believe to be a syntax error. We currently use the MA12 suportpac without any problems. Seems so far to be straight forward and reliable. One thing we like about it is that it allows us to NOT submit a production Job to the internal reader - as doing so is a no-no in this and many other shops. The desire here is that all jobs to be 'scheduled' by the production scheduler. In the case of MA12 triggered jobs the job is scheduled and immediately released by the production scheduling software, the job is then archived like any other scheduled production job. Additionally most analysts appreciate JCL being in JCL libraries and PROCs in PROC libraries. Why because when researching a problem nothing causes more grief than code in JCL libraries or JCL in code libraries as this is the last place one would think to look. But if one desires to reinvent a perfectly good wheel - please send me a copy as one can never have to many wheels. -smile I am. "Miller, Dennis" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] OM> cc: Sent by: MQSeriesSubject: Re: MA12 Batch triggering List <[EMAIL PROTECTED] N.AC.AT> 08/27/2003 04:27 PM Please respond to MQSeries List Humm, Humph... My perspective is that you are essentially requesting a service from MVS/JES. To paraphrase, that request is: "run this job". Rather than enhancing the trigger monitor, I suggest abstracting the layer that is responsible for satisfying the request into a program that you control. This can be done in batch or even more easily in CICS, eliminating the need for MA12 altogether. The model I have in mind is that MA12 or CKTI, starts the program that processes the request and submits the job to an internal reader. In it's simplest form, the name of the job/proc or whatever (YOUR DESIGN) can be stored in the envrdata, userdata, and/or trigdata. (But not in the applicid--that's where the name of your SIL abstraction layer is stored). In a more sophisticated model, you can define a JOB.SUBMISSSION queue to pass job-submission request messages (YOUR DESIGN). With that approach you can even include, JCL, parameter cards, data records, etc., in-line (as part of the request message). In effect (and with due dilligence to security), you have a general purpose utility that any MQ-enabled process anywhere can submit jobs to MVS. By including in-line data records behind the IEBGENER utility, you even have a makeshift file transfer application--simple, but works. regards, Dennis > -Original Message- > From: Roger Lacroix [SMTP:[EMAIL PROTECTED] > Sent: Wednesday, August 27, 2003 1:55 PM > To: [EMAIL PROTECTED] > Subject: Re: MA12 Batch triggering > > Humm, > > I think you misunderstood me. I meant that you stop using MA12 and write your > own trigger monitor program (C or PLI or COBOL). Your new trigger monitor > program would use the APPLCID and/or USERDATA as they wish. > > But most companies don't want to have a custom written trigger monitor. Plus > you would need a compiler / linker on the mainframe. > > If you want help writing the code, let me know. > > later > Roger... > > > Quoting "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]>: > > > I would love to do the simple one Rog. > > > > If I put @TSMT00.MQ.CNTL(MQEX702V) in USERDATA, but what would I put in > > APPLCID? > > > > This assume MQEX702V can be submitted stand alone. > > > > > > -Original Message- > > From: Roger Lacroix [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, August 27, 2003 4:11 PM > > To: [EMAIL PROTECTED] > > Subject: Re: MA12 Batch triggering > > > > > > Hi, > > > > Over the years, I have written a couple of trigger monitors to submit JCL > > (with > > a JOB card) rather than a PROC. > > > > It is really straight forward. You can make a simple one or a more robust > > trigger monitor. The simple one would have the PDS(member) in the USERDATA > > field. For the complex one, you would just specify the member and then the > > program would search a list of PDS(s) for the member. > > > > Either way, the program will read the member then submit it to the INTRDR > > (Internal Reader). > > > > I wish I could post the code but I can't (it's not mine). > > > > later > > Roger... > > > > > > Quoting "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]>: > > > > > No, I never had it working. I mean, I had the job itself working A-OK when > > I > > > submitted SUB from inside the member. But someone told me I could not just > > > submit a JCL member like this from a process definition. I had to change > > it > > > to a proc, which are the changes I made below and the reason I posted the > > > firs
Re: MA12 Batch triggering
(See attached file: temp.txt)
Are you sure your setup is correct. Here is how we do it. Also you
mentioned a PEND at the end of the PROC are you sure you need this since
the proc is cataloged not instream.Please note the space between '//
and exec' we do not user the userdata field at all
TEST process definition
DEFINE PROCESS('PR.H_HAL_010_BILL_OF_LADING.000') +
DESCR('Process for batch job TH1MPU09') +
APPLTYPE(MVS) +
APPLICID('// EXEC TH1MPU09') REPLACE
We do the following in our test environment.
TEST Proc
//TH1MPU09 PROC
//*
//STEP010 EXEC PGM=IEBGENER
//SYSINDD DUMMY
//SYSOUT DD SYSOUT=X
//SYSUT1 DD DSN=TP.HAL.NEW.MINIJCL(TH1MPU09),DISP=SHR
//SYSUT2 DD SYSOUT=(A,INTRDR)
//SYSPRINT DD SYSOUT=X
//
In production we execute a proc which adds a production job to our
production schedule for immediate release.
PRODUCTION
DEFINE PROCESS('PR.H_HAL_010_BILL_OF_LADING.000') +
DESCR('Process for batch job H1MPU09P') +
APPLTYPE(MVS) +
APPLICID('// EXEC CU01AA,MEM=H1MPU09P') REPLACE
here is the PRODUCTION proc CU01AA
//CU01AA PROC MEM=
//* LAST UPDATED BY
//
//* ZEKESET STEP TO COMMUNICATE COMMAND REQUEST TO SCHEDULER - ZEKE *
//
//CU01AA10 EXEC PGM=ZEKESET
//SYSOUT DD SYSOUT=M,DEST=CENTRAL
//SYSUDUMP DD SYSOUT=X,FCB=F800,DEST=CENTRAL
//SYSABEND DD SYSOUT=X,FCB=F800,DEST=CENTRAL
//SYSPRINT DD SYSOUT=M,FCB=F800,DEST=CENTRAL
//SYSIN DD DSN=HP.DPC.A2414(&MEM),DISP=SHR
//*** END OF PROC
Roger Lacroix
<[EMAIL PROTECTED]To: [EMAIL PROTECTED]
ALWARE.BIZ> cc:
Sent by: MQSeries Subject: Re: MA12 Batch triggering
List
<[EMAIL PROTECTED]
C.AT>
08/27/2003 01:10 PM
Please respond to
MQSeries List
Hi,
Over the years, I have written a couple of trigger monitors to submit JCL
(with
a JOB card) rather than a PROC.
It is really straight forward. You can make a simple one or a more robust
trigger monitor. The simple one would have the PDS(member) in the USERDATA
field. For the complex one, you would just specify the member and then the
program would search a list of PDS(s) for the member.
Either way, the program will read the member then submit it to the INTRDR
(Internal Reader).
I wish I could post the code but I can't (it's not mine).
later
Roger...
Quoting "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]>:
> No, I never had it working. I mean, I had the job itself working A-OK
when I
> submitted SUB from inside the member. But someone told me I could not
just
> submit a JCL member like this from a process definition. I had to change
it
> to a proc, which are the changes I made below and the reason I posted the
> first few lines of the member MQEX702B. I think I made the correct
changed
> to it to make it a proc (removed the job card, added PROC to the first
line
> and added PEND to the end)
>
>
> Actually I wish I was able to make this work by simply be able to do
> something like TSO SUB @TSMT00.MQ.CNTL(MQEX702B) in the proccess
definition,
> but I guess this is not possible. (This is assuming MQEX702B was back in
its
> original state when it could be run standalaone by just submitting the
> member.)
>
>
>
> -Original Message-
> From: Bullock, Rebecca (CSC) [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 27, 2003 3:22 PM
> To: [EMAIL PROTECTED]
> Subject: Re: MA12 Batch triggering
>
>
> Peter, I don't use MA12 and we're not a JES3 shop, but was it working
before
> you shut it down? Could it be that a different userid is now associated
with
> it, and that userid is causing it to fail in the SMF exit? I'd talk to
the
> SMF exit person and see what would trigger a failure and take it from
there.
> -- Rebecca
>
> -Original Message-
> From: Hill, Dave [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 27, 2003 3:07 PM
> To: [EMAIL PROTECTED]
> Subject: Re: MA12 Batch triggering
>
>
> Peter -
>
> Process name and content
> EMAIL.SMTP.MSGS
> USED TO PROCESS MAINFRAME EMAI
> TO USERS IN
>
> MVS
> //*S010EXE EXEC PGM=MQMAIL
> //EMAIL DD SYSOUT=(Q,SMTP)
> //SYSOUT DD SYSOUT=*
> //UTLITYF DD DUMMY
>
> -Original Message-
> From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 27, 2003 2:45 PM
> To: [EMAIL PROTECTED]
> Subject: MA12 Batch triggering
>
>
> The trigger monitor is up and running. I can send the shutdown message to
it
> via CKTIEND and it shuts down as expected. So I start it back up and try
to
> drop a message into the triggered queue. The triggered queue name is
> MQT1.LOCAL.QUEUE and the process definition is named MQT1.LOCAL.QUEUE as
> well.
>
>
>
Re: Certified candidates but < 2 years exp - comments
and I doubt your name is joe JoE JK <[EMAIL PROTECTED]To: [EMAIL PROTECTED] .COM>cc: Sent by: MQSeriesSubject: Re: Certified candidates but < 2 years exp - comments List <[EMAIL PROTECTED] N.AC.AT> 08/20/2003 05:22 PM Please respond to MQSeries List dont worry, i'm not from US. :) --- Robert Broderick <[EMAIL PROTECTED]> wrote: > AH. More US tax dollars and a job down the > drain. I'm sure there was no > one qualified in the US to fit the position!!! (Soon > that actually may be a > true statement). > > Some "KID" found out what I did for a living and > asked me the other day at a > Staten Island Yankees ball game if he should go to > college to take up > computers. He said he really liked them. I told him > it's becoming a dead > field and should steer clear of it if he wanted to > financially get anywhere > in the future. > > > > > > > >From: JoE JK <[EMAIL PROTECTED]> > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: Re: Certified candidates but < 2 years exp > - comments > >Date: Wed, 20 Aug 2003 09:03:32 -0700 > > > >Hi, > >Actually we already have ppl from a well known > vendor > >+ experienced to help with the project. Another > >candidate is required to help our team with other > >concurrent project. We got a lot of response from > >those offshore software co with resumes as I > mentioned > >earlier. It just happened some of the candidates > had > >the certification with less exp and some w/o cert > but > > > 2 years exp. > >After talked to them, those with exps are more > >convincing and knows what we're talking about(our > >requirements). I probably would go for this guy. > > > >Many thanks for valuable input. > > > >Joe, > > > > > >--- Roger Lacroix <[EMAIL PROTECTED]> > >wrote: > > > Hi, > > > > > > Joe's original question was about interviewing > > > people with less than 2 years of > > > experience but who have the WMQ Specialist > > > certificate. > > > Quote: "With those certification, are they > really > > > can perform?" > > > > > > I read his question as, "he is looking for > someone > > > capable", i.e. intermediate > > > level not junior or trainee. > > > > > > Hence when talking technical details with a > > > intermediate (or senior) level > > > person, an hour will fly right by. > > > > > > Regards, > > > Roger Lacroix > > > Capitalware Inc. > > > > > > > > > Quoting Benjamin Zhou <[EMAIL PROTECTED]>: > > > > > > > Well,..., Roger, don't be too harsh to the > junior > > > MQers. Everyone deserve a > > > > chance to do his /her best to excel. We were > all > > > junior MQers not many years > > > > ago. > > > > > > > > >>I prefer to have the candidate go through an > > > in-depth technical interview > > > > of at > > > > >>least 1 hour on the on the subject matter. > > > > > > > > Are you serious? this should be for someone > with > > > your lengths of experience. > > > > The most important is that the candidate have > true > > > understanding of the > > > > fundamental ideas and structure of the > middleware, > > > and possesses the > > > > enthusiasm to learn, to try, and enjoy it. The > > > technical details we now know > > > > can quickly become obsolate. Remember, the > > > knowledge we possess today can > > > > turn into obstacle for progress tomorrow if we > > > love it too much. > > > > > > > > cheers, > > > > Benjamin Zhou > > > > State Street Corp. > > > > > > > > > > > > > > > > -Original Message- > > > > From: Roger Lacroix > > > [mailto:[EMAIL PROTECTED] > > > > Sent: Wednesday, August 20, 2003 10:18 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: Certified candidates but < 2 > years > > > exp - comments > > > > > > > > > > > > Hi, > > > > > > > > Certification is a great thing but should be > taken > > > with a grain of salt. (I > > > > have ever noticed the number of people who > have > > > requested the certification > > > > questions on the ListServer or > www.mqseries.net ?) > > > > > > > > I personally assign a value of 2-3 months of > > > equivalent work experience for > > > > a > > > > certificate (MQSeries, Java, or whatever). > i.e. > > > If someone says they have > > > > been > > > > doing MQAdmin work for 6 months and they have > the > > > WMQ Specialist certificate > > > > then I go with a total 9 months work > experience. > > > This may be harsh but I > > > > have > > > > met people with the WMQ Specialists > certificate > > > but cannot resolve a channel > > > > sequence number error. > > > > > > > > I prefer to have the candidate go through an > > > in-depth technical interview of > > > > at > > > > least 1 hour on the on the subject matter. Or > > > have the candidate do a > > > > technical exam from ReviewNet o
Re: GET 3270 Bridge Reply
I am glad somebody can keep this all straight. What a mess. I am thankful for this discussion because now I think by George I got it! "David C. Partridge"To: [EMAIL PROTECTED] <[EMAIL PROTECTED]cc: RIMEUR.COM> Subject: Re: GET 3270 Bridge Reply Sent by: MQSeries List <[EMAIL PROTECTED] .AC.AT> 07/25/2003 05:58 AM Please respond to MQSeries List GMO.MatchOptions only works with a Version 2 or greater MQGMO. OS/390 only supports a Version 1 GMO. So you are forced to reset the MD.MsgId to MQMI_NONE prior to MQGET on 390. Dave 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: AW: GET 3270 Bridge Reply
oh yes good catch. make sure the version value is 2 as the default as shipped is probably 1. http://publibfp.boulder.ibm.com/epubs/html/csqzak09/csqzak09tfrm.htm This is an input field. The initial value of this field is MQMO_MATCH_MSG_ID with MQMO_MATCH_CORREL_ID. This field is ignored if Version is less than MQGMO_VERSION_2. "Miller, Dennis" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] OM> cc: Sent by: MQSeriesSubject: Re: AW: GET 3270 Bridge Reply List <[EMAIL PROTECTED] N.AC.AT> 07/24/2003 01:14 PM Please respond to MQSeries List If your request message were waiting for a syncpoint, then the request would never have been sent and there could not possibly be a reply message. Since other applications can see the reply message, that tells me that both the request message and the reply message have been committed. Your notion of the CICS UOW matching the ID of the batch job in some way is off target. The CICS UOW doesn't care whatsoever about the origin of the message. Your batch program can read the reply queue just like the other applications, it's just a matter of how you set up for the MQGET. Are you certain match options are supported on your version of MQ? > -Original Message- > From: Jeff Orris [SMTP:[EMAIL PROTECTED] > Sent: Thursday, July 24, 2003 11:23 AM > To: [EMAIL PROTECTED] > Subject: Re: AW: GET 3270 Bridge Reply > > I'm sure that the reply msgid is the same as that of the request. It's > true that CICS puts the request msgid in the correlation id of the reply, > but I'm only looking for a match on msgid. > > If I display the msgid returned by the PUT and copy it to a new batch job > along with just the GET reply logic, the message is retrieved successfully. > That's why I believe it has something to do with the unit of work not being > complete. My guess is that CICS is putting the reply with a syncpoint > under a UOW id that matches that of the batch job. Until the job > completes, nothing else can GET the message, although other applications > (like MA10) can browse the message. > > I unsuccessfully tried specifying NO_SYNCPOINT in both by PUT and GET > message options. But I don't think I can instruct CICS to PUT the reply > with NO_SYNCPOINT. > > Jeff > > > > "Raabe, Stefan" > <[EMAIL PROTECTED] To: [EMAIL PROTECTED] > EGIS.COM>cc: > Sent by: Subject: AW: GET 3270 Bridge Reply > MQSeries List > <[EMAIL PROTECTED] > en.AC.AT> > > > 07/24/03 11:05 > AM > Please respond > to MQSeries List > > > > > > > do you see the reply message arriving in the queue while > your program ist still active and waiting? > > if so, then it is no commit problem. your request was processed, thats > why there is an answer, and the request can only be processed if the > message was committed (asuming you run with syncpoint on) > > are you sure that the reply msgid is equal to the request > msgid? many applications return the requestors msgid > in the correlid of the reply. check with ma10 / hex on > if the msgid is really what you expected. > (i dont know cics bridge details). > > regards > > stefan > > > -Ursprungliche Nachricht- > Von: Jeff Orris [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 24. Juli 2003 16:33 > An: [EMAIL PROTECTED] > Betreff: GET 3270 Bridge Reply > > > I'm writing a COBOL z/OS batch program which puts a message to a CICS > bridge queue and attempts to get the reply message from the reply queue. > But the MQGET is failing with a reason code of MQRC_NO_MSG_AVAILABLE. I've > made sure that MQGMO-WAITINTERVAL is long enough (6 ms). I also can > browse the reply message in the queue with another utility (supportpac > MA10) while the MQGET is waiting. > > My match options are set to match on MSGID only (and I don't change the id > returned in MQMD-MSGID by the PUT to the bridge queue). > > I'm guessing that, since the batch job is considered one unit of work, the > message is not available for GET until the batch job completes. I tried > issuing an MQCMIT just before opening the reply queue, but the reply > message is still unavailable. > > Any ideas or suggestions? > > Jeff Orris > > > > > This message contains privileged and confidential information intended for> > the > above addressees only. If you receive this message in error please delete > or destroy > this message and any accompanying documentation after contacting the > sender. > The > sender of this message will fully c
Re: GET 3270 Bridge Reply
are you sure the CICS program has ended or committed the message. are you sure the CICS program is sending the value you are expecting in the msgid. if you can see the message and the cics program has committed it or has completed - then sounds like the only reasonable answer is the msgid you are expecting is not the msgid being returned. BTW we always use correlid to identify messages and let the queue managers set the msgid. We leave the responsibility of unique messages ids to the queue manager. The commit before opening the replyQ would help to make your message available to the CICS program. It seems from your email that the CICS program has already sent the reply message. You mention you can browse it using the ISPF panels. I believe its a match option problem, as the msgid sent does not match the msgid you are expecting. Jason Cornell <[EMAIL PROTECTED]To: [EMAIL PROTECTED] BCORP.COM> cc: Sent by: MQSeriesSubject: Re: GET 3270 Bridge Reply List <[EMAIL PROTECTED] N.AC.AT> 07/24/2003 08:00 AM Please respond to MQSeries List You could try specifying no syncpoint. >>> [EMAIL PROTECTED] 7/24/2003 10:32:56 AM >>> I'm writing a COBOL z/OS batch program which puts a message to a CICS bridge queue and attempts to get the reply message from the reply queue. But the MQGET is failing with a reason code of MQRC_NO_MSG_AVAILABLE. I've made sure that MQGMO-WAITINTERVAL is long enough (6 ms). I also can browse the reply message in the queue with another utility (supportpac MA10) while the MQGET is waiting. My match options are set to match on MSGID only (and I don't change the id returned in MQMD-MSGID by the PUT to the bridge queue). I'm guessing that, since the batch job is considered one unit of work, the message is not available for GET until the batch job completes. I tried issuing an MQCMIT just before opening the reply queue, but the reply message is still unavailable. Any ideas or suggestions? Jeff Orris This message contains privileged and confidential information intended for the above addressees only. If you receive this message in error please delete or destroy this message and any accompanying documentation after contacting the sender. The sender of this message will fully cooperate in the civil and criminal prosecution of any individual engaging in the unauthorized use of this message. 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: ASCII to EBCDIC conversion problem
is the data being sent really string data sometimes the obvious questions are the one not asked for fear of insulting someone - have you verified this with the sender. if the message data is truly not string data the results of the conversion will be junk. "Jose, Prince" <[EMAIL PROTECTED]>To: [EMAIL PROTECTED] Sent by: MQSeriescc: List Subject: ASCII to EBCDIC conversion problem <[EMAIL PROTECTED] N.AC.AT> 07/23/2003 01:35 PM Please respond to MQSeries List I know this issue has been discussed many times here. And I have looked all the archives and gone through the white paper, MQSeries and Conversion. So please excuse me for asking. But when one of our application in mainframe receives messages from a distributed platform, the conversion is not taking place. The distributed platform is outside our firewall. So we do not have any control on that application. But they confirmed that the message descriptor format filed on their MQPUT is set to MQFMT_STRING. Our side in mainframe, MQGMO_CONVERT is specified during MQGET in the program. Also during the MQGET, our programmers set the Format to MQFMT-STRING and the Encoding to MQENC-NATIVE Any ideas what can be wrong? MQ(5.2 on Os390) version 5 on distributed platform. Thanks, Prince 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: ASCII to EBCDIC conversion problem
here are a couple of options you might play with MOVE MQCCSI-Q-MGR TO MQMD-CODEDCHARSETID. MOVE MQENC-NATIVE TO MQMD-ENCODING. "Jose, Prince" <[EMAIL PROTECTED]>To: [EMAIL PROTECTED] Sent by: MQSeriescc: List Subject: Re: ASCII to EBCDIC conversion problem <[EMAIL PROTECTED] N.AC.AT> 07/23/2003 02:17 PM Please respond to MQSeries List I stopped the message in the queue as it arrived and looked at the CCSID of the message. It was 819. Our mainframe qmgr's CCSID is 37. Thanks, -Original Message- From: Glen Shubert [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 4:48 PM To: [EMAIL PROTECTED] Subject: Re: ASCII to EBCDIC conversion problem We had a similar situation, and on the distributed platform the application was setting the CCSID to 500, which is what we use on the mainframe. You might want to check to see what the incoming CCSID is to see if a conversion is taking place. Glen Shubert [EMAIL PROTECTED] Associate Director TSYS - MQSeries Technical Support "Jose, Prince" <[EMAIL PROTECTED]> Sent by: MQSeries List To: <[EMAIL PROTECTED]>[EMAIL PROTECTED] cc: Subject:ASCII to 07/23/2003 04:35 PM EBCDIC conversion problem Please respond to MQSeries List I know this issue has been discussed many times here. And I have looked all the archives and gone through the white paper, MQSeries and Conversion. So please excuse me for asking. But when one of our application in mainframe receives messages from a distributed platform, the conversion is not taking place. The distributed platform is outside our firewall. So we do not have any control on that application. But they confirmed that the message descriptor format filed on their MQPUT is set to MQFMT_STRING. Our side in mainframe, MQGMO_CONVERT is specified during MQGET in the program. Also during the MQGET, our programmers set the Format to MQFMT-STRING and the Encoding to MQENC-NATIVE Any ideas what can be wrong? MQ(5.2 on Os390) version 5 on distributed platform. Thanks, Prince The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you 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: Questionable MQ infrastructure design
I love this I can't stop smiling... #1 its a lot of stuff to type : ) "8. Ask those people what's the benefit of using such long and full names, tell them they do not know anything about MQSeries."LMAO 9. If I were your target company, I would not do business with you unless you change your naming convention to more L mikhail malamud <[EMAIL PROTECTED]To: [EMAIL PROTECTED] .NET>cc: Sent by: MQSeriesSubject: Re: Questionable MQ infrastructure design List <[EMAIL PROTECTED] N.AC.AT> 07/09/2003 07:32 PM Please respond to MQSeries List 1. it is a lot of stuff to type. 2. os/390 supports only 4 letter queue manager names. 3. Instead of specifying full names for name components come up with abreviations where letters and numbers can be mapped to full names. 4. You will be 70% less productive than people who adhere to best practices in the context of the naming convention. 5. You and developers will be a lot more prone to errors. 6. max lenght of mq object names is 48 chars except channels where max name length is 20 chars. 7. Seriously look into queue manager aliasing. 8. Ask those people what's the benefit of using such long and full names, tell them they do not know anything about MQSeries. 9. If I were your target company, I would not do business with you unless you change your naming convention to more 10. What's the point of having distinct queue manager for each application, if all queue managers will be on the same host. This is hardly justifiable over head. - Original Message - From: "Armand ten Dam" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, July 09, 2003 8:58 PM Subject: Questionable MQ infrastructure design | Hi all, | For an integration project I have been asked to adopt an MQ naming standard | that reflects a very unusual approach in MQ-based integration. I have never | seen this approach before and have serious concerns in adopting any of it. | | Key in the design is the use of separate queue managers for each application | pair. E.g. if an application interfaces with eight different distributed | applications this would result in eight separate queue managers on a single | system. | | Some examples: | Queue manager: | QMPROD.SOURCECOMPANY.SOURCEAPP.TARGETCOMPANY.TARGETAPP.SYSTEMNAME | Channel: | CHPROD.SOURCECOMPANY.SOURCEAPP.TO.TARGETCOMPANY.TARGETAPP | Transmission queue: | TXPROD.SOURCECOMPANY.SOURCEAPP.TO.TARGETCOMPANY.TARGETAPP | ... | | Obviously this does not reflect best-practice, seriously impacts | scalability, makes support of the MQ infrastructure difficult etc. | | As it looks like it will be a bit of a political discussion to get this out | of the way, | I am looking to gather as much 'neutral' feedback to back me up. I would | appreciate it if some of you could shed some more light on the implications | of the above approach. | | Any insights much appreciated, | Thanks, | Armand | | _ | Hot chart ringtones and polyphonics. Go to | http://ninemsn.com.au/share/redir/adTrack.asp?mode=click&clientID=174&referral=Hotmail_taglines_plain&URL=http://ninemsn.com.au/mobilemania/default.asp | | 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: QUEUE CURENTLY IN USE
<< After this process I try to delete the Queue1 or empty it (request queue) I receive the error code 2042 and the folowing error message for delete. >> what is it delete or empty two entirely different things in my world. A previous reply in this thread told you that the cics bridge monitor was and is holding the queue. Another reply said what I was thinking are you really trying to delete the queue that the monitor program is monitoring something seems strange with this. Empty it yes but empting it should just be a function of your application working correctly nushin mehran <[EMAIL PROTECTED]>To: [EMAIL PROTECTED] Sent by: MQSeriescc: List Subject: Re: QUEUE CURENTLY IN USE <[EMAIL PROTECTED] N.AC.AT> 06/30/2003 10:10 AM Please respond to MQSeries List Ruzi, You are right I made typo error. It must be CICS that gets hold on the queue and does not release it. I still do not know what is holding the queue. Even the QSTATUS does not tell me who has the queue. This queue is testingh and I know no one elese except me and CICS is using it. --- Ruzi R <[EMAIL PROTECTED]> wrote: > I think you made a couple of typos in your sequence > of > calls. Is the following what you meant instead: > > 1. Open queue1 for output (NOT input) > 2. Put > 3. mqcommit > 4. mqclose (queue1 which I think is your > request > queue) > 5. Open queue2 for input (NOT output) > 6. GET reply messages from queue2 with > syncpoint > 7. mqcommit > 8. close (queue2) > 9. Disconnect > > If the above is correct, You are not the one who is > causing IPPROCS of queue1 (request queue) to be 1 as > it is an output queue for you. I just wanted to make > this clarification. > > Best regards, > > Ruzi > > --- nushin mehran <[EMAIL PROTECTED]> wrote: > > Hello all, > > I would be truly appriciated if some one tells me > > whats going on and how I can resolve this client > > issue. > > This MQ Client application (HP mq client puts > > messages > > to Z/os MQSeries) opens a request queue to put > > messages into an mq bridge queue that triggers > cics > > bridge process. > > After I finish the process and I am out of the > > application the value of IPPROCS = 1 AND OPPROCS = > > 0. > > Can some one tell me what should I do in my > program > > to > > set the IPPROCS TO 0. > > Here is the sequence of the events that happens in > > the > > application. > > > > 1. Open queue1 for input > > 2. Put > > 3. mqcommit > > 4. mqclose > > 5. Open queue2 for output > > 6. GET reply messages from queue2 with > > syncpoint > > 7. mqcommit > > 8. close > > 9. Disconnect > > > > After this process I try to delete the Queue1 or > > empty > > it (request queue) I receive the error code 2042 > and > > the folowing error message for delete. > > > > CSQM101I +QD1 CSQMUQLC QLOCAL(QUEUE1) IS > CURRENTLY > > IN > > > > USE > > > > CSQM090E +QD1 CSQMUQLC FAILURE REASON CODE > > X'00D44005' > > > > CSQ9023E +QD1 CSQMUQLC ' DELETE QLOCAL' ABNORMAL > > COMPLETION . > > > > > > __ > > Do you Yahoo!? > > SBC Yahoo! DSL - Now only $29.95 per month! > > http://sbc.yahoo.com > > > > 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 __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com 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: QUEUE CURENTLY IN USE
nushin mehran <[EMAIL PROTECTED]>To: [EMAIL PROTECTED] Sent by: MQSeriescc: List Subject: Re: QUEUE CURENTLY IN USE <[EMAIL PROTECTED] N.AC.AT> 06/30/2003 10:10 AM Please respond to MQSeries List Ruzi, You are right I made typo error. It must be CICS that gets hold on the queue and does not release it. I still do not know what is holding the queue. Even the QSTATUS does not tell me who has the queue. This queue is testingh and I know no one elese except me and CICS is using it. --- Ruzi R <[EMAIL PROTECTED]> wrote: > I think you made a couple of typos in your sequence > of > calls. Is the following what you meant instead: > > 1. Open queue1 for output (NOT input) > 2. Put > 3. mqcommit > 4. mqclose (queue1 which I think is your > request > queue) > 5. Open queue2 for input (NOT output) > 6. GET reply messages from queue2 with > syncpoint > 7. mqcommit > 8. close (queue2) > 9. Disconnect > > If the above is correct, You are not the one who is > causing IPPROCS of queue1 (request queue) to be 1 as > it is an output queue for you. I just wanted to make > this clarification. > > Best regards, > > Ruzi > > --- nushin mehran <[EMAIL PROTECTED]> wrote: > > Hello all, > > I would be truly appriciated if some one tells me > > whats going on and how I can resolve this client > > issue. > > This MQ Client application (HP mq client puts > > messages > > to Z/os MQSeries) opens a request queue to put > > messages into an mq bridge queue that triggers > cics > > bridge process. > > After I finish the process and I am out of the > > application the value of IPPROCS = 1 AND OPPROCS = > > 0. > > Can some one tell me what should I do in my > program > > to > > set the IPPROCS TO 0. > > Here is the sequence of the events that happens in > > the > > application. > > > > 1. Open queue1 for input > > 2. Put > > 3. mqcommit > > 4. mqclose > > 5. Open queue2 for output > > 6. GET reply messages from queue2 with > > syncpoint > > 7. mqcommit > > 8. close > > 9. Disconnect > > > > After this process I try to delete the Queue1 or > > empty > > it (request queue) I receive the error code 2042 > and > > the folowing error message for delete. > > > > CSQM101I +QD1 CSQMUQLC QLOCAL(QUEUE1) IS > CURRENTLY > > IN > > > > USE > > > > CSQM090E +QD1 CSQMUQLC FAILURE REASON CODE > > X'00D44005' > > > > CSQ9023E +QD1 CSQMUQLC ' DELETE QLOCAL' ABNORMAL > > COMPLETION . > > > > > > __ > > Do you Yahoo!? > > SBC Yahoo! DSL - Now only $29.95 per month! > > http://sbc.yahoo.com > > > > 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 __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com 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: Unsubscribe
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 Richard Santilli <[EMAIL PROTECTED]To: [EMAIL PROTECTED] ESSIVE.COM>cc: Sent by: MQSeries List Subject: Unsubscribe <[EMAIL PROTECTED] T> 06/18/2003 11:03 AM Please respond to MQSeries List Richard Santilli === This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please contact the sender by email/fax and destroy all paper and electronic copies of the original message. 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: Spiraling downhill (OT)
First off I am not a Honda employee... I agree things will turn around as the rest of the world prospers but it will be a long time coming and painful along the way... When did the American cars become competitive the 90's well that was a painful 20-30 years in the US auto industry so I guess the bulk of the next 20-30 years are going to be painful for US IT workers. I agree with that assessment then. Are you instructing college age children to go into the IT field or steer clear... The US Auto industry was once number one in the world and what is it now? Sure still a case can be made that it is number one but only by the har on its chinny chin chin and I would bet hardly any on this board drive and American car. If we stay with the auto industry example the US IT industry dominance is also gone never to return!! CONED has no unions huh? I would assume by your comments you are 5 years or less from retirement - and thus have no worries... I pity the current crop of CS college graduates - what they saw when they entered college and what they are getting 4-5 years later is sure two different pictures. BTW I have contracted at only Japanese companies for 20 years! :) Honda worldwide sells and builds more cars in the US than in any other market - we build and export 1000's of cars from the US each and every week. "Beinert, William" To: [EMAIL PROTECTED] <[EMAIL PROTECTED]cc: OM> Subject: Re: Spiraling downhill (OT) Sent by: MQSeries List <[EMAIL PROTECTED] N.AC.AT> 06/17/2003 12:12 PM Please respond to MQSeries List LMAO at this rant from a Honda employee... He may have quoted this word for word from the auto workers unnions in the 60s when US cars were garbage because they didn't have any competition from manufacturers who did care about quality. I remember being told Japanese cars were cheap becuase the workers only were paid a bowl of rice a day. Today Japanese labor is as expensive as US labor Things will even out as the rest of the world becomes more prosperous, and the free flow of goods and services will only speed the process. Bill -----Original Message- From: Randy J Clark [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 2:36 PM To: [EMAIL PROTECTED] Subject: Re: Spiraling downhill AMEN! Start a union, or maybe get our legislature to wake up and smell the coffee... The good old USA lost 2 million jobs last year. Offshore jobs reduce our wages and also pay zero income taxes. Do you hear that that sucking sound its these jobs on our economy. These offshore income earners at Americans expense spend zero, none, nada, zip, zilch, money in America resulting in zero sales taxes being paid as well. This great offshore push only lines the pockets of the CEO's and the like. They are nothing but a drain on our economy. It may not be your job today but it could be tomorrow. I wonder how long we will go and how bad it will get before we get serious about a union or employing a powerful lobbyist. 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: Spiraling downhill
Safeway in California.I also worked for Safeway in Arizona from 1983 to 1985 and was only making 10.72 per hour as they are a right to work state. I quit in 1985 and I think they broke the unions in the early 90's or atleast broke them down pretty bad in California so I have no idea how it is now. But it was a sweet life for a kid in his early to mid 20's. "Potkay, Peter M (PLC, IT)" To: [EMAIL PROTECTED] <[EMAIL PROTECTED]cc: RTFORD.COM>Subject: Re: Spiraling downhill Sent by: MQSeries List <[EMAIL PROTECTED] AC.AT> 06/17/2003 12:58 PM Please respond to MQSeries List Where in the world did you make 13.52 and hour checking groceries?!? In 1982?!? In 1990 I was getting 6.25 working in FoodMart and loving life. And this is in CT, where wages are generally higher. -Original Message- From: Randy J Clark [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 3:11 PM To: [EMAIL PROTECTED] Subject: Re: Spiraling downhill I was part of the UFCW I htink that is what it was for 10 years from high school through college yes I was on the 6 year plan. I never noticed anything but that I got great benifits and a rediculous hourly rate. In 1982 I was making 13.52 an hour checking groceries. Plus double time on Sundays and triple time on Holidays. I made over 30k in 1982 while working an average of just over 30 hours a week... of course being single I worked all Sundays and Holidays quite happily. 40 bucks an hour for missing out on the July 4th fireworks while 22 years old seemed hardly difficult price to pay. Pavel Tolkachev cc: Sent by: MQSeriesSubject: Re: Spiraling downhill List <[EMAIL PROTECTED] N.AC.AT> 06/17/2003 11:53 AM Please respond to MQSeries List Hello Bobbee, Sorry for continuing on the off-topic.. There is something common and unfortunate in all unions I heard about from my buddies and relatives who happened to join them: after a little while a union is going to take advantage of its hard working members much more efficiently than the employer. So, unless you are going to leave the technical side and join the dark one (meaning -- union administration), a union may not be a beneficial idea for you. For some intermediate form, though, take a look at http://www.freelancersunion.org/. I am not saying they are not like all others unions (and I am not a member myself, I am permanent as of now), but at least they do not have (and supposedly won't have any soon) an exlusive with any employer/trade of type "union job". Pavel Robert Broderick <[EMAIL PROTECTED]To: [EMAIL PROTECTED] OTMAIL.COM> cc: Sent by: MQSeries Subject: Re: Spiraling downhill List <[EMAIL PROTECTED] .AC.AT> 06/17/2003 11:26 AM Please respond to MQSeries List Yes I agree, And sure, There are alot of corners on Wall St. bee-oh-dubble-bee-dubble-egh >From: "Fryett.Chris" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Spiraling downhill >Date: Tue, 17 Jun 2003 09:18:08 -0400 > >Here! Here! > >It is more common today that contracting agencies are taking advantage of >the large surplus of unemployed by paying really bad, but charging the >clients a lot. I suspect that this contract agency if it is one is >charging the client 50-75 percent over this amount. > >Let me know when you get that tin can and I'll join you ;-) > >Chris > > >-Original Message- >From: Robert Broderick [mailto:[EMAIL PROTECTED] >Sent: Tuesday, June 17, 2003 7:59 AM >To: [EMAIL PROTECTED] >Subject: Spiraling downhill > > >This is not a technical issue so take a back seat if you want to complain > >WOW. Look at this. Notice the rate > >SKILLS REQUIRED: MQ Series, Unix, mainframe >LOCATION: Hicksville, NY >RATE: $25-30/hr >AREA: 516 >LENGTH: 12 months >TERM: CON_IND CON_CORP >SUMMARY: X Xx has an immediate opening for a Software Support >Specialist. Candidate should be able work as a MQ Series ad
Re: Spiraling downhill
I was part of the UFCW I htink that is what it was for 10 years from high school through college yes I was on the 6 year plan. I never noticed anything but that I got great benifits and a rediculous hourly rate. In 1982 I was making 13.52 an hour checking groceries. Plus double time on Sundays and triple time on Holidays. I made over 30k in 1982 while working an average of just over 30 hours a week... of course being single I worked all Sundays and Holidays quite happily. 40 bucks an hour for missing out on the July 4th fireworks while 22 years old seemed hardly difficult price to pay. Pavel Tolkachev cc: Sent by: MQSeriesSubject: Re: Spiraling downhill List <[EMAIL PROTECTED] N.AC.AT> 06/17/2003 11:53 AM Please respond to MQSeries List Hello Bobbee, Sorry for continuing on the off-topic.. There is something common and unfortunate in all unions I heard about from my buddies and relatives who happened to join them: after a little while a union is going to take advantage of its hard working members much more efficiently than the employer. So, unless you are going to leave the technical side and join the dark one (meaning -- union administration), a union may not be a beneficial idea for you. For some intermediate form, though, take a look at http://www.freelancersunion.org/. I am not saying they are not like all others unions (and I am not a member myself, I am permanent as of now), but at least they do not have (and supposedly won't have any soon) an exlusive with any employer/trade of type "union job". Pavel Robert Broderick <[EMAIL PROTECTED]To: [EMAIL PROTECTED] OTMAIL.COM> cc: Sent by: MQSeries Subject: Re: Spiraling downhill List <[EMAIL PROTECTED] .AC.AT> 06/17/2003 11:26 AM Please respond to MQSeries List Yes I agree, And sure, There are alot of corners on Wall St. bee-oh-dubble-bee-dubble-egh >From: "Fryett.Chris" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Spiraling downhill >Date: Tue, 17 Jun 2003 09:18:08 -0400 > >Here! Here! > >It is more common today that contracting agencies are taking advantage of >the large surplus of unemployed by paying really bad, but charging the >clients a lot. I suspect that this contract agency if it is one is >charging the client 50-75 percent over this amount. > >Let me know when you get that tin can and I'll join you ;-) > >Chris > > >-Original Message- >From: Robert Broderick [mailto:[EMAIL PROTECTED] >Sent: Tuesday, June 17, 2003 7:59 AM >To: [EMAIL PROTECTED] >Subject: Spiraling downhill > > >This is not a technical issue so take a back seat if you want to complain > >WOW. Look at this. Notice the rate > >SKILLS REQUIRED: MQ Series, Unix, mainframe >LOCATION: Hicksville, NY >RATE: $25-30/hr >AREA: 516 >LENGTH: 12 months >TERM: CON_IND CON_CORP >SUMMARY: X Xx has an immediate opening for a Software Support >Specialist. Candidate should be able work as a MQ Series administrator and >support various MQ series messaging infrastructure related projects. >Candidate must be familiar with MQSeries V5.2 and... > >You know there is a vagrant who hangs out in fromnt of Grand Central >Station. They did and article on him a few years back in the NY Times. He >supposedly make about 100+ K a year pan handeling. I think after my current >contract ends I'm going to the hardware store to get a tin cup and increase >my revenue why decreasing my exposure to STRESS!! We need to start a >UNION!!! > > >bee-oh-dubble-bee-dubble-egh > >_ >The new MSN 8: advanced junk mail protection and 2 months FREE* >http://join.msn.com/?page=features/junkmail > >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 > > >* >The information transmitted is intended solely for the >individual or entity to which it is addressed and may >contain confidential and/or privileged material. Any >review, retransmission, dissemination or other use of >or taking action in reliance upon this information by >persons or entities other than the intended recipient >is prohibited. If you have received this email in error >please contact the sender and delete the material >from any com
Re: Spiraling downhill
AMEN! Start a union, or maybe get our legislature to wake up and smell the coffee... The good old USA lost 2 million jobs last year. Offshore jobs reduce our wages and also pay zero income taxes. Do you hear that that sucking sound its these jobs on our economy. These offshore income earners at Americans expense spend zero, none, nada, zip, zilch, money in America resulting in zero sales taxes being paid as well. This great offshore push only lines the pockets of the CEO's and the like. They are nothing but a drain on our economy. It may not be your job today but it could be tomorrow. I wonder how long we will go and how bad it will get before we get serious about a union or employing a powerful lobbyist. Most say no not me I am more talented than the offshore talent. I have one question for you then when has management concerned itself with talent over cost? I believe this was discussed long and hard not to far back. Deflation... well if we spiral into deflation as Greenspan hints at... look no further than right here at this issue for the root cause. Lower wages with the same or even increased goods output as the supplysiders are in control now. Some how some way supplysiders believe giving tax breaks to the producers will result in an economic pickup. I have never understood how giving tax breaks for plant improvements and capital expenditures is going to result in increased spending and thus resulting in higher demand and finally corporate hiring. They talk out bnoth sides of their mouths anyway saying small business powers the growth in the US economy whole give the tax cuts to their fat cat campaign contributors. If anything results from plant modernization its fewer people with jobs. So if you can not tell I still think this is voodoo economics. Bottom line deflation is too few dollars chasing to many goods I do not think you have to look to hard to see this as a very real possiblity. Could Greenspan do any more to increase the money supply - not much could he make the cost of money much cheaper? I doubt it. The next rate cut will result in money market funds being unable to stay in existance and thus will provide even more fuel to the stock market which is currently in serious disconnect reelect the president mode. What has gone up in price in the last 5 years besides housing and oil products? Cars - No Clothes - nah still the same if not cheaper as retailers resort to more frequent and deeper price reductions to move product. Travel has not gone up at least this has ben my observation. Cars - no way you get more car today for cheaper than anytime in history. Food has not gone up atleast I do not see it. When I go to the grocery store or to my local McDonalds and get my $1 chicken McNuggets on Tuesday and $1 filet of fish on Friday prices seem cheaper than ever! : ) Bottom line: WE NEED A VOICE and NOW! Robert Broderick <[EMAIL PROTECTED]To: [EMAIL PROTECTED] otmail.com> cc: Sent by: MQSeries Subject: Spiraling downhill List <[EMAIL PROTECTED] .AC.AT> 06/17/2003 04:58 AM Please respond to MQSeries List This is not a technical issue so take a back seat if you want to complain WOW. Look at this. Notice the rate SKILLS REQUIRED: MQ Series, Unix, mainframe LOCATION: Hicksville, NY RATE: $25-30/hr AREA: 516 LENGTH: 12 months TERM: CON_IND CON_CORP SUMMARY: X Xx has an immediate opening for a Software Support Specialist. Candidate should be able work as a MQ Series administrator and support various MQ series messaging infrastructure related projects. Candidate must be familiar with MQSeries V5.2 and... You know there is a vagrant who hangs out in fromnt of Grand Central Station. They did and article on him a few years back in the NY Times. He supposedly make about 100+ K a year pan handeling. I think after my current contract ends I'm going to the hardware store to get a tin cup and increase my revenue why decreasing my exposure to STRESS!! We need to start a UNION!!! bee-oh-dubble-bee-dubble-egh _ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail 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: MQSERIES AND CICS
hell I was Jealous of your name (mqm) "Beinert, William" To: [EMAIL PROTECTED] <[EMAIL PROTECTED]cc: OM> Subject: Re: MQSERIES AND CICS Sent by: MQSeries List <[EMAIL PROTECTED] N.AC.AT> 06/12/2003 10:50 AM Please respond to MQSeries List cool, Steve. I always looked in askance at people who seemed to want to hide their identity in technical fora. Bill -Original Message- From: mqm mqm [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2003 1:46 PM To: [EMAIL PROTECTED] Subject: Re: MQSERIES AND CICS Dave, I'm not deliberately keeping my identity a secret. It's just that I don't have an unusual name like yours and therefore I couldn't get a decent yahoo email address. And the email account was set up just to access the listserv so the mqm signature seemed like a good idea at the time. I've just never changed it. And I wasn't expressing any views just pointing someone in the direction of a product that might provide them with a solution. I'm not sure why that makes the views that I express on this forum any more biased than yours or those of anyone else who works for a software company. >From now on I promise to sign my real name! Steve Kelly Senior Consultant TheDotComBusiness www.thedotcombusiness.co.uk 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: MQSERIES AND CICS
layer > >themselves into a calling stack that is so far removed from MQ and the > >world of messaging in general, that it is really scary. In the end the > >programmers are nothing more than changing monkeys that know how to read > >company specific change diagrams - and then just do it. > > > >what a waste of brain power. > > > >Francois van der Merwe > > > > > > > > > > Ronald Weinger > > <[EMAIL PROTECTED]To: > >[EMAIL PROTECTED] > > .COM>cc: > > Sent by: MQSeriesSubject: Re: MQSERIES >AND > >CICS > > List > > <[EMAIL PROTECTED] > > N.AC.AT> > > > > > > 10/06/2003 22:28 > > Please respond to > > MQSeries List > > > > > > > > > >Oh no! > >A rebel without a queue. > > > > > > > > > > "Robert Broderick" > > <[EMAIL PROTECTED]To: > >[EMAIL PROTECTED] > > OTMAIL.COM> cc: > > Sent by: "MQSeriesSubject: Re: MQSERIES >AND > >CICS > > List" > > <[EMAIL PROTECTED] > > .AC.AT> > > > > > > 06/10/2003 03:59 > > PM > > Please respond to > > "MQSeries List" > > > > > > > > > > > > > > > > > >From: Randy J Clark <[EMAIL PROTECTED]> > > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > > >To: [EMAIL PROTECTED] > > >Subject: Re: MQSERIES AND CICS > > >Date: Tue, 10 Jun 2003 11:05:59 -0700 > > > > > >The Bridge simply reads the message passes it to your program BUT it is > >not > > >called by your program like a wrapper. Its monitoring a queue and when >a > > >message arrives it reads it and links to your program and passes the > > >message to your program in the commarea. > > > > > > > > >This is not going to be a substitute for times when you have to add MQ > >API > > >calls into an existing program. Your programmers can not always use >the > > >bridge and thus they will learn the API calls. The API from batch to > > >online is the same so have no fear they will not be isolated from > >learning > > >the MQ API just because they use the bridge in appropriate situations. > > > > > > > > > > > > Robert Broderick > > > <[EMAIL PROTECTED]To: > > >[EMAIL PROTECTED] > > > otmail.com> cc: > > > Sent by: MQSeries Subject: Re: MQSERIES > >AND > > >CICS > > > List > > > <[EMAIL PROTECTED] > > > .AC.AT> > > > > > > > > > 06/10/2003 07:35 > > > AM > > > Please respond to > > > MQSeries List > > > > > > > > > > > > > > > > > > > > >Back to my comments and Dennis'. You will end up building something > >simular > > >to what the bridge offers. Except you will be in charge of the coding. >So > > >if > > >you have requirements NOW or in the Future that the Bridge does not > >address > > >it is within you scope to add it. > > > > > >Now it becomes a point of getting someone to write the code. The >Bridge, > > >although I never worked with it, is a wrapper for MQ to your CICS > >programs. > > >Do you want your CICS programmers sheilded from the MQ stuff. That is a > > >call > > >for your IT people. I prefer to allow everyone to be educated. Makes >for > >a > > >more robust programming environment. Some will argue that it also > > >intorduces > > >the "WILDCARD" syndrome. T much knowledge is dangerous. I on the > >other > > >hand believ in "Give them a fish and they eat for the day. Teach them >to > > >Fish and t
Re: MQSERIES AND CICS
wow someone that is making sense... I agree just because programmers are not bit flippers and are closer to burger flippers (due to offshore outsourcing - ooops I digress) is that necessarily a bad thing "Fryett.Chris" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] TRUST.COM> cc: Sent by: MQSeriesSubject: Re: MQSERIES AND CICS List <[EMAIL PROTECTED] N.AC.AT> 06/10/2003 02:04 PM Please respond to MQSeries List There is no shame for a poor programmer, just the rich ones ;-) This is part of evolution or in some instances de-evolution. Look at the programming languages today. Today kids or young developers don't know squat about memory or computer systems, because they are spoiled with languages like Java and Visual Basic. Look at 'C' which protected most developers from having to do assembler. Are we really wasting brain power, or just putting our effort towards real solutions? Look at MQ which protects the programmer from knowing the different transport protocols. Chris -Original Message- From: Francois Van der Merwe1 [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 10, 2003 10:50 AM To: [EMAIL PROTECTED] Subject: Re: MQSERIES AND CICS I've also seen companies getting so obsessed with "protecting the programmer from MQ complexity" (shame, poor programmers) that they layer themselves into a calling stack that is so far removed from MQ and the world of messaging in general, that it is really scary. In the end the programmers are nothing more than changing monkeys that know how to read company specific change diagrams - and then just do it. what a waste of brain power. Francois van der Merwe Ronald Weinger <[EMAIL PROTECTED]To: [EMAIL PROTECTED] .COM>cc: Sent by: MQSeriesSubject: Re: MQSERIES AND CICS List <[EMAIL PROTECTED] N.AC.AT> 10/06/2003 22:28 Please respond to MQSeries List Oh no! A rebel without a queue. "Robert Broderick" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] OTMAIL.COM> cc: Sent by: "MQSeriesSubject: Re: MQSERIES AND CICS List" <[EMAIL PROTECTED] .AC.AT> 06/10/2003 03:59 PM Please respond to "MQSeries List" So lets say a programmer has only to receive a message and process it. The company picks the bridge. When does the programmer get to learn about MQ?? I have interviewed people who have worked at companies that allowed them access to MQ through their own home grown software (wrappers) These people were useless (in regards to detailed MQ knowledge). The company while pretending to isolate themselves from the messaging layer for the purpose of maybe changing later (remember MQ has about an 84% market share) (hahaha!! Change later?? To What??) has basically limited the usefulness of it's staff to accommodate change. Remember we came into technology to embrace ALL the aspects of technology not to be the porn (opps sorry) pawn of some technology wizards corporate paranoias. If you disagree call 1-800-LACTOSS (Dennis Miller, not to be confused with our beloved DM!!) bee-oh-dubble-bee-dubble-egh >From: Randy J Clark <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: MQSERIES AND CICS >Date: Tue, 10 Jun 2003 11:05:59 -0700 > >The Bridge simply reads the message passes it to your program BUT it is not >called by your program like a wrapper. Its monitoring a queue and when a >message arrives it reads it and links to your program and passes the >message to your program in the commarea. > > >This is not going to be a substitute for times when you have to add MQ API >calls into an existing program. Your programmers can not always use the >bridge and thus they will learn the API calls. The API from batch to >online is the same so have no fear they will not be isolated from learning >the MQ API just because they use the bridge in appropriate situations. > > > > Robert Broderick > <[EMAIL PROTECTED]To: >[EMAIL PROTECTED] >
Re: MQSERIES AND CICS
NEVER! Just kidding I get your point and I am sure we both know the truth is we pick the tool that is appropriate for the job and sometimes heck yes we pick a tool just to learn it so we have the expertise in house... but outside of that between the bridge and the adapter they are really not to ways to solve the same problem - sure thay can both be used to do the same thing and I can hammer a nail with a screwdriver or maybe even a hardsoled shoe but does that make it right. When Well When program is an existing non DPL program and to make it one would be counterproductive. If you are designing from scratch make it the program a DPL program and use the bridge and the program is them more versatile others can link to it as well and just pass it data from whatever source they get the data from... I am done. Robert Broderick <[EMAIL PROTECTED]To: [EMAIL PROTECTED] otmail.com> cc: Sent by: MQSeries Subject: Re: MQSERIES AND CICS List <[EMAIL PROTECTED] .AC.AT> 06/10/2003 12:59 PM Please respond to MQSeries List So lets say a programmer has only to receive a message and process it. The company picks the bridge. When does the programmer get to learn about MQ?? I have interviewed people who have worked at companies that allowed them access to MQ through their own home grown software (wrappers) These people were useless (in regards to detailed MQ knowledge). The company while pretending to isolate themselves from the messaging layer for the purpose of maybe changing later (remember MQ has about an 84% market share) (hahaha!! Change later?? To What??) has basically limited the usefulness of it's staff to accommodate change. Remember we came into technology to embrace ALL the aspects of technology not to be the porn (opps sorry) pawn of some technology wizards corporate paranoias. If you disagree call 1-800-LACTOSS (Dennis Miller, not to be confused with our beloved DM!!) bee-oh-dubble-bee-dubble-egh >From: Randy J Clark <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: MQSERIES AND CICS >Date: Tue, 10 Jun 2003 11:05:59 -0700 > >The Bridge simply reads the message passes it to your program BUT it is not >called by your program like a wrapper. Its monitoring a queue and when a >message arrives it reads it and links to your program and passes the >message to your program in the commarea. > > >This is not going to be a substitute for times when you have to add MQ API >calls into an existing program. Your programmers can not always use the >bridge and thus they will learn the API calls. The API from batch to >online is the same so have no fear they will not be isolated from learning >the MQ API just because they use the bridge in appropriate situations. > > > > Robert Broderick > <[EMAIL PROTECTED]To: >[EMAIL PROTECTED] > otmail.com> cc: > Sent by: MQSeries Subject: Re: MQSERIES AND >CICS > List > <[EMAIL PROTECTED] > .AC.AT> > > > 06/10/2003 07:35 > AM > Please respond to > MQSeries List > > > > > > >Back to my comments and Dennis'. You will end up building something simular >to what the bridge offers. Except you will be in charge of the coding. So >if >you have requirements NOW or in the Future that the Bridge does not address >it is within you scope to add it. > >Now it becomes a point of getting someone to write the code. The Bridge, >although I never worked with it, is a wrapper for MQ to your CICS programs. >Do you want your CICS programmers sheilded from the MQ stuff. That is a >call >for your IT people. I prefer to allow everyone to be educated. Makes for a >more robust programming environment. Some will argue that it also >intorduces >the "WILDCARD" syndrome. T much knowledge is dangerous. I on the other >hand believ in "Give them a fish and they eat for the day. Teach them to >Fish and they will be less likely to p.i.s.s in the water!! > > > bobbee > > > >From: June Lawton <[EMAIL PROTECTED]> > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: Re: MQSERIES AND CICS > >Date: Tue, 10 Jun 2003 08:38:02 -0400 > > > >I was
Re: MQSERIES AND CICS
I think you are thinking they are two ways to do the same thing not exactly and I doubt the Bridge is going to fit in all situations and thus will not allow your people to remain ignorant of the MQ API or allow management to keep them in this state. The situation is the program you want to process data from a queue a DPL program? If not you must add code into the program or convert it to DPL. If its a DPL program believe me the Bridge is the way to go since it is all ready expecting data to be passed to it why add MQ code into it when to do so would be a wasted effort. if the program is a started transaction you can nto use the bridge without converting it to a linked to program if started and you need to access a queue you must have installed the adapter. The adapter simply allows the CICS programs to make MQ API calls without it you can not. Robert Broderick <[EMAIL PROTECTED]To: [EMAIL PROTECTED] OTMAIL.COM> cc: Sent by: MQSeries Subject: Re: MQSERIES AND CICS List <[EMAIL PROTECTED] .AC.AT> 06/09/2003 04:24 PM Please respond to MQSeries List Unwillingness by corp to fund education reluctance by staff to lean new technology project funding for development tasks legacy code toolset vacuum >From: June Lawton <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: MQSERIES AND CICS >Date: Mon, 9 Jun 2003 11:50:35 -0400 > >What would the determining factors be for using the MQ Adapter as opposed >to MQ Bridge with CICS? > > > >June Lawton >Information Systems >The PMA Insurance Group >[EMAIL PROTECTED] >(T) 610.397.5058 >(F) 610.397.5311 > >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 _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail 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: MQSERIES AND CICS
The Bridge simply reads the message passes it to your program BUT it is not called by your program like a wrapper. Its monitoring a queue and when a message arrives it reads it and links to your program and passes the message to your program in the commarea. This is not going to be a substitute for times when you have to add MQ API calls into an existing program. Your programmers can not always use the bridge and thus they will learn the API calls. The API from batch to online is the same so have no fear they will not be isolated from learning the MQ API just because they use the bridge in appropriate situations. Robert Broderick <[EMAIL PROTECTED]To: [EMAIL PROTECTED] otmail.com> cc: Sent by: MQSeries Subject: Re: MQSERIES AND CICS List <[EMAIL PROTECTED] .AC.AT> 06/10/2003 07:35 AM Please respond to MQSeries List Back to my comments and Dennis'. You will end up building something simular to what the bridge offers. Except you will be in charge of the coding. So if you have requirements NOW or in the Future that the Bridge does not address it is within you scope to add it. Now it becomes a point of getting someone to write the code. The Bridge, although I never worked with it, is a wrapper for MQ to your CICS programs. Do you want your CICS programmers sheilded from the MQ stuff. That is a call for your IT people. I prefer to allow everyone to be educated. Makes for a more robust programming environment. Some will argue that it also intorduces the "WILDCARD" syndrome. T much knowledge is dangerous. I on the other hand believ in "Give them a fish and they eat for the day. Teach them to Fish and they will be less likely to p.i.s.s in the water!! bobbee >From: June Lawton <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: MQSERIES AND CICS >Date: Tue, 10 Jun 2003 08:38:02 -0400 > >I was thinking more along the lines of functionality, additional coding >requirements, DPL, etc. For our proof of concept project we want to >replace an application that currently accesses CICS via an EXCI from a DB2 >stored procedure. Currently this request goes directly into an AOR. >However, with our future apps, we may want them to be 3270 initiated via >the TOR. > >I guess what I am asking under what will one give you that the other >doesn't? Basically we want to get tinto CICS and just run the existing >programs. > > > > > >June Lawton >Information Systems >The PMA Insurance Group >[EMAIL PROTECTED] >(T) 610.397.5058 >(F) 610.397.5311 >- Forwarded by June Lawton/PMA/PMAGroup on 06/10/2003 08:40 AM - > > Robert Broderick > <[EMAIL PROTECTED]To: >[EMAIL PROTECTED] > OTMAIL.COM> cc: > Sent by: MQSeries Subject: Re: MQSERIES AND >CICS > List > <[EMAIL PROTECTED] > .AC.AT> > > > 06/09/2003 07:24 > PM > Please respond to > MQSeries List > > > > > > >Unwillingness by corp to fund education >reluctance by staff to lean new technology >project funding for development tasks >legacy code toolset vacuum > > > >From: June Lawton <[EMAIL PROTECTED]> > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: MQSERIES AND CICS > >Date: Mon, 9 Jun 2003 11:50:35 -0400 > > > >What would the determining factors be for using the MQ Adapter as opposed > >to MQ Bridge with CICS? > > > > > > > >June Lawton > >Information Systems > >The PMA Insurance Group > >[EMAIL PROTECTED] > >(T) 610.397.5058 > >(F) 610.397.5311 > > > >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 > >_ >Add photos to your messages with MSN 8. Get 2 months FREE*. >http://join.msn.com/?page=features/featuredemail > >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 _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus Instructions for managing your mailin
Re: 2059 trying to connect mq series 5.3 on z/os 1.4 and new question ??
I DO NOT THINK IT WAS EVER FREE AND ITS ONE OF THOSE THINGS WHERE YOU PROBABLY NEED TO TALK TO YOUR IBM SALES REP. javier sotela <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 03/12/2003 03:18:07 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: 2059 trying to connect mq series 5.3 on z/os 1.4 and new question ?? Thanks for all the responses, its look like we need the CAF for z/os. Does anybody know if this feature was for free in releases 2.x, and know its not free or it is still for free in mq 5.x. If so, where i can get it, is there any place on internet to download or something like that. TIA Javier S. >From: Roger Lacroix <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: 2059 trying to connect mq series 5.3 on z/os 1.4 >Date: Tue, 11 Mar 2003 18:50:11 -0500 > >Hi, > >Do you the "Client Attachment Feature" (CAF) installed on z/OS? It is >separate >product from WMQ. > >To find out if you have CAF installed on z/OS, look at CHIN >started-task >(on z/OS under SDSF, Display Active) for the following: > +CSQX099I CSQXGIP Client attachment feature available > >where is the z/OS queue manager name. > >later >Roger... > >Quoting javier sotela <[EMAIL PROTECTED]>: > > > Hi Everyone: > > > > We are trying to connect to a mq series 5.3 on z/os 1.4 from different > > clients, windows, unix, etc, but we are receiving a 2059 error from the > > mainframe. With mq series server to server the communiaction its o.k., >the > > only problem is trying to connect client to server (at mq level). > > The channel server its working and connected, any ideas > > > > TIA. > > > > Javier S. > > > > > > > > > > > > _ > > The new MSN 8: smart spam protection and 2 months FREE* > > http://join.msn.com/?page=features/junkmail > > > > 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 _ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail 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: 2059 trying to connect mq series 5.3 on z/os 1.4 <-- Attachment History Removed
Javier Bottom line you need the CAF to attach to the os390 server. You are connecting as a client and they are going to want to sell that little feature to you! Alan Stewart <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 03/11/2003 04:37:08 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: 2059 trying to connect mq series 5.3 on z/os 1.4 Javier, when I make a client connection to a queue manager, I specify the hostname, server connection channel and tcp port of the queue manager's listener. You can create a listener for the queue manager concerned if one doesn't already exist. Alan javier sotela <[EMAIL PROTECTED]> Sent by: MQSeries List To <[EMAIL PROTECTED]> [EMAIL PROTECTED] H-WIEN.AC.A 12/03/2003 10:17 AM T cc Please respond to MQSeries List Subject <[EMAIL PROTECTED] Re: 2059 AT> trying to connect mq series 5.3 on z/os 1.4 Alan: Maybe you can help me, when you mention listener, what do you mean ?? We have defined a server connection, could you tell me with more detail how you turn off the listener and what do you mean TIA. Javier S. >From: Alan Stewart <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: 2059 trying to connect mq series 5.3 on z/os 1.4 >Date: Wed, 12 Mar 2003 08:53:03 +1100 > >Is the listener running ? or is the listener port OK? > >I just did a test by turning off my listener for my one of my mq >client-connected applications, and got a 2059. It also occurred when I >deliberately used a wrong port as well > >Alan > > > >javier sotela <[EMAIL PROTECTED]> >Sent by: MQSeries List <[EMAIL PROTECTED]> >12/03/2003 08:38 AM >Please respond to >MQSeries List <[EMAIL PROTECTED]> > > >To >[EMAIL PROTECTED] >cc > >Subject >2059 trying to connect mq series 5.3 on z/os 1.4 > > > > > > >Hi Everyone: > >We are trying to connect to a mq series 5.3 on z/os 1.4 from different >clients, windows, unix, etc, but we are receiving a 2059 error from the >mainframe. With mq series server to server the communiaction its o.k., the >only problem is trying to connect client to server (at mq level). >The channel server its working and connected, any ideas > >TIA. > >Javier S. > > > > > >_ >The new MSN 8: smart spam protection and 2 months FREE* >http://join.msn.com/?page=features/junkmail > >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 > > ><< Disclaimer.txt >> _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail 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: 2059 trying to connect mq series 5.3 on z/os 1.4
YOUR CASE IS EXACTLY WHEN IT IS REQUIRED!!! javier sotela <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 03/11/2003 03:10:00 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: 2059 trying to connect mq series 5.3 on z/os 1.4 Hi everyone: There is two people asking about the client attach feature on the Z/OS, if I understand correctly this feature is used only when you try to connect from z/os to a other mq series server. In my case, I'm connecting from windows or unix to the z/os. The mq server its on z/os. In this case, is the client attach feature on the Z/OS required ??? TIA. Javier S. >From: Richard Crook <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: 2059 trying to connect mq series 5.3 on z/os 1.4 >Date: Wed, 12 Mar 2003 10:54:26 +1300 > >Javier, >2059 is QMGR_NOT_AVAILABLE. Are you getting this on the client end? > >I presume that you have the client attach feature on the Z/OS version of >MQ? On Z/OS, client attach is a seperate, chargable feature. I believe that >it's included as part of the Qmgr on all the other platforms. > >Richard. > > > > > >javier sotela <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 12/03/2003 10:38:31 > >Please respond to MQSeries List <[EMAIL PROTECTED]> > >Sent by:MQSeries List <[EMAIL PROTECTED]> > > >To:[EMAIL PROTECTED] >cc: >Subject:2059 trying to connect mq series 5.3 on z/os 1.4 > > >Hi Everyone: > >We are trying to connect to a mq series 5.3 on z/os 1.4 from different >clients, windows, unix, etc, but we are receiving a 2059 error from the >mainframe. With mq series server to server the communiaction its o.k., the >only problem is trying to connect client to server (at mq level). >The channel server its working and connected, any ideas > >TIA. > >Javier S. > > > > > >_ >The new MSN 8: smart spam protection and 2 months FREE* >http://join.msn.com/?page=features/junkmail > >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 > > The contents of this e-mail are confidential. If you have received this > communication by mistake, please advise the sender immediately and delete > the message and any attachments. > Westpac Banking Corporation, ABN 33 007 457 141, is incorporated in > Australia > > > >- >The contents of this e-mail are confidential. If you have received this >communication by mistake, please advise the sender immediately and delete >the message and any attachments. >Nothing in this email designates an information system for the purposes of >Section 11(a) of the New Zealand Electronic Transactions Act 2002. >Westpac Banking Corporation, ABN 33 007 457 141, is incorporated in >Australia >- > >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 _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail 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: 2059 trying to connect mq series 5.3 on z/os 1.4
u need the CAF in your case a server can connect to another server but for other non servers CLIENTS to be able to connect to os390 you need the CAF javier sotela <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 03/11/2003 03:17:41 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: 2059 trying to connect mq series 5.3 on z/os 1.4 Alan: Maybe you can help me, when you mention listener, what do you mean ?? We have defined a server connection, could you tell me with more detail how you turn off the listener and what do you mean TIA. Javier S. >From: Alan Stewart <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: 2059 trying to connect mq series 5.3 on z/os 1.4 >Date: Wed, 12 Mar 2003 08:53:03 +1100 > >Is the listener running ? or is the listener port OK? > >I just did a test by turning off my listener for my one of my mq >client-connected applications, and got a 2059. It also occurred when I >deliberately used a wrong port as well > >Alan > > > >javier sotela <[EMAIL PROTECTED]> >Sent by: MQSeries List <[EMAIL PROTECTED]> >12/03/2003 08:38 AM >Please respond to >MQSeries List <[EMAIL PROTECTED]> > > >To >[EMAIL PROTECTED] >cc > >Subject >2059 trying to connect mq series 5.3 on z/os 1.4 > > > > > > >Hi Everyone: > >We are trying to connect to a mq series 5.3 on z/os 1.4 from different >clients, windows, unix, etc, but we are receiving a 2059 error from the >mainframe. With mq series server to server the communiaction its o.k., the >only problem is trying to connect client to server (at mq level). >The channel server its working and connected, any ideas > >TIA. > >Javier S. > > > > > >_ >The new MSN 8: smart spam protection and 2 months FREE* >http://join.msn.com/?page=features/junkmail > >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 > > ><< Disclaimer.txt >> _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail 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: Fun with MQ
or committed. Ronald Weinger <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 01/16/2003 12:11:28 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: Fun with MQ Someone tried that when the first electronic poker machines were introduced. He ended up permanently SYNCPOINTED. "Wyatt, T. Rob" cc: Sent by: "MQSeries Subject: Re: Fun with MQ List" <[EMAIL PROTECTED] C.AT> 01/16/2003 02:45 PM Please respond to "MQSeries List" Absolutely! I plan to leave code snippets in every casino on the strip. (The house has a slight advantage, you know...) -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 16, 2003 1:37 PM To: [EMAIL PROTECTED] Subject: Re: Fun with MQ Rob, Getting ready for the night life in Vegas? Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 -Original Message- From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 16, 2003 1:22 PM To: [EMAIL PROTECTED] Subject: Fun with MQ MQ Message pick-up lines... Your queue or mine? What's your sign-bit? Is that a COA in your message descriptor, or are you just glad to see me? What's a message like you doing in a queue like this? You look like you've got a good message header on your shoulders. With your payload and my routing information, we could really go places! Is this buffer taken? You remind me of my first QMgr. You make my HBINT go wild! Does this channel go all the way to Chicago? I must have expired because I'm looking at an angel! Your message segments are in all the right places! I'll bet our code pages are compatible. Don't tell anyone, but I'm a message channel secret-agent. Wanna be in my cluster? MQ Message rejections... I'm GET Disabled. I could never commit to a message like you. Come back when you have a higher priority. Not even if you were the last message in the queue! Your backout-count is showing. I'm in a proprietary format and you could never parse me. You are a Dead Letter entry waiting to happen. Locked by another process. Don't let the message exit hit you on the ass on the way out! You sure are persistent, aren't you? User-defined format? Right! Like I haven't heard THAT before! You're ASCII and I'm EBCDIC. It would never work out. You've expired and don't even know it. Sorry, no available BROWSE handles. You've obviously mistaken me for an event message. GET WAIT forever, buddy! MQ Message Sour Grapes... It was probably a poison message anyway. That "Rules and Format Header" should've been my first clue. Every time I meet a really nice message, it's addressed to a remote node. Messages. Give 'em a K and they'll take a MB. Ok, new rule - never date a message from a queue-sharing group! Well, I didn't really want to convert just for the relationship. Never trust a message with an alias queue name. That other message was probably going to expire soon anyway. That's the last time I'll ever bare my context information over a drink! More like a hair-trigger message if you ask me! Momma told me never to mix with MSMQ messages. That message was too old a version for me anyway. I guess we'll always be in different units of work. Seems like and the really good messages are under syncpoint. Ok, that's it. I'm giving up message affinities altogether! I had a little too much time on my hands over lunch break. -- T.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 This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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 The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and d
Re: Remote Queues
yes I think so... but the input of others has led me to be less willing to try sell my way as the best way! smile Before I could hardly see when I would think to not have a remote queue def would led to over administration work but now I can see when there might be such cases. "Bullock, Rebecca (CSC)" <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 01/10/2003 10:06:26 AM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: Remote Queues Randy, I think you've answered your own question -- it all depends on your environment and applications. -----Original Message- From: Randy J Clark [mailto:[EMAIL PROTECTED]] Sent: Friday, January 10, 2003 12:42 PM To: [EMAIL PROTECTED] Subject: Re: Remote Queues I should clarify - I was not talking about hardcoding per se but using the replytoqmgr and replytoqueuename and not defining them on the replying side qmanager. I know these are mutually exclusive we have hundreds of flows and only about 3 or 4 have taken this approach and everytime there is a problem it kinda stumps us for a bit because we can not even find the definition for the queue they are talking about - then we say oh ya its not required and they have to go back to their program and find the complete queue name for us. Doing this there is no visibility to the flow inside of MQ when looking at definitions - you know there is a channel and an xmitQ queue but if someone asked you what these are used for other than sending messages all you could do is shrug your shoulders. we also have had to add multiple channels to service some message flows when we did this all we had to do create the channels and xmitQ's and modify the RemoteQdefs and no application changes were required this was a lifesaver. Tim Armstrong <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 01/09/2003 05:21:52 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: Remote Queues Except that you can wind up with hundreds of definitions, queue manager aliasing is kind of nice for avoiding that. Someone else mentioned hardcoding of names I would have thought that the actual names of destination queue and queue manager should be in a configuration file read by the program not hard coded. Also if you take proper advantage of MQ's clustering features then you have no need to create remote queue definitions it's all done automatically. I realise that MQ clustering used to have its own problems but its pretty stable now. Regards Tim A Randy J Clark cc: Sent by: MQSeriesSubject: Remote Queues List 10/01/2003 08:49 Please respond to MQSeries List I am asking for some opinions on sending to remote queues without having a remote queue definition on the sending queue manager just specifying remote qmgr and remote queue name in the MQOPEN. Usig this method. In the ObjectName field of the MQOD structure, specify the name of the remote queue, as known to the remote queue manager. In the ObjectQMgrName field, specify either: The name of the transmission queue that has the same name as the remote queue manager. Note that the name and case (capitals, lower case or a mixture) must match exactly. The name of a queue manager alias object that resolves to the destination queue manager or the transmission queue. This tells the queue manager the destination of the message as well as the transmission queue it needs to be put on to get there. I know there are or maybe times when you "have to" do it this way but overall I am not crazy about the lack of documentation involved using this method. Seems to me even if the sending application is not going to create and use a remote queue def on its own local Qmgr one should or maybe should exist just for documentation purposes. Without this it seems there is no reasonable way to know exactly what is being sent between Qmgrs. Any comments?? As you can tell I think there should be I know an extra object created even if not used just for documentational purposes otherwise when ask what is going between these two qmgrs I have no idea. 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 ma
Re: Remote Queues
point well taken in our case the request/reply scenarios are simple straight forward and have a single qmgr requesting and a single qmgr replying - thanks. definitely makes me think though maybe requiring remote queue defs is more of a guideline and not a true requirement... I still think until we get to the point where we have the potential for an application to be getting requests from a lot of different queue managers and the admin gets crazy we should atleast point out the benefits (at least my perceived) from a documentation point of view of having the remote queue def. Robert Broderick <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 01/10/2003 04:59:10 AM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: Remote Queues You have a dynamic application that can at anytime receive messages from existing and NEW queue managers. Without overexcercising the ADMIN how would you handle this. The request message itself will allow the application to route the message back to the source without hardcoding queue names in the program. Security is security and maybe this is an issue left for client applications. But on an ITRANET I would think this is not an issue as everyone should be trusted. Or are we coming down to the fact that you cannot trust the person in the next cube! I implement this design when I can. It makes design and functionality easier. If the client has a problem with it . We just add 10 pounds of routing code to the program. bobbee >From: Randy J Clark <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Remote Queues >Date: Thu, 9 Jan 2003 13:49:50 -0800 > >I am asking for some opinions on sending to remote queues without having a >remote queue definition on the sending queue manager just specifying remote >qmgr and remote queue name in the MQOPEN. > >Usig this method. > > > In the ObjectName field of the MQOD structure, specify the name of > the remote queue, as known to the remote queue manager. In the > ObjectQMgrName field, specify either: > The name of the transmission queue that has the same name as > the remote queue manager. Note that the name and case > (capitals, lower case or a mixture) must match exactly. > The name of a queue manager alias object that resolves to the > destination queue manager or the transmission queue. > > > This tells the queue manager the destination of the message as well > as the transmission queue it needs to be put on to get there. > > >I know there are or maybe times when you "have to" do it this way but >overall I am not crazy about the lack of documentation involved using this >method. > >Seems to me even if the sending application is not going to create and use >a remote queue def on its own local Qmgr one should or maybe should exist >just for documentation purposes. > >Without this it seems there is no reasonable way to know exactly what is >being sent between Qmgrs. > >Any comments?? > >As you can tell I think there should be I know an extra object created even >if not used just for documentational purposes otherwise when ask what is >going between these two qmgrs I have no idea. > >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 _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail 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: Batch triggering
Exactly what we do too! We execute a proc that executes a program that
demands a job based on a parm.
Here is a sample process definition
DEFINE PROCESS('PR.H_HAL_010_BILL_OF_LADING.000') +
DESCR('Process for batch job H1MPU09P') +
APPLTYPE(MVS) +
APPLICID('// EXEC CU01AA,MEM=H1MPU09P') REPLACE
Jim Ford <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 01/10/2003 07:40:38 AM
Please respond to MQSeries List <[EMAIL PROTECTED]>
Sent by:MQSeries List <[EMAIL PROTECTED]>
To:[EMAIL PROTECTED]
cc:
Subject:Re: Batch triggering
We use the MA12 support pac, which allows batch triggering. We always
trigger a special program that goes into our production scheduling
system (OPC) and tells it to demand in the real job. That way all
scheduling dependencies are allowed for, and the submitted job is
tracked.
Larry Murray
cc:
Sent by: MQSeriesSubject: Batch triggering
List
01/10/2003 08:12
AM
Please respond to
MQSeries List
Good Morning,
Does anybody have experience with OS/390 batch triggering?
Looking for different ideas.
Thanks.Larry
Larry Murray
Putnam Investments
Tech Services
1-617-760-3270
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: Remote Queues
thanks... "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 01/10/2003 05:21:53 AM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: Remote Queues I always define remote queue defs, except on the replying side of a request/reply scenario. The replying application will always have Reply2Queue and Reply2QueueManager info from the request message. On day one where there is only 1 requestor, I suppose it wouldn't be a big hassle to make the remote queue def to point back to the (permanent) reply queue on the requestor's QM. But the nice thing about not having remote queue defs on the replying side is if the app is coded to dynamically respect the Reply2Queue and Reply2QueueManager info, you can have more and more requestors send messages in, and not have to make any admin or coding changes on the replying side as new requestors come on board. Also, any of the requestors can now use dynamic reply queues. On the requestor's side, I always use the remote defs. The name of the remote queue def is the same from DEV to QA to PROD, so as the app migrates between the testing levels, there is no need to change code or input properties files to simply accommodate the Queue Manager's name changing between the testing environments. Peter Potkay -Original Message- From: Tim Armstrong [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 8:22 PM To: [EMAIL PROTECTED] Subject: Re: Remote Queues Except that you can wind up with hundreds of definitions, queue manager aliasing is kind of nice for avoiding that. Someone else mentioned hardcoding of names I would have thought that the actual names of destination queue and queue manager should be in a configuration file read by the program not hard coded. Also if you take proper advantage of MQ's clustering features then you have no need to create remote queue definitions it's all done automatically. I realise that MQ clustering used to have its own problems but its pretty stable now. Regards Tim A Randy J Clark cc: Sent by: MQSeriesSubject: Remote Queues List 10/01/2003 08:49 Please respond to MQSeries List I am asking for some opinions on sending to remote queues without having a remote queue definition on the sending queue manager just specifying remote qmgr and remote queue name in the MQOPEN. Usig this method. In the ObjectName field of the MQOD structure, specify the name of the remote queue, as known to the remote queue manager. In the ObjectQMgrName field, specify either: The name of the transmission queue that has the same name as the remote queue manager. Note that the name and case (capitals, lower case or a mixture) must match exactly. The name of a queue manager alias object that resolves to the destination queue manager or the transmission queue. This tells the queue manager the destination of the message as well as the transmission queue it needs to be put on to get there. I know there are or maybe times when you "have to" do it this way but overall I am not crazy about the lack of documentation involved using this method. Seems to me even if the sending application is not going to create and use a remote queue def on its own local Qmgr one should or maybe should exist just for documentation purposes. Without this it seems there is no reasonable way to know exactly what is being sent between Qmgrs. Any comments?? As you can tell I think there should be I know an extra object created even if not used just for documentational purposes otherwise when ask what is going between these two qmgrs I have no idea. 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 This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: ht
Re: Remote Queues
I should clarify - I was not talking about hardcoding per se but using the replytoqmgr and replytoqueuename and not defining them on the replying side qmanager. I know these are mutually exclusive we have hundreds of flows and only about 3 or 4 have taken this approach and everytime there is a problem it kinda stumps us for a bit because we can not even find the definition for the queue they are talking about - then we say oh ya its not required and they have to go back to their program and find the complete queue name for us. Doing this there is no visibility to the flow inside of MQ when looking at definitions - you know there is a channel and an xmitQ queue but if someone asked you what these are used for other than sending messages all you could do is shrug your shoulders. we also have had to add multiple channels to service some message flows when we did this all we had to do create the channels and xmitQ's and modify the RemoteQdefs and no application changes were required this was a lifesaver. Tim Armstrong <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 01/09/2003 05:21:52 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: Remote Queues Except that you can wind up with hundreds of definitions, queue manager aliasing is kind of nice for avoiding that. Someone else mentioned hardcoding of names I would have thought that the actual names of destination queue and queue manager should be in a configuration file read by the program not hard coded. Also if you take proper advantage of MQ's clustering features then you have no need to create remote queue definitions it's all done automatically. I realise that MQ clustering used to have its own problems but its pretty stable now. Regards Tim A Randy J Clark cc: Sent by: MQSeriesSubject: Remote Queues List 10/01/2003 08:49 Please respond to MQSeries List I am asking for some opinions on sending to remote queues without having a remote queue definition on the sending queue manager just specifying remote qmgr and remote queue name in the MQOPEN. Usig this method. In the ObjectName field of the MQOD structure, specify the name of the remote queue, as known to the remote queue manager. In the ObjectQMgrName field, specify either: The name of the transmission queue that has the same name as the remote queue manager. Note that the name and case (capitals, lower case or a mixture) must match exactly. The name of a queue manager alias object that resolves to the destination queue manager or the transmission queue. This tells the queue manager the destination of the message as well as the transmission queue it needs to be put on to get there. I know there are or maybe times when you "have to" do it this way but overall I am not crazy about the lack of documentation involved using this method. Seems to me even if the sending application is not going to create and use a remote queue def on its own local Qmgr one should or maybe should exist just for documentation purposes. Without this it seems there is no reasonable way to know exactly what is being sent between Qmgrs. Any comments?? As you can tell I think there should be I know an extra object created even if not used just for documentational purposes otherwise when ask what is going between these two qmgrs I have no idea. 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
Remote Queues
I am asking for some opinions on sending to remote queues without having a remote queue definition on the sending queue manager just specifying remote qmgr and remote queue name in the MQOPEN. Usig this method. In the ObjectName field of the MQOD structure, specify the name of the remote queue, as known to the remote queue manager. In the ObjectQMgrName field, specify either: The name of the transmission queue that has the same name as the remote queue manager. Note that the name and case (capitals, lower case or a mixture) must match exactly. The name of a queue manager alias object that resolves to the destination queue manager or the transmission queue. This tells the queue manager the destination of the message as well as the transmission queue it needs to be put on to get there. I know there are or maybe times when you "have to" do it this way but overall I am not crazy about the lack of documentation involved using this method. Seems to me even if the sending application is not going to create and use a remote queue def on its own local Qmgr one should or maybe should exist just for documentation purposes. Without this it seems there is no reasonable way to know exactly what is being sent between Qmgrs. Any comments?? As you can tell I think there should be I know an extra object created even if not used just for documentational purposes otherwise when ask what is going between these two qmgrs I have no idea. 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: Restting Queue statistics
I am curious does WMQ still come with Manuals? In reviewing some of the recent postings it would seem as if the manuals have been obsoleted and replaced by the listserv. MQSeries <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 01/07/2003 02:44:00 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: Restting Queue statistics You could use support pac MO71 to reset queue stats. http://www-3.ibm.com/software/ts/mqseries/txppacs/mo71.html You could also modify sample C program AMQSAILQ. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED]] On Behalf Of Manickam, Roshini Sent: Tuesday, January 07, 2003 4:21 PM To: [EMAIL PROTECTED] Subject: Restting Queue statistics Hi, I need to rest queue stats . This supposedly also returns the values for TimeSinceReset, HighQDepth, MsgEnqCount and MsgDeqCount which I am interested in. I beleive it is supported by MQAI but am unable to find the command and it's syntax to do the same. Has anybody ever done this , or has a sample program that can do the same. Thanks, Roshini 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: Am I asking too much to MQ?!?! (PROTOm@il:200211221113 CENTROSIM) <-- Attachment History Removed
I know this is an obvious suggestion but I did not see anyone make it this time. Why not block the records into say a 32k block for a nice easy round number... when you send each 380 byte record they each get their own 324 byte MQMD. we block everything now when sending groups of messages or files the performance improvements are dramatic especially when each record is so small - we were sending 30 bytes messages and each one got a 324 MQMD - kinda ridiculous huh. Alessandro Caffarra <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 11/22/2002 06:21:14 AM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Am I asking too much to MQ?!?!(PROTOm@il:200211221113 CENTROSIM) As many of know, I am sending a file from a Win2K MQ to a MVS-based MQ. For some file integrity reason I am sending all records within the same SYNCPOINT: if all records are gone (I.E. my app reached the EOF without any bad retcode from MQ), I will issue a MQCMIT once. Today the input file is about 6000 rks, about 380 byte each, and MQ return a retcode 2 with reason 2003, after 4754 rks. Am I asking too much?! 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: MQGET with CORRELID on OS/390.
I agree use the entire 24 bytes correlid first before you start thinking it is your mq coding I think what you have is a match problem spaces verses low-values... fill up the entire 24 bytes and see if it works as we use this option extensively and we have no problems in fact if we did we would be in big trouble. "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 11/19/2002 06:10:45 AM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: MQGET with CORRELID on OS/390. I always had a problem using the MATCH CORRELID option in my COBOL code. There is no need to use it. If you do an MQGET on OS/390 and there is some value in the either the CORRELID field or the MESSAGID field (i.e. they are not initialized), that is what you will attempt to match on, regardless of the fact that MATCH CORRELID or MATCH MESSAGID is not set. Try removing the setting of any match options, init your message id field, and properly set the CorrelId field, and it should work. Make sure the CorrelId is actually the same (right justification and all that). To get that out of the equation, try your test by putting in a 24 byte CorrelId on the PUT, and using that on the get. Something easy, like 123456789012345678901234. The weird thing is in my VB code, the match won't work UNLESS I have this match option set. Go figure. Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 -Original Message- From: Shah, Urvesh (CAP, GEFA Contractor) [mailto:[EMAIL PROTECTED]] Sent: Monday, November 18, 2002 8:56 PM To: [EMAIL PROTECTED] Subject: Re: MQGET with CORRELID on OS/390. Thanks for your responses. I changed the MQGMO-VERSION to 2 but no luck. With respect to some previous suggestions from Nick DiLauro (1,2) and Tim Armstrong (3): 1. The messages are committed to the queue as I can display those messages using a different program that reads the queue without using any match options. 2. To check if the byte values are the same in the actual correlid and the one that I am moving, I used an intermediate variable with same definition in both the programs and then used that variable to move the value to MQMD-CORRELID field. 3. As regards z/OS and the IndexType attribute - the queue is indexed on correlid as mentioned in my 1st email post and I am working on OS/390 v2.1 which is a predecessor to z/OS. I had also checked the IndexType attribute earlier but did not find anything specific to z/OS. Thanks again and best regards, Urvesh. -----Original Message- From: Randy J Clark [mailto:[EMAIL PROTECTED]] Sent: Monday, November 18, 2002 6:48 PM To: [EMAIL PROTECTED] Subject: Re: MQGET with CORRELID on OS/390. Is your MQGMO-VERSION = (2 or 3) If not and its set to the default of 1 then I believe matchoptions are ignored. "DiLauro, Nick" <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 11/18/2002 03:32:16 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: MQGET with CORRELID on OS/390. The default on OS390 is 3 which is the combination of 1 (match msg id) and 2 (match correlid), so adding 2 more gives 5 which is 4 (match group id) and 1 (match msg id), I think. Anyway, you're original code of moving MQMO-NONE (0) and then adding MQMO-MATCH-CORREL-ID (2) should have given you the desired value of 2. Are you sure the messages are committed to the queue? Are you sure the value '12345' you are moving into the field (right filled with spaces) has the same byte value as the actual correlid of the message? -Original Message- From: Shah, Urvesh (CAP, GEFA Contractor) [mailto:[EMAIL PROTECTED]] Sent: Monday, November 18, 2002 2:28 PM To: [EMAIL PROTECTED] Subject: Re: MQGET with CORRELID on OS/390. I have. Sorry, I did not mention it before. I have these 2 lines *before* the code I mentioned in my previous email. MOVE MQMI-NONE TO MQMD-MSGID MOVE MQCI-NONE TO MQMD-CORRELID Thanks and regards, Urvesh. -Original Message- From: Ronald Weinger [mailto:[EMAIL PROTECTED]] Sent: Monday, November 18, 2002 4:33 PM To: [EMAIL PROTECTED] Subject: Re: MQGET with CORRELID on OS/390. Try moving the appropriate 'none' value to MQMD-MSGID. "Shah, Urvesh (CAP, GEFA Contractor)" <[EMAIL PROTECTED]> @AKH-Wien.AC.AT> on 11/18/2002 03:23:16 PM Please respond to "MQSeries List" <[EMAIL PROTECTED]> Sent by:"MQSeries List" <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:MQGET with CORRELID on OS/390. Hi, I am trying to select a message based on the value in MQMD-CORRELID and am not able to. Here's what I am doing: 1. Putting 3 messages in a local queue in batch mode with the correlId's set as
Re: MQGET with CORRELID on OS/390.
Is your MQGMO-VERSION = (2 or 3) If not and its set to the default of 1 then I believe matchoptions are ignored. "DiLauro, Nick" <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 11/18/2002 03:32:16 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: MQGET with CORRELID on OS/390. The default on OS390 is 3 which is the combination of 1 (match msg id) and 2 (match correlid), so adding 2 more gives 5 which is 4 (match group id) and 1 (match msg id), I think. Anyway, you're original code of moving MQMO-NONE (0) and then adding MQMO-MATCH-CORREL-ID (2) should have given you the desired value of 2. Are you sure the messages are committed to the queue? Are you sure the value '12345' you are moving into the field (right filled with spaces) has the same byte value as the actual correlid of the message? -Original Message- From: Shah, Urvesh (CAP, GEFA Contractor) [mailto:[EMAIL PROTECTED]] Sent: Monday, November 18, 2002 2:28 PM To: [EMAIL PROTECTED] Subject: Re: MQGET with CORRELID on OS/390. I have. Sorry, I did not mention it before. I have these 2 lines *before* the code I mentioned in my previous email. MOVE MQMI-NONE TO MQMD-MSGID MOVE MQCI-NONE TO MQMD-CORRELID Thanks and regards, Urvesh. -Original Message- From: Ronald Weinger [mailto:[EMAIL PROTECTED]] Sent: Monday, November 18, 2002 4:33 PM To: [EMAIL PROTECTED] Subject: Re: MQGET with CORRELID on OS/390. Try moving the appropriate 'none' value to MQMD-MSGID. "Shah, Urvesh (CAP, GEFA Contractor)" <[EMAIL PROTECTED]> @AKH-Wien.AC.AT> on 11/18/2002 03:23:16 PM Please respond to "MQSeries List" <[EMAIL PROTECTED]> Sent by:"MQSeries List" <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:MQGET with CORRELID on OS/390. Hi, I am trying to select a message based on the value in MQMD-CORRELID and am not able to. Here's what I am doing: 1. Putting 3 messages in a local queue in batch mode with the correlId's set as '12345', '8' and '9'. 2. Trying to get the message with the correlId = '12345' with the following code (again using a different program in batch): MOVE '12345' TO MQMD-CORRELID MOVE MQMO-NONE TO MQGMO-MATCHOPTIONS ADD MQMO-MATCH-CORREL-ID TO MQGMO-MATCHOPTIONS The queue is PUT and GET enabled with INDEX TYPE = C (for CORREL-ID). I tried commenting the second line in the code above making the MATCHOPTIONS field value = 5 (3 default + 2 for MQMO-CORREL-ID), but it doesn't seem to retrieve the message with correl-id = '12345'. Any pointers?? Thanks in advance for your help. Best regards, Urvesh. 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 The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message. 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
Re: Waitinterval and response time of CICS transaction
Did I miss something if so I apologize but I think you may have not read the response that told you the looping is your problem - you can not loop if you loop the last get will wait as that is when thwere is no message so it waits for one before returning the 2033. In previous replies a couple of good suggestions were made. Only wait on first get outside of the loop then go into loop to process the remaining messages. In your logic make sure step 5 is with a zero wait. 1: CICS transaction starts 2: Puts a message to the MQ queue. This is a query type message. 3: process the message and the reply is put into the REPLY queue 4: Does a GET with wait from the REPLY queue 5: Loop to get message WITH NO WAIT (write out TSQ in CICS) from reply queue by correlid and msgid until 2033 or error code 6: Close reply queue "Jose, Prince" <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 11/18/2002 07:30:39 AM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: Waitinterval and response time of CICS transaction Many Thanks for all who responded. I spoke with the programmer and it looks like, he saves the messages into the temporary storage queue in CICS and then waits for the loop to finish, close the queue and then process the messages in the TSQ. The MQ GET call uses SYNCPOINT option. Also, for testing purpose, I asked the programmer to increase the waitinterval to 2minutes. The queue depth was always zero. But the CICS transaction was clocking(waiting) and after 2 minutes got a response. I think instead of buffering the messages in the temporary storage queue, if the application just processes the messages as it is retrieved, it will work. But I do not know how to implement that in CICS. Any ideas will be greatly appreciated. We tried the following testing scenarios. Waitinterval in MQGET CICS Transaction Response time 10 seconds 13seconds 20 seconds 23seconds 30seconds 33seconds. So there is a direct relationship to the waitinterval for response. The program logic is something like this. 1: CICS transaction starts 2: Puts a message to the MQ queue. This is a query type message. 3: process the message and the reply is put into the REPLY queue 4: Does a GET with wait from the REPLY queue 5: Loop to get message (write out TSQ in CICS) from reply queue by correlid and msgid until 2033 or error code 6: Close reply queue Also, is there any sample program to illustrate this kind of processing Thanks Again, Prince -Original Message- From: Thomas Dunlap [mailto:[EMAIL PROTECTED]] Sent: Friday, November 15, 2002 6:43 AM To: [EMAIL PROTECTED] Subject: Re: Waitinterval and response time of CICS transaction Prince, You are correct in that the WaitInterval is a maximum time value. However, if the application processes all of the messages and then issues another MQGET, it will wait for the full time to obtain the "queue empty" status (MQRC_NO_MSG_AVAILABLE) before ending. You may want to have the application use a longer WaitInterval for the first MQGET and then reset the time to a shorter interval after a successful MQGET. This assumes that the application has completed its processing and has no more work to do. Jose, Prince wrote: Environment: MQSeries 5.2 on OS390 and CICS Hello, I have never done any MQcoding myself, so please excuse me if this sounds very dumb It is about the response time of a CICS transaction and the wait interval coded on the MQGET. Our application programmers are working on a CICS transaction doing PUT(request) to an MQ queue and doing a GET with WAIT from a reply queue. The response time of this transaction is always equal to the Waitinterval coded in the MQGET call. As I understand it, waitinterval is the max time, the MQGET call waits for the messages to arrives in the queue. Now if we code a waitinterval of 30seconds and say, 10 message arrives in the queue within 2seconds, the program should be able to process these 10 messages immediately as they arrive in the queue right? Then what are we doing wrong here? Any inputs will be greatly appreciated. Thanks, Prince -- Regards, Thomas DunlapChief Technology Officer[EMAIL PROTECTED], Inc.http://www.themisinc.com1 (800) 756-3000 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 vs CICS Sockets
The advantages and disadvantages really depend on how your application is intended to act. If you do not want messages sent or saved if CICS is down then the sockets choise certainly will do this for you. If the process that will be sending the messages should always send the message regardless of CICS's availability then MQ is more than likely your choice. The application processing requirements should drive the choice of sockets or MQ. Sockets require a higher level of programming skill. MQ removes this and make use of simple API calls. Sockets => Synchronous MQ => Asynchronous --- "MQ will assure delivery if CICS is down when the messages are sent" This could be disadvantage if you do not want to have the message sending process successful when CICS is down Ronald Weinger <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 11/07/2002 03:02:55 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: MQ vs CICS Sockets MQ is easier to set up MQ will assure delivery if CICS is down when the messages are sent "Wesley Shaw" <[EMAIL PROTECTED]>@AKH-Wien.AC.AT> on 11/07/2002 04:12:11 PM Please respond to "MQSeries List" <[EMAIL PROTECTED]> Sent by:"MQSeries List" <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:MQ vs CICS Sockets I have a client who wants to push 100,000 small messages per hour up to CICS. They originally wanted to use MQ to do this but have been told that MQ messages are large(including header+message) and they would have to spend money on the band width So they are now talking CICS Sockets. What are the advantages and disadvantages of one over the other ? I may need to defend the MQ method. 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 The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message. 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: IT Employment Survey - Correct Attachment
I like it you are correct sir! I feel badly as you are 100% correct. I better get back to work I have some reading to do! Now we can look forward to Dennis's new book! I needed a laugh! Dennis can I get an autographed first print edition? Robert Broderick <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 11/01/2002 06:05:18 AM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: IT Employment Survey - Correct Attachment I've read up and down this thread from this point and everyone has made valid points. I believe there is not one side to this story. YES, there are companies that would hire the 'CHEAP" person over a much more qualified person!! I have run into this and it is very frustrating to see that you are ideal for a contract and some other less qualified person, OOOPPS I almost said IDIOT, got the position. I have seen where a company is out sourcing their work to foreign entities. This is unfair but it will come back to haunt us and is the 'American Way of Life in Business" More work, less expenses!! But as someone pointed out. WE are to blame. I have seen many a times someone sitting at a desk, hiding from new things, comfortable in his job and waiting for the Golden Umbrella to open up for him. I personally have not picked up a good book in years!! Every time my daughter hands me one I get a guilty feeling I should have a manual in my hand instead. This is a fast paced IT world we live in and if you stop to take a drink of water there are many people with ambition who will run past you. Like it was stated, we have become a nation of complacent individuals. How many time have you heard "or look at that, all the stores are owned by THEM" or "Oh we are loosing our jobs to all these foreigners" etc Well let me tell you something, I work with all these people and while we sit back and smoke our fat cigars they are earnestly working their butts off to better themselves. There is an easy solution here. Get back to work and make ourselves better like we used to. We did not get to be the 'Fat Pig" country we are today by sitting on our butts. Remember Darwin said it best "Survival of the Fittest". I for one do my best to keep ahead. It is certainly self gratifying, if not tiring!!! Sorry for the rant bobbee PS Another good quote that is running on a radio commercial up here in NY. "Most people miss opportunity because it's dressed in coveralls and looks like works". >From: Jim Keohane <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: IT Employment Survey - Correct Attachment >Date: Thu, 31 Oct 2002 18:12:12 -0500 > >Chris, > > Make that four cents. Aw heck, I'll dig deep and make it a whole >nickel!!! > > Hard work pays off. Keeping skills sharp pays off. I've seen the gravy >train days come and go. Not sure if IT will come back as much as before. >Programming talent is much less of an arcane knack and becoming much more >of >a commodity item. That happens to *everything* in time. It's called >progress. It also means change. > > I consider myself and my family very lucky I chose certain career >paths. >If the IT consulting & softdev market remains depressed, well, I have no >right to complain. Take the good with bad. Don't begrudge the next >hard-working fella or gal working to improve their family's opportunities. >Under different circumstances it would be you. A friend from the >Phillipines, with a beautiful wife and adorable kids, has finally landed a >systems programming spot. This was after almost a year's downtime since the >software startup, where he worked and I consulted, went belly up. I never >saw anyone crack the books like this "kid" did. I wish him well. He didn't >take anyone's job. He earned it. > >Thanks again, Chris! - Jim > - Jim > > >Jim Keohane, Multi-Platforms, Inc. >"Down with the verbing of nouns!" >- Original Message - >From: "Christopher Fryett" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Thursday, October 31, 2002 16:51 >Subject: Re: IT Employment Survey - Correct Attachment > > > The reality is that in the 90's we took advantage of the situation and > > shortage of IT personnel and demanded high salaries ($90-200K/yr), stock > > options, health club memberships, cars, houses, and other perks that >only > > executives received. Then we had the reality check that dot.coms where >an > > uncontrolled and unstable commodity in the market and people lost >thousands > > and even millions of dollars. Back then you could start a dot.com, go > > public, and have tons of money even if the actual product or services > > didn't exist at the time. Everyone bet on the possibility not the >reality. > > Then the layoffs occurred, and still are today. > > > > Just my two cents. > > > > Chris > >Instructions for m
Re: IT Employment Survey - Correct Attachment
Spoken like a true gentleman. A gentleman that has not lost his job to lower priced and many times less productive person with an acceptable lower standard of living. Most companies given the choice will opt for the lower priced option 9 out of 10 times. I do not begrudge anyone I have not lost my job or my rate. I am just observing and wondering were to run to next as this gravy train is over. The next hardworking gal or fella is being imported at the same time other jobs us professionals do nto care about have been exported for years. Okay where to turn? We are importing cheaper labor and for years have been exporting labor jobs... What the hell are we going to do if we just absorb the world and I can not see us not doing that sure it makes good business but get ready for over all wage deflation and sure maybe cheaper goods if you have a job and can buy them... The 3rd world joining the rest of us is going to be painful for a time - how long that time will be is anyone's guess Progress as you call it is painful. Just observations and I wonder where to go next become certified financial planner why people will be paid so low they may not have money other than that which to live day to day. Corporations maybe be come very profitable at the expense of the labor force I guess we must pay for the days when it was the other day around. Jim Keohane <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 10/31/2002 03:12:12 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: IT Employment Survey - Correct Attachment Chris, Make that four cents. Aw heck, I'll dig deep and make it a whole nickel!!! Hard work pays off. Keeping skills sharp pays off. I've seen the gravy train days come and go. Not sure if IT will come back as much as before. Programming talent is much less of an arcane knack and becoming much more of a commodity item. That happens to *everything* in time. It's called progress. It also means change. I consider myself and my family very lucky I chose certain career paths. If the IT consulting & softdev market remains depressed, well, I have no right to complain. Take the good with bad. Don't begrudge the next hard-working fella or gal working to improve their family's opportunities. Under different circumstances it would be you. A friend from the Phillipines, with a beautiful wife and adorable kids, has finally landed a systems programming spot. This was after almost a year's downtime since the software startup, where he worked and I consulted, went belly up. I never saw anyone crack the books like this "kid" did. I wish him well. He didn't take anyone's job. He earned it. Thanks again, Chris! - Jim - Jim Jim Keohane, Multi-Platforms, Inc. "Down with the verbing of nouns!" - Original Message - From: "Christopher Fryett" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, October 31, 2002 16:51 Subject: Re: IT Employment Survey - Correct Attachment > The reality is that in the 90's we took advantage of the situation and > shortage of IT personnel and demanded high salaries ($90-200K/yr), stock > options, health club memberships, cars, houses, and other perks that only > executives received. Then we had the reality check that dot.coms where an > uncontrolled and unstable commodity in the market and people lost thousands > and even millions of dollars. Back then you could start a dot.com, go > public, and have tons of money even if the actual product or services > didn't exist at the time. Everyone bet on the possibility not the reality. > Then the layoffs occurred, and still are today. > > Just my two cents. > > Chris 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: IT Employment Survey - Correct Attachment
My sister is a 7th grade teacher and makes 65-70k per, she has legitimate Ph.D from Columbia, unlike some of the suspect Ph.D.'s we are uncovering on some resumes. These Ph.D.s are usually from unheard of foreign institutions which are incredibly difficult to verify. 2-3 times teachers social workers salary??? SAP contractors are being imported at a billing rate of 46.00 making it difficult to survive and maintain the standard of living many have become accustom to. I am not making nor is any contractor/consultant I know making 210k per year Pretty soon we will be at a teachers level and without the gratification... Given anywhere close to the same wages I'll chose teaching or social work... there at least you can MAKE a difference. "Miller, Dennis" <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 10/31/2002 11:08:17 AM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: IT Employment Survey - Correct Attachment And still making 2-3 X the salary of a teacher or social worker???? > -Original Message- > From: Randy J Clark [SMTP:[EMAIL PROTECTED]] > Sent: Thursday, October 31, 2002 9:55 AM > To: [EMAIL PROTECTED] > Subject: Re: IT Employment Survey - Correct Attachment > > FREE as in we will all be working for free one day! > > > > > Robert Broderick <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on > 10/31/2002 05:52:56 AM > > Please respond to MQSeries List <[EMAIL PROTECTED]> > > Sent by:MQSeries List <[EMAIL PROTECTED]> > > > To:[EMAIL PROTECTED] > cc: > Subject:Re: IT Employment Survey - Correct Attachment > > > Funny though, We had the Russian invasion a few years back now it seems to > be from India these days!! I guess this is why they call this the land of > the free!! > > bobbee > > > > > > > >From: Randy J Clark <[EMAIL PROTECTED]> > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: Re: IT Employment Survey - Correct Attachment > >Date: Wed, 30 Oct 2002 15:46:07 -0800 > > > >I think he sent it to the right places as they are all here on H1B's so > he > >is okay... > >From what I can tell India must be a good place to be FROM! > > > > > > > > > >Ken Russo <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 10/30/2002 > 03:38:27 > >PM > > > >Please respond to MQSeries List <[EMAIL PROTECTED]> > > > >Sent by:MQSeries List <[EMAIL PROTECTED]> > > > > > >To:[EMAIL PROTECTED] > >cc: > >Subject:Re: IT Employment Survey - Correct Attachment > > > > > > > > > >You may want to send this survey to IT people in other countries since > that > >is where most of all our jobs are going. > > > > > > > > > > > >Do you Yahoo!? > >Y! Web Hosting - Let the expert host your web site > > > > > >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 a speedy connection with MSN Broadband. Join now! > http://resourcecenter.msn.com/access/plans/freeactivation.asp > > 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
Re: IT Employment Survey - Correct Attachment
FREE as in we will all be working for free one day! Robert Broderick <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 10/31/2002 05:52:56 AM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: IT Employment Survey - Correct Attachment Funny though, We had the Russian invasion a few years back now it seems to be from India these days!! I guess this is why they call this the land of the free!! bobbee >From: Randy J Clark <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: IT Employment Survey - Correct Attachment >Date: Wed, 30 Oct 2002 15:46:07 -0800 > >I think he sent it to the right places as they are all here on H1B's so he >is okay... >From what I can tell India must be a good place to be FROM! > > > > >Ken Russo <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 10/30/2002 03:38:27 >PM > >Please respond to MQSeries List <[EMAIL PROTECTED]> > >Sent by:MQSeries List <[EMAIL PROTECTED]> > > >To:[EMAIL PROTECTED] >cc: >Subject:Re: IT Employment Survey - Correct Attachment > > > > >You may want to send this survey to IT people in other countries since that >is where most of all our jobs are going. > > > > > >Do you Yahoo!? >Y! Web Hosting - Let the expert host your web site > > >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 a speedy connection with MSN Broadband. Join now! http://resourcecenter.msn.com/access/plans/freeactivation.asp 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: IT Employment Survey - Correct Attachment
At times of need or at times of need to reduce your budget??? It is all good - Management will get theirs as managements pay is directly proportional to the salary of the people they manage... reduce the salary of your people and you are only kidding yourself if you believe that it ot just a matter of time before that comes home to roost. The end. Stefan Sievert <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 10/30/2002 04:10:50 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: IT Employment Survey - Correct Attachment Oh well, somebody must have hired them (including myself) in the first place, correct!? Probably at times of need, correct!? Hmmm...... >From: Randy J Clark <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: IT Employment Survey - Correct Attachment >Date: Wed, 30 Oct 2002 15:46:07 -0800 > >I think he sent it to the right places as they are all here on H1B's so he >is okay... >From what I can tell India must be a good place to be FROM! > > > > >Ken Russo <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 10/30/2002 03:38:27 >PM > >Please respond to MQSeries List <[EMAIL PROTECTED]> > >Sent by:MQSeries List <[EMAIL PROTECTED]> > > >To:[EMAIL PROTECTED] >cc: >Subject:Re: IT Employment Survey - Correct Attachment > > > > >You may want to send this survey to IT people in other countries since that >is where most of all our jobs are going. > > > > > >Do you Yahoo!? >Y! Web Hosting - Let the expert host your web site > > >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 _ Protect your PC - get McAfee.com VirusScan Online 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 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: IT Employment Survey - Correct Attachment
I think he sent it to the right places as they are all here on H1B's so he is okay... >From what I can tell India must be a good place to be FROM! Ken Russo <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 10/30/2002 03:38:27 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: IT Employment Survey - Correct Attachment You may want to send this survey to IT people in other countries since that is where most of all our jobs are going. Do you Yahoo!? Y! Web Hosting - Let the expert host your web site 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 Wrapper
Wow Peter now that's a wrapper! Thanks to everyone for all their 'two cents' worth. Definitely some valid points were made on both sides. I must say I wish I had the time to write a wrapper like Peter's it sounds very interesting and pretty close to 'perfect' :) Thanks all "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 10/18/2002 07:03:27 AM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: MQ Wrapper I think wrappers are a good idea. The bigger the audience, the better the idea. Ideally, yes, I would love it if all the programmers here learned the API and actually understood what all the implications are of the various options. But in today's day and age where I got a dozen project going on at the same time, new apps on the horizon, legacy apps switching to MQ to do their work, I can't possible expect that all these people are going to go to a 5 day MQ class, absorb everything, adhere to all the best practices etc. So I wrote the wrapper. First problem was how do you make a set of code that will work for everyone yet one that maintains a simple interface? What I did is had my wrapper go out to a database to find an application's particular row whenever the wrapper was called. This row on the database has about 90 columns. Expiry, Persistence, Queue Name, Syncpoint, Message Format, Pass-CorrelId Option,etc. Anything you could possibly choose to do when calling MQ, broken down by MQ call. So the first column in the table has Queue Manager name, and that takes care of the MQCONN call, since that is the only thing you can specify for that call. Then the next few columns have all the MQOPEN stuff. Queue name, Fail If Quiescing, etc. So on and so forth. The main body of the program is then the same for all. Based on what options were set in the database determines how this pass thru the wrapper will execute. Same set of code that theoretically can execute 10s of thousands of different ways. Now, you can't code everything on the table always. A replying app can't have its expiry value on the table if it is replying, nor should it be tied to a specific queue name for the reply. Or the CorrelId of the reply needs to be the message id of the request. So the I opened up about 6 parameters that a calling app can pass in that will override anything on the database. Now when a new app calls up our group, I add a row into the database. I have complete control on syncpoint, and persistence, and Fail if quiescing, etc. I don't have to worry if they are going to botch up my infrastructure with 4 meg persistence message going who knows where with unlimited expiry under syncpoint. I meet with the group, get their requirements, code the rows, create the queues, and give them the key they should pass in, along with a doc that explains the simple interface to the wrapper. A day later they are happily MQing in a way that I have complete control over. The wrapper sends back completion codes for each and every MQ call, so they can see exactly what didn't work. I also made a hi level completion code and give them the key to decipher that in plain English. Do they really care that they got a 2018? No. But when they see a "CF" error, their chart says the Connection call failed. They also do have that 2018 code so when they call me, so I know exactly what the problem is. But I tell you what, errors are few and far between, since I control how they call MQ. I haven't once seen an Invalid Options error! And no one has wasted time trying to debug that error. I also added stuff like logging that I can turn on and off thru the database. I made a version for IMS, CICS and Batch (all basically the same, just compiled differently) and all call the same database. A VB person cloned my wrappers for that environment. In production for 2 years now. Is it worth writing a wrapper for a small company with a couple MQ apps. Heck no. Big company with hundreds of MQ apps? I wouldn't consider anything but wrappers. Plus, writing a comprehensive wrapper will have you learn more about MQ than any other exercise. Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 -Original Message- From: Peter Heggie [mailto:Peter.Heggie@;US.NGRID.COM] Sent: Friday, October 18, 2002 8:35 AM To: [EMAIL PROTECTED] Subject: Re: MQ Wrapper Hey Randy, This is one of those classic IT problems - how to gain the benefits of code re-use without sacrificing flexibility. There is no easy answer. IBM has provided a middle ground solution in the MQ AMI. It doesn't totally satisfy either side, but it does remove a layer of complexity. While there is still additional administration, it does remove the need to actually re-code a wrapper every time an application needs a different set of parameters. Does it do what you want? Judging by your notes I would say no. Also, usually a wrapper provides a lot of ben
Re: MQ Wrappers
Thanks You opinion is kinda where I ended up too after thinking about it for a while but still the thought of it entices me and I can't seem to shake this nagging feeling that it is indeed a good idea. I just can't seem to figure out how to create the perfect wrapper. If its not perfect wrapper or close to it then you are right it will eventually have to be modified and or another version created. Knowing my shop I would have to create another versionso as to not potentially affect the others using the existing wrapper. Tim Armstrong <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 10/17/2002 03:21:01 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: MQ Wrappers My own personal thoughts on Wrappers. DONT DO IT, especially writing your own. Write some simple programming guidelines instead. Eg. Rule 1) Always specify the relevant *_FAIL_IF_QUIESCING option for MQOO, MQGMO and MQPMO. Aside from anything else the issue you mentioned of what parts of the API to expose and what to hide get complicated when sooner or later ProjectX comes along and needs an option not included and so we get Wrapper V2 with potential compatability issues. I have on more than one occasion had to help a client resolve simple problems made complex by the wrapper classes they have written. I have seen people write a wrapper around their own wrapper that wraps the VB classes. Yes there a C++ classes and JMS etc. and they are nice to use but when it comes time to resolve a problem the question I invariably wind up asking myself is how is this thing driving the underlying MQ API. So especially in a COBOL environment I'd just use the API. Regards Tim A Randy J Clark cc: Sent by: MQSeriesSubject: MQ Wrappers List 18/10/2002 07:18 AM Please respond to MQSeries List COBOL shop. We thought about a MQ wrapper program and then backed away from it as we had a hard time deciding how generic to make it. I see other installations that have successfully implemented MQWrappers. Fundamentally a MQWrapper sure seems like a good idea.We have some issues though we basically could not resolve so we gave up. We decided the MQ API is really not to terribly difficult to learn but I certainly wish we had a valuable MQWrapper program. We just did not want to have a MQWrapper program for the sake of having a MQWrapper. Our Struggles For instance how many different processing options would we handle. If we handled all the options of the MQ API then we might as well use the MQ API. Our motivation was to reduce/simplify the options and thus have a wrapper that reduces the programmers need to know the MQ options. To us it still seemed like there were some processing we must handle for instance whether or not the messages should be PUT or GET under syncpoint. Help Anyone have documentation on their MQ wrapper. What I am after is basically the documentation you would supply the programmer of the program that is going to call the wrapper. Showing what they must provide and I am sure there are some basic options the wrapper will accept. I will take programs, code snippets, program documentation, whatever you can give me beggars can't be choosy. "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> on 10/17/2002 01:50:21 PM To:"'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> cc: Subject:RE: OS/390 IMS - MQCONN call The wrapper is simply a self contained module(progrtam) with a Linkage section, Working Storage,Procedure Using Division, etc. Any other module in the mainframe calls it when they want to interface with MQ. these other applications now don't need to know about MQ at all. All they need to know is how to build the simple Linkage section when calling this program. Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 -Original Message- From: [EMAIL PROTECTED] [mailto:Randy_Clark@;ahm.honda.com] Sent: Thursday, October 17, 2002 2:09 PM To: [EMAIL PROTECTED] Subject: Re: OS/390 IMS - MQCONN call Peter, Is your MQ Wrapper a cobol program? I guess I do not undertand this wrapper concept is it a subroutine that all application programs call to handle the MQ 'stuff'. If so seems to me each main program that calls it would get their own version of the subroutines working storage at a minimum so passing the connection and object handles is not required since the subrountine would have them available in its own working storage and the subroutine is not released until the main program completes... Help can you either send me your warpper program does not have to include
MQ Wrappers
COBOL shop. We thought about a MQ wrapper program and then backed away from it as we had a hard time deciding how generic to make it. I see other installations that have successfully implemented MQWrappers. Fundamentally a MQWrapper sure seems like a good idea.We have some issues though we basically could not resolve so we gave up. We decided the MQ API is really not to terribly difficult to learn but I certainly wish we had a valuable MQWrapper program. We just did not want to have a MQWrapper program for the sake of having a MQWrapper. Our Struggles For instance how many different processing options would we handle. If we handled all the options of the MQ API then we might as well use the MQ API. Our motivation was to reduce/simplify the options and thus have a wrapper that reduces the programmers need to know the MQ options. To us it still seemed like there were some processing we must handle for instance whether or not the messages should be PUT or GET under syncpoint. Help Anyone have documentation on their MQ wrapper. What I am after is basically the documentation you would supply the programmer of the program that is going to call the wrapper. Showing what they must provide and I am sure there are some basic options the wrapper will accept. I will take programs, code snippets, program documentation, whatever you can give me beggars can't be choosy. "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> on 10/17/2002 01:50:21 PM To:"'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> cc: Subject:RE: OS/390 IMS - MQCONN call The wrapper is simply a self contained module(progrtam) with a Linkage section, Working Storage,Procedure Using Division, etc. Any other module in the mainframe calls it when they want to interface with MQ. these other applications now don't need to know about MQ at all. All they need to know is how to build the simple Linkage section when calling this program. Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 -Original Message- From: [EMAIL PROTECTED] [mailto:Randy_Clark@;ahm.honda.com] Sent: Thursday, October 17, 2002 2:09 PM To: [EMAIL PROTECTED] Subject: Re: OS/390 IMS - MQCONN call Peter, Is your MQ Wrapper a cobol program? I guess I do not undertand this wrapper concept is it a subroutine that all application programs call to handle the MQ 'stuff'. If so seems to me each main program that calls it would get their own version of the subroutines working storage at a minimum so passing the connection and object handles is not required since the subrountine would have them available in its own working storage and the subroutine is not released until the main program completes... Help can you either send me your warpper program does not have to include the includes or copys basically I am not asking for a working copy just something I can see OR can you just explain this wrapper further... I know I am obviously confused. : ) "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 10/17/2002 07:38:45 AM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:OS/390 IMS - MQCONN call We incorporate an MQWrapper. All mainframe programs in the online environment that need to talk to MQ call this one program. We have a Batch version as well. In the Batch version, I wrote it so that a calling app can pass back and forth the connection handle and the object handle during a job. In this way, the wrapper does not have to Connect/Open and Close/Disconnect each time it is called. For the duration of the job, as long as the handles are maintained by the calling app, all is good. Can this concept be implemented in any way in the Online environment? I don't think so, but want to be absolutely sure, since a new project we have that calls the wrapper is very time sensitive. Milliseconds count. The MQCONN/MQDISC combination takes on average 200 ms. And we need to do that every time we need to send a message. The reason I think it wont work is that in the Online environment, I have many different users in many different TCODES all calling the common module. I don't see how a connection handle could be shared among all of them. Even if it was possible, if any of them do a commit or rollback, everyone would be affected, since the connection handle to the QM is what ties an MQ UOW together. All actions under that handle would be affected. Also, when a TCODE ends, doesn't an implicit disconnect occur anyway, killing the handle whether you like it or not? Am I correct in telling the customer that it is not possible to do this in the Online Environment. And even if it was, it wouldn't be safe anyway due to commits/rollbacks? Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, con
Re: Change Management
thanks for your comments our attempt at some type of change mangement is just a start. I hope to get to this place you describe one day. Remembering our current situation is the developer calls the mq sys admin person gives that person the qmgr name and the queue name and then the queue is bulit with standard defaults unless developer mentions something that makes this queue not standard. Or could be email that is the extent of the 'system' now. Robert Broderick <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 10/11/2002 05:07:49 AM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: Change Management Peter brings up a good point. You can require all the documentation you want but if the developers are left to themselves at 3:00AM your looking at the change request, the developers cannot be found and all your SLAs WERE a good idea. How do you cope with a decision on what to remove if the only thing you have to go on is "Move to Production". Almost all the shops I have been in require some sort of change management review by ops and other group members in the development cycle and possibly the user group consortium. MOST places, the review is a joke. Just an honerable mention and Yes!!...I was the one who put the change in.yadda yadda yadda Last place I was in, the review board was knowledgeable about the environment and there were actuall questions asked as to "what are you actually doing??" and "your description doesm't say that! FIX it and come back next week" I was impressed! A little anoyed too! How dare they question me!!! Yes arrogance is a wonderful thing...but it doesn't help the organization and a good system of checks and balances does. bobbee Sorry for the long note. I am at a client right now and we are designing the same cycle right now. >From: Peter Heggie <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Change Management >Date: Thu, 10 Oct 2002 11:16:01 -0400 > >Do you just want an audit trail? Your solution is a good one - names, >dates, objects, status. Is there a life-cycle of dev - test - prod? With >change control? Do you store these changes in text files as a group , so if >there were two separate, un-related changes on one day, you would have two >text files? Is the path and name of the MO71 file entered into the Notes >database? > >Coming from a background of change control, I can tell you that including >appropriate descriptions of contents or events is very difficult. Difficult >to get people to do it. If you want it to be meaningful, someone has to >review them. Perhaps if the descriptions show up in the Notes View of the >database, then it may motivate people to put something good in that field. >Or perhaps motivate them to hide what they are doing by putting in >something bland and generic.. How many times have I seen 'MOVE TO >PRODUCTION' in a change request.. > >If you get into tracking changes to existing objects, you could use the >same system, and depending on how you manage your MO71 files, could >incorporate automation to quickly fallback to a 'before' MO71 snapshot. > >Peter > >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 _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx 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
Change Management
I am asking for opinions... and all are welcomed.
Here is a brief description of what were going to do for our MQ change
management. Remember this is only a start and is being designed to handle
creates only the alters will be handled but as special instructions in the
change requests unless the developer is knowledgeable enough to create the
MQSC alter text file.
We are going to use a Lotus notes database to request the changes and
handle the workflow. The developer will MO71 to create a text file for
environments other then the Mainframe - mainframe requests will use the
MO71 export function but the resulting text file will be FTP'd to a
predetermined PDS (file) expressly for this change request process.
Once the developer creates and submits the request the MQ Admin person
responsible for the particular platform will either accept or reject the
request and then if accepted he/she will complete the requests. Emails
containing a link to the specific document representing the change request
in the lotus notes database will be automatically sent upon each change of
status.
We are using the MO71 support pac and its export function. SAMPLE output
of the Export function.
Currently our mq change request system is handled via emails and phone
calls... no request archival, audit trail. The developer supplies the
queue name to the responsible admin person for the platform. Any Xmit
queue issues are just talked about prior to the creation of the object and
then the admin person creates the object and then the developer can check
the results. One draw back of this is the admin person has no idea of what
to use as a description. I believe the developers should create the MQSC
commands and understand what they are doing and be responsible for the
description and all the other attributes. I believe the developer by being
'forced' to do this will greatly benefit in a shorter learning curve and a
greater undertanding of the MQ Objects and there attributes
We are only rolling this out for queues and only alias remote and local all
other objects will continue to be created outside of this system and by the
MQ sys admin people.
DEFINE QREMOTE('RQ.AH1_TNL12.L_CAS_DGRM_WES03PRTRAN.001') +
RNAME('LQ.L_CAS_DGRM_WES03PRTRAN.001') +
RQMNAME('AH1_TNL12') +
XMITQ('AH1_TNL12') +
DEFPRTY(0) +
DEFPSIST(NO) +
DEFBIND(OPEN) +
PUT(ENABLED) REPLACE
DEFINE QALIAS('AQ.L_CAS_DGRM_REPEXTPRTRAN.001') +
TARGQ('RQ.MQSIV2.L_CAS_DGRM_REPEXTPRTRAN.001') +
DEFPRTY(0) +
DEFPSIST(YES) +
DEFBIND(OPEN) +
PUT(ENABLED) +
GET(ENABLED) REPLACE
DEFINE QREMOTE('RQ.MQSIV2.L_CAS_DGRM_REPEXTPRTRAN.001') +
DESCR('AHFC/CAS remote queue to NT') +
RNAME('LQ.L_CAS_DGRM_REPEXTPRTRAN.001') +
RQMNAME('AH1_TNL11') +
XMITQ('AH1_TNL11') +
DEFPRTY(0) +
DEFPSIST(NO) +
DEFBIND(OPEN) +
PUT(ENABLED) REPLACE
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: retrieve order
I must say we send 100's of 1000's of messages each day from an os/390 qmgr to an RS6000 AIX qmgr and we have never experienced a message not arriving in the 'sent sequence'. We have only have a single apps active and sending to a queue. We never have multiple apps active and sending to the same queue we of course could have multiple app active but they would have different destination queues. In CICS we do have multiple active programs but they are sending a single message and retrieving a single message so potential sequencing problems here. We in batch are mainly sending files and the files are surrounded by a header and trailer and the sequence has always been maintained. So far so good in a simple MQ application like ours... we do not use priority just basic vanilla mq gets and puts Robert Broderick <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 09/19/2002 11:20:25 AM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: retrieve order I don't know.but as long as I have been in MQ, there was always the spoken rule that no matter what you did, don't rely on the order. If you start with that premis, then you can architect/code effectively AND with the notion that some day some genious will come along and change your network configuration and it will not break your application. Why code for absolutes? bobbee >From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: retrieve order >Date: Thu, 19 Sep 2002 13:22:51 -0400 > >I think it boils down to how you interpret the following line: > > For remote queuing, the configuration is such that there can only be one > > path from the application making the put request, through its queue > > manager, through intercommunication, to the destination queue manager >and > > the target queue. > > >One Path. If your set up is so that QM1 talks to QM2 (via channel QM1.QM2) >and then QM2 talks to QM3 (via channel QM2.QM3), and you start putting >messages onto QM1 destined for QueueC on QM3, they will get there in order >if you follow the rules listed below. TCP breaking up the message while it >flows between the QMs does not mean you don't have one path. > >A channel between 2 QM2 is one path. If you can insure your messages get to >the XMIT queue in order, rest assured they will be on the destination queue >in order (assuming all the MQPUTS were done the same and in 1 UOW). > > >BUT, I have this question. If I get the messages to the XMITQ in the order >of 1,2,3,4, they will be put to the queue on the other side as 1,2,3,4. Can >my queue on the other side look like this: 1,2,A,3,B,C,4, where the letters >are messages put by another app from another QM, or even the local one? >Notice 1,2,3,4 are still in "order". > >The rules say there can only be 1 getting app. Shouldn't there be a rule >also saying that there is only one app putting as well? > >Peter Potkay >IBM MQSeries Certified Specialist, Developer >[EMAIL PROTECTED] >X 77906 > > >-Original Message- >From: Bullock, Rebecca (CSC) [mailto:[EMAIL PROTECTED]] >Sent: Thursday, September 19, 2002 12:53 PM >To: [EMAIL PROTECTED] >Subject: Re: retrieve order > > >Rick, I think that the part below says that if they end up taking different >paths then the order can't be guaranteed: > > > For remote queuing, the configuration is such that there can only be one > > path from the application making the put request, through its queue > > manager, through intercommunication, to the destination queue manager >and > > the target queue. > >I think it's time for someone from IBM (Paul -- Are you out there?) to >enter >into this fray and answer the question... Rebecca > >-Original Message- >From: Rick Tsujimoto [mailto:[EMAIL PROTECTED]] >Sent: Thursday, September 19, 2002 12:41 PM >To: [EMAIL PROTECTED] >Subject: Re: retrieve order > > >Rebecca, > >The assumption is that the requirements set by IBM are met. See extract >from IBM doc below. > > > > > "Bullock, > Rebecca (CSC)" To: >[EMAIL PROTECTED] > <[EMAIL PROTECTED] cc: > G> Subject: Re: retrieve order > Sent by: > MQSeries List > en.AC.AT> > > > 09/19/2002 12:23 > PM > Please respond > to MQSeries List > > > > > >Not if they don't take the same path -- Rebecca > >-Original Message- >From: Rick Tsujimoto [mailto:[EMAIL PROTECTED]] >Sent: Thursday, September 19, 2002 12:09 PM >To: [EMAIL PROTECTED] >Subject: Re: retrieve order > > >Brian, > >If the user sends msg-1, 2, 3 and gets 1, 3, 2 doesn't that conflict with >the IBM doc's cla
Re: spam
Sorry I am wrong on all accounts... Bad memory Nastel not Reconda and Reconda has agent to pull email addresses BUT I still think this would be a clever way to innocently get your marketing information published - All marketing types feel free to utilize this method but please send a small monetary gift to show your appreciation. : ) "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 09/19/2002 11:29:04 AM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: spam I think it was Nastel, not Reconda, that recently released the free demo that caused "discussions" here. Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 -Original Message- From: Randy J Clark [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 19, 2002 2:07 PM To: [EMAIL PROTECTED] Subject: Re: spam I hate to say it but the devil in me and my nature makes me believe this could be VERY clever way to get your companies marketing information out while looking somewhat innocent and sparing yourself the wrath of this list. This particular company has already felt the wrath of this list as it relates to its free demo version. As I for one did not have this experience when I joined the list. Again its just me wondering aloud - still thinking this is very very clever! Dave Adam <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 09/19/2002 10:50:12 AM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:spam I just signed up for this list yesterday since our MQ guy is no longer here when I returned to my cubical world today I had the following message and was wondering if it is normal to get this stuff from this list Dave, I wanted to send you a personal invitation to our upcoming Webinar and introduce myself and my company. I am the Regional Sales Manager for Reconda an IBM WebSphere MQ partner and we have developed a cutting-edge solution for MQ Development called QN-AppWatch. The Webinar is a great opportunity to learn and see our solution in action. If you're interested please let me know and I can register you and send you the information necessary to access the conference. Please join Reconda International Corporation on Tuesday September 24th from 12:00-1:00 pm EST for a free one hour informative Webinar and live demonstration on QN-AppWatch for WebSphere MQ. QN-AppWatch for WebSphere MQ is a web-based solution that requires a single server installation on either the UNIX or Windows platform. QN-AppWatch connects with MQ Queue Managers on any platform including the mainframe to provide MQ Administrators and Developers the ability to view, manipulate, edit, create and manage MQ objects all through a web-browser. QN-AppWatch addresses the problem that users of MQ commonly experience, which is that there is no easy way to provide developers with secure and safe access to only their own queue and channel information. Using QN-AppWatch, developers can safely troubleshoot their MQ applications without jeopardizing the integrity of the Queue Managers or constantly call upon an MQ administrator group to provide assistance. QN-AppWatch segregates by project and lifecycle your WebSphere MQ environment. It facilitates optimal MQ development, testing, support and deployment into a Hub and Spoke (Integration Broker) environment all through a detailed level of security and authorization levels. Administrators supporting multiple Queue Managers and MQ installations can use QN-AppWatch to easily and quickly determine the status of MQ objects across the network, while greatly increasing their productivity. QN-AppWatch compliments current monitoring software to provide real-time root-cause analysis and problem resolution based on alerts generated from the monitoring software. If for example an alert is received about a channel problem, QN-AppWatch would be used to investigate the status of the sender and receiver channels, and perhaps then ping, reset and or start the channel after diagnosing the problem. Key Benefits - Ability to Create, Edit, Manipulate, View and Manage MQ objects through a web-based front-end - Provides secure access for developers and administrators - Allows users to migrate point-to-point architectures to broker environments easily - Single server installation on either UNIX or Windows platform - Reduces administer support time - Reduces development timelines - Supports every platform in parallel with MQ including the mainframe To register--simply send an email to [EMAIL PROTECTED] with the word "register" in the title or call 617-764-1226. If you are unable to attend but would like more information on Reconda and our products please go to: www.reconda.com REGISTER TODAY!!! Once you regist
Re: spam
I hate to say it but the devil in me and my nature makes me believe this could be VERY clever way to get your companies marketing information out while looking somewhat innocent and sparing yourself the wrath of this list. This particular company has already felt the wrath of this list as it relates to its free demo version. As I for one did not have this experience when I joined the list. Again its just me wondering aloud - still thinking this is very very clever! Dave Adam <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 09/19/2002 10:50:12 AM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:spam I just signed up for this list yesterday since our MQ guy is no longer here when I returned to my cubical world today I had the following message and was wondering if it is normal to get this stuff from this list Dave, I wanted to send you a personal invitation to our upcoming Webinar and introduce myself and my company. I am the Regional Sales Manager for Reconda an IBM WebSphere MQ partner and we have developed a cutting-edge solution for MQ Development called QN-AppWatch. The Webinar is a great opportunity to learn and see our solution in action. If you're interested please let me know and I can register you and send you the information necessary to access the conference. Please join Reconda International Corporation on Tuesday September 24th from 12:00-1:00 pm EST for a free one hour informative Webinar and live demonstration on QN-AppWatch for WebSphere MQ. QN-AppWatch for WebSphere MQ is a web-based solution that requires a single server installation on either the UNIX or Windows platform. QN-AppWatch connects with MQ Queue Managers on any platform including the mainframe to provide MQ Administrators and Developers the ability to view, manipulate, edit, create and manage MQ objects all through a web-browser. QN-AppWatch addresses the problem that users of MQ commonly experience, which is that there is no easy way to provide developers with secure and safe access to only their own queue and channel information. Using QN-AppWatch, developers can safely troubleshoot their MQ applications without jeopardizing the integrity of the Queue Managers or constantly call upon an MQ administrator group to provide assistance. QN-AppWatch segregates by project and lifecycle your WebSphere MQ environment. It facilitates optimal MQ development, testing, support and deployment into a Hub and Spoke (Integration Broker) environment all through a detailed level of security and authorization levels. Administrators supporting multiple Queue Managers and MQ installations can use QN-AppWatch to easily and quickly determine the status of MQ objects across the network, while greatly increasing their productivity. QN-AppWatch compliments current monitoring software to provide real-time root-cause analysis and problem resolution based on alerts generated from the monitoring software. If for example an alert is received about a channel problem, QN-AppWatch would be used to investigate the status of the sender and receiver channels, and perhaps then ping, reset and or start the channel after diagnosing the problem. Key Benefits - Ability to Create, Edit, Manipulate, View and Manage MQ objects through a web-based front-end - Provides secure access for developers and administrators - Allows users to migrate point-to-point architectures to broker environments easily - Single server installation on either UNIX or Windows platform - Reduces administer support time - Reduces development timelines - Supports every platform in parallel with MQ including the mainframe To register--simply send an email to [EMAIL PROTECTED] with the word "register" in the title or call 617-764-1226. If you are unable to attend but would like more information on Reconda and our products please go to: www.reconda.com REGISTER TODAY!!! Once you register, you'll receive an e-mail with all the information you'll need to join the Webinar presentation and demonstration. It's that simple and you never have to leave your desk. We look forward to having you join us on September 24th. Sincerely, Jeffrey J. Parillo Regional Sales Manager Reconda International Corporation (p)617.764.1226 (c)617.901.5381 (f)203.299.4095 [EMAIL PROTECTED] http://www.reconda.com "Web-based solutions for MQ" 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: Return Code 2018
I am not sure but I know using the OS/390 CICS adapter no CONN is required and I would assume HCONN is of no use. I am thinking you get the 2018 on the open when the adapter is trying to connect or something along these lines... I have no experience with your platform but maybe someone will correct me (set me straight) and at the same time give you your answer. Stacy Rodwell <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 09/18/2002 01:35:13 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Return Code 2018 Here is more information on my problem. Does anyone have any ideas? I am running TXSeries 5.0 and MQ 5.2 fixpack 5 on AIX 5100-02. I have an XA open connection between TXSeries and MQseries. In an CICS applications code I code the following: CALL 'MQCONN' USING QM-NAME, HCONN, COMPLETION-CODE, REASON. >From which I get Zeros for the codes and the HCONN has been filled in with information (I assume an address). The next step in the code is: ADD MQOO-SET MQOO-FAIL-IF-QUIESCING GIVING OPTIONS. CALL 'MQOPEN' USING HCONN, OBJECT-DESCRIPTOR, OPTIONS, SET-HANDLE, COMPLETION-CODE, REASON. The completion-code is 2 and the Reason code is 2018. I am not doing any steps between the connect and the open yet the connection handle is invalid. If I program this as a non-CICS program it works fine. The XA-open connection seems to be fine but I cannot open any of the queues. I have opened up permissions for cics on the queues and queue manager as well as included the group mqm in the cics userid. It does not appear to be a security or access problem. It seems that we are losing the connection handle address or it becomes corrupt and unusable. I need help as soon as possible with this problem. Thanks Stacy 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: MQSeries Secured Connection
I would love a copy - TIA Kevin Tobin <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 09/05/2002 10:56:57 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: MQSeries Secured Connection If anyone is looking for a good tutorial on how to setup and configure MQ5.3 SSL using the W2K platform then I have one and am happy to distribute it to you. Kevin 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 about a separate list for MQSI/WMQI?
Why could you not just subscribe to all three lists then. Having three lists would allow flexibility and would allow you to subscribe to all 3 and others 1, 2 or 3. Robert Broderick <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 06/25/2002 05:25:24 AM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: How about a separate list for MQSI/WMQI? Lets face it. Many of us are interconnected to MQSI thru MQ, and also WorkFlow. MAny of the problems are related. Also being the BIG Websphere MQ family why would you want to seperate them. I am both MQ and MQSI Cert. I prefer to have all those discussions here. It would be a pain to bounce back an forth between three EMAIL addresses to cover all the discussions. All I have to do is click the 'Delete" button for items I don't want to read. Really not much of an energy drain for me. And with all the 'F R E E" information you get, in todays job market, why would you turn that down. Remember, "What makes us smarter makes us richer!!" Only Dave from Wendy's got ahead without an education!! bobbee >From: ANAND <[EMAIL PROTECTED]> >Reply-To: ANAND <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: How about a separate list for MQSI/WMQI? >Date: Tue, 25 Jun 2002 14:14:25 +0530 > >Yup, > I with Mike.There should really be separate list for SI and >Workflow. > Regards, >Anand Jammi > - Original Message - > From: Mike Kelly > To: [EMAIL PROTECTED] > Sent: Tuesday, June 25, 2002 1:45 PM > Subject: How about a separate list for MQSI/WMQI? > > > > It would benefit me a lot to have the MQ list of questions/issues >separated from SI and WorkFlow. Does anyone else agree? Who would we need >to speak to? What was the reason for only maintaining one list? > > Regards, > Mike _ Send and receive Hotmail on your mobile device: http://mobile.msn.com 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 about a separate list for MQSI/WMQI?
Plase! I agree Mike Kelly <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 06/25/2002 01:15:44 AM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:How about a separate list for MQSI/WMQI? It would benefit me a lot to have the MQ list of questions/issues separated from SI and WorkFlow. Does anyone else agree? Who would we need to speak to? What was the reason for only maintaining one list? Regards, Mike 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: Design ???
I think the CAF for os/390 is usually in the neighborhood of about 900.00 per month - I know it depends on certain variables but I believe we are a fairly average shop and that was what I heard for us. so if utilizing the CAF would make your design easier spend the money... as for Why not let > clients (Linux/VM in my case) connect directly to the OS/390 managed queue > ? seems to me their is no way to let the client know he should pull the messages if its the type of application that just is going to connect and process whatever is there when the application is executed sure why not but using client to pull messages could result in delays of processing if os/390 has messages but is down when you try and connect but was up for awhile after messages where on the queue the 390 could of sent the messages to the unix or whatever box and then trigggered your application or even if not triggered and user driven the messaes are on the local server now and available whereas if 390 is down they are still on 390 and you can not get to them. I am probably wrong and if not definitely overstating the obvious! Go Nets Laker hater here "Miller, Dennis" <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 06/06/2002 05:58:07 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: Design ??? >Is it customary (beneficial ??) to have OS/390 processes write to a locally managed queue and to have that queue > pushed by the server to a remote managed queue (hub) in a non OS/390 environment...I 'm sure there's a logical > reason why OS/390 support is refusing to allow this. Seems we will have to pay double the charges to utilize 2 queues. IBM doesn't provide any other way to "push" messages from OS/390. As for the "logical reason", perhaps you have answered that yourself. >Why not let clients (Linux/VM in my case) connect directly to the OS/390 managed queue? Clients certainly can "Pull" messages OS/390. The advisability of doing so tends to be customer specific. It's the kind of advice for which you might pay a consultant big $. It's also a feature for which you will pay IBM additional $. You can glean quite a bit by researching the listserv archives, as that topic has been discussed numerous times before. The considerations run the gamut, including performance, scalability, security, system administration, problem diagnosis, availability, etc. The obvious one that usually surfaces is the additional cost of the OS/390 client attach feature compared with the cost of concentrator hub. > -Original Message- > From: Lindsay, William (USPC.PCT.Hopewell) [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, June 05, 2002 6:04 PM > To: [EMAIL PROTECTED] > Subject: Design ??? > > > Is it customary (beneficial ??) to have OS/390 processes write to a > locally managed queue and to have that queue pushed by the server to a > remote managed queue (hub) in a non OS/390 environment. Why not let > clients (Linux/VM in my case) connect directly to the OS/390 managed queue > ? > > I'm sure there's a logical reason why OS/390 support is refusing to allow > this. Seems we will have to pay double the charges to utilize 2 queues. > > Bill Lindsay > Retirement Group Technology 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: Batch Syncpoint - How many messages can be held back?
5msg 5bytes each is going to absolutely KILL you... with probably upwards of an hour or more to process - just my guess based on our experiences here. Stefan Sievert <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 05/31/2002 01:58:57 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: Batch Syncpoint - How many messages can be held back? Hi Peter, technically, they can have as many messages in a single UOW as defined by the DEFINE MAXSMSGS command (default 1, maximum 9) and sufficient logging resources, BUT I tend to not recommend extended UOW sizes in batch programs, especially because of log implications and restart/recovery considerations. I would chose a design the finds itself between the two that you suggested. One commit per message is as 'bad' as one per 5, maybe even worse. MQ Channels perform best with a BATSCHSZ of about 50. In a /390 batch program, a 'batch size' of 100 to 500 is probably a good compromise. I did some testing with various batch sizes a long time ago and this provided a good compromise between log usage, performance and recovery time. One implementation I did (same sort of program than yours) used a control queue which contained a message with the number of records successfully processed at the time of an abend. During program startup this message was read by the batch program (only present if a previous run abended), and skipped the number of file records contained in the message. Restart logic was rather simple and very stable. You could also write this info to a file which will protect you from a dependency on MQ for restart processing, in case MQ is the reason for an abend (which of course never is the case...). :-) Or, to think completely different: Consider an abend to be the exception to the rule and make your consuming application tolerant of duplicates. But this is more complicated most of the times. Hope those 2 cents help, Stefan >From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Batch Syncpoint - How many messages can be held back? >Date: Fri, 31 May 2002 14:31:42 -0400 > >OS/390 app with MQ 5.2 needs to put 50,000 messages that are each 50,000 >bytes long, all under syncpoint. Will they be able to commit just once, at >the end of the job, when they know everything worked? Sort of an all or >nothing approach to the job. Or will this strain the QM? > >connect >open >do until EOF ( around 5 records) > put to queue > write to file/db >end do >close >disconnect (with implicit commit) > > > >The other option would be... > >connect >open >do until EOF ( around 5 records) > put to queue > write to file/db > if good >commit > else > rollback > end-if >end do >close >disconnect > >Would all these commits degrade performance? Also in this design extra >logic >would need to be added to the app to know where to pick up should the job >abend the first time around, so as not to reduplicate puts, hence the >reason >we are leaning towards the first design. Comments? > > >Peter > > >This communication, including attachments, is for the exclusive use of >addressee and may contain proprietary, confidential or privileged >information. If you are not the intended recipient, any use, copying, >disclosure, dissemination or distribution is strictly prohibited. If >you are not the intended recipient, please notify the sender >immediately by return email and delete this communication and destroy all >copies. > >Instructions for managing your mailing list subscription are provided in >the Listserv General Users Guide available at http://www.lsoft.com >Archive: http://vm.akh-wien.ac.at/MQSeries.archive _ Join the world s largest e-mail service with MSN Hotmail. http://www.hotmail.com 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: Problem in MQDISC SOC-4 Abend
first of all why are we connecting to two QM's? To PUT to QMB just create remote queue definition on QMA and connect to ONLY ONE QM. I am wondering if you understand what MQ is for... connecting to two QM's is new a dfifferent approach to putting data to a ?remote? QM... Sometimes things just make me say Humm and shake my head. shailesh bhaskaran <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 05/30/2002 11:58:43 AM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: Problem in MQDISC SOC-4 Abend Hi!, I am using two different HCONN variables one with name HCONN-PUT and another with HCONN-GET. After doing get I see that both HCONN-PUT and HCONN-GET have exactly the same values. I am doing MQCONN using HCONN-GET to connect to QMA and MQCONN using HCONN-PUT to connect to QMB. For testing purpose I have kept both QMA and QMB name same i,e both Get and Put queue manager names are same. I was wondering if from the same program if I issue MQCONN twice to the same queue manager, will I get the same value for the connection handles and if I disconnect using one connection handle will the other be also destroyed. I can guess that whenever I am closing the first connection handle say HCONN-GET, it somehow marks HCONN-PUT also closed.I can't understand why it is happening. Is it because I am connecting to same queue manager (with two different calls) using HCONN-GET and HCONN-PUT. Thanks Shailesh --- John M Hammond <[EMAIL PROTECTED]> wrote: > Shailesh, > > You need to disconnect from both queue managers. > > Check your program and look at what you are doing > with the variables you > are storing your HConns in. You have 2 separate > HConns and need 2 separate > variables to store them in (if you want to be > connected to both queue > managers simultaneously). My guess is that you are > corrupting the HConn > somehow. The HConn is just a storage address, so if > you corrupt it MQ will > end up referencing bad addresses and 0C4's are > likely. > > John > > John M Hammond - Middleware Support Team > Household International > 100 Mittel Drive > Wood Dale, IL 60191 > Phone: (630) 521-4339; Pager: (866) 237-0985 > > > > > shailesh To: > [EMAIL PROTECTED] > bhaskaran cc: > Subject:Problem in MQDISC SOC-4 Abend > [EMAIL PROTECTED]> > Sent by: MQSeries > List > n.AC.AT> > > > 05/30/2002 11:51 > AM > Please respond to > MQSeries List > > > > > > Hi! All, > > I am facing a strange problem. I am running a batch > application in which I am connecting to one queue > manager say QMA and opening the queue to MQGET the > message and also connecting to another queue manager > say QMB and opening another queue to MQPUT the > message > read from the previous queue. > > Everything goes fine, At the end,I am disconnecting > from QMA and QMB. The disconnect from first queue > manager QMA goes fine but when it performs the para > to > disconnect from queue manager QMB, I get a SOC4 > abend. > I tried to do reverse also i,e first disconnecting > from QMB (which goes fine) and then QMA again I get > SOC4. I am using different connection handle to > connect to two different queue manager. > > Can any one think of why it might be happening? Does > disconnecting from any one queue manager is enough? > > > Thanks > Shailesh > > __ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.yahoo.com > > 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 __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com 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: "Queue Manager Clusters" References
...and I hope when you complete your white paper you will publish to the list : ) John M Hammond <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 05/23/2002 10:42:21 AM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:"Queue Manager Clusters" References Hi there, I'm putting together a white paper on MQSeries clustering for my company, and would like to include some references to people already using them in production. I know (from my time in the MQ change team) that a great number of people are running clusters successfully in production, and I understand the issues surrounding clustering. What I'm looking for is something to say, "Look, company x has been running with clustering for n years now and this is what they think". The kind of information I would like is along the lines of: How long have you been running, what level of MQ are you on, what platforms are involved, was it worth it? If anyone wold be willing to divulge a few details, please drop me an email. Thanks, John John M Hammond - Middleware Support Team 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: Selective MQGET using MsgId or CorrelD
the numbers you have are nice but what is more important is how many messages will be on the queue at any one time. We use correlid as a way to group messages as we send entire files across platform to platform using MQ and we need the messages to stay together so we sender a header that contains the correlid that all the messages will have so we can retrieve them all before going on to retrieve the next batch. We also matchoption match by correlid on our cics transactions that use the MQ Cics bridge we send the correlid via the bridge so the bridge forwards it to our program via the commarea then we retrieve the associated message from another local queue. We are not having any problems our volumes are not to large I really can not supply the numbers okay I will try probably only about 2000 messages a day for the online... and some of our batch queues could have upwards of 50,000 messages retrieved by correlid and all having the same correlid only time we would have multiple correlid is if we had multiple batches of data on the queue we can happen that is why we used correlid in the first place. [EMAIL PROTECTED]@AKH-WIEN.AC.AT> on 05/23/2002 03:17:10 AM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Selective MQGET using MsgId or CorrelD Hi, within our organization, some people are looking into reading specific messages of a queue, based on either MsgId or CorrelID. I have read some threads in the past on this issue, but I'm still looking for 'hard' numbers on performance impact (either improvement or degrading). We are talking about OS/390 implementation, where indexing is possible. My personal (gut) feeling is NOT to use these selective reads, but I'm open for all positive advise as well. I have been looking through performance reports for MQ, but there doesn't seem to be any numbers on selective reading of messages. Has anybody performed any comparison between reading specific messages off a queue or just in FIFO order? If so, would you be willing to share your results? I've asked the architects/designers for more specific information on the case in which they want to use this mechanism, but they can't come up with good characteristics (yet). The only thing they are mentioning now is that the system will have to handle 9 million messages per year, with a peak maximum of 200.000 messages per day. Apart from any numbers, are there any pittfalls to using indexing and selective reads? Regards, Ard van der Leeuw -- De Belastingdienst gebruikt e-mail niet voor officiele mededelingen. == 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: Question About Dead Letter Queue
does your remote Q def on unix point to the local queue on os/390. make sure os/390 local queue is not put inhibited in its definition the header of DLQ should tell you the reason code for why the message was delivered there and not the local queue. Sergio Lima <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 05/17/2002 06:42:26 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Question About Dead Letter Queue Hello . Here We have another problem. Now, the UNIX send message to OS/390, and the message stop into DEAD LETTER QUEUE. The question are. What can I do to unserstand why the messages are there ? We also can do a browse in message, but have any field there that explain why ? Thanks Sergio Lima Costa System Consultant Sao Paulo - Brasil _ Join the world s largest e-mail service with MSN Hotmail. http://www.hotmail.com 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: Problem with 2058 on MQCONN
if you are running on the 390 I am assuming you would want to connect to the 390 not the unix box it appears to me you are using the wrong queue manager Sergio Lima <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 05/16/2002 07:06:48 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Problem with 2058 on MQCONN Hello. Here We try connect a OS/390 MQ with UNIX MQ, and received 2058 on MQCONN . We also checked the channels, queues, name of Qmanager, and can't find the mistake. We also can see that the channels are RUNNING status like bellow : OS/390 : CSUX034.TO.MQD1 CHLRECEIVER RUN MQD1.TO.CSUX034 CHLSENDERRUN UNIX : 14 : display chstatus(*) AMQ8417: Display Channel Status details. CHANNEL(MQD1.TO.CSUX034)XMITQ( ) CONNAME(10.1.8.76) CURRENT CHLTYPE(RCVR) STATUS(RUNNING) AMQ8417: Display Channel Status details. CHANNEL(CSUX034.TO.MQD1)XMITQ(MQD1.XMIT.QUEUE) CONNAME(10.1.8.76) CURRENT CHLTYPE(SDR)STATUS(RUNNING) We tried do this connection with the sample job : //CICSBVK1 JOB (CIC,SP,72613,09,40),SUPORTE //*NOTIFY=&SYSUID, //*CLASS=K,MSGCLASS=T,MSGLEVEL=(1,1) //* //*PUT MENSAGENS DE FILAS //* //CSQ4 EXEC PGM=CSQ4BVK1,REGION=2M, // PARM='CSUX034,RQ.MQD1.CSUX034,0010,A,0080,N' //STEPLIB DD DSN=SUP.CICS.P991107.LOAD,DISP=SHR //*DD DSN=MQSD1.MQS210.SCSQLOAD,DISP=SHR //*DD DSN=MQSD1.MQS210.SCSQANLE,DISP=SHR // DD DSN=MQSD1.MQS210.SCSQAUTH,DISP=SHR //SYSPRINT DD SYSOUT=* //SYSINDD * Bottom of Data ** And the result : W00-MSGLENGTH-NUM -0080 W00-NUMMSGS-NUM -0010 === PARAMETERS PASSED : QMGR- CSUX034 QNAME - RQ.MQD1.CSUX034 NUMMSGS - 00010 PADCHAR - A MSGLENGTH - 00080 PERSISTENCE - N === * MQCONN * COMPLETION CODE : 2 * REASON CODE : 02058 Any Help ? Sergio Lima Costa System Consultant Sao Paulo - Brasil _ Join the world s largest e-mail service with MSN Hotmail. http://www.hotmail.com 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
