date:20030709

Can you point me to some documentation.

-Original Message-
From: peter d [mailto:[EMAIL PROTECTED]
Sent: 09 July 2003 06:45
To: [EMAIL PROTECTED]
Subject: Re: MQ and LDAP

Emile, i work with a product called QN-AppWatch from Reconda International.
It works in a similar environment to what you suggested in your post.
Perhaps this will help you adhere to the environment you specified.

I'm not sure from your post if you are trying to work with specific access
for admin purposes to your MQ environment, or if you just need code to
authenticate against LDAP within an application (there are Java libraries to
accomplish this).

If the reason is the former (access for admin purposes) then:

1- QN-AppWatch is browser based, so uses Apache as the HTTP listener (it
could also use the Apache with WAS).  So it is platform independent (AIX,
Solaris, HP, Linux, Windows, OS390, etc.)
2- It can authenticate users against an LDAP directory (i.e. Netegrity) to
"authenticate" the user to its environment.
3- Once in the environment, user's are assigned to PROJECTs - which are a
kind of 'sandbox' as to what the user/admin can do (which Qmgrs, channels,
queues) in their sandbox.
4- It has further persmissions (i.e. read, write, delete, admin) in order to
allow certain users in the project the permissions to MQobjects and messages
within that sandbox.
5- Lastly, it will LOG any actions to these objects.

regards, peter d.

-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Kearns,
Emile E
Sent: Wednesday, July 09, 2003 9:54 AM
To: [EMAIL PROTECTED]
Subject: Re: MQ and LDAP
Importance: High

I would like to do user authentication but NOT at a UNIX OS Level. I thought
if LDAP or something similar exists like in the case of WAS.

-Original Message-
From: David C. Partridge [mailto:[EMAIL PROTECTED]
Sent: 09 July 2003 03:30
To: [EMAIL PROTECTED]
Subject: Re: MQ and LDAP

Emile,

I don't quite understand the question.   SSL supports LDAP for retrieving
CRLs, but I don't think that's what you're getting at.  Do you think you
could give us a bit more to chew on?

Thanks
Dave

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

For information about the Standard Bank group visit our web site
www.standardbank.co.za

Disclaimer and confidentiality note

Everything in this e-mail and any attachments relating to the official
business of the Standard Bank Group Limited  is proprietary to the group.
It is confidential, legally privileged and protected by law. Standard Bank
does not own and endorse any other content. Views and opinions are
those of the sender unless clearly stated as being that of the group.The
person addressed in the e-mail is the sole authorised recipient. Please
notify the sender immediately if it has unintentionally reached you and do
not read, disclose or use the content in any way.
Standard Bank can not assure that the integrity of this communication has
been maintained nor that it is free of errors, virus, interception or
interference.
II

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

For information about the Standard Bank group visit our web site
www.standardbank.co.za

Disclaimer and confidentiality note

Everything in this e-mail and any attachments relating to the official business of the 
Standard Bank Group Limited  is proprietary to the group.
It is confidential, legally privileged and protected by law. Standard Bank does not 
own and endorse any other content. Views and opinions are
those of the sender unless clearly stated as being that of the group.The person 
addressed in the e-mail is the sole authorised recipient. Please
notify the sender immediately if it has unintentionally reached you and do not read, 
disclose or use the content in any way.
Standard Bank can not assure that the integrity of this communication has been 
maintained nor that it is free of errors, virus, interception or interference.
II

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: MQ and LDAP

2003-07-09 Thread mikhail malamud

You can do this yourself in java.
First of all LDAP does not support any type of authentication services
to external applications although it happens to be very convenient to
store indentity related information.

In java, you can enable a security manager develop your mqseries app
with JAAS hooks in it. Secruity manager will ask for auth info and pass
it on to your custom developed authentication/authorzation module which
implements all necessary JASS interfaces and you can make it use LDAP,
kerberos or anything you can imagine of as an
authentication/authorization procedure.

AMBI from tivoli uses LDAP it will import both your mq objects and your
user name space into LDAP. From that point on you can register specific
users in your name space have access to the mq objects which are also in
your name space and all happens to be in LDAP.

It might be misleading just to want MQSeries and LDAP for user
authentication. There should some specific need which hopefully can
resolved by externalizing authentication authorization process and
probably will use LDAP or maybe just a password file or maybe some other
SSO entity.

HTH,

mikhail.
- Original Message -
From: "Kearns, Emile E" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, July 09, 2003 9:03 AM
Subject: MQ and LDAP


| Hi Guys and Dolls,
|
| Does anybody out there know if the above is supported, especially for
user
| authentication on UNIX platforms?
| IBMers, is this in the pipeline?
|
| It will bypass the usimg of OS level security checks.
|
|
| Emile Kearns
| IBM Certified System Administrator - Websphere MQ, V5.3
| MQSeries Administrator SCMB
| >  Technology Infrastructure Group
| > Information Technology Department
| > Standard Corporate and Merchant Bank
| >
| >   E-mail: [EMAIL PROTECTED]
| >   *Phone: +27-11-636-3336 SCMB, P.O. Box 61344,
Marshalltown,
| > 2107, Gauteng, RSA
| >   *Fax:   +27-11-636-5713 2nd Floor, Entrance 6, 3
Simmonds
| > Street, JHB
| >
| >
| >
|
| For information about the Standard Bank group visit our web site
| www.standardbank.co.za
|
| Disclaimer and confidentiality note
|
| Everything in this e-mail and any attachments relating to the official
business of the Standard Bank Group Limited  is proprietary to the
group.
| It is confidential, legally privileged and protected by law. Standard
Bank does not own and endorse any other content. Views and opinions are
| those of the sender unless clearly stated as being that of the
group.The person addressed in the e-mail is the sole authorised
recipient. Please
| notify the sender immediately if it has unintentionally reached you
and do not read, disclose or use the content in any way.
| Standard Bank can not assure that the integrity of this communication
has been maintained nor that it is free of errors, virus, interception
or interference.
| I
|
| 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: Questionable MQ infrastructure design

2003-07-09 Thread mikhail malamud

1. it is a lot of stuff to type.
2. os/390 supports only 4 letter queue manager names.
3. Instead of specifying full names for name components come up with
abreviations where letters and numbers can be mapped to full names.
4. You will be 70% less productive than people who adhere to best
practices in the context of the naming convention.
5. You and developers will be a lot more prone to errors.
6. max lenght of mq object names  is 48 chars except channels where max
name length is 20 chars.
7. Seriously look into queue manager aliasing.
8. Ask those people what's the benefit of using such long and full
names, tell them they do not know anything about MQSeries.
9. If I were your target company, I would not do business with you
unless you change your naming convention to more
10. What's the point of having distinct queue manager for each
application, if all queue managers will be on the same host. This is
hardly justifiable over head.
- Original Message -
From: "Armand ten Dam" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, July 09, 2003 8:58 PM
Subject: Questionable MQ infrastructure design


| Hi all,
| For an integration project I have been asked to adopt an MQ naming
standard
| that reflects a very unusual approach in MQ-based integration. I have
never
| seen this approach before and have serious concerns in adopting any of
it.
|
| Key in the design is the use of separate queue managers for each
application
| pair. E.g. if an application interfaces with eight different
distributed
| applications this would result in eight separate queue managers on a
single
| system.
|
| Some examples:
| Queue manager:
| QMPROD.SOURCECOMPANY.SOURCEAPP.TARGETCOMPANY.TARGETAPP.SYSTEMNAME
| Channel:
| CHPROD.SOURCECOMPANY.SOURCEAPP.TO.TARGETCOMPANY.TARGETAPP
| Transmission queue:
| TXPROD.SOURCECOMPANY.SOURCEAPP.TO.TARGETCOMPANY.TARGETAPP
| ...
|
| Obviously this does not reflect best-practice, seriously impacts
| scalability, makes support of the MQ infrastructure difficult etc.
|
| As it looks like it will be a bit of a political discussion to get
this out
| of the way,
| I am looking to gather as much 'neutral' feedback to back me up. I
would
| appreciate it if some of you could shed some more light on the
implications
| of the above approach.
|
| Any insights much appreciated,
| Thanks,
| Armand
|
| _
| Hot chart ringtones and polyphonics. Go to
|
http://ninemsn.com.au/share/redir/adTrack.asp?mode=click&clientID=174&referral=Hotmail_taglines_plain&URL=http://ninemsn.com.au/mobilemania/default.asp
|
| 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: Questionable MQ infrastructure design

2003-07-09 Thread Potkay, Peter M (PLC, IT)

For one thing, channel names can only be 20 bytes long, so as a rule, by QM
names are never longer than 9 bytes, so I can always adhere to the
SendingQMname.ReceivingQMname naming standard. I don't see how you can get
all that info into 20 bytes with the below.

If you have one server with multiple applications, just have one QM and use
queue naming standards to give a logical separation. There is no benefit
that I can think of in giving each app its own queue manager if they share
the same server. But it will cause more admin work when it comes time to
define all those MQ objects. I am sure 10 QMs with 10 queues each use a LOT
more resources than one QM with a 100 queues (never mind all the extra
channels, trigger monitors, processes, etc that you will have to define).

If one server will house both production and test (not recommended but
sometimes unavoidable), then a case can be made for separate QMs (one for
Test and one for Production).

This is always a balancing act as new applications come aboard. On one end,
you can have 1 QM with 1 queue for each and every instance of every app. On
the other hand you could have one common dumping queue on one QM for all
apps, and use a homegrown SIL app to sort out the messages and start the
right app. Clearly neither case is correct, but rather somewhere in the
middle. I think your guys are proposing something that is swinging
dangerously close to one extreme (being overly anal and cautious, at the
expense of common sense and day to day workability).

Having said all that, as long as their naming ideas fit within the confines
of what MQ allows (20 byte channel names and 48 bytes for most everything
else), there really is nothing you can say that proves what they want wont
work. It will, it just will be much more difficult than it needs to be. Are
they trying to insure job security for the person that builds this???  ;-).





-Original Message-
From: Armand ten Dam [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 09, 2003 8:58 PM
To: [EMAIL PROTECTED]
Subject: Questionable MQ infrastructure design


Hi all,
For an integration project I have been asked to adopt an MQ naming standard
that reflects a very unusual approach in MQ-based integration. I have never
seen this approach before and have serious concerns in adopting any of it.

Key in the design is the use of separate queue managers for each application
pair. E.g. if an application interfaces with eight different distributed
applications this would result in eight separate queue managers on a single
system.

Some examples:
Queue manager:
QMPROD.SOURCECOMPANY.SOURCEAPP.TARGETCOMPANY.TARGETAPP.SYSTEMNAME
Channel:
CHPROD.SOURCECOMPANY.SOURCEAPP.TO.TARGETCOMPANY.TARGETAPP
Transmission queue:
TXPROD.SOURCECOMPANY.SOURCEAPP.TO.TARGETCOMPANY.TARGETAPP
...

Obviously this does not reflect best-practice, seriously impacts
scalability, makes support of the MQ infrastructure difficult etc.

As it looks like it will be a bit of a political discussion to get this out
of the way,
I am looking to gather as much 'neutral' feedback to back me up. I would
appreciate it if some of you could shed some more light on the implications
of the above approach.

Any insights much appreciated,
Thanks,
Armand

_
Hot chart ringtones and polyphonics. Go to
http://ninemsn.com.au/share/redir/adTrack.asp?mode=click&clientID=174&referr
al=Hotmail_taglines_plain&URL=http://ninemsn.com.au/mobilemania/default.asp

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 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

Questionable MQ infrastructure design

2003-07-09 Thread Armand ten Dam

Hi all,
For an integration project I have been asked to adopt an MQ naming standard
that reflects a very unusual approach in MQ-based integration. I have never
seen this approach before and have serious concerns in adopting any of it.
Key in the design is the use of separate queue managers for each application
pair. E.g. if an application interfaces with eight different distributed
applications this would result in eight separate queue managers on a single
system.
Some examples:
Queue manager:
QMPROD.SOURCECOMPANY.SOURCEAPP.TARGETCOMPANY.TARGETAPP.SYSTEMNAME
Channel:
CHPROD.SOURCECOMPANY.SOURCEAPP.TO.TARGETCOMPANY.TARGETAPP
Transmission queue:
TXPROD.SOURCECOMPANY.SOURCEAPP.TO.TARGETCOMPANY.TARGETAPP
...
Obviously this does not reflect best-practice, seriously impacts
scalability, makes support of the MQ infrastructure difficult etc.
As it looks like it will be a bit of a political discussion to get this out
of the way,
I am looking to gather as much 'neutral' feedback to back me up. I would
appreciate it if some of you could shed some more light on the implications
of the above approach.
Any insights much appreciated,
Thanks,
Armand
_
Hot chart ringtones and polyphonics. Go to
http://ninemsn.com.au/share/redir/adTrack.asp?mode=click&clientID=174&referral=Hotmail_taglines_plain&URL=http://ninemsn.com.au/mobilemania/default.asp
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: OS/390 system scope

2003-07-09 Thread Richard Crook

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.

Could this be a timing issue? - the original Qmgr hasn't finished shutting
down when you try to start the new one?

Richard.





Burke Edward <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 10/07/2003
03:14:15

Please respond to MQSeries List <[EMAIL PROTECTED]>

Sent by:MQSeries List <[EMAIL PROTECTED]>


To:[EMAIL PROTECTED]
cc:
Subject:OS/390 system scope




Ok the manual says this :


A WebSphere MQ subsystem with a CPF with scope of S can be defined on one
or more z/OS images within a sysplex, so these images can share a single
subsystem name table. However, you must ensure that the initial START
command is issued on (or routed to) the z/OS image on which you want the
WebSphere MQ subsystem to run. If you use this option, you can stop the
WebSphere MQ subsystem and restart it on a different z/OS image within the
sysplex without having to change the subsystem name table or re-IPL a z/OS
system.


But when I stop the Qmgr and try to bring it up on different LPAR I get a
message stating that the subsystem is still running on another LPAR.


To stop the subsystem do I need to do something besides stop the QMGR ?





-
The contents of this e-mail are confidential. If you have received this
communication by mistake, please advise the sender immediately and delete
the message and any attachments.
Nothing in this email designates an information system for the purposes of
Section 11(a) of the New Zealand Electronic Transactions Act 2002.
Westpac Banking Corporation, ABN 33 007 457 141, is incorporated in
Australia
-

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

Making OS390 Channel Initiator non-swappable

2003-07-09 Thread alan . turnbull

Hi

On OS390 running MQ V5.2 we are experiencing problem with the channel
initiator CHIN getting swapped out because it is idle and then not
being swapped back in when messages arrive for it because the CPU is too
busy.

The sys progs have given the channel initiator very high priority but the
problem is persisting. They are reluctant to make it non-swappable because
of this advice in the IBM manual 

" You should not set NOSWAP because the MQSeries queue manager controls
 swapping itself. However, if you have a heavily-loaded MQSeries network
 and response time is critical, it might be advantageous to make the
 MQSeries channel initiator non-swappable, by adding the following further
 PPT entry, at the risk of impacting the performance of the rest of your
 OS/390 system: "

Has anyone any experience with this ?

Thanks
Alan





IMPORTANT NOTICE : The information in this email is confidential and may also be 
privileged. If you are not the intended recipient, any use or dissemination of the 
information and any disclosure or copying of this email is unauthorised and strictly 
prohibited. If you have received this email in error, please promptly inform us by 
reply email or telephone. You should also delete this email and destroy any hard 
copies produced.

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: AS/400 RPG pgms cannot handle msg > 32k?

2003-07-09 Thread eai grp

yes , like Joerg understood , I was refering to the RPG limitation.I understand that MQ can handle upto 100MB data. 
Will programming get too complex , if we used the Pointer stuff?What about MQ Series Segmenting?
 "David C. Partridge" <[EMAIL PROTECTED]> wrote:

My copy of the iSeries APG for ILE RPG says:BUFLEN (10-digit signed integer) - inputLength of the message in BUFFER.Zero is valid, and indicates that the message contains no application data.The upper limit for BUFLEN depends on various factors:If the destination queue is a shared queue, the upper limit is 63 KB (64 512bytes).If the destination is a local queue or resolves to a local queue (but is nota shared queue), the upper limit depends on whether:The local queue manager supports segmentation.The sending application specifies the flag that allows the queue manager tosegment the message. This flag is MFSEGA, and can be specified either in aversion-2 MQMD, or in an MQMDE used with a version-1 MQMD.If both of these conditions are satisfied, BUFLEN cannot exceed 999 999 999minus the value of the MDOFF field in MQMD. The
 longest logical message thatcan be put is therefore 999 999 999 bytes (when MDOFF is zero). However,resource constraints imposed by the operating system or environment in whichthe application is running may result in a lower limit.If one or both of the above conditions is not satisfied, BUFLEN cannotexceed the smaller of the queue's MaxMsgLength attribute and queue manager'sMaxMsgLength attribute.If the destination is a remote queue or resolves to a remote queue, theconditions for local queues apply, but at each queue manager through whichthe message must pass in order to reach the destination queue; inparticular:The local transmission queue used to store the message temporarily at thelocal queue managerIntermediate transmission queues (if any) used to store the message at queuemanagers on the route between the local and destination queue managersThe destination queue at the destination queue managerThe longest message
 that can be put is therefore governed by the mostrestrictive of these queues and queue managers.When a message is on a transmission queue, additional information resideswith the message data, and this reduces the amount of application data thatcan be carried. In this situation it is recommended that LNMHD bytes besubtracted from the MaxMsgLength values of the transmission queues whendetermining the limit for BUFLEN.Note:Only failure to comply with condition 1 can be diagnosed synchronously (withreason code RC2030 or RC2031) when the message is put. If conditions 2 or 3are not satisfied, the message is redirected to a dead-letter(undelivered-message) queue, either at an intermediate queue manager or atthe destination queue manager. If this happens, a report message isgenerated if one was requested by the sender.So I don't see the 32K restriction you mentionDaveInstructions for managing your mailing list
 subscription are provided inthe Listserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archive
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!

Re: Applying HIPER PTF on AIX for CSD03...

2003-07-09 Thread McCarty, Brian

Thanks guys,

The fuser -fux  is what worked.  I found the culprit (it was an application 
that was linking libraries, but not connected to the queue manager).  However, even 
after stopping those applications and doing another fuser -fux and not getting a 
response...we were still unable to copy the libraries like the documentation states.  
Instead, we did have to delete the 2 files as root and then copy in the new ones.  
Therefore, it's working now...but not the way it states in the readme.

Thanks again for the help,

B

 -Original Message-
From:   Peter Uranyi [mailto:[EMAIL PROTECTED] 
Sent:   Tuesday, July 08, 2003 3:06 PM
To: [EMAIL PROTECTED]
Subject: Re: Applying HIPER PTF on AIX for CSD03...

Brian,

Try using the -x flag with the 'fuser' command, like this:

   fuser -fux libimqb23ia_r.a

HTH,
Peter


--- "McCarty, Brian" <[EMAIL PROTECTED]> wrote:
> I commented out listener and port entries in inetd.conf and services and
> refreshed inetd.conf.  There are no memory segments showing up with ipcs -a |
> grep mqm and I am executing slibclean.  I am still getting cannot open or
> remove a file containing a running program.
>
> I tried using fuser -fu libimqb23ia_r.a but it only returns this to the
> command line:
>
> libimqb23ia_r.a:
>
> Is there any other options or tools I can use here?  Thanks for all the help,
>
> Brian
>
>  -Original Message-
> From:   Stephan C. Moen [mailto:[EMAIL PROTECTED]
> Sent:   Tuesday, July 08, 2003 11:28 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Applying HIPER PTF on AIX for CSD03...
>
> Use the 'fuser -fu ' command to display the process Ids that have
> this file open.
>
> Steve Moen
>
> -Original Message-
> From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of McCarty,
> Brian
> Sent: Tuesday, July 08, 2003 11:00 AM
> To: [EMAIL PROTECTED]
> Subject: Applying HIPER PTF on AIX for CSD03...
>
> There is a HIPER fix out called IY43610 that I am trying to apply on AIX
> 4.3.3 running WMQ 5.3 CSD03.  I stopped the queue managers and used ipcrm
> and slibclean before trying to copy the files.  I was able to move 6 of the
> files (logged in as root), but I can't get 2 of them to copy.
>
> cp: ./libimqb23ia_r.a: Cannot open or remove a file containing a running
> program.
> cp: ./libimqs23ia_r.a: Cannot open or remove a file containing a running
> program.
>
> Does anyone have any idea why these files are still being used or if there
> is a tool or process that I can use to figure it out?
>
> Thanks for any advice in advance,
>
> Brian M. McCarty
> USAA, Senior Systems Programmer
> 210.913.1678
> MQ/WMQI Specialist/Solutions Expert
> e-business Solution Advisor/Designer/Technologist
>
> 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 message was content-scanned by GatewayDefender
> 7/8/2003 - 12:12:02 PM - BA045ecefc.0001.mml
>
> 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: Deleting/Creating Temp Dynamic queues

2003-07-09 Thread Nick Dilauro

Ruzi,

1.  Yes you will get the object already exists rc, but the code is 2100, not
2010.

2.  Yes.

Nick

-Original Message-
From: Ruzi R [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 09, 2003 12:18 PM
To: [EMAIL PROTECTED]
Subject: Deleting/Creating Temp Dynamic queues

Platform is MQ 5.3 CSD3 on NT.

1- If a program that creates a temp dynamic queue
called Q1 (using full name) and tries to re-create it
(via open) with exactly the same name,  would it get
2010 (mqrc_object_already_exists), or would it be able
to create a second instance of it (getting a different
handle of course)? Please don't ask me why the program
would want to re-create it. I just need to know the
answer.

2- I assume that if the temp dyn queue is logically
deleted, it is possible to create a temp dyn with the
same name. Correct?

I know you can create temp dynamic queues each time
making them unique (... using the "*" after the last
byte of the name... as long as the name is shorter
than 33 bytes). However, we are using full names for
various reaons that I don't want to get into.

Your response would be much appreciated as always...

Best regards,

Ruzi

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: Message on dead letter queue

2003-07-09 Thread Bullock, Rebecca (CSC)

Francois -- Here's what you need to do (and it's nuts, but so be it):

1) Start with the hex reason code (2508)
2) Flip the two bytes, giving you 0825
3) Convert that to decimal, giving you 2085

It has to do with how stuff is stored internally. I have notes on this
particular thing -- it's not something a sane person would remember.

Cheers, Rebecca

Rebecca Bullock
Computer Sciences Corporation
MFCoE/Newark CS Team

Educational Testing Service Account
Princeton, NJ 08541

email: [EMAIL PROTECTED] or [EMAIL PROTECTED]

-Original Message-
From: F Vartan [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 09, 2003 3:41 PM
To: [EMAIL PROTECTED]
Subject: Message on dead letter queue


Hi everyone,

On the NT with WQM 5.3 when I am using amqsbcgc  to
browse our dead letter queue, I am getting this at the
beginning of a message:

:  444C 4820 0100  2508  5445 5354
'DLH %...TEST'
0010:  2E41 474D 452E 4F52 4420 2020 2020 2020
'.AGME.ORD   '
0020:  2020 2020 2020 2020 2020 2020 2020 2020 '
 '

I think 2508 (decimal 9480) is the reason field. But d
there is no such reason code. How to figure it out? Is
this explained in any manual?

Many thanks.

Francois


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

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 e-mail and any files transmitted with it may contain privileged or
confidential information. It is solely for use by the individual for whom
it is intended, even if addressed incorrectly. If you received this e-mail
in error, please notify the sender; do not disclose, copy, distribute, or
take any action in reliance on the contents of this information; and delete
it from your system. Any other use of this e-mail is prohibited. Thank you
for your compliance.

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: Message on dead letter queue

2003-07-09 Thread Christopher Frank

Francois,

>>>On the NT with WQM 5.3 when I am using amqsbcgc  to
>>>browse our dead letter queue, I am getting this at the
>>>beginning of a message:
>>>
>>>:  444C 4820 0100  2508  5445 5354
>>>'DLH %...TEST'
>>>0010:  2E41 474D 452E 4F52 4420 2020 2020 2020
>>>'.AGME.ORD   '
>>>0020:  2020 2020 2020 2020 2020 2020 2020 2020
>>>I think 2508 (decimal 9480) is the reason field. But there
>>>is no such reason code. How to figure it out? Is this
>>>explained in any manual?

On Intel you have to swap the bytes, so it's 0825 (decimal 2085, "UNKNOWN
OBJECT") not 2508.

Regards,

Christopher Frank
Sr. I/T Specialist - IBM Software Group
IBM Certified Solutions Expert - Websphere MQ & MQ Integrator

Phone: 612-397-5532 (t/l 653-5532) mobile: 612-669-3008
e-mail: [EMAIL PROTECTED]

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: Message on dead letter queue

2003-07-09 Thread Reiss, William

Francios,

The reason code is actually 0825 hex (swap the bytes, since least
significant byte comes first) which converts to 2085.

Bill Reiss
CommerceQuest, Inc. 


-Original Message-
From: F Vartan [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 09, 2003 3:41 PM
To: [EMAIL PROTECTED]

Hi everyone,

On the NT with WQM 5.3 when I am using amqsbcgc  to browse our dead
letter queue, I am getting this at the beginning of a message:

:  444C 4820 0100  2508  5445 5354 'DLH %...TEST'
0010:  2E41 474D 452E 4F52 4420 2020 2020 2020
'.AGME.ORD   '
0020:  2020 2020 2020 2020 2020 2020 2020 2020 '
 '

I think 2508 (decimal 9480) is the reason field. But d there is no such
reason code. How to figure it out? Is this explained in any manual?

Many thanks.

Francois


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

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: Message on dead letter queue

2003-07-09 Thread Stefan Sievert

Francois,
it's actually 0x0825 (little endian integer), which is 2085 decimal,
which is 'object not found'.
Most likely you are trying to put to a queue that doesn't exist.
The structure of the MQDLH should be documented in the Application
Programming Reference.
Hope this helps,
Stefan

From: F Vartan <[EMAIL PROTECTED]>
Reply-To: MQSeries List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Message on dead letter queue
Date: Wed, 9 Jul 2003 12:41:22 -0700
Hi everyone,

On the NT with WQM 5.3 when I am using amqsbcgc  to
browse our dead letter queue, I am getting this at the
beginning of a message:
:  444C 4820 0100  2508  5445 5354
'DLH %...TEST'
0010:  2E41 474D 452E 4F52 4420 2020 2020 2020
'.AGME.ORD   '
0020:  2020 2020 2020 2020 2020 2020 2020 2020 '
 '
I think 2508 (decimal 9480) is the reason field. But d
there is no such reason code. How to figure it out? Is
this explained in any manual?
Many thanks.

Francois

__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
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
_
STOP MORE 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: Message on dead letter queue

2003-07-09 Thread Dawson, John

Francois,

  Invert the x'2508' to x'0825', which is a decimal 2085 which is
MQRC_UNKNOWN_OBJECT_NAME.


Regards,

John Dawson
Phone: 972.281.4016
Fax: 972.281.4904
mailto:[EMAIL PROTECTED]

 -Original Message-
From:   F Vartan [mailto:[EMAIL PROTECTED]
Sent:   Wednesday, July 09, 2003 2:41 PM
To: [EMAIL PROTECTED]
Subject:Message on dead letter queue

Hi everyone,

On the NT with WQM 5.3 when I am using amqsbcgc  to
browse our dead letter queue, I am getting this at the
beginning of a message:

:  444C 4820 0100  2508  5445 5354
'DLH %...TEST'
0010:  2E41 474D 452E 4F52 4420 2020 2020 2020
'.AGME.ORD   '
0020:  2020 2020 2020 2020 2020 2020 2020 2020 '
 '

I think 2508 (decimal 9480) is the reason field. But d
there is no such reason code. How to figure it out? Is
this explained in any manual?

Many thanks.

Francois


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

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: Message on dead letter queue

2003-07-09 Thread Jim Ford

Your reason code is actually x'0825', which is a decimal 2085, or
MQRC_UNKOWN_OBJECT_NAME. The bytes are reversed in the message because
of the way Intel stores its data (I can never remember if it's little-
or big-Endian),




  F Vartan
  <[EMAIL PROTECTED]To:   [EMAIL PROTECTED]
  M>   cc:
  Sent by: MQSeriesSubject:  Message on dead letter queue
  List
  <[EMAIL PROTECTED]
  N.AC.AT>


  07/09/2003 02:41
  PM
  Please respond to
  MQSeries List






Hi everyone,

On the NT with WQM 5.3 when I am using amqsbcgc  to
browse our dead letter queue, I am getting this at the
beginning of a message:

:  444C 4820 0100  2508  5445 5354
'DLH %...TEST'
0010:  2E41 474D 452E 4F52 4420 2020 2020 2020
'.AGME.ORD   '
0020:  2020 2020 2020 2020 2020 2020 2020 2020 '
 '

I think 2508 (decimal 9480) is the reason field. But d
there is no such reason code. How to figure it out? Is
this explained in any manual?

Many thanks.

Francois


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

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

Message on dead letter queue

2003-07-09 Thread F Vartan

Hi everyone,

On the NT with WQM 5.3 when I am using amqsbcgc  to
browse our dead letter queue, I am getting this at the
beginning of a message:

:  444C 4820 0100  2508  5445 5354
'DLH %...TEST'
0010:  2E41 474D 452E 4F52 4420 2020 2020 2020
'.AGME.ORD   '
0020:  2020 2020 2020 2020 2020 2020 2020 2020 '
 '

I think 2508 (decimal 9480) is the reason field. But d
there is no such reason code. How to figure it out? Is
this explained in any manual?

Many thanks.

Francois


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

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

Deleting/Creating Temp Dynamic queues

2003-07-09 Thread Ruzi R

Platform is MQ 5.3 CSD3 on NT.

1- If a program that creates a temp dynamic queue
called Q1 (using full name) and tries to re-create it
(via open) with exactly the same name,  would it get
2010 (mqrc_object_already_exists), or would it be able
to create a second instance of it (getting a different
handle of course)? Please don't ask me why the program
would want to re-create it. I just need to know the
answer.

2- I assume that if the temp dyn queue is logically
deleted, it is possible to create a temp dyn with the
same name. Correct?

I know you can create temp dynamic queues each time
making them unique (... using the "*" after the last
byte of the name... as long as the name is shorter
than 33 bytes). However, we are using full names for
various reaons that I don't want to get into.

Your response would be much appreciated as always...

Best regards,

Ruzi

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: WMQI : Set MQMD.Format to MQFMT_CICS

2003-07-09 Thread Govender Magendran

Title: Re: WMQI : Set MQMD.Format to MQFMT_CICS





Hi all


I have a messageflow that transforms an input XML message to a Custom Wire Format(Cobol Copybook).


The output message has a CICS Header followed by the copybook record.


We have a CICS Bridge that picks up the cobol message and processes it.


We have to set the MQMD.Format to MQFMT_CICS because a CICS Header exists.


When trying to set MQMD.Format field in WMQI, WMQI does not set it. When the message written to the output queue the message format seems to be MQFMT_NONE.

The ESQL used in WMQI is as follows :
SET "OutputRoot"."MQMD"."Format" = MQFMT_CICS;
I have tried setting the MQMD.Format to MQFMT_STRING and this work i.e. WMQI sets the value.
I have run traces and when tracing ${Root} the MQMD.Format field is not in the trace when setting the field to MQFMT_CICS but it is in the trace when setting the MQMD.Format field to MQFMT_STRING .i.e. the trace shows the field set to MQSTR.

Any ideas on what might be wrong will really be appreciated.


Thanks, in advance


Magendran Govender

Re: Using setmqaut

Thanks David, Rebecca:

Basically, I agree with all Rebecca said about limiting access in general: that's why 
we try not to work under root account on Unix, even if we have it; in the particular 
case, however, I implicitly assumed David was seeking to actually prohibit users in 
mqm group from accessing a queue; I should have probably asked first.

I also made my check (on AIX system) and found that setmqaut cannot deprive mqm group 
of its ability to access queues (checked with dspmqaut: -all does not change mqm's 
unlimited rights). I was wrong in my previous mail : mqm *is* on the list from the 
beginning; and it cannot be removed (at least I could not).

I also agree that, from security administration point of view, the argument of 
accountability is used (and misused) pretty often especially when they cannot offer 
some technically sound solution for a difficult problem, like providing keystore 
passphrases for unattended servers (MQ's CMS keystore is not an exception -- another 
reason why you may want to keep most users out of mqm group). Once I had to scramble 
(of course, not to encrypt -- with what password?) such a phrase for these guys who 
earnestly beleived that using 'od' on encrypted password file or 'vi' or 'view' on a 
script in which did the scrambling would look much more fishy in their logs than using 
'view' or 'vi' on an unencrypted file (and whom they want to hide the password from? 
-- from the very user who was supposed to enter it at the first place!). Back to 
David's problem, I do not see any greater chances for the user allowed in mqm group to 
be caught for running setmqaut (why else he would be allowed
there?) than for running the application capable to access a queue (why would s/he do 
it if s/he is supposed to administer?).

Also, on Unix, playing around with MQ installation (you would have to change the 
binary permissions that are r-sr-s--- for setmqaut after installation) might make the 
work IBM technical support, should you need it, more difficult. I always try to avoid 
that.

Actually, I had to play with this unnatural (MQ+security on distributed systems) 
combination quite a bit, so, if David tells us in more details what he wants to 
achieve, there is a chance I have some more or less proven recipe (for Unix or Windows 
platform only).

Thanks for reading this far :-),
Pavel







  "Bullock, Rebecca
  (CSC)"   To:   [EMAIL PROTECTED]
  <[EMAIL PROTECTED]cc:
  >Subject:  Re: Using setmqaut
  Sent by: MQSeries
  List
  <[EMAIL PROTECTED]
  n.AC.AT>


  07/09/2003 11:56
  AM
  Please respond to
  MQSeries List






Pavel, while it may seem somewhat counterintuitive, it's not terribly
uncommon for a user who can change security access to something to not have
access to that thing. Yes, they can change the access, but the hope is that
this would be caught through some sort of reporting/logging. The other
advantage of doing this is that it prevents accidental modification of some
critical queue data; if you needed to do those modifications, you would at
that time do the setmqaut and then turn it back off when you're done.

This may not be irrelevant here anyway. Since setmqaut sets access at the
group level and, I presume, you could set the permissions on setmqaut so
that group could not run it while the owner could, it would be possible to
stop a user in the mqm group, but is not mqm himself, from running setmqaut
to reset permissions.

Just my take on this issue, based on doing other security stuff that's not
MQ... Rebecca

Rebecca Bullock
Computer Sciences Corporation
MFCoE/Newark CS Team

Educational Testing Service Account
Princeton, NJ 08541

email: [EMAIL PROTECTED] or [EMAIL PROTECTED]


-Original Message-
From: Pavel Tolkachev [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 09, 2003 11:06 AM
To: [EMAIL PROTECTED]
Subject: Re: Using setmqaut


David,

First, I seems to me I tried all those tricks while ago and found mqm is a
God.

Second, logically mqm is not in the ACLs from the very beginning (check with
dspmqaut), so deleting him from there should not change anything (just an
educated guess)

Third, even assuming mqm could be deleted from .. whatever, why whould s/he
be able to add him/herself back .. there.. using that very setmqaut?
(another educated guess).

All those considerations are valid for Unix and (if I am not mistaken)
Windows. I am not sure about other platforms.

Hope this will help,
Pavel




  "David C.
  Partridge"To:
[EMAIL PROTECTED]
  <[EMAIL PROTECTED]cc:
  RIMEUR.COM>   Subject:  Re: Using setmqaut
  Sen

Re: MQ and LDAP

2003-07-09 Thread peter d

Emile, i work with a product called QN-AppWatch from Reconda International.
It works in a similar environment to what you suggested in your post.
Perhaps this will help you adhere to the environment you specified.

I'm not sure from your post if you are trying to work with specific access
for admin purposes to your MQ environment, or if you just need code to
authenticate against LDAP within an application (there are Java libraries to
accomplish this).

If the reason is the former (access for admin purposes) then:

1- QN-AppWatch is browser based, so uses Apache as the HTTP listener (it
could also use the Apache with WAS).  So it is platform independent (AIX,
Solaris, HP, Linux, Windows, OS390, etc.)
2- It can authenticate users against an LDAP directory (i.e. Netegrity) to
"authenticate" the user to its environment.
3- Once in the environment, user's are assigned to PROJECTs - which are a
kind of 'sandbox' as to what the user/admin can do (which Qmgrs, channels,
queues) in their sandbox.
4- It has further persmissions (i.e. read, write, delete, admin) in order to
allow certain users in the project the permissions to MQobjects and messages
within that sandbox.
5- Lastly, it will LOG any actions to these objects.

regards, peter d.

-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Kearns,
Emile E
Sent: Wednesday, July 09, 2003 9:54 AM
To: [EMAIL PROTECTED]
Subject: Re: MQ and LDAP
Importance: High


I would like to do user authentication but NOT at a UNIX OS Level. I thought
if LDAP or something similar exists like in the case of WAS.

-Original Message-
From: David C. Partridge [mailto:[EMAIL PROTECTED]
Sent: 09 July 2003 03:30
To: [EMAIL PROTECTED]
Subject: Re: MQ and LDAP


Emile,

I don't quite understand the question.   SSL supports LDAP for retrieving
CRLs, but I don't think that's what you're getting at.  Do you think you
could give us a bit more to chew on?

Thanks
Dave

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

For information about the Standard Bank group visit our web site
www.standardbank.co.za

Disclaimer and confidentiality note

Everything in this e-mail and any attachments relating to the official
business of the Standard Bank Group Limited  is proprietary to the group.
It is confidential, legally privileged and protected by law. Standard Bank
does not own and endorse any other content. Views and opinions are
those of the sender unless clearly stated as being that of the group.The
person addressed in the e-mail is the sole authorised recipient. Please
notify the sender immediately if it has unintentionally reached you and do
not read, disclose or use the content in any way.
Standard Bank can not assure that the integrity of this communication has
been maintained nor that it is free of errors, virus, interception or
interference.
II

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: AS/400 RPG pgms cannot handle msg > 32k?

2003-07-09 Thread Joerg Wende

this limit is not caused by MQSeries, it is coming from RPG (II / III),
there you are limited in field size definition

Joerg



|-+->
| |   "David C. |
| |   Partridge"|
| |   <[EMAIL PROTECTED]|
| |   RIMEUR.COM>   |
| |   Sent by: MQSeries |
| |   List  |
| |   <[EMAIL PROTECTED]|
| |   .AC.AT>   |
| | |
| | |
| |   09.07.2003 17:45  |
| |   Please respond to |
| |   MQSeries List |
| | |
|-+->
  
>-|
  |
 |
  |   To:   [EMAIL PROTECTED]  
   |
  |   cc:  
 |
  |   Subject:  Re: AS/400 RPG pgms cannot handle msg > 32k?   
 |
  |
 |
  |
 |
  
>-|



My copy of the iSeries APG for ILE RPG says:

BUFLEN (10-digit signed integer) - input
Length of the message in BUFFER.
Zero is valid, and indicates that the message contains no application data.
The upper limit for BUFLEN depends on various factors:
If the destination queue is a shared queue, the upper limit is 63 KB (64
512
bytes).
If the destination is a local queue or resolves to a local queue (but is
not
a shared queue), the upper limit depends on whether:
The local queue manager supports segmentation.
The sending application specifies the flag that allows the queue manager to
segment the message. This flag is MFSEGA, and can be specified either in a
version-2 MQMD, or in an MQMDE used with a version-1 MQMD.
If both of these conditions are satisfied, BUFLEN cannot exceed 999 999 999
minus the value of the MDOFF field in MQMD. The longest logical message
that
can be put is therefore 999 999 999 bytes (when MDOFF is zero). However,
resource constraints imposed by the operating system or environment in
which
the application is running may result in a lower limit.
If one or both of the above conditions is not satisfied, BUFLEN cannot
exceed the smaller of the queue's MaxMsgLength attribute and queue
manager's
MaxMsgLength attribute.
If the destination is a remote queue or resolves to a remote queue, the
conditions for local queues apply, but at each queue manager through which
the message must pass in order to reach the destination queue; in
particular:
The local transmission queue used to store the message temporarily at the
local queue manager
Intermediate transmission queues (if any) used to store the message at
queue
managers on the route between the local and destination queue managers
The destination queue at the destination queue manager
The longest message that can be put is therefore governed by the most
restrictive of these queues and queue managers.
When a message is on a transmission queue, additional information resides
with the message data, and this reduces the amount of application data that
can be carried. In this situation it is recommended that LNMHD bytes be
subtracted from the MaxMsgLength values of the transmission queues when
determining the limit for BUFLEN.
Note:
Only failure to comply with condition 1 can be diagnosed synchronously
(with
reason code RC2030 or RC2031) when the message is put. If conditions 2 or 3
are not satisfied, the message is redirected to a dead-letter
(undelivered-message) queue, either at an intermediate queue manager or at
the destination queue manager. If this happens, a report message is
generated if one was requested by the sender.

So I don't see the 32K restriction you mention

Dave

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
Archiv

Re: Using setmqaut

2003-07-09 Thread Bullock, Rebecca (CSC)

Pavel, while it may seem somewhat counterintuitive, it's not terribly
uncommon for a user who can change security access to something to not have
access to that thing. Yes, they can change the access, but the hope is that
this would be caught through some sort of reporting/logging. The other
advantage of doing this is that it prevents accidental modification of some
critical queue data; if you needed to do those modifications, you would at
that time do the setmqaut and then turn it back off when you're done.

This may not be irrelevant here anyway. Since setmqaut sets access at the
group level and, I presume, you could set the permissions on setmqaut so
that group could not run it while the owner could, it would be possible to
stop a user in the mqm group, but is not mqm himself, from running setmqaut
to reset permissions.

Just my take on this issue, based on doing other security stuff that's not
MQ... Rebecca

Rebecca Bullock
Computer Sciences Corporation
MFCoE/Newark CS Team

Educational Testing Service Account
Princeton, NJ 08541

email: [EMAIL PROTECTED] or [EMAIL PROTECTED]


-Original Message-
From: Pavel Tolkachev [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 09, 2003 11:06 AM
To: [EMAIL PROTECTED]
Subject: Re: Using setmqaut


David,

First, I seems to me I tried all those tricks while ago and found mqm is a
God.

Second, logically mqm is not in the ACLs from the very beginning (check with
dspmqaut), so deleting him from there should not change anything (just an
educated guess)

Third, even assuming mqm could be deleted from .. whatever, why whould s/he
be able to add him/herself back .. there.. using that very setmqaut?
(another educated guess).

All those considerations are valid for Unix and (if I am not mistaken)
Windows. I am not sure about other platforms.

Hope this will help,
Pavel




  "David C.
  Partridge"To:
[EMAIL PROTECTED]
  <[EMAIL PROTECTED]cc:
  RIMEUR.COM>   Subject:  Re: Using setmqaut
  Sent by: MQSeries
  List
  <[EMAIL PROTECTED]
  .AC.AT>


  07/09/2003 10:17
  AM
  Please respond to
  MQSeries List






Rick,

Hmmm... that sounds like it *is* possible, but use at your own risk - can
anyone confirm?

Thanks
David

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 e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.

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 e-mail and any files transmitted with it may contain privileged or
confidential information. It is solely for use by the individual for whom
it is intended, even if addressed incorrectly. If you received this e-mail
in error, please notify the sender; do not disclose, copy, distribute, or
take any action in reliance on the contents of this information; and delete
it from your system. Any other use of this e-mail is prohibited. Thank you
for your compliance.

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

WMQI Aggregation

2003-07-09 Thread Tony Reddiough









Does anyone know when the Aggregate control message gets used ?

 

I thought the control message was used to tie up the Aggregate Control
node with the Aggregate reply node. 
In my case these are in different flows and so I joined them using a
queue putting on an MQMD etc. 

 

I then put a trace node after the Aggregate Control node coming down the
control leg.  I didn’t get any
trace nor did I get a message on the control queue (I stopped the flow that
read from it).

 

So, I then decided to remove the control message completely from the fan
in and the fan out and the aggregation still worked.  

 

So what’s the point of it ?

 

Regards,

Tony.

 

Tony Reddiough

Certified
MQSeries Specialist

Tel:   +44 (0)
1793 616100

Mobile:  +44 (0) 7711 264281

www.alphacourt.com

 

Alphacourt -
"The Integration Practice"

Re: AS/400 RPG pgms cannot handle msg > 32k?

My copy of the iSeries APG for ILE RPG says:

BUFLEN (10-digit signed integer) - input
Length of the message in BUFFER.
Zero is valid, and indicates that the message contains no application data.
The upper limit for BUFLEN depends on various factors:
If the destination queue is a shared queue, the upper limit is 63 KB (64 512
bytes).
If the destination is a local queue or resolves to a local queue (but is not
a shared queue), the upper limit depends on whether:
The local queue manager supports segmentation.
The sending application specifies the flag that allows the queue manager to
segment the message. This flag is MFSEGA, and can be specified either in a
version-2 MQMD, or in an MQMDE used with a version-1 MQMD.
If both of these conditions are satisfied, BUFLEN cannot exceed 999 999 999
minus the value of the MDOFF field in MQMD. The longest logical message that
can be put is therefore 999 999 999 bytes (when MDOFF is zero). However,
resource constraints imposed by the operating system or environment in which
the application is running may result in a lower limit.
If one or both of the above conditions is not satisfied, BUFLEN cannot
exceed the smaller of the queue's MaxMsgLength attribute and queue manager's
MaxMsgLength attribute.
If the destination is a remote queue or resolves to a remote queue, the
conditions for local queues apply, but at each queue manager through which
the message must pass in order to reach the destination queue; in
particular:
The local transmission queue used to store the message temporarily at the
local queue manager
Intermediate transmission queues (if any) used to store the message at queue
managers on the route between the local and destination queue managers
The destination queue at the destination queue manager
The longest message that can be put is therefore governed by the most
restrictive of these queues and queue managers.
When a message is on a transmission queue, additional information resides
with the message data, and this reduces the amount of application data that
can be carried. In this situation it is recommended that LNMHD bytes be
subtracted from the MaxMsgLength values of the transmission queues when
determining the limit for BUFLEN.
Note:
Only failure to comply with condition 1 can be diagnosed synchronously (with
reason code RC2030 or RC2031) when the message is put. If conditions 2 or 3
are not satisfied, the message is redirected to a dead-letter
(undelivered-message) queue, either at an intermediate queue manager or at
the destination queue manager. If this happens, a report message is
generated if one was requested by the sender.

So I don't see the 32K restriction you mention

Dave

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: OS/390 system scope

2003-07-09 Thread Rick Tsujimoto

There's a console command called SETSSI which might be what you're looking
for.




  Burke Edward
   cc:
  Sent by: Subject: OS/390 system scope
  MQSeries List
  <[EMAIL PROTECTED]
  en.AC.AT>


  07/09/2003 11:14
  AM
  Please respond
  to MQSeries List








Ok the manual says this :


A WebSphere MQ subsystem with a CPF with scope of S can be defined on one
or more z/OS images within a sysplex, so these images can share a single
subsystem name table. However, you must ensure that the initial START
command is issued on (or routed to) the z/OS image on which you want the
WebSphere MQ subsystem to run. If you use this option, you can stop the
WebSphere MQ subsystem and restart it on a different z/OS image within the
sysplex without having to change the subsystem name table or re-IPL a z/OS
system.


But when I stop the Qmgr and try to bring it up on different LPAR I get a
message stating that the subsystem is still running on another LPAR.


To stop the subsystem do I need to do something besides stop the QMGR ?

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: AS/400 RPG pgms cannot handle msg > 32k?

2003-07-09 Thread Joerg Wende

Using RPG pointers you can overcome this limitation ...
e.g.  see  http://klement.dstorm.net/rpg/pointers.html

Mit freundlichen Grüßen / kind regards

Joerg Wende

Consult. IT Specialist / Business Integration
IBM SWG Technical Sales Central (Mitte)

Office Frankfurt: +49 69/6645 (*134) 1088
Mobil:  +49-171-2229636
Home: +49-35952-4  Fax -48932


|-+>
| |   eai grp  |
| |   <[EMAIL PROTECTED]|
| |   >|
| |   Sent by: MQSeries|
| |   List |
| |   <[EMAIL PROTECTED]|
| |   N.AC.AT> |
| ||
| ||
| |   09.07.2003 16:22 |
| |   Please respond to|
| |   MQSeries List|
| ||
|-+>
  
>-|
  |
 |
  |   To:   [EMAIL PROTECTED]  
   |
  |   cc:  
 |
  |   Subject:  AS/400 RPG pgms cannot handle msg > 32k?   
 |
  |
 |
  |
 |
  
>-|



Hi All,

What are my options if i need to put a message greater than 32K into queue
using MQ API for RPG? I see that there is a limitation on the 'buffer'
parameter declared to put/get messages.
Is 'nt there applications handling such large messages, MQ limit of 100MB
will never be used to its best, then!
If I use segmentation, will i have problems  during clustering?
Any idea about the release of this new adapter for iSeries, you think it
will help?

Thanks In Advance


Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!






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: Using setmqaut

Pavel,

Yes, I just tried to remove put and get authority from a queue for mqm and
found that any user of group mqm could still put/get messages.  So until
told otherwise, it looks like mqm IS GOD (as far as MQ is concerned) and
can't be restricted (same applies on windows if I try to restrict a
principal name that is a member of mqm - can still put/get).

Dave

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

OS/390 system scope

2003-07-09 Thread Burke Edward

Title: OS/390 system scope 






Ok the manual says this :


A WebSphere MQ subsystem with a CPF with scope of S can be defined on one or more z/OS images within a sysplex, so these images can share a single subsystem name table. However, you must ensure that the initial START command is issued on (or routed to) the z/OS image on which you want the WebSphere MQ subsystem to run. If you use this option, you can stop the WebSphere MQ subsystem and restart it on a different z/OS image within the sysplex without having to change the subsystem name table or re-IPL a z/OS system. 

But when I stop the Qmgr and try to bring it up on different LPAR I get a message stating that the subsystem is still running on another LPAR.  

To stop the subsystem do I need to do something besides stop the QMGR ?

Re: Using setmqaut

David,

First, I seems to me I tried all those tricks while ago and found mqm is a God.

Second, logically mqm is not in the ACLs from the very beginning (check with 
dspmqaut), so deleting him from there should not change anything (just an educated 
guess)

Third, even assuming mqm could be deleted from .. whatever, why whould s/he  be able 
to add him/herself back .. there.. using that very setmqaut? (another educated guess).

All those considerations are valid for Unix and (if I am not mistaken) Windows. I am 
not sure about other platforms.

Hope this will help,
Pavel




  "David C.
  Partridge"To:   [EMAIL PROTECTED]
  <[EMAIL PROTECTED]cc:
  RIMEUR.COM>   Subject:  Re: Using setmqaut
  Sent by: MQSeries
  List
  <[EMAIL PROTECTED]
  .AC.AT>


  07/09/2003 10:17
  AM
  Please respond to
  MQSeries List






Rick,

Hmmm... that sounds like it *is* possible, but use at your own risk - can
anyone confirm?

Thanks
David

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 e-mail may contain confidential and/or privileged information. If you are not the 
intended recipient (or have received this e-mail in error) please notify the sender 
immediately and destroy this e-mail. Any unauthorized copying, disclosure or 
distribution of the material in this e-mail is strictly forbidden.

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: Using setmqaut

Hello David,

AFAIK the answer is no. mqm is a God. I guess the only way to actually control access 
to the resources is to make sure no regular user is in mqm group. If some of them need 
to administer their own queue managers, then (on Unix platform), consider using 
trusted setuid-ed or sudo-controlled binaries or scripts, wrapping MQ control commands.

Hope this will help,
Pavel




  "David C.
  Partridge"To:   [EMAIL PROTECTED]
  <[EMAIL PROTECTED]cc:
  RIMEUR.COM>   Subject:  Using setmqaut
  Sent by: MQSeries
  List
  <[EMAIL PROTECTED]
  .AC.AT>


  07/09/2003 09:17
  AM
  Please respond to
  MQSeries List






Is it possible to use setmqaut to limit the access to a queue so that
members of group "mqm" do *not* have update access?

e.g. setmqaut -m qmgr1 -n a.b.* -t q -p mqm -put -get

Regards,
David C. Partridge
Security and MQ Products Manager
Primeur Group
Tel: +44 (0)1926 511058
Mobile: +44 (0)7713 880197

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 e-mail may contain confidential and/or privileged information. If you are not the 
intended recipient (or have received this e-mail in error) please notify the sender 
immediately and destroy this e-mail. Any unauthorized copying, disclosure or 
distribution of the material in this e-mail is strictly forbidden.

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

AS/400 RPG pgms cannot handle msg > 32k?

2003-07-09 Thread eai grp


Hi All,
 
What are my options if i need to put a message greater than 32K into queue using MQ API for RPG? I see that there is a limitation on the 'buffer' parameter declared to put/get messages.
Is 'nt there applications handling such large messages, MQ limit of 100MB will never be used to its best, then! 
If I use segmentation, will i have problems  during clustering?
Any idea about the release of this new adapter for iSeries, you think it will help?Thanks In Advance
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!

Re: Using setmqaut

Rick,

Hmmm... that sounds like it *is* possible, but use at your own risk - can
anyone confirm?

Thanks
David

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: TIBCO Rendezvous and MQ

Hello Yip,

No, you have to write your own event loop in MQ. It is not difficult to write it 
though (I wrote one a year or so ago). If I am not mistaken, though, you may use tibco 
internal queues to drive your mq message fetching (adding another event each time you 
are processing a callback) but I doubt it is worth it. The simple loop of type of the 
one shown in my previous e-mail must do. Especially because earlier  you mentioned you 
want to keep your app single-threaded, so even for tibrv you most probably will 
dispatch your queues explicitly from the program (tibrv C api has a call for it, I do 
not remember its name exactly, but the verb is 'dispatch' or at least is derived from 
it). BTW, if you are writing a new application I would definitely suggest you use C 
API in both RV and MQ -- it is much cleaner. IMHO, of course.

MQ pub/sub is more a server side animal, it allows sending and retrieving messages on 
by-topic basis, and smart inter-QM routing , instead of defining a separate queues 
and/or writing custom code. But it does not add much to the API (there is a "simpler" 
API, called AMI -- see support pack MA0F -- but even there, I guess you have to get 
the message manually with amReceivePublication() call. I have never used it myself 
though so others can correct me here). All pub/sub machinery (brokers) is controlled 
by sending messages to special queues and using special message headers -- MQRFH in 
your data messsages. I prefer not to use pub/sub in my MQ apps -- the MQ 
implementation of "simpler" pub/sub paradigm just requires too much from both the 
infrastructure and the code and adds additional hops and performance overhead to 
already existing MQ idiosyncrasies. But you mileage can vary, of course.

Hope this will help,
Pavel






  Chun Yip Lai
  <[EMAIL PROTECTED]To:   [EMAIL PROTECTED]
  OO.COM.HK>   cc:
  Sent by: MQSeriesSubject:  Re: TIBCO Rendezvous and MQ
  List
  <[EMAIL PROTECTED]
  n.AC.AT>


  07/08/2003 11:42
  PM
  Please respond to
  MQSeries List






Hi,

Thank for the reply from Arul Doss and Pavel
Tolkachev.

It seems that explicitly GET from the Queue is a must.
Could you clarify whether your GET means Subscribe? I
would like to use the PUB/SUB messaging.

Sorry that I am a novice in MQ, my question may be too
basic. Does MQ have any event manager and event loop
mechanism, which are used in TIB/Rv. If not, how can
MQ implement the callback for SUB? Or how can messages
be dispatched to my program? I am quite confusing
here.

If yes, I would like to confirm whether the event loop
of TIB/Rv works with that of MQ SUB. My program is
handling several Tib/Rendezvous listen callbacks, and
may handle together few MQ SUB callbacks later.

Tolkachev,
Thanks for your coding example. But running my loop is
not my preference. Anyway, since a C++ rv needs
running rv_MainLoop(). I would like to know the
position for the main loop in your case.

Thank you in advance. Regards,

Yip

> Subject: Re: TIBCO Rendezvous and MQ
> To: [EMAIL PROTECTED]
> From: "Pavel Tolkachev" <[EMAIL PROTECTED]>
> Date: Mon, 7 Jul 2003 09:28:59 -0400
>
>
> Hello Yip,
>
> Yes, you can use both from the same prorgram and, as
long as you
> dispatch your RV queue yourself, you can do it in a
single thread. MQ
> (even pub/sub) is not actually "pushing" messages to
your thread, so
> you can intermix those tibrv_...dispatch (I don't
remember the exact
> syntax) and MQPUT and MQGET calls in a tight (or not
so tight) loop.
> You will want to use MQGMO_NO_WAIT option in MQGET
message options to
> avoid delaying your rv dispatches. If you do not
want to waste much
> of your CPU horspower in a tight loop, that's how I
usually do it in
> my code (some people on the list may know I usually
advise to be a
> conservative with threads, so here is a small
single-thread trick).
>
> --cut here--
> bool someWorkDone; //not necessarily global, just
for the sake of
> example
>
> void yourTibrvCallBack() {
>   someWorkDone = true;
> }
>
> void yourRunLoopFunction() {
>   while(whatever) {
> someWorkDone = false;
> try to mqput, mqget and dispatch your tibrv
queue (the latter
> ends up in yourTibrvCallBack
> if(you have actually done some mqput or get some
message from
> mqget above)
>   someWorkDone = true;
> if(!someWorkDone)  sleep(some small time,
usually 1 msec is
> enough to keep a modern CPU almost free on idle
times);
>   }
> }
> --cut here--
>
> In this way  you do not limit your throughput when
you have messages
> to process, and, at the same time, give out almost
all CPU cycles
> when  you don't.
>
> Hope this will help,
> Pavel


_
[EMAIL PROTECTED]:$Q-1.I%q!A$d*w!A$_2H..

Re: MQ and LDAP

I would like to do user authentication but NOT at a UNIX OS Level. I thought
if LDAP or something similar exists like in the case of WAS.

-Original Message-
From: David C. Partridge [mailto:[EMAIL PROTECTED]
Sent: 09 July 2003 03:30
To: [EMAIL PROTECTED]
Subject: Re: MQ and LDAP

Emile,

I don't quite understand the question.   SSL supports LDAP for retrieving
CRLs, but I don't think that's what you're getting at.  Do you think you
could give us a bit more to chew on?

Thanks
Dave

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

For information about the Standard Bank group visit our web site
www.standardbank.co.za

Disclaimer and confidentiality note

Everything in this e-mail and any attachments relating to the official business of the 
Standard Bank Group Limited  is proprietary to the group.
It is confidential, legally privileged and protected by law. Standard Bank does not 
own and endorse any other content. Views and opinions are
those of the sender unless clearly stated as being that of the group.The person 
addressed in the e-mail is the sole authorised recipient. Please
notify the sender immediately if it has unintentionally reached you and do not read, 
disclose or use the content in any way.
Standard Bank can not assure that the integrity of this communication has been 
maintained nor that it is free of errors, virus, interception or interference.
II

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: Using setmqaut

2003-07-09 Thread Rick Tsujimoto

David,

I remember once that I did something along those lines and then realized
that I couldn't delete the queue!  I had to muck with the setmqaut settings
outside of MQ to restore the access I needed.  That happened using V5.1.




  "David C.
  Partridge" To:  [EMAIL PROTECTED]
  <[EMAIL PROTECTED] cc:
  RIMEUR.COM>Subject: Using setmqaut
  Sent by: MQSeries
  List
  <[EMAIL PROTECTED]
  .AC.AT>


  07/09/2003 09:17
  AM
  Please respond to
  MQSeries List





Is it possible to use setmqaut to limit the access to a queue so that
members of group "mqm" do *not* have update access?

e.g. setmqaut -m qmgr1 -n a.b.* -t q -p mqm -put -get

Regards,
David C. Partridge
Security and MQ Products Manager
Primeur Group
Tel: +44 (0)1926 511058
Mobile: +44 (0)7713 880197

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: MQ and LDAP

Emile,

I don't quite understand the question.   SSL supports LDAP for retrieving
CRLs, but I don't think that's what you're getting at.  Do you think you
could give us a bit more to chew on?

Thanks
Dave

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

Using setmqaut

Is it possible to use setmqaut to limit the access to a queue so that
members of group "mqm" do *not* have update access?

e.g. setmqaut -m qmgr1 -n a.b.* -t q -p mqm -put -get

Regards,
David C. Partridge
Security and MQ Products Manager
Primeur Group
Tel: +44 (0)1926 511058
Mobile: +44 (0)7713 880197

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: MQCONN FAILED

2003-07-09 Thread Stephan C. Moen

Title: RE: MQCONN FAILED









I have periodically seen similar
symptoms on MQ v5.2.0, where MQ does NOT log incidents or outages consistently
or the timestamps appear to be wrong. 
Upgrade to the latest CSD levels at v5.1 to seek resolution.  This may not resolve your MQCONN
problem but should restore a more consistent MQ logging picture for you. In
turn, a more reliable logging environment may lead you to the answer to resolving
your MQCONN problem.

 

-Original
Message-
From: MQSeries List
[mailto:[EMAIL PROTECTED]On Behalf Of Voges,
P. (Pieter)
Sent: Wednesday, July 09, 2003
4:14 AM
To: [EMAIL PROTECTED]
Subject: Re: MQCONN FAILED

 

Thanks everybody for the feedback. This
one really get to me. I have checked all 3 logs, and 2 of them is empty since
the last time the QMGR was sterted. The one under SYSTEM shows a channel going
inactive at 18:00 the previous day because of disconnect interval, and active
again on the day in question at 09:00. There is nothing inbetween at 06:10 when
the error occured.

On the sollution to retry the connect
because the QMGR might still be coming up, doesn't help. The QMGR has been
running since May 18 and this happened on June 25. 

Thank you 
Pieter Voges 
MQ Support 
Nedcor Limited 
Tel: (011) 881 4410 
Sel: 083 6455 300 
E-mail: [EMAIL PROTECTED] 
 

 

-Original Message- 
From: Robert Broderick [mailto:[EMAIL PROTECTED]] 
Sent: 08 July 2003 04:24 
To: [EMAIL PROTECTED] 
Subject: Re: MQCONN FAILED 

 

With an extension on Peter's comments
there are three error logs you need to 
look at. One in /errors and two in /qmgrs one under @SYSTEM/error
and one 
under YOUR_QMGR/error. 

  
bobbee 

 

>From: "Potkay, Peter M (PLC,
IT)" <[EMAIL PROTECTED]> 
>Reply-To: MQSeries List <[EMAIL PROTECTED]> 
>To: [EMAIL PROTECTED] 
>Subject: Re: MQCONN FAILED 
>Date: Tue, 8 Jul 2003 08:23:52 -0400 
> 
>Did you check both the server level MQ error logs as well as
the queue 
>manager specific error logs? 
> 
> 
>-Original Message- 
>From: Voges, P. (Pieter) [mailto:[EMAIL PROTECTED]] 
>Sent: Tuesday, July 08, 2003 2:36 AM 
>To: [EMAIL PROTECTED] 
>Subject: MQCONN FAILED 
> 
> 
> 
>We ran into an interesting problem and if anybody can explain
it or supply 
>me with any info in this regard I will really appreciate it. 
> 
>We got a QMGR (5.1 - I know I must upgrade to 5.3) running on
a AIX 
>box(4.3). On the box there is an application running as a
process that 
>starts up in the morning and then firstly does a connect to
the QMGR. Last 
>week the app started and tried to connect. It got a 2059 (QMGR
not 
>available) return code. Later in the day the app was restarted
and 
>connected 
>fine. My problem is that the QMGR had been running for a month
when this 
>happened. It was up and running on the first connect attempt.
There was no 
>intervention between the 2 attempts. There are no errors in
the logs. It is 
>a very low volume box so no default maximums was reached. 
> 
>Can anybody provide me with any possible causes or direct me
to whatever 
>else I can check. 
> 
>Thank you 
>Pieter Voges 
>MQ Support 
>Nedcor Limited 
>Tel: (011) 881 4410 
>Sel: 083 6455 300 
>E-mail: [EMAIL PROTECTED] 
>< http://dotweb.it.nednet.co.za/link.asp?names=Voges,%20Pieter 
>
> 
> 
> 
> 
> 
> 
>   _ 
> 
> 
> 
> 
> 
> 
>This email and any accompanying attachments may contain
confidential and 
>proprietary information.  This information is private and
protected by law 
>and, accordingly, if you are not the intended recipient, you
are requested 
>to delete this entire communication immediately and are
notified that any 
>disclosure, copying or distribution of or taking any action
based on this 
>information is prohibited. 
> 
>Emails cannot be guaranteed to be secure or free of errors or
viruses.  The 
>sender does not accept any liability or responsibility for any 
>interception, 
>corruption, destruction, loss, late arrival or incompleteness
of or 
>tampering or interference with any of the information
contained in this 
>email or for its incorrect delivery or non-delivery for
whatsoever reason 
>or 
>for its effect on any electronic device of the recipient. 
> 
>If verification of this email or any attachment is required,
please request 
>a hard-copy version. 
> 
> 
> 
>   _ 
> 
> 
> 
> 
> 
> 
> 
> 
>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. 
> 

_ 
The new MSN 8: smar

MQ and LDAP

Hi Guys and Dolls,

Does anybody out there know if the above is supported, especially for user
authentication on UNIX platforms?
IBMers, is this in the pipeline?

It will bypass the usimg of OS level security checks.


Emile Kearns
IBM Certified System Administrator - Websphere MQ, V5.3
MQSeries Administrator SCMB
>  Technology Infrastructure Group
> Information Technology Department
> Standard Corporate and Merchant Bank
>
>   E-mail: [EMAIL PROTECTED]
>   *Phone: +27-11-636-3336 SCMB, P.O. Box 61344, Marshalltown,
> 2107, Gauteng, RSA
>   *Fax:   +27-11-636-5713 2nd Floor, Entrance 6, 3 Simmonds
> Street, JHB
>
>
>

For information about the Standard Bank group visit our web site
www.standardbank.co.za

Disclaimer and confidentiality note

Everything in this e-mail and any attachments relating to the official business of the 
Standard Bank Group Limited  is proprietary to the group.
It is confidential, legally privileged and protected by law. Standard Bank does not 
own and endorse any other content. Views and opinions are
those of the sender unless clearly stated as being that of the group.The person 
addressed in the e-mail is the sole authorised recipient. Please
notify the sender immediately if it has unintentionally reached you and do not read, 
disclose or use the content in any way.
Standard Bank can not assure that the integrity of this communication has been 
maintained nor that it is free of errors, virus, interception or interference.
I

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: Finding userids - OS/390

2003-07-09 Thread Peter Moir

Title: Message

Thanks
Rebeccayou are right, I can actually get it from MO12 after all now I
look a bit more closely.
thanks
again,
Pete.

-Original Message-From: Bullock, Rebecca
(CSC) [mailto:[EMAIL PROTECTED] Sent: 09 July 2003
13:31To: [EMAIL PROTECTED]Subject: Re: Finding
userids - OS/390
Hi,
Pete. I suspect that the answer will be "no" from IBM because they want to be
able to modify the format of the log without worrying about impacting
customers (at least, that was the explanation from the distributed crowd, and
I'd expect the same from the MF folks). Actually, I would have expected MO12
to have done the trick since I'd expect to be able to extract the userids from
the message headers. You may have to play around with it though (It's been a
while since I did any significant playing with the MO12 output, so I can't say
for absolute positive).
Cheers, Rebecca

Rebecca BullockComputer Sciences
CorporationMFCoE/Newark CS TeamEducational Testing Service
AccountPrinceton, NJ 08541email: [EMAIL PROTECTED] or
[EMAIL PROTECTED]

-Original Message-From: Peter Moir
[mailto:[EMAIL PROTECTED]Sent: Wednesday, July 09,
2003 7:07 AMTo: [EMAIL PROTECTED]Subject:
Finding userids - OS/390
re:
MQ v5.2 on OS/390 V2.10.
Anyone know if
there are macros to map the records on the MQ logs. There is
some information in there that I want that I don't seem to be able to get
easily by other means i.e CSQ1LOGP.
In particular
the userid associated with incoming messages. I get it in the detailed
o/p from CSQ1LOGP (UNDO/REDO record) but not easily identifiable, the userid
field on the summary o/p doesn't list these userids (I get the CHIN userid).
I have MO12 but doesn't help in this case.
Maybe (probably!) there's an easier way
?
I want to do this over a period of time so
would rather not run any traces and because
of the current security settings on the systems I'm interested in these
userids are not being checked by RACF so I can't find them out from
RACF.
thanks,
Pete.
_

Notice to recipient:
The information in this internet e-mail and
any attachments is confidential and may be privileged. It is intended solely
for the addressee. If you are not the intended addressee please notify the
sender immediately by telephone. If you are not the intended recipient, any
disclosure, copying, distribution or any action taken or omitted to be taken
in reliance on it, is prohibited and may be unlawful.
When addressed to external clients any opinions
or advice contained in this internet e-mail are subject to the terms and
conditions expressed in any applicable governing terms of business or client
engagement letter issued by the pertinent Bank of America group entity.

If this email originates from the U.K. please
note that Bank of America, N.A., London Branch, Banc of America Securities
Limited and Banc of America Futures Incorporated are regulated by the
Financial Services Authority.
_

This e-mail and any files transmitted with it may contain
privileged or
confidential information. It is solely for use by the
individual for whom
it is intended, even if addressed incorrectly. If you received
this e-mail
in error, please notify the sender; do not disclose, copy,
distribute, or
take any action in reliance on the contents of this
information; and delete
it from your system. Any other use of this e-mail is
prohibited. Thank you
for your
compliance.

Notice to recipient:

The information in this internet e-mail and any attachments is confidential and may be privileged. It is intended solely for the addressee. If you are not the intended addressee please notify the sender immediately by telephone. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.

When addressed to external clients any opinions or advice contained in this internet e-mail are subject to the terms and conditions expressed in any applicable governing terms of business or client engagement letter issued by the pertinent Bank of America group entity.

If this email originates from the U.K. please note that Bank of America, N.A., London Branch, Banc of America Securities Limited and Banc of America Futures Incorporated are regulated by the Financial Services Authority.

Re: Finding userids - OS/390

2003-07-09 Thread Bullock, Rebecca (CSC)

Title: Message



Hi,
Pete. I suspect that the answer will be "no" from IBM because they want to be
able to modify the format of the log without worrying about impacting customers
(at least, that was the explanation from the distributed crowd, and I'd expect
the same from the MF folks). Actually, I would have expected MO12 to have done
the trick since I'd expect to be able to extract the userids from the message
headers. You may have to play around with it though (It's been a while since I
did any significant playing with the MO12 output, so I can't say for absolute
positive). 
 
Cheers, Rebecca
 

Rebecca BullockComputer Sciences CorporationMFCoE/Newark
CS TeamEducational Testing Service AccountPrinceton, NJ
08541email: [EMAIL PROTECTED] or [EMAIL PROTECTED]
  

  -Original Message-From: Peter Moir
  [mailto:[EMAIL PROTECTED]Sent: Wednesday, July 09, 2003
  7:07 AMTo: [EMAIL PROTECTED]Subject: Finding
  userids - OS/390
  re:
  MQ v5.2 on OS/390 V2.10.
   
  Anyone know if
  there are macros to map the records on the MQ logs. There is
  some information in there that I want that I don't seem to be able to get
  easily by other means i.e CSQ1LOGP.
   
  In particular the
  userid associated with incoming messages. I get it in the detailed o/p
  from CSQ1LOGP (UNDO/REDO record) but not easily identifiable, the userid field
  on the summary o/p doesn't list these userids (I get the CHIN userid). I have
  MO12 but doesn't help in this case.
   
  Maybe (probably!) there's an easier way
  ?
   
  I want to do this over a period of time so would
  rather not run any traces and because of the
  current security settings on the systems I'm interested in these userids
  are not being checked by RACF so I can't find them out from
  RACF.
   
  thanks,
  Pete.
  _
  
  Notice to recipient: 
  The information in this internet e-mail and any
  attachments is confidential and may be privileged. It is intended solely for
  the addressee. If you are not the intended addressee please notify the sender
  immediately by telephone. If you are not the intended recipient, any
  disclosure, copying, distribution or any action taken or omitted to be taken
  in reliance on it, is prohibited and may be unlawful. 
  When addressed to external clients any opinions or
  advice contained in this internet e-mail are subject to the terms and
  conditions expressed in any applicable governing terms of business or client
  engagement letter issued by the pertinent Bank of America group entity.
  
  If this email originates from the U.K. please note
  that Bank of America, N.A., London Branch, Banc of America Securities Limited
  and Banc of America Futures Incorporated are regulated by the Financial
  Services Authority.
  _
  




** 

This e-mail and any files transmitted with it may contain privileged or 

confidential information. It is solely for use by the individual for whom 

it is intended, even if addressed incorrectly. If you received this e-mail 

in error, please notify the sender; do not disclose, copy, distribute, or 

take any action in reliance on the contents of this information; and delete 

it from your system. Any other use of this e-mail is prohibited. Thank you 

for your compliance.

Re: World Writable File in MQ Directory - Security issue

Thanks Dave,

Where are the IBM'ers on THIS???

-Original Message-
From: David C. Partridge [mailto:[EMAIL PROTECTED]
Sent: 09 July 2003 01:15
To: [EMAIL PROTECTED]
Subject: Re: World Writable File in MQ Directory - Security issue

Any user needs to be able to create files in these directories in order for
the MQ code to work.   Is the issue that you are concerned about a DOS
attack where a malicious user does an rmdir?

The permissions I see on my Linux MQ 5.3 system for (most of) these
directories are:

drwxrwsrwx

So (for most)  the "sgid" bit is set, which means that files created in
these directories have a group owner of mqm.

However, the bit I was expecting to see set (and was not) was the "sticky
bit" which would prevent a normal user from removing the directory or files
in it they didn't create.

So I suspect that your concern may be valid.

Time for a "security/integrity" APAR?

PS The permissions on the /var/mqm/qmgrs/QMGR directories were drwxrwxr-x
and this should be OK!

Dave

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

For information about the Standard Bank group visit our web site
www.standardbank.co.za

Disclaimer and confidentiality note

Everything in this e-mail and any attachments relating to the official business of the 
Standard Bank Group Limited  is proprietary to the group.
It is confidential, legally privileged and protected by law. Standard Bank does not 
own and endorse any other content. Views and opinions are
those of the sender unless clearly stated as being that of the group.The person 
addressed in the e-mail is the sole authorised recipient. Please
notify the sender immediately if it has unintentionally reached you and do not read, 
disclose or use the content in any way.
Standard Bank can not assure that the integrity of this communication has been 
maintained nor that it is free of errors, virus, interception or interference.
I

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: World Writable File in MQ Directory - Security issue

Any user needs to be able to create files in these directories in order for
the MQ code to work.   Is the issue that you are concerned about a DOS
attack where a malicious user does an rmdir?

The permissions I see on my Linux MQ 5.3 system for (most of) these
directories are:

drwxrwsrwx

So (for most)  the "sgid" bit is set, which means that files created in
these directories have a group owner of mqm.

However, the bit I was expecting to see set (and was not) was the "sticky
bit" which would prevent a normal user from removing the directory or files
in it they didn't create.

So I suspect that your concern may be valid.

Time for a "security/integrity" APAR?

PS The permissions on the /var/mqm/qmgrs/QMGR directories were drwxrwxr-x
and this should be OK!

Dave

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

Finding userids - OS/390

2003-07-09 Thread Peter Moir

Title: Message

re:
MQ v5.2 on OS/390 V2.10.
Anyone know if
there are macros to map the records on the MQ logs. There is some
information in there that I want that I don't seem to be able to get easily by
other means i.e CSQ1LOGP.
In particular the
userid associated with incoming messages. I get it in the detailed o/p from
CSQ1LOGP (UNDO/REDO record) but not easily identifiable, the userid field on the
summary o/p doesn't list these userids (I get the CHIN userid). I have MO12 but
doesn't help in this case.
Maybe (probably!) there's an easier way
?
I want to do this over a period of time so would
rather not run any traces and because of the
current security settings on the systems I'm interested in these userids
are not being checked by RACF so I can't find them out from
RACF.
thanks,
Pete.

Notice to recipient:

If this email originates from the U.K. please note that Bank of America, N.A., London Branch, Banc of America Securities Limited and Banc of America Futures Incorporated are regulated by the Financial Services Authority.

Re: World Writable File in MQ Directory - Security issue

var/mqm/qmgrs/@SYSTEM/errors
var/mqm/qmgrs/@SYSTEM/shmem
var/mqm/qmgrs/QMGR/@ipcc/ssem
var/mqm/qmgrs/QMGR/ssem
var/mqm/errors
var/mqm/trace

They all seem to be /var/mqm/??? type of directories

-Original Message-
From: David C. Partridge [mailto:[EMAIL PROTECTED]
Sent: 09 July 2003 12:21
To: [EMAIL PROTECTED]
Subject: Re: World Writable File in MQ Directory - Security issue


Emile,

Are you prepared to share what file this might be?  Is it shipped by MQ
install with a mask of 777 or has this happened since?   Is this in
/var/mqm/ or /opt/mqm/

David

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

For information about the Standard Bank group visit our web site
www.standardbank.co.za

Disclaimer and confidentiality note

Everything in this e-mail and any attachments relating to the official business of the 
Standard Bank Group Limited  is proprietary to the group.
It is confidential, legally privileged and protected by law. Standard Bank does not 
own and endorse any other content. Views and opinions are
those of the sender unless clearly stated as being that of the group.The person 
addressed in the e-mail is the sole authorised recipient. Please
notify the sender immediately if it has unintentionally reached you and do not read, 
disclose or use the content in any way.
Standard Bank can not assure that the integrity of this communication has been 
maintained nor that it is free of errors, virus, interception or interference.
II

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: World Writable File in MQ Directory - Security issue

Emile,

Are you prepared to share what file this might be?  Is it shipped by MQ
install with a mask of 777 or has this happened since?   Is this in
/var/mqm/ or /opt/mqm/

David

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

World Writable File in MQ Directory - Security issue