Re: WMQ MIPS usage on idle mainframe

Francois, I can offer a couple of examples. On an R56, in 42 hrs elapsed time, the MSTR used 143 seconds of CPU, and the CHIN used 38 secs. The CHIN probably didn't do anything, but the Command Server would have been active in the MSTR. OK, so it's not strictly idle. On a Y56, again in 42 hrs ela

Re: CICS 6.2

Ian, Yes, we ran MQ 2.1 successfully with CICS TS2.2. But have a look at APAR PQ35501 (PTF UQ41060) which says: PROBLEM SUMMARY: * USERS AFFECTED: All Users of MQSeries V2.1 for OS/390* ***

Re: arrival time of last message

Larry, There doesn't seem to be anything useful in the Queue stats. But there is Last-msg date and Last-msg time fields in Display Channelstatus. For a Receiver channel, this is the date/time the last msg was put to its target queue. You might have to monitor several channels, instead of just one

Re: Sender Channel can not re establish connection after an abnormal end to the connection

Bill, If the Receiver channel doesn't see the error for some reason, then it can be left in a RUNNING state. And in that case, you'll have problems re-connecting. I can't answer the question of why the connection is dropping, and why the RCVR doesn't see it. But can you set the ADOPTMCA parms in t

Re: Backout Queue name

Thank you to all who replied. Exactly the sort of info I was looking for. Thanks, Richard. Glen Shubert <[EMAIL PROTECTED]>@AKH-Wien.AC.AT> on 16/09/2003 02:08:26 Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc:

Backout Queue name

OK Listers, an easy question to start the week. This is on OS/390, although I don't think that matters. When I define a local queue, I can define the BOQNAME (Backout requeue name) and BOTHRESH (Backout Threshold). The FM says that the Qmgr maintains these values, but takes no action based on the

Re: Migrating MQSeries libraries in IDMS

Ernest, 2058 is a Q_MGR_NAME_ERROR. Is your IDMS connection using the defaults module CQSBDEFV to get the Qmgr name? If so, did you update this with the 5.3 install? Just a thought. Richard. earMERC Roberts <[EMAIL PROTECTED]>@AKH-Wien.AC.AT> on 12/09/2003 08:21:27 Please respond to MQSerie

Re: MQSC Command on OS/390 using COBOL(all Q names & some attributes)

Riyaz, I wrote a command processor similar to yours and tried this. There's nothing wrong with the syntax of your command - when I ran it, it gave me each queue with the attributes requested. As you noted, the response for each queue comes back in a seperate message, so your message length should

Re: Odd data at start of messages

Sid, Message Descriptor Extension: ** FUNCTION: This file declares the structure MQMDE, which ** is used by the main MQI. ** How were these messages put on the queue? Richard. [EMAIL PROTECTED]@AKH-WIEN.AC.AT> on 03/09/2003 15:34:30 Please respond to MQSeries List <

Re: MVS msg exit (MQPUT) processing causes increase in MSTR region size.

Dax, I presume that TEST.EXIT.QUEUE is a local queue in both of the Qmgrs. OK, if you send 1000 msgs in each direction, then the exit will be invoked 2000 times at each end. If I've added it up correctly, each msg that you put to the queue is 1.5K plus header. So 1.8K * 2000 is 3.6Mb - which is

Re: OS/390 system scope

Edward, This shouldn't be a problem. Our system is defined like this, and we use it to move the Qmgr round MVS images as we IPL the various systems. The only other thing we do is to move the VTAM ACB (because we use APPC for some of the channels), but that shouldn't prevent the Qmgr from starting.

Re: 2059 trying to connect mq series 5.3 on z/os 1.4

Javier, 2059 is QMGR_NOT_AVAILABLE. Are you getting this on the client end? I presume that you have the client attach feature on the Z/OS version of MQ? On Z/OS, client attach is a seperate, chargable feature. I believe that it's included as part of the Qmgr on all the other platforms. Richard.

Re: CSQUZAP documents

Erik, Why do you ask? CSQUZAP seems to be a utility for working with offline logs. It appears to be deliberately un-documented, and only to be used at the direction of IBM support. Richard. "Dijkerman, E (Erik)" <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 31/01/2003 03:27:29 Please respond to MQ

Re: File System Operations Fail After MQI Calls

It doesn't happen on my OS/390 system :-o Richard. Pavel Tolkachev <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 29/01/2003 13:30:44 Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: File System Operati

Re: Channel Initiation on OS/390.

Was that a typo for the APPLICID ? Ours have: Application ID : CSQX START. The command Ref manulal says that's what it should be for distributed queueing without CICS. Richard. Mark Steely <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 26/11/2002 09:25:39 Please respond to MQSeries List <[EMAIL P

Re: Detecting MQ subsystem shutdown

Thanks to all who responded to me on this. I have read all the replies, although I haven't had a chance to do anything about it yet, because an unrelated area has turned to custard and consumed all my time. For those of you who are familiar with it, the "long running task" that I originally refere

Detecting MQ subsystem shutdown

I have a long running task that I want to be able to query MQ resources. This task will call my program and provide: - a function code: Initialise, closedown, or normal call - a correlator that I can use to anchor storage across calls - any other parameters I need to pass. What I planned to do was

Re: Expiration time problem.

Pablo, Yes, this is normal behaviour. The manual (can't remember which one at the moment) says that expired messages count towards the queue depth, even though you can't read them any more. Queue depth will go to 0 then the messages are deleted from the queue - this happens when the first non-brow