Re: Client on NT Connect to Z/OS

2003-02-06 Thread Tom Dunlap


Linda,
I have provided some information below. I hope it helps out a
little. I am sure that others will share
their experiences.
"Kinnard.Linda" wrote:

Where can I get information regarding
the client connection to MQ on Z/OS? We'd like to know:
1. what's the recommended # of client
connections to one queue manager on the mainframe? Client will be
installed on Window NT, both client and the queue manager on mainframe
are running MQ 5.3.
The real concern is the activity of the applications handling the inbound
message traffic from the clients. The client will simply
put or get messages from the queues on z/OS. Each channel takes
memory (documented in WebSphere MQ manuals), but in
z/OS it is possible to support many thousands on connections.
I think the current limit is around 10 or 11 thousand.

2. what's the recommended method to
setup client connection, use MQSERVER variable, MQCHLLIB or MQCHLTAB?
The client will only connect to one queue manager.
MQSERVER is fine for a single connection, so long as the host name or IP
address are somewhat static. The use of channel
table definitions allows for multiples, but you could also maintain
a central copy and replicate to many workstations if you
are required to change hosts frequently. I believe the other
advantage is the ability to have channel level exits in support of
compression and encryption when using the table. Also, it would
allow you to implement channel level security on the
workstations if required.

3. are there any known problems/issues
that I should be aware of?
Distance. If the client must connect over a multiple segment network,
you may experience frequent "broken connections".
These will require special handling by the application and the administration
people. Connections across the Internet may
be prone to these outages since you may find paths have been dynamically
routed as you take the various hops across the net.
If you are dealing with an intranet behind your corporate walls, then
it is probably more stable then public networks so
this may not be an issue. The other main concern is that
WebSphere MQ itself can not be terminated gracefully (quiesced)
as long as client connections are still active. Should users
simply leave their workstations active active, the client may still
be running (if applications are left open).
There are several ways to deal with this depending on your requirements.
However, you could simply stop the queue manager
with MODE(FORCE). As long as other applications are not running
on z/OS, this may not cause problems. You will force
break the client connection and impact their application. If
the client is primarily for presentation of information, this should
not be an issue.

4. what's the recommended method to
secure the connection? We have Top Secret on the host. The
user's logon ID on the workstation is not the same on the host. They
are two different naming standard. What's the best way to grant user
authority to put/get messages from the queue?
The ideal way is to have logons the same. The next solution is to
define the workstation userids in Top Secret. The third choice
is to have a channel exit on WebSphere perform a translation of the
workstation userid to its synonym user under Top Secret. Still
another choice it to have the exit translate to a few "generic" userids
defined in Top Secret based upon the business application.
No matter how you look at it, there is a considerable amount of work
to do. The best way really depends upon your environment
and predictability of application naming standards.

Thanks in advance for your advise.
Linda Kinnard
Automobile Club of So.California

--
Regards,
Thomas Dunlap Chief Technology Officer
[EMAIL PROTECTED]
Themis, Inc. http://www.themisinc.com
1 (800) 756-3000



Re: Client on NT Connect to Z/OS

2003-02-06 Thread Matt Gurney

One other consideration.

MQSERVER variable will only allow a maximum message size of 4MB, we use MQCHLLIB for this reason, so the maximum message size can be specifed on the client channel definition.

Matt Gurney 









Tom Dunlap [EMAIL PROTECTED]
WORLDNET.ATT.NET
Sent by: MQSeries List [EMAIL PROTECTED]
06/02/2003 10:06
Please respond to MQSeries List






To:
[EMAIL PROTECTED]

cc:





Subject:
Re: Client on NT Connect to Z/OS 


Linda, 
I have provided some information below. I hope it helps out a little. I am sure that others will share 
their experiences. 
Kinnard.Linda wrote: 
 
Where can I get information regarding the client connection to MQ on Z/OS? We'd like to know: 
1. what's the recommended # of client connections to one queue manager on the mainframe? Client will be installed on Window NT, both client and the queue manager on mainframe are running MQ 5.3.
The real concern is the activity of the applications handling the inbound message traffic from the clients. The client will simply 
put or get messages from the queues on z/OS. Each channel takes memory (documented in WebSphere MQ manuals), but in 
z/OS it is possible to support many thousands on connections. I think the current limit is around 10 or 11 thousand. 
 
2. what's the recommended method to setup client connection, use MQSERVER variable, MQCHLLIB or MQCHLTAB? The client will only connect to one queue manager.
MQSERVER is fine for a single connection, so long as the host name or IP address are somewhat static. The use of channel 
table definitions allows for multiples, but you could also maintain a central copy and replicate to many workstations if you 
are required to change hosts frequently. I believe the other advantage is the ability to have channel level exits in support of 
compression and encryption when using the table. Also, it would allow you to implement channel level security on the 
workstations if required. 
 
