We do it, and do it a lot. Your MD's
format must be set to NONE. If the messages can exceed 4M, make sure that
the queue definition, xmit queue and channels all can handle it. Consider
sending the big messages via their own channel, so as not to interfere
with more normally sized traffic. Or, cons
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
The channel should have stopped, and
the messages should still be sitting on the transmit queue.
Bill Anderson <[EMAIL PROTECTED]>
Sent by: MQSeries List <[EMAIL PROTECTED]>
10/25/2004 03:38 PM
Please respond to
MQSeries List <[EMAIL PROTECTED]>
To
[EMAIL PROTECTED]
cc
Subject
W
After thinking all of this through,
we've decided to use RFH2 in a pilot application. It seems to be exactly
what we need. The application team was starting to design a solution that
Mime-encoded the binary data, but RFH2 makes much more sense.
marty <[EMAIL PROTECTED]>
Sent by: MQSeries Lis
tralia Bank
Southern Star Technology
WebSphere MQ Support
1/122 Lewis Rd Wantirna South
office. +61 3 9886 2375 (x82375)
mobile. +61 414 615 334
Jim Ford
<[EMAIL PROTECTED]
M>
To
t curious about the original decision to have multiple messages
coming from the same app.
Regards
Tim A
-Original Message-
From: Jim Ford [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 5 October 2004 8:55 AM
To: [EMAIL PROTECTED]
Subject: Re: Clustering w/ Message Affinity
But whether we put to on
ay you go. Even the above
can have problems in that the queue will need to be indexed to get reasonable
performance if there are a large number of messages on the queue at any
one time, which of course has an overhead of its own :(
Regards
Tim A
-Original Message-
From: Jim Ford [mailto:[EMA
ll these QMs, so the app wouldn't have to change as you add / remove
QMs. At least you will get the benefit of reduced Administration for queues
and channels.
-Original Message-
From: Jim Ford [mailto:[EMAIL PROTECTED]
Sent: Monday, October 04, 2004 5:23 PM
To: [EMAIL PROTECTED]
es.
Now both messages will always
be on Q1 / Q2 on the same QM. But you will get a random QM each time.
-----Original Message-
From: Jim Ford [mailto:[EMAIL PROTECTED]
Sent: Monday, October 04, 2004 4:55 PM
To: [EMAIL PROTECTED]
Subject: Clustering w/ Message Affinity
We don't use clu
We don't use clustering at our site,
but are considering it for a couple of high volume applications. Some of
these applications, though, use correlation ID to match messages on two
different queues.
To be more specific, a binary message
is put to Q1 under syncpoint. A second message is put to Q2
It's always worked that way, and it's
always been documented that it works that way. So I think it's extremely
unlikely that IBM would consider it to be a bug.
"Wright, Tim (AFM)"
<[EMAIL PROTECTED]>
Sent by: MQSeries List <[EMAIL PROTECTED]>
09/29/2004 09:15 AM
Please respond to
MQSeries
and put queue options can be used to validate this?
>
> Your answers are appreciated.
>
> Thanks,
>
> [attachment "InterScan_Disclaimer.txt" deleted by Jim Ford/MGIC]
Instructions for managing your mailing list subscription are provided in
the Listserv General Users
you to wade through all the WebSphere stuff to find
them.
- Bruce
Giordano
Jim Ford <[EMAIL PROTECTED]>
To:
[EMAIL PROTECTED]
Sent by
Try this:
http://www-306.ibm.com/software/integration/mqfamily/library/manualsa/
And sure, IBM's site may be really disorganized, but it's really slow.
IBMLink and IBMLink 2000 have to be the absolute worst way to search for
product defects I've seen.
There was a problem (IC39679) with CSD 6 for Windows that caused the
product to not save configuration data. So after a reboot, MQ will have
lost port and protocol info for the listener. It's fixed at newer
maintenance levels.
"Bender, Alan"
<[EMAIL P
Unless, of course, you don't want to read discussions about any of this,
either.
"Dawson, John"
<[EMAIL PROTECTED]To: [EMAIL PROTECTED]
IGROUP.COM> cc:
Sent by: MQSeries S
QSeries List
I am afraid that it is not a DB2 problem. It is a problem with a
developer not understanding the concepts and rules governing a
logical unit of work in a CICS transaction.
Cheers...
Jim Nuckolls
Jim Ford wrote:
> I posted a question to the list last week about help in debuggi
I posted a question to the list last week about help in debugging a CICS
app that's having problems. More than anything else, I was venting my
spleen. But since I posted it, I thought I'd post the cause of the problem,
now that I've found it.
The top level program in the problem transaction insert
One of our less savvy application teams has put together a big, clumsy app
that is having problems. It's big and clumsy enough that they are having
problems describing it to me. As near as I can tell, they have an
MQ-enabled CICS transaction. This transaction does an EXEC CICS LINK to a
few subprog
Is it possible that the program is closing the queue after each message?
That would cause what you're seeing. Check the IPPROCS for the queue; is it
60 or 1? Or 0?
Lawrence Coombs
<[EMAIL PROTECTED]To: [EMAIL PROTECTED]
Did you hide the MQSeries task bar icon? On the task bar, right click on
the "Websphere MQ" icon and select "Hide" from the menu. That stops
amqmtbrn.exe, and that has been enough to get me over the hump.
Roger Lacroix
<[EMAIL PROTECTED]To:
Before you do the Browse(MQGET), make sure that you set the correlation ID
to MQCI-NONE and the message ID to MQMI-NONE in the appropriate message
descriptor. If there's data in either of these things you're telling MQ to
get a specific message with that ID. So if one or both contains residual
data
Use the -s flag with amqoamd. That tells it to write out setmqaut commands,
which you can save to a file. Then you can do whatever you need to with
them, including run them.
"Ward, Mike S"
<[EMAIL PROTECTED]>To: [EMAIL PROTECTED]
We use runmqtmc on Solaris 8 with the 5.3 client, and there's no problems
at all. We previoulsy used it on 5.2 and Solaris 2.6, and that worked as
well.
To be honest with you, we never saw the note that said "AIX clients only"
in the Admin manual. Runmqtmc ships with the Solaris client, and we nev
The other situation that comes to mind is if messages on a queue have
differing priorities. If your delivery sequence is FIFO, just browsing the
first message on the queue will delete any expired messages. But if the
delivery sequence is priority, you could concievably have low priority
expired mes
irectory somewhere -
Anybody else explored.
Cheers and thanks once again for the forum to bring out such hidden
treasures.
Rao
-Original Message-
From: Jim Ford [mailto:[EMAIL PROTECTED]
Sent: 6 April 2004 2:24 AM
To: [EMAIL PROTECTED]
Subject: Re: MQ Security data in SYSTEM.AUTH.DATA.QUEUE
I think that the user's primary group is the one that is given access. So
using the newgrp command doesn't have any effect.
"Wyatt, T. Rob"
<[EMAIL PROTECTED]To: [EMAIL PROTECTED]
MERICA.COM> cc:
When a queue is defined, group mqm always gets full access. The second
group is the default Unix group of the person that defined the queue.
That's why when you use the mqm ID to define queues there's only one entry.
The mqm ID's default group is mqm.
Because of this it's probably a good idea to h
And that means there's one less sponsor at the annual Technical Conference.
-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Roger
Lacroix
Sent: Thursday, April 01, 2004 10:27 AM
To: [EMAIL PROTECTED]
Subject: News: IBM buys Candle
All,
Now here's an int
guess, did you try to use the -remove switch?
setmqaut -m QM1 -t q -n your.queue.name -remove -p theIDyouWantToBoot
-Original Message-
From: Jim Ford [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 16, 2004 11:12 AM
To: [EMAIL PROTECTED]
Subject: Authorization Question
I'm attempt
I'm attempting to use generic profiles on our 5.3 distributed queue
managers. It's an overdue feature that should significantly simplify our
security model. But for our existing queues, there's a problem.
It looks like there's no way to remove a group from a queue's access list.
If you do a setmqa
The way this is generally done is to copy the incoming ReplyToQ to the
ObjectName of the Object Descriptor, and ReplyToQMgr to the ObjectQMgrName
of the OD. Then do your MQPUT1. MQ will put the message on the transmit
queue with the same name as the ObjectQMgrName. What's in the RTQ and RTQM
of the
I would say that you have an application that repeatedly opens a remote
queue without closing it.
Jeff A Tressler
<[EMAIL PROTECTED]To: [EMAIL PROTECTED]
>cc:
Sent by: M
We had that problem on a few machines, all running NIS+. There were three
causes.
On one machine, the mqm ID didn't have authority to read /etc/passd (or
/etc/group, I forget).
On another, /etc/nsswitch.conf was messed up. I never got a clear answer as
to what was wrong, but I believe the config
Can it be done asynchronously? In other words, must the user wait around
for the DB update? If not, as soon as the puts complete, they are done.
The concept of putting a final triggering message out ensures that nothing
happens on the backend until all 10,000 rows have been sent. Consider a
traile
It does seem odd, but also kind of useful. To me it means that you can have
a class of message that are sort of persistent, but any logging is deferred
until the qmgr shuts down. So you get the performance benefits of a NP
message yet there's persistence, too. I suppose it means that the shutdown
t
mqm.dll is the server's DLL for API calls. mqic.dll is the one that handles
clients.
"Heggie, Peter"
<[EMAIL PROTECTED]To: [EMAIL PROTECTED]
NGRID.COM> cc:
Sent by: MQSeries
Are you sure that you set it to the name of the queue? I don't know how
Java uses it, but every other language needs the handle or object not the
name. Which means that the queue who's context is to be passed must have
been opened with MQOO_SAVE_ALL_CONTEXT, or some other context option.
But Java
ic error, and to reissue the get
with the larger buffer. But if it can simply reissue the MQGET with a
bigger
buffer, why didn't it just issue the GET with the biggest possible buffer
it
can handle in the first place? And sooner or later, a message will land
thats bigger than that, unless your a
We follow those same rules, and have written a wrapper to enforce them. It
*almost* always does the trick, but not always. The problem is when the
application encounters a message that is bigger than the buffer length that
was specified in the MQGET. In that case, a a reason code of 2080
(MQRC_TRUN
00C60004 means:
Explanation: MQSeries was unable to load the message table (CSQFMTAB).
Module: CSQFMGIN
System Action: MQSeries terminates.
System Programmer Response: Ensure that the message table is in the
required library (SCSQANLx, where x is your national language letter),
and that it
To "fix" these long URLs, check out http://tinyurl.com. It's a clever
little way to get around the problem.
"Wyatt, T. Rob"
<[EMAIL PROTECTED]To: [EMAIL PROTECTED]
MERICA.COM> cc:
CALL data-name is dynamic.
CALL 'PROGRAM' is dynamic if compiled with the DYNAM compiler option.
CALL 'PROGRAM' is static if compiled with the NODYNAM compiler option.
Dave Adam
<[EMAIL PROTECTED]To: [EMAIL PROTECTED]
Isn't AMI on its way out? I seem to remember hearing that IBM was dropping
support for it.
"Schiradin,Roland
HG-Dir itb-db/dc" To: [EMAIL PROTECTED]
<[EMAIL PROTECTED]cc:
IPZIGER.DE>
The first four characters of the RACF profile are the name of the MQSeries
subsystem. So it's very possible that the CITT00 ID has access to
MQSA.INITQ.** (for example), but it's not on the access list for
MQSB.INITQ.**. WHich is what the error says.
Or... if the ID was recently added to MQSB.INIT
No, but I'm trying to figure it out myself. We're running in 'end-to-end'
mode, which I guess means that the scheduling info is stored on the
mainframe, and I need to use mainframe techniques to get the jobstream
scheduled. Is that your environment, too?
"Jose, Prince"
This really should work without coding exits. My Windows ID is
"nthomdom01\ford". When I connect to Unix as a client, authentication is
done using my Unix "ford" ID just fine. I can secure queues based on ford's
group membership. We have spaces in the SVRCONN's MCAUSER field, an we
don't use exits,
he remote queue could be the job name. The triggered
program could use that message to perform the "demand in" process. How the
program actually does the "demand in" request can run a gamut of choices,
depending on the product's API, your ability to run APF
Please respond to MQSeries
List
Jim,
You state that you need to "demand in" a Solaris job when messages hit a
Solaris queue. Isn't that exactly what triggering does? I think I must be
missing something here.
Jim Ford
port message)
Jim Ford
<[EMAIL PROTECTED]To:
[EMAIL PROTECTED]
M> cc:
Sent by: MQSeriesSubject: Triggering Design
Question
List
I got an interesting triggering dilemma. The short description of the
dilemma is that when a message arrives on a Solaris queue, I need to
trigger an OS/390 process. The longer description follows...
We've purchased Tivoli 8.2, which is allows us to run a unified scheduling
system between Unix and
Please respond to
MQSeries List
Jim,
I think the parameters that you have listed control
the threading of the amqzlaa0 agent processes and not
the amqrmppa processes. I thought the channel pooling
parameters had PP on the front of them, but I may be
wrong.
Ron
--- Jim Ford <[
We're on 5.3 and Solaris, and we've started using the multi-threaded
listener on the machines that handle our client connections. One thing that
we've noticed is that an amqrmppa process (the channel receiver) seems to
always handle 64 threads. When that number is hit, another amqrmppa is
started.
They are defined in /opt/mqm/inc/cmqc.h on Solaris. Do a grep for MQFB_ and
you will see them. And the Programming reference manuals also describe the
MQFB_ constants.
[EMAIL PROTECTED]
COM To: [EMAIL PROTECTED]
Well, one way to do it is to do a "dis q(*)" in runmqsc, then examine the
output looking for a left bracket ('['). Runmqsc reports damaged objects
with the queue name followed by a reason code in brackets.
After a disk failure on a dev Unix box last month, I piped the runmqsc
output to grep, picki
5.3 qmgr
configuration I have default transmit queue defined?
Since I have two different sender channels using 2 different transmit q I
Didn't defined any default transmit q in qmgr.
But my remote queue in 5.3 qmgr does have transmit queue defined.
Thanks
Alex.
-Original Message-
Fro
If you MQOPEN the ReplyToQ and ReplyToQMgr what actually happens is that an
open is attempted for a transmit queue with the same name as the
ReplyToQMgr. You should check that the 5.3 qmgr does in fact have the
transmit queue defined.
This is good news for us, but not great news. The Notes guys want to plow
ahead with R6, but we've got a slew of MQLSX apps. This doesn't help that.
But the MQ guys (me) want to plow ahead with 5.3, and this does let me do
that. The way I read it, anyway.
Jim Wendorf
We have several hundred users that start an MQ client app as soon as they
arrive in the morning, and shut it down when they leave for the night. They
are connected the whole time, and it doesn't cause any problems. As long as
both halfs of the connection are "alive" (even if they're not especially
I checked how we define security in this situation, and for the queue
manager object, we give the MCAUSER:
connect
inq
set
setall
setid
As I recall, we also got a security the first time we tried to start one of
these. I examined the security event in SYSTEM.ADMIN.QM
abcuser will also need +set on the queue manager object. This authority is
needed in order to start a channel.
"Potkay, Peter M
(PLC, IT)" To: [EMAIL PROTECTED]
<[EMAIL PROTECTED]cc:
ge happens at the same time?
Joan Hughes
(Embedded image moved to file: pic18467.gif)
Jim Ford
<[EMAIL PROTECTED]To:
[EMAIL PROTECTED]
M> cc:
Sent by: MQSeries
<[EMAIL PROTECTED]>
10/28/2003 09:21 AM
Please respond to MQSeries
List
Are they any other non-MQ apps/processes running during the slowdowns? Any
candidates that might hog the cpu?
I posted a week or so ago about slow performance on MQPUTs, which I was
convinced was caused by replication tasks on our EMC SAN. It was sporadic,
and unpredictible, but when slowdowns occured they did correlate with some
SAN work. When I reviewed the code, though, I found that they were actually
d
I knew this, because I've got a problem open with IBM, and they have
already recommended that I put on csd05 (I'm at csd04 now). There was
nothing specific in csd05 that addressed my problem, though. I'm pretty
sure that IBM releases these every so often just so support can just tell
customers to g
No, that's working as designed. The Programming Reference manual says "An
attempt to put a message on a queue that
already contains MaxQDepth messages fails with reason code MQRC_Q_FULL."
But once the application has received the 2053, it can then do whatever it
wants with the message (actuall, it
problems (like 2-minute delays). If your
description is correct, it will. Then give it to your storage team and ask
them for a cure. No MQ involved.
Hopefully this will help,
Pavel
Jim Ford
<[EMAIL PROTECTED]To:
[EMAIL PROTECTED]
ne: +01-412-893-1659
Fax: 412-893-1844
* mailto:[EMAIL PROTECTED]
-Original Message-
From: Jim Ford [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 15, 2003 3:20 PM
To: [EMAIL PROTECTED]
Subject: Re: MQ "Problem" - Advice Needed
Actually, they agreed to do that. The
Please respond to MQSeries
List
Jim,
If they're willing, have them turn off replication. Show them the audit
numbers from your apps. Turn on replication and show them the audit
numbers again.
Jim Ford
We have periodic "pauses" on some of our Solaris servers. CPU usage drops
down to nothing for a couple of minutes, then things begin to function
normally again. Many of our MQ apps on Solaris were written in the last two
years, and maintain exhaustive audit trails, Those audit trails showed that
th
Right click on the MQSeries icon on the task bar, and select "Hide" from
the menu. This terminates amqmtbrn, and that let us complete the install.
Francois Van der
Merwe1 To: [EMAIL PROTECTED]
<[EMAIL PROT
We are successfully sending and receiving binary files using VB. We had
some problems initially, too, though. If I recall correctly, it wasn't the
fault of MQ. Instead, it was because the VB program read in the file before
writing it to the queue, and the way it read it caused VB to translate the
i
If I add this parameter to qm.ini, does it take effect immediately, or must
I recycle the queue manager?
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 Perl interface to MQSeries has to decide if it's running on a client or
server machine.
For Unix, the method it uses is to look for a directory named
/var/mqm/qmgrs/@SYSTEM. If it exists, it's a server install, else a client
install.
For Windows, the code looks into the MQ portion of the regis
Actually, 104,857,600 is exactly 100 mb (100*1024*1024).
"Wyatt, T. Rob"
<[EMAIL PROTECTED]To: [EMAIL PROTECTED]
MERICA.COM> cc:
Sent by: MQSeries Subject: Re: Websph
Are you sure that you're getting the 2030 on the get? The reason I'm asking
is that 2030 is a reason code associated with puts, not gets. While your
queue may be "big enough," I would verify that the MAXMSGL parameter for
the output queue is also big enough. Generally, this parameter defaults to
4
Please respond to
MQSeries List
How does CSQUTIL react against the
queue?
COPY QUEUE(APPLICATION.DLQ) DDNAME(FILEOUT)
EMPTY QUEUE(APPLICATION.DLQ)
sages.
Rick
|-+--->
| | Jim Ford <[EMAIL PROTECTED]>|
| | |
| | Sent by: MQSeries List |
|
EMPTY QUEUE(APPLICATION.DLQ)
bobbee
>From: Jim Ford <[EMAIL PROTECTED]>
>Reply-To: MQSeries List <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: OS/390 5.2 - Stuck Message!
>Date: Mon, 15 Sep 2003 11:03:34 -0500
>
>One o
Well, neither of your scenarios are specific to batch processing. We've
seen several instances where a poorly coded app gets the 'truncated
message' error, ends, and is restarted. They've all been on Unix or CICS,
tho. And while we've never seen what you describe in your second scenario,
it could h
One of our application DLQs seems to have a message "stuck" on it. We ran
the product's Dead Letter Handler (CSQUDLQH), and after it processed a few
messages it appeared to loop. I tried to use Candle's PQEdit utility to
look at the contents of the queue, and it looped too. Then I ran a simple
brow
Are these apps connecting using the default queue manager? If so, I'll bet
that mqs.ini is used to find that queue manager's name.
Jeff A Tressler
<[EMAIL PROTECTED]To: [EMAIL PROTECTED]
>cc:
I totally agree. Our network is in a constant state of change, but our host
names change much less frequently. So I get to ignore most of the things
that change here. I doubt that there's any appreciable response time hit
either, because I would assume that the host-to-IP translation only is done
a
Nastel's MQControl and Message Explorer let you do that (www.nastel.com).
Vivekananda
DoraswamyTo: [EMAIL PROTECTED]
<[EMAIL PROTECTED]cc:
BM.COM> Subject: Acc
While researching a performance problem on a Solaris server, I noticed that
the queue manager had over 1,100 temporary dynamic local queues open. I did
a "dis ql(amq.*)" to come up with this number. This number steadily
increases, but I expect it to drop tonight when some of these processes
end. Ob
I doubt that MQSeries is spending many cycles managing junk. But if a
message really does become junk after a certain amount of time, then the
message's Expiry time should be set to that time.
If you keep MQ down on the mainframe until CICS comes up, then this 'junk'
is just accumulating somewher
Problems storing
it in
a DB? Are you hitting a CPU limit? An I/O subsystem limit? Does
running
multiple processes against the queue help?
Regards
Tim A
Jim Ford
<[EMAIL PROTECTED]To:
[EMAIL PROTECTED]
M>
o
MQSeries List
Why queue it up in MQ? As I said in a previous reply its fairly simple
to
modify you app so the delivery is paced and continuous.
Regards
Tim A
Jim Ford
<[EMAIL PROTECTED]To:
[
conds and
retry). or - if the
message sequence does not matter - you could use multiple channels
with
multiple
transmission queues. but in every case you must put some logic into
your
sending application program to "switch" to the other xmit queue (use
another
remoteq).
Regards, Stefan.
then in Retry for relatively short period of
time. By the time I get around to trouble shoot
I have usually missed the 'Retry' phase.
-Original Message-
From: Jim Ford [mailto:[EMAIL PROTECTED]
Sent: Friday, August 01, 2003 2:40 PM
To: [EMAIL PROTECTED]
Subject: Re: Channel Retrie
In a previous thread, I mentioned that we are sending gobs of BLOBs
from the mainframe to a Unix machine. The mainframe side will be
putting the messages far faster than the Solaris side will be
consuming them. So we want to queue up as much data in the xmitq as we
can, and let MQSeries deliver it
Actually, you also see value of these parameters when the channel is
in RETRY status. Your example shows the channel in STOPPED status, but
the values aren't meaningful then. Only when the channel is retrying.
Bob Kasischke
<[EMAIL PROTECTED]T
P/IP
sniffer
over the line which usually tells us exactly what is going on and then
we
can address it. You can also run an MQ comm trace on both sides to
see what
is happening and why.
Lynn
-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Jim
Ford
Sent: Wed
;If you want to use individual queues that hold more than 2 GB of
data, you
must mount the file system with the largefiles option."
-Original Message-
From: Jim Ford [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 30, 2003 1:17 PM
To: [EMAIL PROTECTED]
Subject: Re: Channel Slowdo
xmitq
and
flowing into the page sets. You could up the buffers and try
compressing
the data (if it isn't already compressed).
Jim Ford
<[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
OM> cc:
07/30/2003 11:37 AM
Please respond to
MQSeries List
Do any messages at any point go to the DLQ on the Solaris side?
-Original Message-
From: Jim Ford [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 30, 2003 12:28 PM
To: [EMAIL PROTECTED]
Su
We're trying to use MQSeries to send large amounts of LOB data from
MVS (MQ 5.2) to Solaris (MQ 5.3, CSD 4). It's designed so that we have
is a single batch program that's going through archive tapes of LOB
data, writing each file as a message to a remote queue. On the Solaris
side, the messages ar
The thing that was holding up the install for us was amqmtbrn.exe.
This is the executable behind the MQSeries icon on the task bar. If
you right click on the icon, and select "Hide," the executable will
end and you may be able to install the CSD. It worked for us.
"Heggie,
In our case, we need to store loan-related documents for 7 years.
These are things like HTML, TIFs, Word docs, etc., and can be as big
as 40M although most of them are substantially smaller. Our client
application is totally MQ-centric (the developers love the product),
and they use MQ to save the
I;m not sure what's confusing you about it. Paraphrased, it means that
any app that's got the proper authorization can delete the permdyn
queue by using the right MQCLOSE options. But the creating app, even
if it wasn't given +dlt via setmqaut, will be able to delete the
queue.
1 - 100 of 176 matches
Mail list logo
