I am afraid 7.1.0.6 as target is correct, 7.1.0.5 just came out on the 9th
of June http://www-01.ibm.com/support/docview.wss?uid=swg27024302#7105
and think this one just didn't make the cut.
Michael
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
T.Rob
Sent: vrijdag 6 juni 2014 19:32
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: dmpmqcfg missing AUTHREC?
Awesome! Thanks for the pointer, Peter.
If anyone at IBM is listening, is 7.1.0.6 really the correct target?
Because Recommended Fixes http://www-01.ibm.com/support/docview.wss?rs=171
<http://www-01.ibm.com/support/docview.wss?rs=171&uid=swg27006037>
&uid=swg27006037 lists 7.1.0.4 as current version and 06 is two fix packs
distant. Seems odd.
Also, nothing in the TechNote says that the fix will include printing of
rules that have +none in them. For example,
setmqaut -n "**" +put +get +browse +inq
setmqaut -n "SYSTEM.**" +none
setmqaut -n "SYSTEM.ADMIN,.COMMAND.QUEUE" +put +get +browse +inq
Used to be we'd get back the first and last of these but not the one in the
middle responsible for protecting internal queues. Was that already fixed?
I don't remember and don't have time to go test just now.
Thanks - T.Rob
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Potkay, Peter M (CTO Architecture + Engineering)
Sent: Friday, June 06, 2014 12:52 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: dmpmqcfg missing AUTHREC?
This APAR webpage was published yesterday.
http://www-01.ibm.com/support/docview.wss?uid=swg1IT00612
<http://www-01.ibm.com/support/docview.wss?uid=swg1IT00612&myns=swgws&mynp=O
CSSFKSJ&mync=E> &myns=swgws&mynp=OCSSFKSJ&mync=E
. "PROBLEM DESCRIPTION:
. This APAR adds functionality to the dmpmqcfg command and also
. fixes some existing defects."
Peter Potkay
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
T.Rob
Sent: Thursday, March 13, 2014 1:21 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: dmpmqcfg missing AUTHREC?
I disagree about the RFE. Here's why.
Remember that saveqmgr was withdrawn because dmpmqcfg was supposed to
replace it, but dmpmqcfg doesn't provide all the same features. That's
unfortunate because the saveqmgr feature set was the embodiment of years of
customer feedback. The main thing saveqmgr lacked was support. The
supported thing lacks functionality and some of functionality it does
provide is broken. It would be one thing is we could choose between
unsupported saveqmgr versus supported but less functional dmpmqcfg but
saveqmgr was retired.
What about the claim that dmpmqcfg is not defective? If dmpmqcfg really is
working as designed, which is IBM's published policy as per the wording of
the Technote, think about what that actually means. All of the following
would have to be true:
. The feature set is the result of a conscious and deliberate
decision to provide a tool that backs up some but not all of the security
settings.
. Someone articulated a use case in which a partial backup of the
security profiles is the ideal solution. What exactly is that use case?
. The use alternate case for having a complete set of security
profiles must be believed to be insignificant.
. The feature set of saveqmgr, the tool replaced by dmpmqcfg, was
evaluated and found to be mostly puff.
Is this Bizzarro World? A decade ago "working as designed" meant that what
you wanted truly fell into the category of an enhancement. Today seems to
mean "it's broke and we don't have resources to fix it but we can't
acknowledge that." I'm not saying that's the case and I was never privy to
budget numbers, but the only use case in which dmpmqcfg is not broken is
that you simply do not care about security. Security isn't an enhancement.
It was the major theme of v7.1 and these changes are a huge step backwards.
To me, submitting this through the RFE process validates the dubious claim
that the tool is actually usable in its current state. It says customers
are OK with delivery of something that removes working and useful features
of a previous component, even if that action greatly increases operational
risk to our businesses or requires significant investment in retooling on
our part. Saying that dmpmqcfg is working as designed also accumulates more
technical debt in the product by shifting legitimate defect support to the
enhancement queue. Opening an RFE - overtly moving to IBM's enhancement
requirements farm rather than working it through defect support - says that
this shift of legitimate defects into the enhancement queue is acceptable.
Is that what we really want? Personally, I'd rather not encourage that
trend and will continue to pursue it as a defect. There's enough
accumulated technical debt in the product as it is, in my opinion.
-- T.Rob
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Tim Zielke
Sent: Thursday, March 13, 2014 11:59 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: dmpmqcfg missing AUTHREC?
I think we (MQ distributed administrators) need an RFE that requests that
IBM provides a tool/command that can exhaustively back up all the MQ objects
and security rules for a distributed queue manager. I am sure there are
better administrators than myself to state the appropriate requirements for
this RFE. If not, I will give it a shot in the near future. I will
definitely vote for anyone that submits this RFE, as should all other MQ
distributed administrators that want to fully back up/restore their queue
managers.
Thanks,
Tim
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
T.Rob
Sent: Thursday, March 13, 2014 9:32 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: dmpmqcfg missing AUTHREC?
I re-worked this email into a blog post that explains in much more detail
the issues and history. In testing, I discovered more problems with
dmpmqcfg that are not addressed by the Technote. Dynamic queues aren't the
only kind of object that doesn't get printed. Not by a long shot. If you
have gone to the trouble of locking down admin access per my presentations,
or anything more complex, there's about 90% likelihood that dmpmqcfg is
going to miss many of your security rules. Especially if you have a
cluster.
http://iopt.us/1kOG2V8
Kind regards,
-- T.Rob
From: T.Rob [mailto:t.rob-2T3zYZGRgog/u7dgPfZd+***@public.gmane.org]
Sent: Wednesday, March 12, 2014 13:53 PM
To: 'MQSeries List'
Subject: RE: dmpmqcfg missing AUTHREC?
Thanks for the link, Peter. Hopefully everyone will rate that Technote 1
star and leave a comment that amqoamd does NOT capture all the security
profiles either. For those who missed my previous email here's an
explanation.
If you are worried about security, then chances are you do not let adjacent
QMgrs administer the local QMgr. Otherwise compromise of any one node
compromises the entire network. To prevent an adjacent QMgr from
administering the local one, you probably set the MCAUSER of the
RCVR/RQSTR/CLUSRCVR channel with a low-privileged account. Then you
authorize it with a set of rules that look something like this:
# Allow MCAUSER to connect. Needs +set and +setall per IBM docs.
setmqaut -m QMGR -g mqmmca -t qmgr -all +connect +inq +set +setall
# Grant MCAUSER default policy of "allow all" to all queues. Channels
# put messages so no need for get, browse, etc. Also needs +setall.
setmqaut -m QMGR -g mqmmca -n '**' -t queue -all +put +setall
# Now deny access to administrative queues
setmqaut -m QMGR -g mqmmca -n SYSTEM.ADMIN.COMMAND.QUEUE -t queue -all +none
setmqaut -m QMGR -g mqmmca -n SYSTEM.DEFAULT.INITIATION.QUEUE -t queue -all
+none
A similar technique is usually granted to anything that needs to dynamically
resolve destinations. Many shops use similar rules on SVRCONN channels
because whitelisting every possible use case across many queues and many
people is too resource-intensive to not use generic grants followed by small
blacklist entries. This is a VERY common technique for any shop that needs
even slightly granular security.
The problem is that amqoamd does not record the lines with +none. It does,
however, happily record the lines where access is granted. So if you
restore a QMgr or for whatever reason run the output of amqoamd, your
application, users or even external business partners will be massively
over-authorized, even to the point of giving them full administrative
access. When I reported this some time ago I was told "working as designed"
and would not be fixed. Part of the justification for this was that amqoamd
is not a documented component. When I checked today on a v7.5 QMgr it still
has this behavior.
If you have WMQ installed on your Windows desktop, cut and paste this into a
command window to see for yourself:
crtmqm DUMMY
strmqm DUMMY
amqoamd -m DUMMY -s | findstr Guest
setmqaut -m DUMMY -p Guest -n ** -t queue -all +put +inq +dsp
setmqaut -m DUMMY -p Guest -n SYSTEM.ADMIN.COMMAND.QUEUE -t queue -all +put
setmqaut -m DUMMY -p Guest -n SYSTEM.CLUSTER.COMMAND.QUEUE -t queue -all
+none
amqoamd -m DUMMY -s | findstr Guest
Here is the output that I get with these commands:
C:\Users\T.Rob>amqoamd -m DUMMY -s | findstr Guest
C:\Users\T.Rob>setmqaut -m DUMMY -p Guest -n ** -t queue -all +put +get
+browse +inq +dsp
The setmqaut command completed successfully.
C:\Users\T.Rob>setmqaut -m DUMMY -p Guest -n SYSTEM.ADMIN.COMMAND.QUEUE -t
queue -all +put +inq +dsp
The setmqaut command completed successfully.
C:\Users\T.Rob>setmqaut -m DUMMY -p Guest -n SYSTEM.CLUSTER.COMMAND.QUEUE -t
queue -all +none
The setmqaut command completed successfully.
C:\Users\T.Rob>amqoamd -m DUMMY -s | findstr Guest
setmqaut -m DUMMY -n '**' -t queue -p ***@M4700 +browse +get +inq +put
+dsp
setmqaut -m DUMMY -n SYSTEM.ADMIN.COMMAND.QUEUE -t queue -p ***@M4700 +put
Notice what *doesn't* print? The blacklisted queue or queues with +none.
Congratulations. Run these commands on a newly built QMgr and Guest has
access to SYSTEM.CLUSTER.COMMAND.QUEUE - and any other objects where you set
+none. This is a lot more prevalent and leaves you a lot more exposed than
does the dmpmqcfg issue.
Kind regards,
-- T.Rob
T.Robert Wyatt, Managing partner
IoPT Consulting, LLC
+1 704-443-TROB
https://ioptconsulting.com
https://twitter.com/tdotrob
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Potkay, Peter M (CTO Architecture + Engineering)
Sent: Wednesday, March 12, 2014 13:10 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: dmpmqcfg missing AUTHREC?
A Tech Note was published today on the topic of dmpmqcfg and dynamic queues.
http://www-01.ibm.com/support/docview.wss?uid=swg21666771
<http://www-01.ibm.com/support/docview.wss?uid=swg21666771&myns=swgws&mynp=O
CSSFKSJ&mync=E> &myns=swgws&mynp=OCSSFKSJ&mync=E
Peter Potkay
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Tim Zielke
Sent: Thursday, March 06, 2014 6:10 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: dmpmqcfg missing AUTHREC?
I did take your previous e-mail the way you just elaborated. Or at least, I
think I did. J. Basically, we are not being given one tool from IBM that
holistically gives you a back up for your 7.1/7.5 queue manager security
rules on the distributed platform.
Using the following 2 commands in conjunction are very close, I believe:
dmpmqcfg -m qmgr -a
amqoamd -m qmgr -s
But even that would miss the scenario where you have just a +none grant on a
queue name that would only cover PERMDYN queues.
However, the approach above is good enough to back up all of our queue
manager security rules for distributed.
Things are a lot easier on z/OS, where your queue manager security rules
exist in an external security manager like RACF. J
Thanks,
Tim
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
T.Rob
Sent: Thursday, March 06, 2014 2:32 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: dmpmqcfg missing AUTHREC?
I think you misunderstood me. At this point Peter was told "working as
designed" for the defects in dmpmqcfg, and I was told "working as designed"
for the defects in amqoamd. So even though it is fully supported, if you
disagree with IBM as to whether the tool is producing complete output, you
are out of luck.
I'm not suggesting these were appropriate responses from IBM. I am at this
moment in a customer's offices explaining that NO SINGLE IBM WMQ TOOL can
back up something as fundamental as authorization control lists. I have
pointed them to Capitalware's 3rd Party Tools index and pointed out MQSCX,
MQDocument and Visual Edit as candidates that are more comprehensive and
whose vendors are likely to see an incomplete config backup as a defect.
Coincidentally, they have a meeting with their IBM account rep tomorrow
which should be VERY interesting. I suggested they webcast it and sell
tickets but it's kinda short notice.
-- T.Rob
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Tim Zielke
Sent: Thursday, March 06, 2014 14:13 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: dmpmqcfg missing AUTHREC?
Hi T.Rob,
Thanks for the information. We were going to do an approach like the
following (similar to what you mentioned at the end of your note) to back up
the queue manager, which should cover your +none grant use case:
dmpmqcfg -m qmgr -a
amqoamd -m qmgr -s
Also, this was what IBM said about amqoamd from the PMR:
"The amqoamd utility is not actually documented, but it does have a
comprehensive usage statement, and it is fully supported."
Regarding the statement that dmpmqcfg is working as designed, if the design
requirement was to provide an exhaustive back up/restore process for you
queue manager, I would disagree with this assessment. However, I have been
given another approach (albeit with two commands, instead of one) that does
meet our back up/restore queue manager needs.
Thanks,
Tim
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
T.Rob
Sent: Thursday, March 06, 2014 10:19 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: dmpmqcfg missing AUTHREC?
Unfortunately, amqoamd is not considered a user-facing tool that is
maintained as part of the release. When I inquired about the problem I was
told it would not be fixed. A quick check with a dummy v7.5.0.2 QMgr on
Windows shows it still exists. The issue with it was this:
C:\Users\T.Rob>amqoamd -m DUMMY -s | findstr Guest
C:\Users\T.Rob>setmqaut -m DUMMY -n ** -t queue -p ***@M4700 -all +put
+get +browse +inq +dsp
The setmqaut command completed successfully.
C:\Users\T.Rob>setmqaut -m DUMMY -n SYSTEM.** -t queue -p ***@M4700 -all
+none
The setmqaut command completed successfully.
C:\Users\T.Rob>amqoamd -m DUMMY -s | findstr Guest
setmqaut -m DUMMY -n '**' -t queue -p ***@M4700 +browse +get +inq +put
+dsp
(I used a principal because I'm on Windows and know there's a Guest acct
already created. Please don't EVER use -p without @domain at the end and
never on *NIX platforms!)
The idea here is that we first grant broad auths to all queues, then
restrict access to the command queue. This is the standard way that we keep
adjacent QMgrs from administering the local QMgr. But amqoamd does not
print setmqaut commands with +none. It treats them as a no-op and skips
printing them. The result is that if you ever used the captured setmqaut
commands to rebuild a QMgr it would massively over-authorize. The setmqaut
granting access would be executed but the one restricting access on the
specific queue would not.
I guess to get all the objects, you'd have to use MQSCX from MQGem. The
response I got back yesterday off-list from Paul said it would work.
You might also try doing a dmpmqcfg -o 1line and an amqoamd then combine
them and pipe through sort | uniq to get a complete set of objects and
auths.
Isn't this wonderful? And working as designed.
-- T.Rob
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Tim Zielke
Sent: Thursday, March 06, 2014 9:12 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: dmpmqcfg missing AUTHREC?
The service request came back with the statement that dmpmqcfg is working as
designed, and the command "amqoamd -m qmgr -s" can be used as an alternative
to exhaustively back up the security rules for your distributed queue
manager. I verified that amqoamd does include the security rules that
dmpmqcfg was missing. We will be changing our queue manager back up/restore
strategy to include this amqoamd step. I also added a feedback comment to
the MQ infocenter that the back up/restore documents that talk about using
"dmpmqcfg -m qmgr -a" should highlight that this will not exhaustively back
up your security rules, and that amqoamd is a tool that can be used to
accomplish that task.
Thanks,
Tim
From: Tim Zielke
Sent: Wednesday, March 05, 2014 10:10 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: RE: dmpmqcfg missing AUTHREC?
I submitted my PMR, so I will see what happens. I also just noticed that
dmpmqcfg does not seem to support the ability to create local queue
definitions from PERMDYN queues (like the -p option of saveqmgr). Or
someone please tell me if I am missing it.
I updated Peter's RFE mentioned below with a comment to also enhance
dmpmqcfg to support the -p option of saveqmgr.
Thanks,
Tim
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Neil Casey
Sent: Monday, March 03, 2014 2:36 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: dmpmqcfg missing AUTHREC?
Hi Tim,
Peter Potkay opened a conversation on the list about this issue last year,
and then raised a PMR.
This was his note at the end of that conversation:
"The PMR concluded that dmpmqcfg is working as designed and that I should
open an RFE.
Here is the link to vote for the RFE to update dmpmqcfg to capture authority
records for profiles for names of queues that don't exist yet.
<http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=41015>
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=41015"
So it appears that the best you can do is vote for the RFE, because the
service process is clearly broken. There is no way that it makes sense for
dmpmqcfg to NOT dump some of the auth records, just because they don't match
an existing queue.
Regards,
Neil Casey
Syntegrity Solutions
On 4 Mar 2014, at 1:26 am, Tim Zielke <tim.zielke-PR+tvw7B/***@public.gmane.org> wrote:
Hello,
I ran across something recently, and was curious if any other MQ
administrators were aware of this or had a workaround for it.
If you have the set up like the following:
DEFINE QMODEL('HLQ.00000.Q1.MODEL')
And your applications will create queues from this model like follows:
HLQ.12345.Q1
HLQ.12346.Q1
etc.
And you create an authority record like the following to cover it:
setmqaut -t q -n 'HLQ.*.Q1' -g mygroup +get +put +inq +browse
then dmpmqcfg does not include that authrec that was created above when you
do a back up of the queue manager like:
dmpmqcfg -m qmg1 -a
The command dspmqaut does report this authrec, correctly.
Does this look like a bug to anyone with dmpmqcfg? Or is this
known/expected behavior?
I checked the MQ 7.5 manual and did not see anything to suggest that this is
expected behavior.
I am probably going to open a service request about it, but just curious if
anyone else had seen it or was aware of it.
Thanks,
Tim Zielke
CICS/MQ Systems Programmer
Aon
_____
<http://listserv.meduniwien.ac.at/archives/mqser-l.html> List Archive -
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> Manage Your
List Settings -
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries> Unsubscribe
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at
<http://www.lsoft.com/resources/manuals.asp> http://www.lsoft.com
_____
List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries>
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
<http://www.lsoft.com/resources/manuals.asp>
_____
List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries>
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
<http://www.lsoft.com/resources/manuals.asp>
_____
List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries>
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
<http://www.lsoft.com/resources/manuals.asp>
_____
List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries>
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
<http://www.lsoft.com/resources/manuals.asp>
_____
List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries>
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
<http://www.lsoft.com/resources/manuals.asp>
_____
List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries>
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
<http://www.lsoft.com/resources/manuals.asp>
************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/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 e-mail, delete this communication and destroy all copies.
************************************************************
_____
List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries>
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
<http://www.lsoft.com/resources/manuals.asp>
_____
List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries>
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
<http://www.lsoft.com/resources/manuals.asp>
_____
List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries>
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
<http://www.lsoft.com/resources/manuals.asp>
_____
List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries>
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
<http://www.lsoft.com/resources/manuals.asp>
************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/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 e-mail, delete this communication and destroy all copies.
************************************************************
_____
List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries>
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
<http://www.lsoft.com/resources/manuals.asp>
_____
List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries>
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
<http://www.lsoft.com/resources/manuals.asp>
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html