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:
The real concern is the activity of the applications handling the inbound message traffic from the clients. The client will simplyWhere 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.
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.
MQSERVER is fine for a single connection, so long as the host name or IP address are somewhat static. The use of channel2. what's the recommended method to setup client connection, use MQSERVER variable, MQCHLLIB or MQCHLTAB? The client will only connect to one queue manager.
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.
Distance. If the client must connect over a multiple segment network, you may experience frequent "broken connections".3. are there any known problems/issues that I should be aware of?
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.
The ideal way is to have logons the same. The next solution is to define the workstation userids in Top Secret. The third choice4. 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?
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
