Re: MQClient authorization error (2035)

2003-06-04 Thread John Scott
Rebecca may be on the right track. Check that the NIS account is in an
authorised group on the server. I would also ensure that the account number
(use the command id on both servers) and group numbers are the same on
both servers.

Regards
John.

-Original Message-
From: Sony Varghese [mailto:[EMAIL PROTECTED]
Sent: 02 June 2003 15:51
To: [EMAIL PROTECTED]
Subject: Re: MQClient authorization error (2035)


Hi John,

My userid is a NIS userid id ..
The MCAUSER is set to blank ..


Regards
Sony


-Original Message-
From: John Scott [mailto:[EMAIL PROTECTED]
Sent: 02 June 2003 17:18
To: [EMAIL PROTECTED]
Subject: Re: MQClient authorization error (2035)


Are you logging on using a different user name from the client?

What is the MCAUSER set to for the server connection channel the client is
using?

Regards
John.

-Original Message-
From: Sony Varghese [mailto:[EMAIL PROTECTED]
Sent: 02 June 2003 14:58
To: [EMAIL PROTECTED]
Subject: MQClient authorization error (2035)


Hi ,

I'm getting a 2035 error when I run amqsputc (MQClient) on a UNIX box. If I
log in to the UNIX box where MQSeries is installed and run amqsput
(MQServer), the program works fine.

If it works fine on the server, shouldn't it also work fine on the client?
Any idea why this happens?

Do reply

Regards
Sony

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


**

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 confidential, and is intended exclusively for the addressee.
The views expressed may not be official policy, but the personal views of
the originator. If you are not the intended addressee, any disclosure,
reproduction, distribution, dissemination or use of this communication is
not authorised. If you have received this message in error, please advise
the sender by using your reply facility in your e-mail software. All
messages sent and received by Argos Ltd are monitored for virus, high risk
file extensions, and inappropriate content. As a result users should be
aware that mail maybe accessed.

**

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


mqsi version

2003-06-04 Thread Sony Varghese
Hi all,

How do you find the mqsi version on an aix box? including the CSDs?

i've tried lslpp -l | grep wmqi


but is there any standard command like mqver for mqseries?

Thanks
VJ.

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: MQClient thread-safe?

2003-06-04 Thread Paul Clarke
To all,
My apologies I had read about shared connections in V5.3 and promptly
forgot them again so yes you now can coordinate units of work across
multiple threads.

Tim,

I don't wish to be picky here but I didn't mention coordination. A shared
connection can be used across multiple threads but there is still only one
unit of work associated with the connection.

Cheers,
P.


Paul G Clarke
WebSphere MQ Development
IBM Hursley

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: Client and server configuration

2003-06-04 Thread Potkay, Peter M (PLC, IT)



Yes.

But if
you install the MQServer onto your machine, then you must install the MQClient
from the CD. You cannot use the MQClient that you download as a Support
Pack.

If you
install ONLY MQClient on a PC, then you can use either the client from the CD or
the client from the support pack download page.




  -Original Message-From: Teresa Cheung
  [mailto:[EMAIL PROTECTED]Sent: Monday, June 02, 2003 4:56
  PMTo: [EMAIL PROTECTED]Subject: Client and server
  configuration
  Can both have MQSeries client and seversoftware installedon
  the sameoperating system?I am running Windows 2000. 
  
  Thanks
  TC
  
  
  Do you Yahoo!?Free online
  calendar with sync to Outlook(TM).

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.




Re: Client and server configuration

2003-06-04 Thread Robert Broderick
YUP


From: Teresa Cheung [EMAIL PROTECTED]
Reply-To: MQSeries List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Client and server configuration
Date: Mon, 2 Jun 2003 13:56:21 -0700
Can both have MQSeries client and sever software installed on the same
operating system? I am running Windows 2000 .
Thanks
TC
-
Do you Yahoo!?
Free online calendar with sync to Outlook(TM).
_
Add photos to your e-mail 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


Re: Production MQ abends - 2019 / 2195 / 2079 and more.

2003-06-04 Thread Stefan Sievert
Michelle,
is it possible that a new application went into production three days ago
that (by accident) writes directly to the initiation queue
MQPB.INITQ.PB.PCCIC?
Also, the RACF message shows a queue name of MVB1.MQPB.INITQ.PB.PCCIC, which
is a different name, but that might be OK.
Did any RACF definitions change or is the later INITQ a new one and the RACF
permissions for your started task userID(ZMQMAB1) have not been properly
set?
Just guessing here, it's hard to say if the error messages you see are
related.
Stefan

From: Michelle Russell [EMAIL PROTECTED]
Reply-To: MQSeries List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Production MQ abends - 2019 / 2195 / 2079 and more.
Date: Tue, 3 Jun 2003 10:00:43 +0100
Hi all,

MQ V2.1.  OS/390

The last two mornings at exactly the same time we have experienced an issue
with the connections between MQSeries and a production CICS region.
The errors that are being seen in the CICS log are:
+CSQC106D PCCIC CSQCTASK MQGET failure. CKTI will end. MQCC=2 MQRC=2019
(Object Handle)
+CSQC110I PCCIC CSQCTASK Queue name = MQPB.INITQ.PB.PCCIC
+KAD6500 ERROR ON MQCLOSE QAKE.GET.VALIDATE.CUSTOMER.DETAILS.REQUEST
+KAD6500 ERROR ON MQCLOSE REASON =  2019
+CSQC111D PCCIC CSQCTASK CKTI has read a trigger message with an incorrect
length of 297
As well as the above we are getting 2195 (Unexpected error) and
2079(Truncated msg) errors.
In addition to the above the CICS and MQ logs are showing RACF messages:

06.53.41 STC04301  ICH408I JOB(MVB1MSTR) STEP(MVB1MSTR)---
This should be USER (ZMQMAB1) GROUP ([EMAIL PROTECTED])
 MVB1.MQPB.INITQ.PB.PCCIC CL(MQQUEUE )
 INSUFFICIENT ACCESS AUTHORITY
 FROM MVB1.MQPB.INITQ.** (G)
 ACCESS INTENT(UPDATE )  ACCESS ALLOWED(NONE   )
Has anyone experienced any of the above ?

Any help would be much appreciated

Regards
Michelle




This email and any attachments are confidential. They may
contain privileged information and are intended for the
named addressee(s) only. They must not be distributed
without our consent. If you are not the intended recipient,
please notify us immediately and do not disclose, distribute
or retain this email or any part of it. Unless expressly stated,
opinions in this email are those of the individual sender
and not N Brown Group plc or any of its subsidiaries.
You must take full responsibility for virus checking this
email and any attachments.
Please note that the content of this email or any of its
attachments may contain data that falls within the scope
of the Data Protection Acts and that you must ensure that
any handling or processing of such data by you is fully
compliant with the terms and provisions of the Data
Protection Act 1984 and 1998.
N Brown Group plc. Registered office: 53 Dale Street,
Manchester, M60 6ES. Registered in England No.814103.
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


Re: Production MQ abends - 2019 / 2195 / 2079 and more.

2003-06-04 Thread Stephen Price
has someone deleted the STARTED profile for this region ?  or perhaps
changed the jcl that would cause it to select what looks like a default
STARTED profile.

Stephen Price
Advisory IT Specialist;
Database and Middleware
UK SSO North Region
Strategic Outsourcing, IBM Global Services
Manchester, Mailpoint 2JH

Tel +44(0)161 905 6675; Internal 626675
e-mail [EMAIL PROTECTED]


|-+---
| |   Michelle Russell|
| |   [EMAIL PROTECTED]|
| |   IAMS.CO.UK |
| |   Sent by: MQSeries List  |
| |   [EMAIL PROTECTED]|
| |  |
| |   |
| |   |
| |   03-06-03 10:00  |
| |   Please respond to   |
| |   MQSeries List   |
| |   |
|-+---
  
-|
  |
 |
  |   To:   [EMAIL PROTECTED]  
   |
  |   cc:  
 |
  |   Subject:  Production MQ abends - 2019 / 2195 / 2079 and more.
 |
  |
 |
  
-|




Hi all,

MQ V2.1.  OS/390

The last two mornings at exactly the same time we have experienced an issue
with the connections between MQSeries and a production CICS region.
The errors that are being seen in the CICS log are:

+CSQC106D PCCIC CSQCTASK MQGET failure. CKTI will end. MQCC=2 MQRC=2019
(Object Handle)
+CSQC110I PCCIC CSQCTASK Queue name = MQPB.INITQ.PB.PCCIC

+KAD6500 ERROR ON MQCLOSE QAKE.GET.VALIDATE.CUSTOMER.DETAILS.REQUEST
+KAD6500 ERROR ON MQCLOSE REASON =  2019

+CSQC111D PCCIC CSQCTASK CKTI has read a trigger message with an incorrect
length of 297

As well as the above we are getting 2195 (Unexpected error) and
2079(Truncated msg) errors.

In addition to the above the CICS and MQ logs are showing RACF messages:

06.53.41 STC04301  ICH408I JOB(MVB1MSTR) STEP(MVB1MSTR)---
 This should be USER (ZMQMAB1) GROUP ([EMAIL PROTECTED])
 MVB1.MQPB.INITQ.PB.PCCIC CL(MQQUEUE )
 INSUFFICIENT ACCESS AUTHORITY
 FROM MVB1.MQPB.INITQ.** (G)
 ACCESS INTENT(UPDATE )  ACCESS ALLOWED(NONE   )

Has anyone experienced any of the above ?

Any help would be much appreciated

Regards
Michelle






This email and any attachments are confidential. They may
contain privileged information and are intended for the
named addressee(s) only. They must not be distributed
without our consent. If you are not the intended recipient,
please notify us immediately and do not disclose, distribute
or retain this email or any part of it. Unless expressly stated,
opinions in this email are those of the individual sender
and not N Brown Group plc or any of its subsidiaries.
You must take full responsibility for virus checking this
email and any attachments.

Please note that the content of this email or any of its
attachments may contain data that falls within the scope
of the Data Protection Acts and that you must ensure that
any handling or processing of such data by you is fully
compliant with the terms and provisions of the Data
Protection Act 1984 and 1998.

N Brown Group plc. Registered office: 53 Dale Street,
Manchester, M60 6ES. Registered in England No.814103.

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: mqsi version

2003-06-04 Thread Robert Broderick
There sould be a file call MEMO.ptf in the install directory.


From: Sony Varghese [EMAIL PROTECTED]
Reply-To: MQSeries List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: mqsi version
Date: Tue, 3 Jun 2003 11:51:05 +0100
Hi all,

How do you find the mqsi version on an aix box? including the CSDs?

i've tried lslpp -l | grep wmqi

but is there any standard command like mqver for mqseries?

Thanks
VJ.
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
_
Help STOP SPAM with the new MSN 8 and get 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


Re: Client and server configuration

2003-06-04 Thread Francois Van der Merwe1
Just to make this a little bit more clear.   You MUST install the client
that is on the SERVER CD.   When you start installation from the server CD,
one of the options is to also install the client code - use that.

Francois van der Merwe
Senior IT Specialist: IBM MQSeries Certified Specialist, Solutions Expert 
Developer



   
  
  Potkay, Peter M 
  
  (PLC, IT) To:   [EMAIL PROTECTED]   

  [EMAIL PROTECTED]cc:
 
  RTFORD.COMSubject:  Re: Client and server 
configuration   
  Sent by: MQSeries
  
  List 
  
  [EMAIL PROTECTED]   
 
  AC.AT   
  
   
  
   
  
  03/06/2003 14:02 
  
  Please respond to
  
  MQSeries List
  
   
  





Yes.

But if you install the MQServer onto your machine, then you must install
the MQClient from the CD. You cannot use the MQClient that you download as
a Support Pack.

If you install ONLY MQClient on a PC, then you can use either the client
from the CD or the client from the support pack download page.



-Original Message-
From: Teresa Cheung [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2003 4:56 PM
To: [EMAIL PROTECTED]
Subject: Client and server configuration


Can both have MQSeries client and sever software installed on the
same operating system? I am running Windows 2000 .

Thanks
TC


Do you Yahoo!?
Free online calendar with sync to Outlook(TM).

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


Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages

2003-06-04 Thread Potkay, Peter M (PLC, IT)
Well, I think I have proved what everyone was saying. A channel speed of
Normal is what is getting me here. Neil Casey and Brian McCarty provided the
exact explanation as to why: non persistent messages sent over a normal
speed channel cause persistent message to be written to the channel sync
queue, which requires disk. I set up some tests in my lab environment. Here
are the results.



*
Server1: SpokeQM1, Win2000 SP2, MQ 5.3 CSD03
RemoteQ called FinalQ that points to FinalQ on SpokeQM2, via transmit queue
HubQM1

Server2: HubQM1, Win2000 SP2, MQ 5.2.1 CSD05
QMAlias called SpokeQM2, which sends messages to transmit queue
SpokeQM2.XMITQ

Server3: SpokeQM2, Win2000 SP2, MQ 5.2.1 CSD05
Local queue called FinalQ

***


Test #1: Channel SpokeQM1.HubQM1 has a speed of NORMAL. Start putting 1K
Non-Persistent(NP) messages every 250 milliseconds to the remote queue def
on SpokeQM1.
Results #1: As expected, constant disk writes on the server that houses
HubQM1.


Test #2: Channel SpokeQM1.HubQM1 has a speed of FAST. Start putting 1K NP
messages every 250 milliseconds to the remote queue def on SpokeQM1.
Results #2: As expected, no disk activity at all on the server that houses
HubQM1. Actually, there was disk activity when the channel started/ended,
but for the whole duration while the channel was running, no I/O.


Test #3: Channel SpokeQM1.HubQM1 has a speed of FAST. Start putting 70,000
byte NP messages every 250 milliseconds to the remote queue def on SpokeQM1.
Results #3: No disk activity at all on the server that houses HubQM1. ???
These messages are larger than the 64K queue buffer, so why are the messages
flying thru the hub with no I/O? I am happy with these results, just that it
is unexpected. Could it be that the Sending MCA to SpokeQM2 has the XMIT
queue open ready for messages, with an outstanding GET? But I thought this
was a feature new to 5.3 only.


Test #4: Channel SpokeQM1.HubQM1 has a speed of FAST. Start putting 5000
byte NP messages every 250 milliseconds to the remote queue def on SpokeQM1.
Every 45 seconds or so, I send over a Persistent 5000 byte message on the
same channel.
Results #4: As expected, no disk activity at all on the server that houses
HubQM1, except every 45 seconds when the P message comes over.


Test #5: Channel SpokeQM1.HubQM1 has a speed of FAST. Start putting 5000
byte NP messages every 250 milliseconds to the remote queue def on SpokeQM1.
As the messages are flowing, yank the 2 cables that connect this server to
the SAN (Veritas was disabled so it would not try and fail over).
Results #5: No effect at all. Even though the server had no hard disk, these
messages still kept flying thru the server as if nothing at all was wrong.


Test #6: Channel SpokeQM1.HubQM1 has a speed of FAST. Start putting 5000
byte NP messages every 250 milliseconds to the remote queue def on SpokeQM1.
At the same time, start putting 5000 byte P messages over the same channel.
As the messages are flowing, yank the 2 cables that connect this server to
the SAN (Veritas was disabled so it would not try and fail over).
Results #6: Everything backs up. Both NP and P messages are backed up in the
XMITQ on SPOKEQM1. As soon as the cables are plugged back in, the messages
start flowing again.



Test #7: Channel SpokeQM1.HubQM1 has a speed of FAST. Start putting 5000
byte NP messages every 250 milliseconds to the remote queue def on SpokeQM1.
At the same time, start putting 5000 byte P messages over A DIFFERENT
CHANNEL between SpokeQM1 and HubQM1. As the messages are flowing, yank the 2
cables that connect this server to the SAN (Veritas was disabled so it would
not try and fail over).

Results #7: Everything backs up on the channel that was dealing with P
messages. The channel that had only NP messages was not effected at all. As
soon as the cables are plugged back in, the messages start flowing again on
the secondary channel. The primary channel that had NP messages never
blinked.




So now I am kinda stuck. Back in the production environment, what to do? I
can set the channel between SpokeQM1 and the HUB to fast, as it is a
dedicated channel for this application anyway. I'll just let them know of
the possibility (very remote) that the channel may lose their message. SAN
blips are a lot more frequent than MQ losing NP messages over a FAST
channel.

But what do I do with the CLUSRCVR channels? They are a shared resource for
the whole company. Do I let this one application dictate that these channels
get switched to FAST, at the risk of other apps having NP message lost.
Granted, we have a pretty reliable network here, but man, what a waste of
time trying to hunt for messages that get lost over the fast channel. (For
anyone just jumping into the thread now, please don't suggest that I just
make the messages persistent. That is not the 

Re: Production MQ abends - 2019 / 2195 / 2079 and more.

2003-06-04 Thread Michelle Russell
I have checked all production applications that use MQSeries and searched
on MQGET and MQPUT and MQPUT1 to the Initiation queue.
Nothing is displayed.

I have spoken with the developers and checked the implementation records
and nothing has been implemented in the last three days.

The RACF msg is prefixed with the MQSubsystem name, i.e MVB1.  This is the
standard RACF practise here.

No RACF changes have been made for at least two months.  No new definitions
to the INITQ's in production.

If you can think of anything else please let me know.

Regards
Michelle





Stefan Sievert [EMAIL PROTECTED]@AKH-Wien.AC.AT on 03/06/2003
15:08:38

Please respond to MQSeries List [EMAIL PROTECTED]

Sent by:MQSeries List [EMAIL PROTECTED]


To:[EMAIL PROTECTED]
cc:

Subject:Re: Production MQ abends - 2019 / 2195 / 2079 and more.


Michelle,
is it possible that a new application went into production three days ago
that (by accident) writes directly to the initiation queue
MQPB.INITQ.PB.PCCIC?
Also, the RACF message shows a queue name of MVB1.MQPB.INITQ.PB.PCCIC,
which
is a different name, but that might be OK.
Did any RACF definitions change or is the later INITQ a new one and the
RACF
permissions for your started task userID(ZMQMAB1) have not been properly
set?
Just guessing here, it's hard to say if the error messages you see are
related.
Stefan


From: Michelle Russell [EMAIL PROTECTED]
Reply-To: MQSeries List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Production MQ abends - 2019 / 2195 / 2079 and more.
Date: Tue, 3 Jun 2003 10:00:43 +0100

Hi all,

MQ V2.1.  OS/390

The last two mornings at exactly the same time we have experienced an
issue
with the connections between MQSeries and a production CICS region.
The errors that are being seen in the CICS log are:

+CSQC106D PCCIC CSQCTASK MQGET failure. CKTI will end. MQCC=2 MQRC=2019
(Object Handle)
+CSQC110I PCCIC CSQCTASK Queue name = MQPB.INITQ.PB.PCCIC

+KAD6500 ERROR ON MQCLOSE QAKE.GET.VALIDATE.CUSTOMER.DETAILS.REQUEST
+KAD6500 ERROR ON MQCLOSE REASON =  2019

+CSQC111D PCCIC CSQCTASK CKTI has read a trigger message with an incorrect
length of 297

As well as the above we are getting 2195 (Unexpected error) and
2079(Truncated msg) errors.

In addition to the above the CICS and MQ logs are showing RACF messages:

06.53.41 STC04301  ICH408I JOB(MVB1MSTR) STEP(MVB1MSTR)---
This should be USER (ZMQMAB1) GROUP ([EMAIL PROTECTED])
  MVB1.MQPB.INITQ.PB.PCCIC CL(MQQUEUE )
  INSUFFICIENT ACCESS AUTHORITY
  FROM MVB1.MQPB.INITQ.** (G)
  ACCESS INTENT(UPDATE )  ACCESS ALLOWED(NONE   )

Has anyone experienced any of the above ?

Any help would be much appreciated

Regards
Michelle






This email and any attachments are confidential. They may
contain privileged information and are intended for the
named addressee(s) only. They must not be distributed
without our consent. If you are not the intended recipient,
please notify us immediately and do not disclose, distribute
or retain this email or any part of it. Unless expressly stated,
opinions in this email are those of the individual sender
and not N Brown Group plc or any of its subsidiaries.
You must take full responsibility for virus checking this
email and any attachments.

Please note that the content of this email or any of its
attachments may contain data that falls within the scope
of the Data Protection Acts and that you must ensure that
any handling or processing of such data by you is fully
compliant with the terms and provisions of the Data
Protection Act 1984 and 1998.

N Brown Group plc. Registered office: 53 Dale Street,
Manchester, M60 6ES. Registered in England No.814103.

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





This email and any attachments are confidential. They may
contain privileged information and are intended for the
named addressee(s) only. They must not be distributed
without our consent. If you are not the intended recipient,
please notify us immediately and do not disclose, distribute
or retain this email or any part of it. Unless expressly stated,
opinions in this email are those of the individual sender
and not N Brown Group plc or any of its subsidiaries.
You must take full responsibility for virus checking this
email and any attachments.

Please note that the content of this email or any of its
attachments may contain data that falls within the scope
of the Data Protection Acts and 

MQseries installation

2003-06-04 Thread Sony Varghese
Hi everyone,

Is it possible to have MQ v5.2 and MQ v5.3 on the same AIX box?
Is there a way of doing this?

Thanks,
VJ

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 with MA7P using .NET application

2003-06-04 Thread Capodicci, Dan (COMFIN, ITSS)
Hi Elena

We are using it and ran into the same problems. We are setting the channels to convert 
the data for us and my guess is that may be where the problem is. The data coming out 
of our front end, .Net app seemed to be causing an error which related to it not 
getting correctly converted. The quick fix that I came up with was to have the .Net 
app pass the CCSID parm of 500 which is the CCSID of our mainframe qmanager. This 
rectified the problem immediately. 

Hope it helps.
Dan

-Original Message-
From: Elena Nanos [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 03, 2003 11:23 AM
To: [EMAIL PROTECTED]
Subject: Data conversion with MA7P using .NET application


Hello,
we are using Support pack MA7P - WebSphere MQ classes for Microsoft .NET,
which allows MQ  to be invoked from Microsoft .NET applications.

We ran into a problem with data conversion.  The data coming from mainframe
going to distributed, is not being converted to ASCII.

Is any one else using this support pack and can share the experience with
us?

Thank you.

Elena Nanos
Sr. Software and System Architect
IBM Certified Solution Expert in CICS WEB Enablement and MQSeries
Zurich NA

*** PLEASE NOTE ***
This E-Mail/telefax message and any documents accompanying this
transmission may contain privileged and/or confidential information and is
intended solely for the addressee(s) named above.  If you are not the
intended addressee/recipient, you are hereby notified that any use of,
disclosure, copying, distribution, or reliance on the contents of this
E-Mail/telefax information is strictly prohibited and may result in legal
action against you. Please reply to the sender advising of the error in
transmission and immediately delete/destroy the message and any
accompanying documents.  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


MQSeries msgid length not 24 bytes

2003-06-04 Thread Teresa Cheung
I thought MQSeries generated msgid is 24bytes long. We have a processthatsave the value of msgid generated into Sybase database. WhenI ranthe following sql statement to check the length of msgid and found out that they are not 24 bytes long.??

Sybase SQL statement

select distinct(datalength(MQ_MSGID)) MsgIdLength 
from ATABLE
Result from above statement
MsgIdLength20212223
Please advise on this findings. 
Thanks,
TC
Do you Yahoo!?
Free online calendar with sync to Outlook(TM).

Re: Production MQ abends - 2019 / 2195 / 2079 and more.

2003-06-04 Thread Michelle Russell
I will look into this by reading up on the RACF CLASSES AND PROFILES
Chapter in the System Management Guide.

Thanks





Morag Hughson [EMAIL PROTECTED]@AKH-Wien.AC.AT on 03/06/2003 16:51:26

Please respond to MQSeries List [EMAIL PROTECTED]

Sent by:MQSeries List [EMAIL PROTECTED]


To:[EMAIL PROTECTED]
cc:

Subject:Re: Production MQ abends - 2019 / 2195 / 2079 and more.


In the z/OS System Setup Guide in the chapter MQSeries Security
Management, under Security Problem Determination, it talks about
Violation messages.

In there is states, If the ICH408I violation message shows the queue
manager jobname rather than a user ID, this is normally as a result of a
blank alternate user ID being specified.

Given your other error messages about finding truncated messages, are you
not getting enough of the message to find the alternate user ID and so
hitting the above problem?

Morag Hughson
WebSphere MQ for z/OS Development
Internet: [EMAIL PROTECTED]




  Michelle Russell
  [EMAIL PROTECTED]To:
  [EMAIL PROTECTED]
  IAMS.CO.UK cc:
  Sent by: MQSeries List  Subject:  Production
  MQ abends - 2019 / 2195 / 2079 and more.
  [EMAIL PROTECTED]
  


  03/06/2003 10:00
  Please respond to
  MQSeries List






Hi all,

MQ V2.1.  OS/390

The last two mornings at exactly the same time we have experienced an issue
with the connections between MQSeries and a production CICS region.
The errors that are being seen in the CICS log are:

+CSQC106D PCCIC CSQCTASK MQGET failure. CKTI will end. MQCC=2 MQRC=2019
(Object Handle)
+CSQC110I PCCIC CSQCTASK Queue name = MQPB.INITQ.PB.PCCIC

+KAD6500 ERROR ON MQCLOSE QAKE.GET.VALIDATE.CUSTOMER.DETAILS.REQUEST
+KAD6500 ERROR ON MQCLOSE REASON =  2019

+CSQC111D PCCIC CSQCTASK CKTI has read a trigger message with an incorrect
length of 297

As well as the above we are getting 2195 (Unexpected error) and
2079(Truncated msg) errors.

In addition to the above the CICS and MQ logs are showing RACF messages:

06.53.41 STC04301  ICH408I JOB(MVB1MSTR) STEP(MVB1MSTR)---
This should be USER (ZMQMAB1) GROUP ([EMAIL PROTECTED])
 MVB1.MQPB.INITQ.PB.PCCIC CL(MQQUEUE )
 INSUFFICIENT ACCESS AUTHORITY
 FROM MVB1.MQPB.INITQ.** (G)
 ACCESS INTENT(UPDATE )  ACCESS ALLOWED(NONE   )

Has anyone experienced any of the above ?

Any help would be much appreciated

Regards
Michelle






This email and any attachments are confidential. They may
contain privileged information and are intended for the
named addressee(s) only. They must not be distributed
without our consent. If you are not the intended recipient,
please notify us immediately and do not disclose, distribute
or retain this email or any part of it. Unless expressly stated,
opinions in this email are those of the individual sender
and not N Brown Group plc or any of its subsidiaries.
You must take full responsibility for virus checking this
email and any attachments.

Please note that the content of this email or any of its
attachments may contain data that falls within the scope
of the Data Protection Acts and that you must ensure that
any handling or processing of such data by you is fully
compliant with the terms and provisions of the Data
Protection Act 1984 and 1998.

N Brown Group plc. Registered office: 53 Dale Street,
Manchester, M60 6ES. Registered in England No.814103.

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: Data conversion with MA7P using .NET application

2003-06-04 Thread Elena Nanos
Hello Dan,
thank you very much for that useful tip.

Elena.


Capodicci, Dan (COMFIN, ITSS) [EMAIL PROTECTED]@AKH-Wien.AC.AT on
06/03/2003 11:18:40 AM

Please respond to MQSeries List [EMAIL PROTECTED]

Sent by:MQSeries List [EMAIL PROTECTED]


To:[EMAIL PROTECTED]
cc:

Subject:Re: Data conversion with MA7P using .NET application


Hi Elena

We are using it and ran into the same problems. We are setting the channels
to convert the data for us and my guess is that may be where the problem
is. The data coming out of our front end, .Net app seemed to be causing an
error which related to it not getting correctly converted. The quick fix
that I came up with was to have the .Net app pass the CCSID parm of 500
which is the CCSID of our mainframe qmanager. This rectified the problem
immediately.

Hope it helps.
Dan

-Original Message-
From: Elena Nanos [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 03, 2003 11:23 AM
To: [EMAIL PROTECTED]
Subject: Data conversion with MA7P using .NET application


Hello,
we are using Support pack MA7P - WebSphere MQ classes for Microsoft .NET,
which allows MQ  to be invoked from Microsoft .NET applications.

We ran into a problem with data conversion.  The data coming from mainframe
going to distributed, is not being converted to ASCII.

Is any one else using this support pack and can share the experience with
us?

Thank you.

Elena Nanos
Sr. Software and System Architect
IBM Certified Solution Expert in CICS WEB Enablement and MQSeries
Zurich NA

*** PLEASE NOTE ***
This E-Mail/telefax message and any documents accompanying this
transmission may contain privileged and/or confidential information and is
intended solely for the addressee(s) named above.  If you are not the
intended addressee/recipient, you are hereby notified that any use of,
disclosure, copying, distribution, or reliance on the contents of this
E-Mail/telefax information is strictly prohibited and may result in legal
action against you. Please reply to the sender advising of the error in
transmission and immediately delete/destroy the message and any
accompanying documents.  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

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 with MA7P using .NET application

2003-06-04 Thread Glen Larson
Dan,

MQ convertion works fine when done by the application, plus we have some
blobs to traverse the network.  Channel convertion is not an option.  As
far as messing with the CCSID, we're using standard NT, AIX , and MVS queue
managers.  The application group is converting to the .NET and we have been
using the standard to convert at the receiving application without
problem.   This should support the standard API.

glen


Capodicci, Dan (COMFIN, ITSS) [EMAIL PROTECTED]@AKH-Wien.AC.AT on
06/03/2003 01:08:42 PM

Please respond to MQSeries List [EMAIL PROTECTED]

Sent by:MQSeries List [EMAIL PROTECTED]


To:[EMAIL PROTECTED]
cc:

Subject:Re: Data conversion with MA7P using .NET application


Hi Glen

I can't say whether this is a bug or not (or as I like to refer to them,
undocumented enhancements) although I haven't encountered this issue in
the past with VB and ActiveX apps that do pretty much the same as is being
done in this .Net app. What lead me to putting the CCSID parm change in was
that I was receiving a 2110 MQRC_FORMAT_ERROR on the data passing through
the channels and the conversion was not taking place. My problem was from
the front end up to the mainframe which is why I had the CCSID changed to
500. We have a request/reply scenario so once the requesting data got to
the mainframe correctly, I had no further problems from there. I am not
having a problem with the conversion on the way down but I am doing it in
the channels (I now this is generally not the preferred method but I have
found it much easier to work with this way!) The only difference that I
would think between the 2 methods here is that the channel method converts
it to the CCSID for the receiving qmanager, in my case 437 so I do not need
to have the CCSID parm set in the return message.

In your case, are you having the mainframe app set the CCSID in the MQMD?!?
It sounds as though you are failing on the MQGET with convert, are you
getting an error thrown, such as a 2110?!? If so, you might try having the
mainframe program setting the CCSID parm to that of the receiving qmanager
and see if that helps.

Hope it helps!!
Dan

-Original Message-
From: Glen Larson [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 03, 2003 1:10 PM
To: [EMAIL PROTECTED]
Subject: Re: Data conversion with MA7P using .NET application


Dan,

the problem is this is a shared channel.

we do not want to use channel conversion.

So is this a bug in the .NET,  or is there some parm the application needs
to use.

glen larson
zurich north america


Capodicci, Dan (COMFIN, ITSS) [EMAIL PROTECTED]@AKH-Wien.AC.AT on
06/03/2003 11:18:40 AM

Please respond to MQSeries List [EMAIL PROTECTED]

Sent by:MQSeries List [EMAIL PROTECTED]


To:[EMAIL PROTECTED]
cc:

Subject:Re: Data conversion with MA7P using .NET application


Hi Elena

We are using it and ran into the same problems. We are setting the channels
to convert the data for us and my guess is that may be where the problem
is. The data coming out of our front end, .Net app seemed to be causing an
error which related to it not getting correctly converted. The quick fix
that I came up with was to have the .Net app pass the CCSID parm of 500
which is the CCSID of our mainframe qmanager. This rectified the problem
immediately.

Hope it helps.
Dan

-Original Message-
From: Elena Nanos [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 03, 2003 11:23 AM
To: [EMAIL PROTECTED]
Subject: Data conversion with MA7P using .NET application


Hello,
we are using Support pack MA7P - WebSphere MQ classes for Microsoft .NET,
which allows MQ  to be invoked from Microsoft .NET applications.

We ran into a problem with data conversion.  The data coming from mainframe
going to distributed, is not being converted to ASCII.

Is any one else using this support pack and can share the experience with
us?

Thank you.

Elena Nanos
Sr. Software and System Architect
IBM Certified Solution Expert in CICS WEB Enablement and MQSeries
Zurich NA

*** PLEASE NOTE ***
This E-Mail/telefax message and any documents accompanying this
transmission may contain privileged and/or confidential information and is
intended solely for the addressee(s) named above.  If you are not the
intended addressee/recipient, you are hereby notified that any use of,
disclosure, copying, distribution, or reliance on the contents of this
E-Mail/telefax information is strictly prohibited and may result in legal
action against you. Please reply to the sender advising of the error in
transmission and immediately delete/destroy the message and any
accompanying documents.  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 

Re: Data conversion with MA7P using .NET application

2003-06-04 Thread GIES, STEVE
Elena -

This is a known bug in the current .NET support pac.  What is happening is
that by default the MQQueue class attempts to get the message with a 1 byte
buffer.  This of course fails (unless you just happen to be passing a 1 or 0
byte message!!) with a truncation failure.  The class then resizes its
internal buffer and retries the MQGET call, and since the buffer is now
large enough the message is retrieved.  (BTW, the ActiveX classes do the
same thing, but they start with a 2K buffer).

The problem with the .NET classes is that after the first MQGET call the
MQMD-CCSID field has been updated with the value from the message - which is
the value from the mainframe queue manager.  When the second call is made,
this field is not reinitialized.  This tells MQ to convert the data into the
code page from the mainframe.  Since the data is already in this code page,
no conversion takes place.

One way to work around this problem is to instruct the class to use a bigger
default buffer size.  You do this on the put method.  For example, to use a
5000 byte buffer in VB.NET code the following

  myQueue.Get(myMsg, myGMO, 5000)

This does, however, require you to know what the largest size message will
be.

Steve Gies
Safeco Insurance
IT Specialist - WebSphere MQ



-Original Message-
From: Elena Nanos [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 03, 2003 8:23 AM
To: [EMAIL PROTECTED]
Subject: Data conversion with MA7P using .NET application


Hello,
we are using Support pack MA7P - WebSphere MQ classes for Microsoft .NET,
which allows MQ  to be invoked from Microsoft .NET applications.

We ran into a problem with data conversion.  The data coming from mainframe
going to distributed, is not being converted to ASCII.

Is any one else using this support pack and can share the experience with
us?

Thank you.

Elena Nanos
Sr. Software and System Architect
IBM Certified Solution Expert in CICS WEB Enablement and MQSeries Zurich NA

*** PLEASE NOTE ***
This E-Mail/telefax message and any documents accompanying this transmission
may contain privileged and/or confidential information and is intended
solely for the addressee(s) named above.  If you are not the intended
addressee/recipient, you are hereby notified that any use of, disclosure,
copying, distribution, or reliance on the contents of this E-Mail/telefax
information is strictly prohibited and may result in legal action against
you. Please reply to the sender advising of the error in transmission and
immediately delete/destroy the message and any accompanying documents.
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


WMQ 5.3 SupportPac MC74

2003-06-04 Thread Antony Boggis
Title: WMQ 5.3  SupportPac MC74






Does anyone have any knowledge regarding the two items? 


Does WMQ 5.3 (CSD03) on Win2000 Server work with Microsoft Cluster Server  the latest incantation of MC74?


Appreciate any feedback,


tonyB.





MQSeries 5.3 for Windows NT thread safe?

2003-06-04 Thread Robert Martin
I have a question. Is MQSeries 5.3 thread safe now? In the past, you
couldn't use the same queue manager connection handle for across
multiple threads. Has this changed ever?
--
Robert Martin
Design Engineer
SISCO 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


Re: IPProcs and OPProcs

2003-06-04 Thread Nick Dilauro
The Event Monitoring Manual is also a good reference for understanding
events.

-Original Message-
From: Conklin, William [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 03, 2003 12:58 PM
To: [EMAIL PROTECTED]
Subject: IPProcs and OPProcs


Hi All,
Is there a way to determine which MQSeries object has a queue/channel open
for input (IPPROCS) or output (OPPROCS)? These attributes changes of course
as the Qmgr operates.  I'm using MQSeries 5.3 on 390, Windows and Solaris.

Second question, our SYSTEM.ADMIN.QMGR.EVENT is filling up very fast, in
fact we had to clear it out before it filled up the page set.  We just moved
to 5.3 from 2.1 and we didn't experience this before.  Do you know what
events the Qmgr is Putting to this queue?  I haven't been able to find any
detail information about the behavior of this queue.

Thanks a MILLION in advance.
Bill C.

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 installation

2003-06-04 Thread Wyatt, T. Rob
Sony,

You are sure giving us all a good workout!  If we collect all your
questions, we would have a pretty good MQSeries FAQ.  ;-)

Current and prior releases of MQ, at least as far back as v2 anyway, all
look for executables in /opt/mqm/bin.  Therefore it would be impossible to
have two versions running at the same time.

-- T.Rob

-Original Message-
From: Sony Varghese [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 03, 2003 12:03 PM
To: [EMAIL PROTECTED]
Subject: MQseries installation


Hi everyone,

Is it possible to have MQ v5.2 and MQ v5.3 on the same AIX box?
Is there a way of doing this?

Thanks,
VJ

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: Data conversion with MA7P using .NET application

2003-06-04 Thread Elena Nanos
Hello Steve,
thank you very much for your reply, it is nice to know that we are not
alone ...

The queues using this support pack are set to 4 Meg max message size.  Our
developer will test setting larger buffer size on a PUT.  What size do you
recommend?

Thanks again.

Elena.


GIES, STEVE [EMAIL PROTECTED]@AKH-Wien.AC.AT on 06/03/2003 01:55:38 PM

Please respond to MQSeries List [EMAIL PROTECTED]

Sent by:MQSeries List [EMAIL PROTECTED]


To:[EMAIL PROTECTED]
cc:

Subject:Re: Data conversion with MA7P using .NET application


Elena -

This is a known bug in the current .NET support pac.  What is happening is
that by default the MQQueue class attempts to get the message with a 1 byte
buffer.  This of course fails (unless you just happen to be passing a 1 or
0
byte message!!) with a truncation failure.  The class then resizes its
internal buffer and retries the MQGET call, and since the buffer is now
large enough the message is retrieved.  (BTW, the ActiveX classes do the
same thing, but they start with a 2K buffer).

The problem with the .NET classes is that after the first MQGET call the
MQMD-CCSID field has been updated with the value from the message - which
is
the value from the mainframe queue manager.  When the second call is made,
this field is not reinitialized.  This tells MQ to convert the data into
the
code page from the mainframe.  Since the data is already in this code page,
no conversion takes place.

One way to work around this problem is to instruct the class to use a
bigger
default buffer size.  You do this on the put method.  For example, to use a
5000 byte buffer in VB.NET code the following

  myQueue.Get(myMsg, myGMO, 5000)

This does, however, require you to know what the largest size message will
be.

Steve Gies
Safeco Insurance
IT Specialist - WebSphere MQ



-Original Message-
From: Elena Nanos [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 03, 2003 8:23 AM
To: [EMAIL PROTECTED]
Subject: Data conversion with MA7P using .NET application


Hello,
we are using Support pack MA7P - WebSphere MQ classes for Microsoft .NET,
which allows MQ  to be invoked from Microsoft .NET applications.

We ran into a problem with data conversion.  The data coming from mainframe
going to distributed, is not being converted to ASCII.

Is any one else using this support pack and can share the experience with
us?

Thank you.

Elena Nanos
Sr. Software and System Architect
IBM Certified Solution Expert in CICS WEB Enablement and MQSeries Zurich NA

*** PLEASE NOTE ***
This E-Mail/telefax message and any documents accompanying this
transmission
may contain privileged and/or confidential information and is intended
solely for the addressee(s) named above.  If you are not the intended
addressee/recipient, you are hereby notified that any use of, disclosure,
copying, distribution, or reliance on the contents of this E-Mail/telefax
information is strictly prohibited and may result in legal action against
you. Please reply to the sender advising of the error in transmission and
immediately delete/destroy the message and any accompanying documents.
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

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: WMQ 5.3 SupportPac MC74

2003-06-04 Thread Crupi, Margherita
Title: WMQ 5.3 & SupportPac MC74



MQ 5.3 
has MSCS support within the base.
MC74 
is not required (and probably won't work).

  -Original Message-From: Antony Boggis 
  [mailto:[EMAIL PROTECTED]Sent: Wednesday, 4 June 2003 4:57 
  AMTo: [EMAIL PROTECTED]Subject: WMQ 5.3  
  SupportPac MC74
  Does anyone have any knowledge regarding the two 
  items? 
  Does WMQ 5.3 (CSD03) on Win2000 Server work with 
  Microsoft Cluster Server  the latest incantation of MC74? 
  Appreciate any feedback, 
  tonyB. 


Re: IPProcs and OPProcs

2003-06-04 Thread Tim Armstrong
As of V5.3 for z/OS you can do a DISPLAY QSTATUS if you want to know what
processes are using a queue, this command is also available in Windows and
the main flavours of UNIX.

Regards
Tim A



  Nick Dilauro
  [EMAIL PROTECTED]To:   [EMAIL PROTECTED]
  cc:
  Sent by: MQSeriesSubject:  Re: IPProcs and OPProcs
  List
  [EMAIL PROTECTED]
  N.AC.AT


  04/06/2003 06:39
  Please respond to
  MQSeries List





The Event Monitoring Manual is also a good reference for understanding
events.

-Original Message-
From: Conklin, William [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 03, 2003 12:58 PM
To: [EMAIL PROTECTED]
Subject: IPProcs and OPProcs


Hi All,
Is there a way to determine which MQSeries object has a queue/channel open
for input (IPPROCS) or output (OPPROCS)? These attributes changes of course
as the Qmgr operates.  I'm using MQSeries 5.3 on 390, Windows and Solaris.

Second question, our SYSTEM.ADMIN.QMGR.EVENT is filling up very fast, in
fact we had to clear it out before it filled up the page set.  We just
moved
to 5.3 from 2.1 and we didn't experience this before.  Do you know what
events the Qmgr is Putting to this queue?  I haven't been able to find any
detail information about the behavior of this queue.

Thanks a MILLION in advance.
Bill C.

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: MQClient thread-safe?

2003-06-04 Thread Tim Armstrong
Paul,

That is effectively what I meant by coordinate, ie. Thread1 and Thread2
share a connection handle Thread1 does a get under syncpoint and Thread2
does a put under syncpoint and then issues the commit which also commits
Thread1's get. Hope I've got this right.

Regards
Tim A



  Paul Clarke
  [EMAIL PROTECTED]To:   [EMAIL PROTECTED]
  IBM.COM cc:
  Sent by: MQSeriesSubject:  Re: MQClient thread-safe?
  List
  [EMAIL PROTECTED]
  N.AC.AT


  03/06/2003 21:25
  Please respond to
  MQSeries List





To all,
My apologies I had read about shared connections in V5.3 and promptly
forgot them again so yes you now can coordinate units of work across
multiple threads.

Tim,

I don't wish to be picky here but I didn't mention coordination. A shared
connection can be used across multiple threads but there is still only one
unit of work associated with the connection.

Cheers,
P.


Paul G Clarke
WebSphere MQ Development
IBM Hursley

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 a MQSeries Hub does its thing with persistent / non-persi stent messages

2003-06-04 Thread Neil Casey
Hi Peter,

thanks for the update and the information about your test results.

We handle this issue by running multiple overlapping clusters, and having
separate channels for each cluster.

Eg:
QM1 and QM2 are in clusters CL1 and CL2.
Rather than-
   DEFINE NAMELIST(ClusList) names('CL1,CL2') and
   DEFINE chl(TO.QM1) chltype(CLUSRCVR) ... clusnl(ClusList)
we would-
   DEFINE CHL(TO.QM1.CL1) chltype(CLUSRCVR)... cluster(CL1) and
   DEFINE CHL(TO.QM1.CL2) chltype(CLUSRCVR)... cluster(CL2).
   ie a separate channel is used in each cluster.

This lets us put different NPMSPEED, SSL and other parameters on channels
for different uses (clusters), even when they go to the same queue manager.

Our naming standards limit the length of a queue manager name to 8
characters, and also limit cluster names to 8 characters, which means that
our channels names are no more than 20 characters.

In your environment, you could build an new cluster for this application
(you can still use the same queue managers as repositories - just use
namelists to list the clusters you want to host). The high performance
queues live in the new cluster with NPMSPEED(FAST). Everything else goes in
the normal cluster(s).

As always in computing, there are trade-offs to be made. In this case, you
lose some of the perceived benefits of clustering (simplicity) because you
have to build and manage multiple clusters. This makes things like stopping
a queue manager more complicated, because you have to suspend from all
clusters, not just one. You also have to make correct decisions about which
cluster(s) to connect a queue into, which makes administration more complex
(but perhaps more interesting as well).

Regards,

Neil Casey.


|-+--
| |   Potkay, Peter M   |
| |   (PLC, IT) |
| |   [EMAIL PROTECTED]|
| |   RTFORD.COM|
| |   Sent by: MQSeries  |
| |   List   |
| |   [EMAIL PROTECTED]|
| |   AC.AT |
| |  |
| |  |
| |   04/06/2003 01:33   |
| |   Please respond to  |
| |   MQSeries List  |
| |  |
|-+--
  
--|
  |
  |
  |   To:   [EMAIL PROTECTED]  
|
  |   cc:  
  |
  |   Subject:  Re: How a MQSeries Hub does its thing with persistent / non-persi  
stent messages|
  
--|




Well, I think I have proved what everyone was saying. A channel speed of
Normal is what is getting me here. Neil Casey and Brian McCarty provided
the
exact explanation as to why: non persistent messages sent over a normal
speed channel cause persistent message to be written to the channel sync
queue, which requires disk. I set up some tests in my lab environment. Here
are the results.




*
Server1: SpokeQM1, Win2000 SP2, MQ 5.3 CSD03
RemoteQ called FinalQ that points to FinalQ on SpokeQM2, via transmit queue
HubQM1

Server2: HubQM1, Win2000 SP2, MQ 5.2.1 CSD05
QMAlias called SpokeQM2, which sends messages to transmit queue
SpokeQM2.XMITQ

Server3: SpokeQM2, Win2000 SP2, MQ 5.2.1 CSD05
Local queue called FinalQ


***


Test #1: Channel SpokeQM1.HubQM1 has a speed of NORMAL. Start putting 1K
Non-Persistent(NP) messages every 250 milliseconds to the remote queue def
on SpokeQM1.
Results #1: As expected, constant disk writes on the server that houses
HubQM1.


Test #2: Channel SpokeQM1.HubQM1 has a speed of FAST. Start putting 1K NP
messages every 250 milliseconds to the remote queue def on SpokeQM1.
Results #2: As expected, no disk activity at all on the server that houses
HubQM1. Actually, there was disk activity when the channel started/ended,
but for the whole duration while the channel was running, no I/O.


Test #3: Channel SpokeQM1.HubQM1 has a speed of FAST. Start putting 70,000
byte NP messages every 250 milliseconds to the remote queue def on
SpokeQM1.
Results #3: No disk activity at all on the server that houses HubQM1. ???
These messages are larger than the 64K queue buffer, so why are the
messages
flying thru the hub with no I/O? I am happy with these results, just that
it
is 

Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages

2003-06-04 Thread Tim Armstrong
Again my apologies havent been expressing my ideas too well of late. With
regard to selecting candidates the example below is not entirely clear in
that I only mention one set of channels to one queue manager it would have
been better as follows.  nothing to stop you from having TO.QM1.FAST
and TO.QM1.NORMAL, TO.QM2.FAST and TO.QM2.NORMAL, TO.QMx.FAST and
TO.QMx.NORMAL sets of channels. As Neil ...

Regards
Tim A



  Tim
  Armstrong/AustraliTo:   [EMAIL PROTECTED]
  a/[EMAIL PROTECTED]   cc:
  Sent by: MQSeries Subject:  Re: How a MQSeries Hub does 
its thing with persistent / non-persi
  List   stent messages
  [EMAIL PROTECTED]
  .AC.AT


  04/06/2003 07:53
  Please respond to
  MQSeries List





For your cluster channels you could write your own exit, nothing to stop
you from having a TO.QM1.FAST and a TO.QM1.NORMAL set of channels. As Neil
said in another thread rather than try to maintain state information about
what channel is next just use a random number to select an appropriate
candidate. Below is the default selection criteria from the Queue Manager
Clusters manual chapter 11, you should consider its operation if you
decide to design your own.

Algorithm: The steps in choosing a destination for a message:
   1. If a queue name is specified, eliminate queues that are not PUT
  enabled.


  Eliminate remote instances of queues that do not share a cluster with
  the local queue manager.


  Eliminate remote CLUSRCVR channels that are not in the same cluster
  as the queue.
   2. If a queue manager name is specified, eliminate queue manager alias'
  that are not PUT enabled.


  Eliminate remote CLUSRCVR channels that are not in the same cluster
  as the local queue manager.
   3. If the result above contains the local instance of the queue, choose
  it.
   4. If the message is a cluster PCF message, eliminate any queue manager
  you have already sent a publication or subscription to.
   5. If only remote instances of a queue remains, choose Resumed queue
  managers over Suspended ones.
   6. If more than one remote instance of a queue remains, include all
  MQCHS_INACTIVE and MQCHS_RUNNING channels.
   7. If less than one remote instance of a queue remains, include all
  MQCHS_BINDING, MQCHS_INITIALIZING, MQCHS_STARTING, and MQCHS_STOPPING
  channels.
   8. If less than one remote instance of a queue remains, include all
  MQCHS_RETRYING channels.
   9. If less than one remote instance of a queue remains, include all
  MQCHS_REQUESTING, MQCHS_PAUSED and MQCHS_STOPPED channels.
   10.  If more than one remote instance of a queue remains and the
  message is a cluster PCF message, choose locally defined CLUSSDR
  channels.
   11.  If more than one remote instance of a queue remains to any
  queue manager, choose channels with the highest NETPRTY to each queue
  manager.
   12.  If more than one remote instance of a queue remains, choose the
  least recently used channel.

Regards
Tim A



  Potkay, Peter M
  (PLC, IT) To:
[EMAIL PROTECTED]
  [EMAIL PROTECTED]cc:
  RTFORD.COMSubject:  Re: How a
MQSeries Hub does its thing with persistent / non-persi
  Sent by: MQSeries   stent messages
  List
  [EMAIL PROTECTED]
  AC.AT


  04/06/2003 01:33
  Please respond to
  MQSeries List





Well, I think I have proved what everyone was saying. A channel speed of
Normal is what is getting me here. Neil Casey and Brian McCarty provided
the
exact explanation as to why: non persistent messages sent over a normal
speed channel cause persistent message to be written to the channel sync
queue, which requires disk. I set up some tests in my lab environment. Here
are the results.





*
Server1: SpokeQM1, Win2000 SP2, MQ 5.3 CSD03
RemoteQ called FinalQ that points to FinalQ on SpokeQM2, via transmit queue
HubQM1

Server2: HubQM1, Win2000 SP2, MQ 5.2.1 CSD05
QMAlias called SpokeQM2, which sends messages to transmit queue
SpokeQM2.XMITQ

Server3: SpokeQM2, Win2000 SP2, MQ 5.2.1 CSD05
Local queue called FinalQ



***


Test #1: Channel SpokeQM1.HubQM1 has a speed of NORMAL. Start putting 1K
Non-Persistent(NP) messages every 250 milliseconds to the remote queue def
on SpokeQM1.
Results #1: As expected, constant disk writes on the server that houses

Re: Data conversion with MA7P using .NET application

2003-06-04 Thread GIES, STEVE
Elena -

You would set the default buffer size on the Get method, not the Put method.
As to what size to use, that really depends on your application that is
putting messages to your queue.

- Steve

-Original Message-
From: Elena Nanos [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 03, 2003 2:23 PM
To: [EMAIL PROTECTED]
Subject: Re: Data conversion with MA7P using .NET application


Hello Steve,
thank you very much for your reply, it is nice to know that we are not alone
...

The queues using this support pack are set to 4 Meg max message size.  Our
developer will test setting larger buffer size on a PUT.  What size do you
recommend?

Thanks again.

Elena.


GIES, STEVE [EMAIL PROTECTED]@AKH-Wien.AC.AT on 06/03/2003 01:55:38 PM

Please respond to MQSeries List [EMAIL PROTECTED]

Sent by:MQSeries List [EMAIL PROTECTED]


To:[EMAIL PROTECTED]
cc:

Subject:Re: Data conversion with MA7P using .NET application


Elena -

This is a known bug in the current .NET support pac.  What is happening is
that by default the MQQueue class attempts to get the message with a 1 byte
buffer.  This of course fails (unless you just happen to be passing a 1 or 0
byte message!!) with a truncation failure.  The class then resizes its
internal buffer and retries the MQGET call, and since the buffer is now
large enough the message is retrieved.  (BTW, the ActiveX classes do the
same thing, but they start with a 2K buffer).

The problem with the .NET classes is that after the first MQGET call the
MQMD-CCSID field has been updated with the value from the message - which is
the value from the mainframe queue manager.  When the second call is made,
this field is not reinitialized.  This tells MQ to convert the data into the
code page from the mainframe.  Since the data is already in this code page,
no conversion takes place.

One way to work around this problem is to instruct the class to use a bigger
default buffer size.  You do this on the put method.  For example, to use a
5000 byte buffer in VB.NET code the following

  myQueue.Get(myMsg, myGMO, 5000)

This does, however, require you to know what the largest size message will
be.

Steve Gies
Safeco Insurance
IT Specialist - WebSphere MQ



-Original Message-
From: Elena Nanos [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 03, 2003 8:23 AM
To: [EMAIL PROTECTED]
Subject: Data conversion with MA7P using .NET application


Hello,
we are using Support pack MA7P - WebSphere MQ classes for Microsoft .NET,
which allows MQ  to be invoked from Microsoft .NET applications.

We ran into a problem with data conversion.  The data coming from mainframe
going to distributed, is not being converted to ASCII.

Is any one else using this support pack and can share the experience with
us?

Thank you.

Elena Nanos
Sr. Software and System Architect
IBM Certified Solution Expert in CICS WEB Enablement and MQSeries Zurich NA

*** PLEASE NOTE ***
This E-Mail/telefax message and any documents accompanying this transmission
may contain privileged and/or confidential information and is intended
solely for the addressee(s) named above.  If you are not the intended
addressee/recipient, you are hereby notified that any use of, disclosure,
copying, distribution, or reliance on the contents of this E-Mail/telefax
information is strictly prohibited and may result in legal action against
you. Please reply to the sender advising of the error in transmission and
immediately delete/destroy the message and any accompanying documents. 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

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: Client and server configuration

2003-06-04 Thread Chan, Ian M
Just curious.  What is the difference between 'client' in the server CD and
the client from the support pack?

Thanks,
Ian

-Original Message-
From: Francois Van der Merwe1 [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 3 June 2003 7:11 PM
To: [EMAIL PROTECTED]
Subject: Re: Client and server configuration


Just to make this a little bit more clear.   You MUST install the client
that is on the SERVER CD.   When you start installation from the server CD,
one of the options is to also install the client code - use that.

Francois van der Merwe
Senior IT Specialist: IBM MQSeries Certified Specialist, Solutions Expert 
Developer



 

  Potkay, Peter M

  (PLC, IT) To:
[EMAIL PROTECTED]

  [EMAIL PROTECTED]cc:

  RTFORD.COMSubject:  Re: Client and
server configuration   
  Sent by: MQSeries

  List

  [EMAIL PROTECTED]

  AC.AT

 

 

  03/06/2003 14:02

  Please respond to

  MQSeries List

 






Yes.

But if you install the MQServer onto your machine, then you must install
the MQClient from the CD. You cannot use the MQClient that you download as
a Support Pack.

If you install ONLY MQClient on a PC, then you can use either the client
from the CD or the client from the support pack download page.



-Original Message-
From: Teresa Cheung [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2003 4:56 PM
To: [EMAIL PROTECTED]
Subject: Client and server configuration


Can both have MQSeries client and sever software installed on the
same operating system? I am running Windows 2000 .

Thanks
TC


Do you Yahoo!?
Free online calendar with sync to Outlook(TM).

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


MQ v5.3

2003-06-04 Thread Sony Varghese
Hi everyone,

Are there any known issues with MQSeries v5.3?
Would like your inputs on this ...

Thanks.
Sony

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