XML CDATA

I am creating an outbound XML message in which I want one of the elements to look something like this ...Root...element1![CDATA[ #%^ any text ]]/element1/Root. To simply create the element without CDATA I would use "set "OutputRoot"."XML"."Root".element1 = '#%^ any text '; How do I do

Receiver channel parameters mrrty and mrtmr

Hi, We have been asked to justify our decision to let receiving channel message retry count and interval parameters (mrrty and mrtmr) take their default values. These allow (non z/OS) MQ to retry message put failures up to 10 times, one second apart, before writing the message to the dead letter

Re: Receiver channel parameters mrrty and mrtmr

Alan, I'm not sure it answers your question but you seem to indicate that the mesage is retried regardless of the failure. This isn't true, there are only a small number of errors which are considered transitory (and therefore retryable). From memory these are MQRC_PUT_INHIBITED

Re: XML CDATA

Try looking at the instructions in the manual for the latest CICS XML parser van Zyl, Andre [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 11/17/2004 04:21 AM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: XML CDATA I am

Re: Receiver channel parameters mrrty and mrtmr

Paul, Why such reticence? It answers the question splendidly. The description in the command manual is somewhat light, but Intercommunication is much more detailed. The message retry parameters act like a flood plain when a message consumer is over-loaded, giving it a chance to catch up

AMQ9540: Commit failed.

We have been running MQSeries v5.1 on HP-UX 11.0 for many years. Recently we have upgraded machines and set them up in a failover configuration. These new machines are runnng HP-UX 11.11 and use HP Serviceguard to handle the failover. Unfortunatly we also loaded the DCE and non-DCE version of

Re: Cluster Problem

Yes, a Full Repo can host clustered queues. If question below is based on "errors" you are seeing from MQExplorer, ignore them. Ignore most everything that MQExplorer tells you related to errors with Clusters. Verify it with commands from runmqsc before worrying about it. -Original

Re: AMQ9540: Commit failed.

Let me be the first to suggest upgrading to MQ v5.3. :-) --- Jeff A Tressler [EMAIL PROTECTED] wrote: We have been running MQSeries v5.1 on HP-UX 11.0 for many years. Recently we have upgraded machines and set them up in a failover configuration. These new machines are runnng HP-UX 11.11 and

Re: Receiver channel parameters mrrty and mrtmr

The problem we saw with the defaults is that a single application queue could cause a channel to go into retry. But the channel will service loads of queues. So if a problem application fills up a queue, the channel grinds to a halt and more responsible application suffer, too. Because of that, we

Re: Cluster Problem

With my experience with cluster, Issue REFRESH CLUSTER and wait. It usually, works. MQ takes time to propagate the information. Thanks, AkBar E. Dar The United Illuminating Company New Haven, CT Off: (203) 499-5981 Cell: (203) 623-9270 Potkay, Peter M

Backing up Q files but not the LOG files

Hi, We're thinking about setting up replication for our queue manager to ensure that just the Q files are backed up but not the LOG files for the queue manager. This is being contemplated as it appears the log files are updated far more than the Q files as the LOG files are doing internal

Re: Backing up Q files but not the LOG files

Kulbir, You didn't say what platform you're doing this on. I do just mainframes, but expect you'd have the same problems on smaller ones. If you don't replicate the log files and you have any persistent messages on your queues when you go through your exercise below, then you'll have

SYSTEM.CSQOREXX.* queue not found

I have some messages going to DLQ with MQRC_UNKNOWN_OBJECT_NAME SYSTEM.CSQOREXX.xx. I know that these dynamic queues are created by CSQOREXX within the TSO panels . Do you know what special use of these panels could lead to these errors ? This e-mail message, including any attachments

Re: SYSTEM.CSQOREXX.* queue not found

These queues are normally created to receive responses from a command issued via the MQM TSO panels. If you issue a command and it takes a long time, and the response wait time expires, the belated response might not find a tempq anymore. As a result, it lands in the DLQ. IBM provided a DLQH,

Re: Backing up Q files but not the LOG files

You should check with IBM, however... The technique will work, but if an object is broken, then it will likely be broken forever. Also, there's no guarantee the queue file will accurately reflect the state of the queue. That is, there may be messages that would have been backed out and synced

Re: SYSTEM.CSQOREXX.* queue not found

These are generated when you time out on a command based on the value specified on the first panel. Glen Shubert [EMAIL PROTECTED] Associate Director TSYS - MQSeries Technical Support Nguyen DT [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 11/17/04 12:55 Please respond to

cobol copybook inside CDATA

Title: cobol copybook inside CDATA Hi, I have to transform a Cobol copybook to XML in the broker flow. The output message would look as follows ?xml version=1.0 encoding=UTF-8? xmlRequest xmlns=http://a.b.com/ns/ xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance

Re: Backing up Q files but not the LOG files

Kulbir, Again, I do mainframes. On the mainframe, if you have an out-of-sync condition between your page datasets and your logs, the queue manager will abend with a s6C6. I'm not sure if a queue manager would stay up on an small platform or not. If you don't replicate the queue datasets

Re: Receiver channel parameters mrrty and mrtmr

The classic example of this is for 3rd party connections (which for security reasons are usually dedicated to a singlebusiness partneror app). In situations where there is a gateway QMgr in the DMZ that serves multiple 3rd parties the channel retry can isolate the3rd partiesfrom one another.

Re: Backing up Q files but not the LOG files

What I don't understand here, is the purpose of the replication. Are we trying to retain backups of the qmgr's objects, or both the objects and the messages? If you are only trying to retain copies of the objects...

Re: Backing up Q files but not the LOG files

Thanks for the replies. We're testing this on Windows but are contemplating on doing this on Sun Solaris. We're using circular logging. I'm surprised the sequence of events worked, especially as we were using persistent messages. The reason we don't want to replicate the LOGs is because they

Mail Marshal at Standard Bank

Note to the list - I (and probably some of you as well) contacted the folks at Standard Bank and asked them to print the bad email address in their automated message. As you can see below, they were nice enough to comply and now we know the address that is generating all the replies. I have

Re: Backing up Q files but not the LOG files

We're trying to ensure we don't lose messages in Disaster Recovery situations. Our failover solution seems OK, we have a SAN configured to hold all queue manager details and that is accessible by another machine in the Veritas cluster if we need to failover. For DR we're looking to use another

Re: XML CDATA

-- Insert the input message tree as CDATA embedded XML in the messageData element set OutputRoot.XML.RibMessages.ribMessage.messageData.(XML.CDataSection) = BlobToChar(BITSTREAM(InputRoot.XML.*[1])); Raul L. Acevedo Senior IT Architect EAI Application

Re: Backing up Q files but not the LOG files

Kulbir, Persistent messages are written to the log, commited - then written to the queues. Without the log files, you risk losing inflight activity. Plain and simple. If the messages are not persistent - who cares if you loose them? If you have a redundant hardware solution, 2nd machine,