New version of BlockIP2
Dear MQers, I'm very proud to tell you that I've found BlockIP2 version 2 is ready to fly. BlockIP2 have been completely rewritten thanks to Sid Young, and ported to z/OS by Neil Casey ;o) More function have been added to the Security exit. You'll find the exit information here: http://www.mrmq.dk/BlockIP.htm#BlockIP2_version_2.1x Just my $0.02 ;o) Kind regards Jxrgen www.mrmq.dk the author of BlockIP _ Fe alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk/ 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 Triggering question.
Hi Vaughan,
The definitions looks allright, (I have a question, see later).
What seems odd is:
Task No.Task StatusThread StatusNo-of-APIsLast API
-- - --- --
Starting
Initiation Queue Name: INITQ
It should look like:
CKTI 1 to 1 of 1
Task NumTask StatusThread Status Num of APIs Last API
-- - --- --
042 Normal Msg Wait 56 MQGET
Initiation Queue Name: ATGLQUEUE
I think you should take a look on your CICS' log take a look for CSQ
failures and/or other reports from CICS/WebSphere MQ. It seems like that
CKTI is not started ok. Take a look on INITQ, is it open for input ?? By
the way is INITQ defined ??
The only transaction that is allowed to read from INITQ is the
triggermonitor CKTI. Your triggered application(A) should read from
TRIGGER.QUEUE.
Another place to look for information is in your QueueManagers log
(MSTR), if there are security problems they are reported here.
I did a small writing on this topic some time ago, there are also
troubleshooting tips there. If you have other thing to add just drop me a
mail.
You find my CICS triggering info here:
http://www.mrmq.dk/CICStrouble.htm
Back to my question: Why are you using trigger EVERY ???
Have you designed your applications to continue to read until rc=2033 is
reached, just to take one message ??
Kind regards
Jxrgen
www.mrmq.dk
the author of BlockIP
From: Vaughan Phillips <[EMAIL PROTECTED]>
Reply-To: MQSeries List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: A Triggering question.
Date: Tue, 27 Jul 2004 17:23:00 +0100
Hi,
I'm currently prototyping a CICS/MQ application and trying to get
Triggering to work. Here's a quick rundown of how the prototype is "meant"
to work.
Application A puts a message on a queue TRIGGER.QUEUE
A CICS application called TRIGGER1 is defined to retrieve the message from
the initiation Q INITQ and start Application B
Application B opens TRIGGER.QUEUE, retrieves the message and writes it to a
TSQ record, to indicate that all the processes in the loop have completed.
All three programs write "diagnostic" records to the same TSQ starting with
the name of the Program as the very first statement
What actually happens is that Application A puts a message on TRIGGER.QUEUE
and ends. Nothing appears on the TSQ, other than records output by
Application A.
The MQ definitions for the prototype are as follows (complete with the Log
messages telling me that the definitions are OK):
*
DEF QL(TRIGGER.QUEUE) REPLACE -
DESCR('TRIGGER QUEUE')-
INITQ(INITQ) -
PUT(ENABLED) -
GET(ENABLED) -
USAGE(NORMAL) -
PROCESS(TRIGGER1) -
TRIGGER -
TRIGTYPE(EVERY)
CSQ9022I %CSQ1 CSQMMSGP ' DEF QL' NORMAL COMPLETION
*
DEFINE PROCESS (TRIGGER1) REPLACE -
DESCR('PROCESS TRIGGER1') -
APPLTYPE (CICS) -
APPLICID (TRG1) -
USERDATA ('user data')
CSQ9022I %CSQ1 CSQMMSGP ' DEFINE PROCESS' NORMAL COMPLETION
*
DEF QL(TEST.REQUEST) REPLACE
-
DESCR('Request Queue for testing purposes')
-
MAXDEPTH(128) MAXMSGL(512) PUT(ENABLED) GET(ENABLED) DEFPSIST(NO)
-
DEFSOPT(SHARED) MSGDLVSQ(FIFO) NOHARDENBO USAGE(NORMAL)
CSQ9022I %CSQ1 CSQMMSGP ' DEF QL' NORMAL COMPLETION
*
DEF QL(TEST.REPLY) REPLACE
-
DESCR('Reply Queue for testing purposes')
-
MAXDEPTH(128) MAXMSGL(512) PUT(ENABLED) GET(ENABLED) DEFPSIST(NO)
-
DEFSOPT(SHARED) MSGDLVSQ(FIFO) NOHARDENBO USAGE(NORMAL)
CSQ9022I %CSQ1 CSQMMSGP ' DEF QL' NORMAL COMPLETION
*
When I check with the MQSseries for OS/390 - CICS adapter - Display CKTI
panel, I see the following:
CKQCM4 Display CKTI panel
Read CKTI status information. Then press F12 to cancel.
CKTI 1 to 4 of 4
Task No.Task StatusThread StatusNo-of-APIsLast API
-- - --- --
Starting
Initiation Queue Name: INITQ
Any ideas as to where I am going wrong?
Regards,
Vaughan
---
QAS Ltd.
Developers of QuickAddress Software
http://www.qas.com";>www.qas.com
Registered in England: No 2582055
Registered in Australia: No 082 851 474
---
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
_
Fe alle de nye
Re: Cluster Queue Managers
The way to do it might be using the cluster workload exit for routing the messages. Using this exit you can deside where you want to send the message It's all yours. Your setup seems to be quite complicated... so your job is safe ;o) Just my $0.02 ;o) Kind regards Jxrgen www.mrmq.dk the author of BlockIP From: Wmq Techie <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Cluster Queue Managers Date: Mon, 12 Jul 2004 19:51:49 + Hello, There are two different physical sites that host three WMQ 'overlapping' cluster queue managers and five cluster queue managers. That is to say in Site A, there are 3 overlapping queue managers that reside in cluster Y and cluster Z. Also, in cluster Z there are 5 cluster queue managers in site A. Also in site B, there are 3 overlapping queue managers that reside in cluster Y and cluster Z. Also, in cluster Z there are 5 cluster queue managers in site B. A message is put onto an alias cluster queue definition from cluster Y, that is defined in the six overlapping queue managers, three in site A and three in site B. Using the round-robin pattern, the message can be sent to any of the six overlapping queue managers. The alias cluster queue definition points to a cluster queue that resides in 10 different queue managers in cluster Z. For these 10 cluster queue managers, 5 reside in site A and 5 reside in site B. From the alias queue definition in the overlapping queue managers, the message can go to any of the 10 cluster queue managers. If the message is put to an overlapping queue manager in site A, how can the message be controlled to go the other 5 cluster queues that is also defined in site A? I want to keep the message to remain in a specific site so the message does not bounce between sites on it's way to a single queue manager that is not in either of the clusters? Your thoughts! Bud _ Fe alle de nye og sjove ikoner med MSN Messenger http://www.msn.dk/messenger 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 on Mainframes OS/390
Hi Vijay, First of all "No DLL on Z/OS" what you have to do is creating a load module (normal Z/OS wise), and place that in the library specified by DD CSQXLIB on your CHIN Task. When you have done this, you will be able to specify the exit and get WebSphere MQ to load the program. It's all documented in Intercommunicationguide. There are IBM supplied samples, I advise you to take a look on them. I did a Z/OS security exit, which works ;o) You can take a look on it (written in Assembly language so it's easy for a sys.prog. to install) You find the old BlockIP-exit here: http://www.mrmq.dk/BlockIP.htm#BlockIP%20security%20exit including an example of how to specify exit parms. Kind regards Jxrgen www.mrmq.dk the author of BlockIP From: Vijay_Kannan <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: MQSeries on Mainframes OS/390 Date: Wed, 30 Jun 2004 11:04:47 +0530 Hi, I am working in MQSeries on OS/390. I have to develop a Channel Exit program. The setup is like this. I have a Queue Manager, Transmission Queue, Remote Queue Definition and a Sender Channel on Windows. There is another Queue Manager, Destination Queue and a Receiver Channel on the Mainframe Machine. I have the Channel Exit program and have compiled it and made a DLL. Now I have to specify this DLL name and the program that has to be called whenever a message flows through the channel. The program will pick up the message and put it into an Event Queue, which also is on the Mainframe Machine. From the documents that I read, I think these have to be specified in the properties of the Channel - Message Exit Name and User Data. But I am not able to understand how to give these properties. Can anyone who has worked in MQSeries on Mainframes help me with this? The Message Exit Name can only be 8 characters long. I want to know how to give the DLL name and the program name here. I might have to specify the Data Set name also, which has the DLL. Should the Event Queue name be specified in the User Data property of the Channel? Please reply. Regards. Vijay. _ Fe alle de nye og sjove ikoner med MSN Messenger http://www.msn.dk/messenger 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: Channel send/receive exit
Hi Mark, try take a look on the supportpack MO02: http://www-306.ibm.com/software/integration/support/supportpacs/category.html#cat2 It works on: z/OS, windows and AIX. Kind regards Jxrgen www.mrmq.dk the author of BlockIP Mark wrote: Does anyone have a channel send/receive exit that does compression that they might want to share? I'd rather not re-invent the wheel if possible. Thanks, Mark Bond E-mail: [EMAIL PROTECTED] Phone: (440) 264-6140 FAX:(440) 379-6524 Cell Phone: (440) 478-3856 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 _ Fe alle de nye og sjove ikoner med MSN Messenger http://www.msn.dk/messenger 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
New version of BlockIP2 v2.11 Beta released
Hi MQers. Just a small blimp on the blue sky from to announce that the new redesigned version of BlockIP2 is ready to rock and rool (I hope without too many errors). You find the beta version here, http://www.mrmq.dk/BlockIP.htm#BlockIP2_version_2.1x Thanks to all who have tested and commented on the last couple of weeks. I hope it fit your need. Kind regards Jxrgen www.mrmq.dk the author of BlockIP _ Fe alle de nye og sjove ikoner med MSN Messenger http://www.msn.dk/messenger 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: Need help with BlokIP exit
Hi Benjamin,
You should get a file: c:\BlockIP2.log presenting you with a log/trace fil
telling you what BlockIP2 do.
If you're dealing with windows you must specify scyexit() and scydata() like
this:
alt chl(SYSTEM.ADMIN.SVRCONN) chltype(SVRCONN) +
SCYDATA('FN=d:\utils\exit\blck.cfg;-d') +
scyexit('d:\utils\exit\BlockIP2(BlockExit)') * NT
the -d; option tells BlockIP to send "debug" information to the logfile too.
You can read a bit about BlockIP2 here:
http://www.mrmq.dk/BlockIP.htm
By the way (BlockExit) tells windows which entry in the dll to invoke. There
can be many entries/routines in a dll. This is the reason for (BlockExit). I
hope it turn on some light...
Just my $0.02 ;o)
Kind regards
Jxrgen
Author of BlockIP
Hi Ruzi,
did you figure out how to set it? I don't seem to be able to make the
BlockIP2.dll get loaded. specifically, I put all the files into
d:\utils\exit, and configured my SYSTEM.ADMIN.SVRCONN with
scyexit('d:\utils\exit\BlockIP2(BlockExit)'), and
scydata('d:\utils\exit\blck.cfg;-d')
But it doesn't seem to produce any log file, so I anticipate it didn't
load.
Would you mind shed some light on this setting? BTW, that does this
"(BlockExit)" mean? as parameter?
Benjamin F. Zhou
Messaging & Integration Supp.
Mercedes-Benz USA
(201) 573-2474
_
Fe alle de nye og sjove ikoner med MSN Messenger http://www.msn.dk/messenger
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: New BlockIP version -needs testing
Hi all, I've tested BlockIP2 and have to do more testing and changes because of some incompability reasons with older version of BlockIP2. But it seems a bit like "the ugly duckling" by our famous danish writer H.C.Andersen, whaich ended up as a nice Swan. BlockIP2 version 2.x will also be a swan and it's flying soon. Kind regards Jxrgen www.mrmq.dk the author of BlockIP From: [EMAIL PROTECTED] Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: New BlockIP version -needs testing Date: Mon, 29 Mar 2004 11:58:27 +1000 MIME-Version: 1.0 Received: from AKH-Wien.AC.AT ([149.148.150.3]) by mc11-f21.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Sun, 28 Mar 2004 18:02:11 -0800 Received: by AKH-Wien.AC.AT (IBM VM SMTP Level 310) via spool with SMTP id 2531 ; Mon, 29 Mar 2004 03:59:47 MES Received: from AKH-WIEN.AC.AT (NJE origin [EMAIL PROTECTED]) by AKH-WIEN.AC.AT (LMail V1.2d/1.8d) with BSMTP id 5049; Mon, 29 Mar 2004 03:59:41 +0200 Received: from AKH-WIEN.AC.AT by AKH-WIEN.AC.AT (LISTSERV-TCP/IP release 1.8d) with spool id 6901 for [EMAIL PROTECTED]; Mon, 29 Mar 2004 03:59:37 +0200 Received: from AWIIMC12 (NJE origin [EMAIL PROTECTED]) by AKH-WIEN.AC.AT (LMail V1.2d/1.8d) with BSMTP id 5039 for <[EMAIL PROTECTED]>; Mon, 29 Mar 2004 03:59:36 +0200 Received: from *unknown [203.0.230.140] by AKH-Wien.AC.AT (IBM VM SMTP Level 310) via TCP with SMTP ; Mon, 29 Mar 2004 03:59:25 MES Received: by qmlmail.qml.com.au with Internet Mail Service (5.5.2656.59) id ; Mon, 29 Mar 2004 11:58:37 +1000 X-Message-Info: JGTYoYF78jG8grdhVtL/CbrqXJEK8c3W X-Warning: AKH-Wien.AC.AT: Could not confirm that host [203.0.230.140] is qmlmail.qml.com.au X-Mailer: Internet Mail Service (5.5.2656.59) Message-ID: <[EMAIL PROTECTED]> Return-Path: [EMAIL PROTECTED] X-OriginalArrivalTime: 29 Mar 2004 02:02:12.0285 (UTC) FILETIME=[D9ADE6D0:01C41531] G'Day Jxrgen et al, I have appended a new version of BlockIP2 security exit with the logging completed and tested and one or two bugs fixed. I am planning on writing a How-To this week and will distribute it in PDF format. Once people have tested the code I would say that it could be released as a new improved version and made available from your web site. Sid << BlockIP2_00.c >> _ Fe alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk 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: BlockIP logic incorrect ??
well, thats no big deal, it's just a new version of the source... The rework have saved me a lot of work, to enhance it even more ;o) The biggest problem can be the search engines/spiders, which will find this version 2.0 of the program, so newbies will download the source instead of the maintained version. So maybe I should send a mail here and on www.MQSeries.Net when there are new versions released ? Personally I think of such mails as spam, your oppinion wanted here :o) I'm quite happy that Sid did a redesign, I'm shure that the version soon vill be available from my website. I just have to run it thru my testcases to see if it work, I shure it works ;o) When I look a year back, and see how BlockIP have changed, and the requirements, from just a simple conname filtering program to what it is today. I see that it gives www.mrmq.dk a lot of traffic, so it have been a great success, and it know that the z/OS version of the original exit have been used for design base in some vendor packages. The language used here might offend some persons.. Politeness please here :-o Kind regards Jxrgen www.mrmq.dk the author of BlockIP From: "Wyatt, T. Rob" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: BlockIP logic incorrect ?? Date: Thu, 25 Mar 2004 06:59:55 -0600 Actually Sid, you just released it. :-0 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, March 25, 2004 6:59 AM To: [EMAIL PROTECTED] Subject: Re: BlockIP logic incorrect ?? G'Day Jxrgen, Well I went a bit overboard with the additional functionality and after studying your code I decided to do a complete re-write... I figured you would be pissed at me so I have not yet released it but essentially I split out all the code into a modular form so that the main block of logic is no longer a big bloatted mess. I have also made a fundamental change to the logic of the exit so that it denied everything and if criterior failed it exited with the SUPPRESS flag already set. So if you pass everything that needs to be done then you set OK as the LAST step. The original code did a lot of duplication in checking and was not very modular so when I tried to add the logging functionality I needed I found it very difficult with the original structure. Basically each group of checks now has it's own method/function call. So there is Pattern checking, CON= checking (you already had that one in a function), SSL checking, UserId, MqmUsers ids and a method to process the file and a method to process an array of options (which means the options could be in a file or in the exit data field. It is now easier to add additional options and the code to handle them. the code is not yet finished but I have attached todays effort, if you don't want it thats fine, I'll keep it in house for my own use. Sid -Original Message- From: Jxrgen Pedersen [mailto:[EMAIL PROTECTED] Sent: Thursday, 25 March 2004 5:46 PM To: [EMAIL PROTECTED] Subject: Re: BlockIP logic incorrect ?? Hi, Sid & Co. I'll look into it, but it should, match up both conname and userid before accepting the connection and allow evt. the change of MCAUSER. Have you a debug sysprint (with the -d; option), pls. send for investigation. Kind regards Jxrgen www.mrmq.dk the author of BlockIP >From: [EMAIL PROTECTED] >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: BlockIP logic incorrect ?? >Date: Thu, 25 Mar 2004 10:31:16 +1000 > > >G'Day all, > >Has anyone tested the CON= commands in the latest version of BlockIP2.c ?? > >I get odd results when the host IP I am on is different to the pattern to >match on, it seams that the user id is matched but the IP is ignored... not >quite what I would have expected which is if the IP matchs AND the user >matchs then set the MCA to > > >Any thoughts anyone ?? > > >Sid Young >QML Pathology _ Fe alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk 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 _ Fe alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk 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: BlockIP logic incorrect ??
Hi, Sid & Co. I'll look into it, but it should, match up both conname and userid before accepting the connection and allow evt. the change of MCAUSER. Have you a debug sysprint (with the -d; option), pls. send for investigation. Kind regards Jxrgen www.mrmq.dk the author of BlockIP From: [EMAIL PROTECTED] Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: BlockIP logic incorrect ?? Date: Thu, 25 Mar 2004 10:31:16 +1000 G'Day all, Has anyone tested the CON= commands in the latest version of BlockIP2.c ?? I get odd results when the host IP I am on is different to the pattern to match on, it seams that the user id is matched but the IP is ignored... not quite what I would have expected which is if the IP matchs AND the user matchs then set the MCA to Any thoughts anyone ?? Sid Young QML Pathology _ Fe alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk 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: MO71
Hi Mike, You could use BlockIP2 to help you there. BlockIP2 can filter on your connection name together with the userid. And if you have a match it can even change/set MCAUSER depending on your choise. Another ting is when leaving a SVRCONN open you can let everybody inside. If somebody can write a JMS/JAVA program they can connect to your queuemanager and set the usterid to whatever they want: mqm, root, db2admin. All they need is a know userid with the right auth. (and ofcause the connctionname/channel of your qmgr, typicly: 'SYSTEM.DEF.SVRCONN/TCP/conname(1414)') BlockIP2 was designed to help MQ-administrators to keep the mqnetwork more secure. http://www.mrmq.dk/BlockIP.htm#BlockIP2 Just my $0.02 ;o) Kind regards Jxrgen www.mrmq.dk the author of BlockIP From: "Ward, Mike S" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: MO71 Date: Mon, 22 Mar 2004 07:15:17 -0600 I'm not sure I understand. If my NT userid is db2admin why would it work if I change the MCAUSER on the SVRCONN to mqm? How can I secure it so that only users I designate can use it? -Original Message- From: Paul Clarke [mailto:[EMAIL PROTECTED] Sent: Monday, March 22, 2004 4:04 AM To: [EMAIL PROTECTED] Subject: Re: MO71 Mike, I'm not sure what your security policy is; whether you're using SSL, security exits or whatever but to get things working you could change the MCAUSER of the SVRCONN to something which has the required authority. If your MCAUSER is blank then you are even less secure since you'll effectively believe any userid the client cares to throw at you. On most platforms you can switch authority events on in the Queue Manager and then you'll get a message whenever a security check fails. This messages details the userid and the object being checked. Personally I find this quite useful when tracking down security violations. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley |-+> | | "Ward, Mike S" | | | <[EMAIL PROTECTED]>| | | Sent by: MQSeries| | | List | | | <[EMAIL PROTECTED]| | | N.AC.AT> | | || | || | | 19/03/2004 22:20 | | | Please respond to| | | MQSeries List| |-+> >--- --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: MO71 | | | | | >--- --| Thanks, I got it to work. I am also trying to connect to a SCO Unix qmanager and I keep getting a Error connecting via client to 'VRUQMGR3' RC(2035) Not authorized. I tried defining the userid of the NT box that has mqmon running on it and then modifying that user so that it has mqm as a group but I still get the same message. Any thoughts? -Original Message- From: Paul Clarke [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 17, 2004 3:50 AM To: [EMAIL PROTECTED] Subject: Re: MO71 Mike, MO71 supports two types of monitoring. 1/ Normal monitoring relies on a program at the remote Queue Manager to receive the messages and send them back to the reply fields This does therefore require a client (program) running on the remote system 2/ Loopback monitoring allows yoiu to define a remote queue on the remote system which just 'points' back to the originating queue. This does not therefore require a client (program) running on the remote system Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley |-+> | | "Ward, Mike S" | | | <[EMAIL PROTECTED]>| | | Sent by: MQSeries| | | List | | | <[EMAIL PROTECTED]| | | N.AC.AT> | | || | || | | 16/03/2004 14:32 | | | Please respond to| | | MQSeries List| |-+> >--- | | | | To: [EMAIL PROTECTED] | | cc: | | Subject: MO71 | | | | | >--- | Hi, is a client required at both ends in order for the monitoring to work? Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsof
Re: Many Client connections - how many svrconn channels?
Hi Sid, Yes, I'll put your changes into the code, no problem. I thinks it's a good idea just to keep one version of BlockIP/BlockIP2 so we allways know how to solve problems, and not have to deal with at lot of "cousins". Just send me the code, and I'll review the code before release. Kind regards Jxrgen www.mrmq.dk the author of BlockIP From: [EMAIL PROTECTED] Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Many Client connections - how many svrconn channels? Date: Mon, 22 Mar 2004 11:26:44 +1000 Jxrgen, I need to make some changes to BlockIP2 for logging of information, the logs grow way to big on my systems and I need then stamped by date: ie BlockLog_2004_03_22.log I also need to be able to specify a log directory, so I was going to add the following commands: # on NT systems LogDirecty=\qml\log LogDrive=c: LogFormat=NameDate LogBaseName=BlockLog # on Linux systems LogDirecty=/var/spool/blockip2/logs LogFormat=NameDate LogBaseName=BlockLog On the linux the "LogDrive" would be ignored and just the LogDirectory would be applicable using "/"s If I make the changes, are you happy to add them into your code for the benefit of the community as a whole, or would you prefer me to start my own stream of BlockIP ??? Sid Young QML Pathology Brisbane _ Fe alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk 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: Many Client connections - how many svrconn channels?
I just updated BlockIP2 so it might help "Ruzi R" with some of the security
challanges.
It's quite simple what can be done, su}ntax of the new CON parameter:
CON=;[;MCA={*|userid}];
and an example of parameter file
#
# Simple filter implemented in BlockIP2 version 1.22
#
# 1. stop all connection attempts from mqm (NoBody is an undefined or
blocked userid).
CON=*;mqm;MCA=NoBody;
#
# 2. Stop users starting with ww14 from 10.31.* Might be a foregin network
CON=10.31.*;ww14*;MCA=NoBody;
#
# 3. Allow master03 wjen comming from 172.20.10.31
CON=172.20.10.31;master03;
#
# 4. Allow spider when comming from 10.*, and set MCAUSER to master04
CON=10.*;spider;MCA=master04;
#
# 5. Block all other attempts.
CON=*;*;MCA=NoBody;
# EOF
Just my $0.02 ;o)
Kind regards
Jxrgen
www.mrmq.dk
the author of BlockIP
_
Fe alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk
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: RCVR versus RQSTR channels
Hi Paul & Co, This have been a long thread... and I'm going to extend it a bit more. ;o) I like to point some things out with regard to the security, and I agree with Paul and T.Rob to some extend... Without security exits and/or SSL there are no authentication at all. I doesn't matter if you use SDR/RCVR or SVR/RQSTR or the other combinations including cluster channels. If we're using a RQSTR then it uses callback if the RQSTR initiates the conversation, but what happens if it was the sender, does it break the connection ?? NOPE, it just acts as a normal RECEIVER channel. What about a fully qualified SVR channel, if this one starts the connection no callback, just a normal SDR channel. And the Cluster channels, acts allmost the same way, if you can connect to the full-repos qmgr, you have access to the whole cluster (if there are no security exits/SSL on the CLUSRCVR channel). My personal advis is use SDR/RQSTR because you (normally) can start the channel from both ends, and I don't care what the partner in the other end says I allways use RQSTR with some exits. Currently I'm working on a security authentication exit for z/OS and the Distributed platform. And the technic behind it seems to work. The challange is to archive a reasonable security with a low cost, no problem with high security just use SSL or a 3 party product. Just my $0.02 ;o) Kind regards Jxrgen www.MrMQ.dk T.Rob, I agree entirely with you that you should employ some form of mutual authentication such as SSL. However, I do not see this as just a Requester/Server issue but of any channel pairing. I had assumed, perhaps wrongly, that a channel was always protected in this fashion if the data was of a sensitive nature. I would not like people to get the impression that requester/server pairs are somehow inherently unsafe and that sender/receiver pairs are inherently safe. The reality is that all channels should employ something like SSL if one needs to be certain of the authenticity of the data and its source. I also agree that a callback is not an excessive overhead in the grand scheme of things. However, it is still overhead and extra complexity. If users feel safer by having requester/sender pairings then that's fine by me. I was merely trying to point out an alternative. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley _ Fe alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk 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: SSL
Hi There, There is on from Morag at the UK-MQUG http://www.mqug.org.uk/anonftp/021131%20-%20Ssl.pdf Maybee it can help ?? Just my $0.02 ;o) Kind regards Jxrgen I while back there was link to a doc called "How Secure are your channels?" by Morag Hughson. I can't find the link, all I have is a paper copy of the doc, which is excellent. It explains how to SSL, and uses a z/OS Qm to AIX QM in the example. Maybe someone out there remebers this, and can post the link again. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 12:23 PM To: [EMAIL PROTECTED] Subject: Re: SSL It's a big topic. Look at the Security Guide _ Fe alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk 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
Hi Ruzi, I agree with you. Anyway when there are a posibillty, there are no gurantee for other statements between DEQ and MQCLOSE... and maybe another EXEC CICS.. I would prefer that the EXEC CICS DEQ was done before the MQCLOSE to make it fool proof, because the new trigger first can occur after MQCLOSE. Another thing on Triggered CICS transactions is to issue the MQCLOSE call and not rely on CICS to issue the MQCLOSE on cleanup/task terminiation. If we forget to issue MQCLOSE MQ will think the queue is open until the CICS finds time to do the cleanup. You don't see this in testing environments because the CICS systems normally are not stressed. And it's too late to find it in production and in this situation will TRIGINT() not help, because the queue is open seen from MQ. This was one of the main reasone to participate in this thread. No hard feelings! Just my $0.02 ;o) Kind regards Jxrgen From: Ruzi R <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: MQ Triggering in CICS Date: Thu, 4 Mar 2004 06:09:55 -0800 MIME-Version: 1.0 Received: from AKH-Wien.AC.AT ([149.148.150.3]) by mc2-f31.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Thu, 4 Mar 2004 06:23:33 -0800 Received: by AKH-Wien.AC.AT (IBM VM SMTP Level 310) via spool with SMTP id 4328 ; Thu, 04 Mar 2004 15:13:46 MEZ Received: from AKH-WIEN.AC.AT (NJE origin [EMAIL PROTECTED]) by AKH-WIEN.AC.AT (LMail V1.2d/1.8d) with BSMTP id 7666; Thu, 4 Mar 2004 15:11:19 +0100 Received: from AKH-WIEN.AC.AT by AKH-WIEN.AC.AT (LISTSERV-TCP/IP release 1.8d) with spool id 9021 for [EMAIL PROTECTED]; Thu, 4 Mar 2004 15:11:09 +0100 Received: from AWIIMC12 (NJE origin [EMAIL PROTECTED]) by AKH-WIEN.AC.AT (LMail V1.2d/1.8d) with BSMTP id 7624 for <[EMAIL PROTECTED]>; Thu, 4 Mar 2004 15:11:09 +0100 Received: from web106.biz.mail.yahoo.com [216.136.174.208] by AKH-Wien.AC.AT (IBM VM SMTP Level 310) via TCP with SMTP ; Thu, 04 Mar 2004 15:10:37 MEZ Received: from [204.225.30.94] by web106.biz.mail.yahoo.com via HTTP; Thu, 04 Mar 2004 06:09:55 PST X-Message-Info: yilqo4+6kc78XxFhPvV7OhSVkocX7Pyv X-Comment: AKH-Wien.AC.AT: Mail was sent by web106.biz.mail.yahoo.com Message-ID: <[EMAIL PROTECTED]> In-Reply-To: <[EMAIL PROTECTED]> Return-Path: [EMAIL PROTECTED] X-OriginalArrivalTime: 04 Mar 2004 14:23:35.0357 (UTC) FILETIME=[475446D0:01C401F4] Hi JXrgen, Your point is well taken. However, I have seen this design a long time ago and I don't remember the details now. The program had been running in production for over 4 years without any problems. But there is always a chance...but don't you agree that since the MQCLOSE and EXEC CICS DEC are issued without anything else in between, there is an extremely small window in which another message may land on the trig queue. And if the message traffic is not too high this would be a very very rare occurance, which could be be handled by adjusting the TRIGINT of the queue manager... It was just a thought. Most importanlty: I think that I misundrstood the original question. I thought the question was "how can I tell (in a second program) that my triggerable CICS transaction has started". Just too little time to read messages and respond... Sorry... Regards, Ruzi --- Jxrgen Pedersen <[EMAIL PROTECTED]> wrote: > Hi Ruzi, > > It's quite dangerous to use ENQ/DEQ in conjunction > with WebSphere MQ/CICS > triggered applications (If you don't know the > consequences). > > It requires a good program design. The reason to get > me up of the chair is > the fact that you might lose triggers due to the > triggering rules. > > Let's have a small example, based on trigger-FIRST: > > EXEC CICS ENQ > rc <> 0 then exec cics return > > MQOPEN INPUT > > MQGET w. wait > do while rc=0 >process data >MQGET w. wait >End > MQCLOSE > EXEC CICS DEC > EXEC CICS RETURN > > This design will with 99% lose a trigger now and > then, the reason is you get > the trigger message (MQTM) when the queue depth > changes from 0->1, and the > queue is not open for input. > > Why ? > Because there is a time gab between I'm issuing the > MQCLOSE and EC DEQ. If > WebSphere MQ fires the trigger and a new program > gets started, it might > issue the EC ENQ before the first incarnation have > issed the EC DEC. > My second incarnation will therefore terminate after > it's EC ENQ, and > therefore we've lost the MQTM, and will wait until > the TRIGINT() expires, > which typicly never occurs the configurations I've > seen. > > Just my $0.02 ;o) > > Kind regards > Jxrgen > > PS: No hard feelings, I did spend about a month > tracking down such a > situation with a missing MQTM.
Re: MQ Triggering in CICS
Quite simple. until the next idea opens, running the CICS transaction under the auth of the issueing userid. This can require "some" design changes in both the applications and in the adopted CKTI. Just a case to emphesize. Just my $0.02 ;o) Kind regards Jxrgen From: "Heggie, Peter" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: MQ Triggering in CICS Thank you.. the two options help.. I agree that option 1 is better (better integrity and efficiency). I'm not sure we will change the IBM-delivered process, but I can see the advantage. Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Adiraju, Rao Sent: Wednesday, March 03, 2004 3:04 PM To: [EMAIL PROTECTED] Subject: Re: MQ Triggering in CICS Peter Yes - either you can customise CKTI transaction (the sample code is provided by the IBM as part of WebSphere MQ) and plug in your own logic to determine the user-id and issue a EXEC CICS START TRNID(ABCD) USERID() Or alternatively CKTI starts application ABCD by default. In ABCD transaction issues another start for actual application transaction with appropriate user-id similar to as shown above. My personal preference is for option-1. In option-2, ABCD transaction has to pass the trigger message to the next transaction and in the process it has all ready cleaned up the trigger message from initiation queue. If for some reason, second transaction doesn't start or fails half way through, then you would have lost one trigger message. Apart from that both are same. Cheers Rao _ From: Heggie, Peter [mailto:[EMAIL PROTECTED] Sent: 4 March 2004 2:12 AM To: [EMAIL PROTECTED] Subject: Re: MQ Triggering in CICS Is there a way to dynamically set the userid? As long as we are creating a SIL in CICS, is there a way for the SIL to specify the userid when issuing the EXEC CICS START ? Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Adiraju, Rao Sent: Tuesday, March 02, 2004 3:11 PM To: [EMAIL PROTECTED] Subject: Re: MQ Triggering in CICS Few more points to add: (I was quick in pressing the send button): As a design principle the CICS program always should issue a EXEC CICS RETRIEVE - 1) as Joe mentioned, to determine whether this transaction has triggered by CKTI (or one of the equivalents) and secondly to retrieve the trigger message. Trigger message gives you the information about which queue has resulted the trigger, trigger data (that is defined on the base queue), Process name, application data and user data that was put in the PROCESS definitions etc.. Usually the program should determine the queue that it is supposed to read from this trigger message (which is more reliable) rather than hard-coding / soft-coding in the program. Also, most of the times CKTI starts with a default user-id (or CICS userid) and hence your transaction also runs under the same user-id. So watch out for your security rules. Cheers Rao _ From: Adiraju, Rao Sent: 3 March 2004 8:59 AM To: 'MQSeries List' Subject: RE: MQ Triggering in CICS John Additional point to what Joe mentioned - yes, the default you look for is "CKTI" in Rtransid field. But check with your CICS guys as well - because it is possible one CICS region to have multiple initiators and/or different transaction codes (for various reasons). If that's case you need to check for those codes as well (or instead). 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 _ From: DeBlassio, Joe [mailto:[EMAIL PROTECTED] Sent: 3 March 2004 2:56 AM To: [EMAIL PROTECTED] Subject: Re: MQ Triggering in CICS 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 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 immedi
Re: MQ Triggering in CICS
Hi John, take a look here: http://www.mqseries.net/phpBB2/viewtopic.php?t=13836 Just ask the question in one forum please. Just my $0.02 ;o) Kind regards Jxrgen From: "Dawson, John" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: MQ Triggering in CICS Date: Mon, 1 Mar 2004 14:18:31 -0600 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 _ Fe alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk 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
Hi Ruzi, It's quite dangerous to use ENQ/DEQ in conjunction with WebSphere MQ/CICS triggered applications (If you don't know the consequences). It requires a good program design. The reason to get me up of the chair is the fact that you might lose triggers due to the triggering rules. Let's have a small example, based on trigger-FIRST: EXEC CICS ENQ rc <> 0 then exec cics return MQOPEN INPUT MQGET w. wait do while rc=0 process data MQGET w. wait End MQCLOSE EXEC CICS DEC EXEC CICS RETURN This design will with 99% lose a trigger now and then, the reason is you get the trigger message (MQTM) when the queue depth changes from 0->1, and the queue is not open for input. Why ? Because there is a time gab between I'm issuing the MQCLOSE and EC DEQ. If WebSphere MQ fires the trigger and a new program gets started, it might issue the EC ENQ before the first incarnation have issed the EC DEC. My second incarnation will therefore terminate after it's EC ENQ, and therefore we've lost the MQTM, and will wait until the TRIGINT() expires, which typicly never occurs the configurations I've seen. Just my $0.02 ;o) Kind regards Jxrgen PS: No hard feelings, I did spend about a month tracking down such a situation with a missing MQTM.. From: Ruzi R <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: MQ Triggering in CICS Date: Tue, 2 Mar 2004 04:18:14 -0800 By using EXEC CICS ENQ/DEQ. If the triggered progam A is ENQed, you will get a non-zero return code in the program B that issued the ENQ for Program A. You have to make sure that you DEQ the triggered program A when it is finished processing. Regards, Ruzi --- "Dawson, John" <[EMAIL PROTECTED]> wrote: > 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 _ Fe alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk 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: z/OS - WMQ CLUSTERs and CICSPLEX
Hi Carol, First, you have to have a CKTI running on each LPAR. One of my clients are running CICSPLEX and MQ Clustering, it have been a challange, to get the applications to work under these circumstances. It's not free to use MQ Clustering, any new technique requires some studies, experiments and Proof of Concepts before it's going into production. I've choosen to have one CICS running CKTI, and let i be a routing region (but only between CICS' on same LPAR), and have a bounch of AOR'S to do the actual work. It's the nature of MQ that CICS apps. (or other appls.) can't access messages on a remote, therefore we did the senario above. I'm dreaming of shared queues, and the real "pull" workload balancing, instead of the push model offered by MQ-clsuering. By the way why having more than one cluster on your mainframe ?? Security reason ? Just my $0.02 ;o) Kind regards Jxrgen www.mrmq.dk From: "Criscione, Carol (DIS)" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: z/OS - WMQ CLUSTERs and CICSPLEX I want WMQ Clusters and CICSPLEX AORs to communicate with each other across LPARs. WMQ Data Sharing is projected to be implemented after the Clusters function satisfactorily. I know INITPARM=(CSQCPARM='SN=Mxxx,TN=001,IQ=.CICxx.INITQ') is currently needed in SYSIN to associate a CICS region (MAS) to one WMQ subsystem. Do I need to consolidate the individual WMQ subsystems into one/more Clusters to span LPARs? Does the CSQCPARM='SN=Mxxx...' need to point to a Cluster name vs. an individual QMGR? Are there problems using Clustering workload balancing and CICSPLEX workload balancing at the same time? I researched the Clusters manual, the Redbook for Websphere MQ in a z/OS Parallel Sysplex Environment, and the WMQ Intercommunication manual. Any manuals that might be useful? Perhaps I missed something in them...Perhaps I need a break (SIGH)... ThanX! Carol Criscione State of Washington, DIS [EMAIL PROTECTED] 360.902.3051 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 _ Fe alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk 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: FW: CICS - MQSeries Puzzle
Hmm, 6000 milices. sounds to me like 6. seconds right ? just my $0.02 ;o) Kind regsrds joergen From: "Chase, John" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: FW: CICS - MQSeries Puzzle Date: Thu, 12 Feb 2004 11:12:10 -0600 Looks like we found something > -Original Message- > From: < "our MQ Guy" > > Sent: Thursday, February 12, 2004 10:35 AM > To: Chase, John > Subject: RE: CICS - MQSeries Puzzle > > > This was a great response to the question. I think I know > what's wrong... > > As it's stated below, we have trigger First set. The problem > is our trigger interval value is at it's highest value > 999,999,999 milliseconds - we would have had to wait a very > long time for a new trigger message. > > Why we were seeing this work not too long ago was because we > had a reasonable value for Trigger Interval (6000 > milliseconds = 10 minutes) which produced a new trigger > message. We lost the value of Trigger Interval when I had to > rebuild MQS2 on 1/8/04 to fix a problem. I have modified the > Trigger Interval back to 6000 milliseconds (it's global, not > queue specific). I will make sure we do not lose this value > in the future. > > This is a situation we would only notice if we were testing > (like we are) or if there was a real problem. It good to > have a clearer understanding of how this works. > > So this means the disable/enable transaction test should work > now. Let's give it another try. > _ Fe alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk 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: CICS - MQSeries Puzzle
Are CKTI running ?? 2nd. try flip NOTRIGGER/TRIGGER on the queue, this will generate a new trigger message (if the trigger monitor is running).' You can see the status of CKTI using CKQC transaction. Inspiration here: http://www.mrmq.dk/CICStrouble.htm Kind regards joergen From: "Chase, John" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: CICS - MQSeries Puzzle Date: Wed, 11 Feb 2004 10:40:46 -0600 Hi, All, Running CICS TS 2.2, MQ for z/OS 5.3.1 and z/OS 1.4 on a G6 machine. Application Development personnel are trying to "volume-test" new code and are using the technique of setting the triggered CICS transaction "Disabled", queueing up several messages on the relevant Application Queue, setting the triggered transaction "Enabled" again, then sending one more message to trigger the processing. This technique used to work, but now does not. Far as we can tell, no changes have been made to the system software since the last time the technique worked (i.e., no maintenance applied in the last 6 months or so). Current behavior is that when the triggered transaction is re-Enabled and another message sent, the new message just adds to the application queue and nothing triggers; INITQ queue depth stays at zero. Any ideas what to look for, and where? Holler if you need more information. TIA, -jc- -- ps. Hello, Christopher Frank. Long time no see. :-) 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 _ Fe alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk 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 Channel Exits
Hi Mike, you could take a look on BlockIP, because it's written for both Z/OS and the distributed world. The Security exit for Z/OS is written in Assembler, and I've tried to make it readable and the exit can also WTO some interesting MQXX info during execution http://home19.inet.tele.dk/m-invent/tips_and_tricks.htm#BlockIP%20security%20exit It's my hope this can help you started. Just my $0.02 ;o) Regards Joergen From: "Ward, Mike S" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: MQ Channel Exits Hello all, can someone tell me where I can find info for writing MQ channel exits for Z/OS MQ. Thanks. 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 _ Fe alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk 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: Channel Exits
Hi Wesley, You could take a look on my BlockIP2 exit, and get some inspiration from that implementation. Most of the time it's just small modifications needed to solve most of the requirements... http://home19.inet.tele.dk/m-invent/tips_and_tricks.htm#BlockIP2 Just my $0.02 ;o) Kind regards Jxrgen Need to handle the client channel security between a Win2000 client and Unix MQ Server. I can not seem to get setmqaut to understand how to connect a Windows authenticated user ID on a unix group/userid system. They are not the same even though the ID might be the same. For example:ntdomain\wesley vs just wesley in unix Wesley Shaw OJRP 10th Floor Work: 804 771 3589 (736-3589) Pager: 888 436 2805 Mobile 804 512 5260 Aby Philip <[EMAIL PROTECTED]To: [EMAIL PROTECTED] GROUP.COM> cc: Sent by: MQSeriesSubject: Re: Channel Exits List <[EMAIL PROTECTED] N.AC.AT> 01/14/2004 12:26 PM Please respond to MQSeries List Hi Wesley, What kind of exits are you looking at. I mean what sort of functionality? Aby Philip -Original Message- From: MQSeries List on behalf of Wesley Shaw Sent: Wed 1/14/2004 10:46 PM To: [EMAIL PROTECTED] Cc: Subject: Re: Channel Exits 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 _ Fe alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk 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: MCAUSER= blank
Hi Jan, the only time The Channel initiator is using the mqm or MUSRr_MQADMIN is when Remoteuserid field is empty. When you have a "normal" application it's running under your user, and therefore will the data be put (or getted) using the userid runnning the program. A JMS application will (normally) send a blank RemoteUserid, and the be putted using mqm or MUSR.. which can cause security challanges. Just my $0.02 ;o) Kind Regards Joergen From: jan mecallon <[EMAIL PROTECTED]> Subject: MCAUSER= blank I have a svrconn channel with MCAUSER blank (on Windows 2000 MQSeries 5.3).The messages I put on a queue with amqsputc has my userid (the one I signed on to my PC with). But aren't the messages supposed to be put with the "mqm" (or MUSR_MQADMIN) authority when MCAUSER is blank? thanks. Jan _ Fe alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk 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: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Hi Folks, I've just improved (I hope ;o)) BlockIP so it can block those bad useres as quoted below. Thanks to Roger for the nice words, this it what makes it all worth to keep WebSphere MQ secure or at least trying to... Currently BlockIP2 can help you block: mqm, MUSR_MQADMIN and blank uids, this means that a valid userid will pass the exit, I can't block a valid user, that's up to WebSphere MQ and the operating system. I have seen some exits arround calling Windows security, so uid/password will get verified... And it's improved to handle multi, patterns input, so you can specify more networks/addresses, it's still limited to the lenght of SCYDATA (32) pos. I'm planning a version where the specification is moved to a file.. You can find BlockIP2 here: http://home19.inet.tele.dk/m-invent/tips_and_tricks.htm#BlockIP2 I hope you'll enjoy it. I think the only solution to really stop this if the MCAUSER is to be blank is to have an exit on that channel to stop this ID. If I had a magic wand, I would make it so that SVRCONN channels with blank MCAUSERs would default the userID to "knucklehead" if the client did not present one (instead of defaulting to mqm). Also, a new channel attribute called BlockMQM which could be turned on to reject (with no further exits or efforts) any connections coming in as mqm or MUSR_MQADMIN. Just my $0.02 ;o) _ Best regards Jxrgen Pedersen IBM Certified WebSphere MQ * IBM Certified Solution Designer - WebSphere MQ V5.3 IBM Certified Solution Developer - WebSphere MQ V5.3 IBM Certified WebSphere MQ Integrator * _ Fe alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk 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
