ECTED] Behalf Of Paul
Clarke
Sent: Tuesday, August 24, 2004 5:31 AM
To: [EMAIL PROTECTED]
Subject: Re: svrconn chl question(s)
T.Rob,
Ok, well first the good news.
AdoptMCA is equally applicable to runmqlsr and amqcrsta (and amqrmppa) for
that matter. Essentially, it doesn't make any differ
EMAIL PROTECTED]
Subject: Re: svrconn chl question(s)
T.Rob,
Ok, well first the good news.
AdoptMCA is equally applicable to runmqlsr and amqcrsta (and amqrmppa) for
that matter. Essentially, it doesn't make any difference where the channel
is running. We'll route it out and kill it.
Neutr
T.Rob,
Ok, well first the good news.
AdoptMCA is equally applicable to runmqlsr and amqcrsta (and amqrmppa) for
that matter. Essentially, it doesn't make any difference where the channel
is running. We'll route it out and kill it.
Neutral news
AdoptMCA doesn't apply to SVRCON
f clntconn/svrconn channels aren't supported, that would be
another reason :)
Good to spark some debate at least!
Darren.
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, August 23, 2004 7:15 PM
Subject: Re: svrconn chl question(s)
> T
Apologies: setting up my anti-spam program to accept emails from [EMAIL PROTECTED]
Thanks, Philip. I was just hoping that it would be stated explicitly somewhere. The
lack of SVRCONN support would seem to be by design due to the differences in
functionality between client and regular channels, while the lack of any mention of
RQSTR channels appears to be an omission or
"Wyatt, T Rob"
<[EMAIL PROTECTED]To: [EMAIL PROTECTED]
MERICA.COM> cc:
Sent by: MQSeries Subject: Re: svrconn chl question(s)
List
This is like a Moses suggestion. Go into the desert and find your Nirvana!!
From: "Wyatt, T Rob" <[EMAIL PROTECTED]>
Reply-To: MQSeries List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: svrconn chl question(s)
Date: Mon, 23 Aug 2004 12:14:35 -0400
Why not? As
Why not? Aside from the fact that SVRCONN and RQSTR channels are not available as
options to the AdoptNewMCA parm, the fact that you have several instances should not
be a problem as long as you set the AdoptNewMCACheck parameter. It causes a check
against the IP address (among other things
Thanks Bobbee. I neglected to mention that there are a number of apps
scattered around using the same svrconn channel, so I don't think
adoptnewmca is an option here.
Regards
Darren.
- Original Message -
From: "Robert Broderick" <[EMAIL PROTECTED]>
To: <[EMAIL PR
You might want to look at the ADOPTMCA parameter in the Queue Manager
configuration file.
bobbee
From: Darren Douch <[EMAIL PROTECTED]>
Reply-To: MQSeries List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: svrconn chl question(s)
Date: Wed, 18
Hi
I have an app that opens a client connection
channel to put some msgs. It then hangs around for a variable length of
time waiting for some non-MQ stuff to happen - the MQ channel is still up, but
the app is not putting or getting msgs. Eventually some more work comes
along and it gets
..
Pavel
"Benjamin F.
Zhou"To: [EMAIL PROTECTED]
<[EMAIL PROTECTED]cc:
USA.COM> Subject: Re: many svrconn instances,
as many
Pavel Tolkachev
cc:
Sent by: Subject: Re: many svrconn instances, as
many amqcrsta running
MQSeries List
<[EMAIL PROTECTED]
en.AC.AT>
quot;Wyatt, T. Rob"
<[EMAIL PROTECTED]To: [EMAIL PROTECTED]
MERICA.COM> cc:
Sent by: MQSeries Subject: Re: many svrconn
instances, as many amqcrsta running
versions of weblogic, and the latest service pack (Weblogics 6.1 SP6)
adresses these issues (they call close on the sessions).
end quote>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
--Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of
Benjamin F. Zhou
Sent: Tuesday, June 08, 2004 10:52 AM
To: [EMAIL PROTECTED]
Subject: many svrconn instances, as many amqcrsta running
Hi,
AIX, 5.1, MQ5.3, csd06: we have JMS clients connecting to MQ via client
mode.
each test, I see large number of the svrconn channel and the
same number of amqcrsta running against the same qmgr. There's no sign they
will ever come down, although I set keepAlive=yes and tcp_keepintvl and
tcp_keepidle to 10 seconds.
What else can be done to bring down these orphaned processe
Paul, thanks very much for the explanation.
Jan
--- Paul Clarke <[EMAIL PROTECTED]> wrote:
> >Can someone settle an argument? The question is
> >whether to use one or more svrconn channels with a
> big
> >number of MQClients. Both the Queue manager and
> and
>
Each connection will run in its own thread in an amqrmppa process,
so they won't get in each other's way unless there's contention for
exclusive access to a queue.
There's no any specific benefit in having some clients connect on
one channel name, and some on another unless they have different
acc
>Can someone settle an argument? The question is
>whether to use one or more svrconn channels with a big
>number of MQClients. Both the Queue manager and and
>MQClients run on Win 2000 (MQ 5.3). Here is the
>scenario: I have 1000 Mqclients all using the same
>svrconn cha
Can someone settle an argument? The question is
whether to use one or more svrconn channels with a big
number of MQClients. Both the Queue manager and and
MQClients run on Win 2000 (MQ 5.3). Here is the
scenario: I have 1000 Mqclients all using the same
svrconn channel with the same
ode 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
arch 2004 9:44 AM
To: [EMAIL PROTECTED]
Subject: 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={*|use
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 at
Michael, thank you for your clear explanation. That is
exactly what I was trying to say ;).
Ruzi
--- Michael Dag <[EMAIL PROTECTED]> wrote:
> Dennis,
> I think the whole point is when you leave the
> MCAUSER of the SVRCONN blank,
> any (java) client can come in and pretend to
So when all's said and done:
user1 has the mcauser = user1
user2 has the mcauser = user2
...
userb has the mcauser = userb
userc has the mcauser = userc
Which is the standard behavior when MCAUSER is blank. You only need 1
SVRCONN and no exits.
Re
Dennis,
I think the whole point is when you leave the MCAUSER of the SVRCONN blank,
any (java) client can come in and pretend to be mqm.
One of the features of BlockIP2 is that it can block 'unidentified' users,
mqm, MUSR_ADMIN etc and on top of that use a 'list' of au
> From what I can tell, both kinds of users can still
> connect. And once
> connected, either kind of user can do exactly the
> same things as had
> they connected on the other SVRCONN. The only thing
> you've done is
> added front-end complexity for choosing the rig
Maybe I'm misunderstaning your goal, but I don't see what BLOCKIP2
accomplishes if you leave MCAUSER blank. Suppose you want two levels of
access: limited and unlimited. So you set up an SVRCONN for each,
leaving MCAUSER blank on both. Then, you block limited users (or IP
addresses) f
me hear your oppinion on this issue.
> >
> > Just my $0.02 ;o)
> >
> > Kind regards
> > Jxrgen
> > www.MrMQ.dk - the home of BlockIP
> >
> >
> >
> > >From: Ruzi R <[EMAIL PROTECTED]>
> > >Reply-To: MQSeries List <[EMAIL PROTECTED
;[EMAIL PROTECTED]>
> >Reply-To: MQSeries List <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: Re: Many Client connections - how many
> svrconn channels?
> >Date: Mon, 15 Mar 2004 04:49:35 -0800
> >
> >Just to make a correction to my previous note
>
Just to make a correction to my previous note before
anyone jumps in:
The reason why I want to leave the MCAUSER blank is so
that I can tell who put the message on the
the queue. Status of Svrconn does not show the userid
but the connectin name, which is OK.
Thanks,
Ruzi
--- Ruzi R <[EM
AIL PROTECTED]>
Reply-To: MQSeries List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: Many Client connections - how many svrconn channels?
Date: Mon, 15 Mar 2004 04:49:35 -0800
Just to make a correction to my previous note before
anyone jumps in:
I would want to leave the MCAUSER blank s
Just to make a correction to my previous note before
anyone jumps in:
I would want to leave the MCAUSER blank so that
I can tell who put the message onsee whothe message on
the queue. Svrconn does not show the userid but the
connectin name.
Thanks,
Ruzi
things like inquiring the status of the
Just to make a correction to my previous note before
anyone jumps in:
I would want to leave the MCAUSER blank so that
I can tell who put the message onsee whothe message on
the queue. Svrconn does not show the userid but the
connectin name.
Thanks,
Ruzi
--- Ruzi R <[EMAIL PROTECTED]>
> But if you've got relatively few access levels, you
> can define a svrconn
> with appropriate MCAUSER for each and then restrict
> which users are
> permitted to use which connections from the exit.
Thanks Dennis. However, I think it would be safe and
maybe even better to
> But if you've got relatively few access levels, you
> can define a svrconn
> with appropriate MCAUSER for each and then restrict
> which users are
> permitted to use which connections from the exit.
Thanks Dennis. However, I think it would be safe and
maybe better to
I took a look at the BLOCKIP2 URL provided by SID. Very neat. I did
notice that BLOCKIP2 only supports setting the MCAUSER on SSL channels.
But if you've got relatively few access levels, you can define a svrconn
with appropriate MCAUSER for each and then restrict which users are
permitted t
ections will be made.
Most (if not all) of these clients will have the same
authority. I am thinking of leaving the MCAUSER blank
on an svrconn and specify the userids in a file to be
used by the security exit. I think this would do what
I want to acheive. Maybe I could secure this file by
giving ac
connections - how many svrconn channels -
BlockIP 2
G'Day Dennis,
Here is a link to BlockIP2, it doesn't appear in google because it looks
like it is not an absolute path in the URL and hence not findable by
page scrapping.
http://www.mrmq.dk/index.htm?tips_and_tricks.htm#Bloc
is [mailto:[EMAIL PROTECTED]
Sent: Friday, 12 March 2004 8:38 AM
To: [EMAIL PROTECTED]
Subject: Re: Many Client connections - how many svrconn channels?
I don't see the point of dedicating svrconn's to a specific number of
clients. Dedicating a svrconn a specific MCAUSER and sharing it amo
I don't see the point of dedicating svrconn's to a specific number of
clients. Dedicating a svrconn a specific MCAUSER and sharing it among
many clients is a different story. Seems you would only need one
MCAUSER+srvrconn for each authority level.
But to gain a semblence of security f
SVRCONN
channels with the MCUSER set to their respective
userids and giving each userid a limited access. I
have started using BlockIP2 as well. I have brought
up the use of SSL but the company is reluctant to do
that (I don t know about all the concerns surrounding
the issue probably
t; <[EMAIL PROTECTED]To:
> [EMAIL PROTECTED]
> E.SE>cc:
> Sent by: MQSeries
> Subject: More than 1000 svrconn processes started
> List
>
E.SE>cc:
Sent by: MQSeriesSubject: More than 1000 svrconn
processes started
List
<[EMAIL PROTECTED]
n.AC.AT>
01/26/2004 08:16
We implemented a lower KeepAlive value, both on our MQ server AIX
machine and on our PeopleSoft web server machines (where 95% of our
svrconn connections are coming from), and that significantly lowered the
number of connections. The web server is WebLogic 6.1, MQ is v5.3.
Peter Heggie
Hi,
Can anyone clarify this issue?
We are running MQ on an iSeris with WebSphere app srv.
The app srv use client connection to connect to the
qmgr. Now and then the system get full on disk and an
ipl is required to free the disk space again. At the
same time a lot of svrconn channel processes is
Thanks.. At least I've got it set for the regular channels..
Peter Heggie
-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Bill
Anderson
Sent: Friday, January 09, 2004 11:31 AM
To: [EMAIL PROTECTED]
Subject: Re: More on 'orphaned' SVRCONN conn
/
Christopher Frank
<[EMAIL PROTECTED]To: [EMAIL PROTECTED]
COM> cc:
Sent by: MQSeriesSubject: Re: More on 'orphaned'
SVRCONN connections
ubject: Re: More on 'orphaned' SVRCONN connections
Hi Peter,
>>>Last night I made the change to include TCP: KeepAlive=Yes and
>>>CHANNELS: AdoptNewMCA=ALL/Check=QM,ADDRESS,NAME and recycled the
>>>Queue Manager.. (FYI the manual says you can use 'ALL'
Hi Peter,
>>>Last night I made the change to include TCP: KeepAlive=Yes
>>>and CHANNELS: AdoptNewMCA=ALL/Check=QM,ADDRESS,NAME and
>>>recycled the Queue Manager.. (FYI the manual says you can
>>>use 'ALL' for the AdoptNewMCACheck parm, but MQ does not
>>>like it). These parameters were not used pr
Last night I made the change to include TCP: KeepAlive=Yes and CHANNELS:
AdoptNewMCA=ALL/Check=QM,ADDRESS,NAME and recycled the Queue Manager..
(FYI the manual says you can use 'ALL' for the AdoptNewMCACheck parm,
but MQ does not like it). These parameters were not used previously.
This morning I
tems.co.za
-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Larry
Murray
Sent: 01 December 2003 20:52
To: [EMAIL PROTECTED]
Subject: svrconn
Good afternoon all,
Running MQ v2.1 on OS/390. Currently the chin has one chlsvrconn. All
traffic from the
clients to
You can use the STOP/START channel commands in a JCL
using the CSQUTIL program. The JCL would look like
this:
//MQUTIL JOB (),'CSQUTIL JOB',MSGCLASS=T
//STEP1 EXEC PGM=CSQUTIL,PARM='YourQmgrName'
//STEPLIB DD DISP=SHR,DSN=qual.SCSQANLE
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
COMMAND DDNAME(CMDINP)
//C
Good afternoon all,
Running MQ v2.1 on OS/390. Currently the chin has one chlsvrconn. All
traffic from the
clients to Mq on the mainframe travels this path. I would like to add an
additional chlsvrconn.
Also, would like to be able to start and stop this conn via a batch
command. The details ar
#x27;t use MQExplorer over SYSTEM.ADMIN.SVRCONN that had a blank MCAUSER,
and their MQ app couldn't connect over a regular SVRCONN channel with a
blank MCAUSER.
But, for the users that were Admins on their PCs but were not defined
locally on this server (but did show all authority), the access was
-Original Message-
From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 12, 2003 4:32 PM
To: [EMAIL PROTECTED]
Subject: Re: 2035 on SVRCONN channel for UserID in mqm group
T.Rob, you wrote
"you might have to delete and redefine your auths after the accou
To: [EMAIL PROTECTED]
Subject: Re: 2035 on SVRCONN channel for UserID in mqm group
Peter,
You've hit upon the problem. When you see the ID in the logs, it is not the
fully-qualified ID. The domain/ID combination flowed over your SVRCONN is
not the same as the domain/ID presented by
Peter,
You've hit upon the problem. When you see the ID in the logs, it is not the
fully-qualified ID. The domain/ID combination flowed over your SVRCONN is
not the same as the domain/ID presented by the MCAUSER for whatever reason.
If the two IDs are locally-defined IDs on each server,
Title: RE: 2035 on SVRCONN channel for UserID in mqm group
Peter,
are these rb9 users local or domain users (I assume you are on windows ... I see E:\>)
rb9 on machine1 (if this is where the Qmgr is) is not always rb9 on machine2
dspmqaut -m HIGIDGL1 -t qmgr -p [EMAIL PROTEC
?
-Original Message-
From: Rick Tsujimoto [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 12, 2003 9:30 AM
To: [EMAIL PROTECTED]
Subject: Re: 2035 on SVRCONN channel for UserID in mqm group
Did you try a security REFRESH?
"Potkay, Peter M
: 2035 on SVRCONN channel for UserID in mqm group
rb9 is in the mqm group on the server
dspmqaut shows the following:
E:\>dspmqaut -m HIGIDGL1 -t qmgr -p rb9
Entity rb9 has the following authorizations for object HIGIDGL1:
inq
set
connect
alt
Did you try a security REFRESH?
"Potkay, Peter M
(PLC, IT)" To: [EMAIL PROTECTED]
<[EMAIL PROTECTED] cc:
RTFORD.COM> Subject: 2035 on SVR
dsp
setid
setall
The MCAUSER field of the SVRCONN channel is blank.
The error log shows this:
11/12/2003 08:42:16
AMQ8077: Entity 'rb9' has insufficient authority to access object
'HIGIDGL1'.
EXPLANATION:
The specified entity is not authorized to access the require
rson [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 23, 2003 12:10 PM
> To: [EMAIL PROTECTED]
> Subject: Re: To many SVRCONN Connections on
> WebSphere MQ V5.3
>
> I did forget to mention this is on AIX 3.3 /
> WebSphere MQ V5.3.
>
> And that is half of my problem, I d
o determine the cause of the failure.
- amqrmrsa.c : 467
***
What would this indicate? I am guessing there is maybe some client app(s)
out there trying to connect to this QM over this channel (HIGIDGD1.CLIENT is
a SVRCONN) over and over so fast the QM can't ca
Title: RE: To many SVRCONN Connections on WebSphere MQ V5.3
You should also check the server side setting since the default is sometimes high (On Windows the default is something like 2 hours). I'm not that familiar with AIX but the following might help. www.sybase.com/detail?i
;[EMAIL PROTECTED]To: [EMAIL PROTECTED]
>cc:
Sent by: MQSeriesSubject: Re: To many SVRCONN
Connections on WebSphere MQ V5.3
List
<[EM
To: [EMAIL PROTECTED]
>cc:
Sent by: MQSeriesSubject: Re: To many SVRCONN
Connections on WebSphere MQ V5.3
List
<[EMAIL PROTECTED]
N.AC.AT>
-
Van: MQSeries List [mailto:[EMAIL PROTECTED] Bill Anderson
Verzonden: donderdag 23 oktober 2003 19:25
Aan: [EMAIL PROTECTED]
Onderwerp: To many SVRCONN Connections on WebSphere MQ V5.3
On several occasions, we have had customers making 30 + (one did over 200)
connections to a server connection ch
23, 2003 1:25 PM
To: [EMAIL PROTECTED]
Subject: To many SVRCONN Connections on WebSphere MQ V5.3
On several occasions, we have had customers making 30 + (one did over 200)
connections to a server connection channel. Each customer has a dedicated
channel used only by them. Almost all of the
ECTED]
Sent: Thursday, October 23, 2003 10:25 AM
To: [EMAIL PROTECTED]
Subject: To many SVRCONN Connections on WebSphere MQ V5.3
On several occasions, we have had customers making 30 + (one did over 200)
connections to a server connection channel. Each customer has a dedicated
channel used only by
On several occasions, we have had customers making 30 + (one did over 200)
connections to a server connection channel. Each customer has a dedicated
channel used only by them. Almost all of the connections have very low
message counts (like 4 or 6) that do not change. Only one or two have
significa
s.
If you stop the channel with the force option, all the instances should end.
-Original Message-
From: Bill Anderson [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 22, 2003 4:47 PM
To: [EMAIL PROTECTED]
Subject: SVRCONN channel status
I have a SVRCONN channel that has 23 or so c
I have a SVRCONN channel that has 23 or so connections from the same IP
address. When I look at the status, about have of them are "stopping". They
never completely stop. All of the connections to my queue manager are from
external customers, so I have little or no access to ther
SVRCONN
is showing the connections running status with the MDBs.I did force stop and
start, then SVRCONN is released all the connections with MDBs. I am not
understanding why SVRCONN is not releasing the connections with out stopping.!
I have specified
INITIAL_CONTEXT_FACTORY
ly or not.
OK, here is my setup.
Local QM with SVRCONN channel called POTKAY1.CLIENT. I start up 2 instances
of the WatchQ support pac, which each client connect into my QM. If I do a
status on this channel now via runmqsc, MO71 or MQExplorer, I see the 2
instances of the ch
Hi All,
I'm looking into a problem involving long waits on a SVRCONN channel. I'm
comparing a TCP packet trace and an MQ trace of the channel process and I
have a question about how the process is initiated.
In the packet trace I see the socket open and the first few MQ exchanges.
Th
79 matches
Mail list logo