3. are there any known problems/issues that I should be aware of?
Distance. If the client must connect over a multiple segment network, you may experience frequent broken connections. 
These will require special handling by the application and the administration people. Connections across the Internet may 
be prone to these outages since you may find paths have been dynamically routed as you take the various hops across the net. 
If you are dealing with an intranet behind your corporate walls, then it is probably more stable then public networks so 
this may not be an issue.  The other main concern is that WebSphere MQ itself can not be terminated gracefully (quiesced) 
as long as client connections are still active. Should users simply leave their workstations active active, the client may still 
be running (if applications are left open). 
There are several ways to deal with this depending on your requirements. However, you could simply stop the queue manager 
with MODE(FORCE). As long as other applications are not running on z/OS, this may not cause problems. You will force 
break the client connection and impact their application. If the client is primarily for presentation of information, this should 
not be an issue. 
 
4. what's the recommended method to secure the connection? We have Top Secret on the host. The user's logon ID on the workstation is not the same on the host. They are two different naming standard. What's the best way to grant user authority to put/get messages from the queue?
The ideal way is to have logons the same. The next solution is to define the workstation userids in Top Secret. The third choice 
is to have a channel exit on WebSphere perform a translation of the workstation userid to its synonym user under Top Secret. Still 
another choice it to have the exit translate to a few generic userids defined in Top Secret based upon the business application. 
No matter how you look at it, there is a considerable amount of work to do. The best way really depends upon your environment 
and predictability of application naming standards. 
 
Thanks in advance for your advise. 
Linda Kinnard 
Automobile Club of So.California
-- 
Regards, 
Thomas Dunlap  Chief Technology Officer  [EMAIL PROTECTED] 
Themis, Inc.  http://www.themisinc.com  1 (800) 756-3000 
 



Re: Client on NT Connect to Z/OS

2003-02-06 Thread Kinnard.Linda
Title: RE: Client on NT Connect to Z/OS






Thanks, Matt, Tom and Dennis for you advise.


Linda Kinnard
Automobile Club of So. California





Client on NT Connect to Z/OS

2003-02-05 Thread Kinnard.Linda
Title: Client on NT Connect to Z/OS






Where can I get information regarding the client connection to MQ on Z/OS? We'd like to know:


1. what's the recommended # of client connections to one queue manager on the mainframe? Client will be installed on Window NT, both client and the queue manager on mainframe are running MQ 5.3.

2. what's the recommended method to setup client connection, use MQSERVER variable, MQCHLLIB or MQCHLTAB? The client will only connect to one queue manager.

3. are there any known problems/issues that I should be aware of?


4. what's the recommended method to secure the connection? We have Top Secret on the host. The user's logon ID on the workstation is not the same on the host. They are two different naming standard. What's the best way to grant user authority to put/get messages from the queue?

Thanks in advance for your advise.


Linda Kinnard
Automobile Club of So.California





Re: Client on NT Connect to Z/OS

2003-02-05 Thread Miller, Dennis
1. Hard to say--what's good for the goose may not be good for the gander. I do believe 
there are mainframes supporting hundreds if not thousands of connections.

2. Channel tables may be a little more work to set up initially, but they can save 
your bacon down the road. 

3. Security is the biggest gotcha. Clients abandoning connections is probably the 
next. Code pages tend to surface as a common problem. And the merits of shared vrs. 
individual reply queues is an ongoing debate. 

4. You can grant get/put authority to the server connection, but that's like leaving 
your keys in the lock. You can grant authority to individual NT userid's, but they 
need to be defined in your Top Secret name space (hopefully your naming conventions 
are different enough that you won't have any collisions). Even then, you are trusting 
the NT userid and anyone who can add one to their local machine can easily masquerade 
as someone else. If security is of utmost importance, you will probably need to deploy 
exits, a third-party solution, or the relatively new SSL capabilities. 


 -Original Message-
 From: Kinnard.Linda [SMTP:[EMAIL PROTECTED]]
 Sent: Wednesday, February 05, 2003 5:25 PM
 To:   [EMAIL PROTECTED]
 Subject:   Client on NT Connect to Z/OS
 
 
 Where can I get information regarding the client connection to MQ on Z/OS?  We'd 
like to know: 
 
 1. what's the recommended # of client connections to one queue manager on the 
mainframe?  Client will be installed on Window NT, both client and the queue manager 
on mainframe are running MQ 5.3.
 
 2. what's the recommended method to setup client connection, use MQSERVER variable, 
MQCHLLIB or MQCHLTAB?  The client will only connect to one queue manager.
 
 3. are there any known problems/issues that I should be aware of? 
 
 4. what's the recommended method to secure the connection?  We have Top Secret on 
the host.  The user's logon ID on the workstation is not the same on the host.  They 
are two different naming standard.  What's the best way to grant user authority to 
put/get messages from the queue?
 
 Thanks in advance for your advise. 
 
 Linda Kinnard 
 Automobile Club of So.California 
 

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