Re: LSX and WMQ of NT 5.3
The short answer is yes - although it bothered me too just how it managed to do so! I guess the MA88 internals are fundamentally 1.1.8 compliant, despite the claims to the contrary. Another possibility is the "effective" JRE may not be that of the Domino server in run-time. Initially I thought this could be because I was firing the agents from the Notes TM hence the environment in which they ran was outside agent manager. However it also worked as a scheduled agent, so I'm forced to conclude MA88 really is happy with 1.1.8. I wouldn't guarantee this is the case with all other imported JARs however. Hope this clarifies. ___ Steve Sacho S3/CSSD - Architecture Tel: 805-577-3983 Internal: 92-598-3983 "MQSeries List" <[EMAIL PROTECTED]> wrote: Steve, Just to verify, since I'm the orginal requester. You have Domino R5, MQ 5.2.1, writing JAVA code to interface the 2 using JDK 1.3.x Is there any thing you need to do to make it work? Glen Larson Zurich North America Steve Sacho <[EMAIL PROTECTED]>@AKH-Wien.AC.AT> on 10/21/2002 05:53:42 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: LSX and WMQ of NT 5.3 Domino 6 supports Java 1.3.1, but I found no problems with MQ 5.2.1 and R5. Steve "MQSeries List" <[EMAIL PROTECTED]> wrote: Jim, > ... It's fine for IBM to say "just use Java," ... Just a question: MQv53 is _really_ working with Lotus Notes' embeddded JVM? AFAIK, Notes JVM is on level 1.1.8, but MQ Java API supported the version 1.3.0 or above. So how can a Notes developer work with MQv53? Tibor > I'm also interested in this. It's fine for IBM to say "just use Java," > but we've got LSX programmers, not Java programmers. I don't care how > similar the languages are, some of these people are guaranteed to be > befuddled by any change. Any at all. 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 *** PLEASE NOTE *** This E-Mail/telefax message and any documents accompanying this transmission may contain privileged and/or confidential information and is intended solely for the addressee(s) named above. If you are not the intended addressee/recipient, you are hereby notified that any use of, disclosure, copying, distribution, or reliance on the contents of this E-Mail/telefax information is strictly prohibited and may result in legal action against you. Please reply to the sender advising of the error in transmission and immediately delete/destroy the message and any accompanying documents. Thank you. 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: LSX and WMQ of NT 5.3
Domino 6 supports Java 1.3.1, but I found no problems with MQ 5.2.1 and R5. Steve "MQSeries List" <[EMAIL PROTECTED]> wrote: Jim, > ... It's fine for IBM to say "just use Java," ... Just a question: MQv53 is _really_ working with Lotus Notes' embeddded JVM? AFAIK, Notes JVM is on level 1.1.8, but MQ Java API supported the version 1.3.0 or above. So how can a Notes developer work with MQv53? Tibor > I'm also interested in this. It's fine for IBM to say "just use Java," > but we've got LSX programmers, not Java programmers. I don't care how > similar the languages are, some of these people are guaranteed to be > befuddled by any change. Any at all. 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: LSX and WMQ of NT 5.3
It means not supported, but will work. I am using both MQLSX on iSeries and Win32 quite happily , and it is a very rich API. I have converted to Java which works perfectly too, of course. A bigger problem is the triggering of Notes agents, which currently is also a deprecated SupportPac, so you may have to resort to scheduled Notes agents i.e. not triggering. Bottom line is IBM is trying to deprecate any features in Domino that compete with WebSphere, although they won't admit this! __ Steve Sacho Tel: 805-577-3983 Internal: 92-598-3983 "Glen Larson" <[EMAIL PROTECTED]> Sent by: "MQSeries List" <[EMAIL PROTECTED]> 10/17/2002 09:44 AM Please respond to "MQSeries List" <[EMAIL PROTECTED]> To [EMAIL PROTECTED] cc Subject LSX and WMQ of NT 5.3 Hi, I know the DOC says that LSX support is dropped in V5.3. But our application folks what me to verify whether that means it will not work, or is just not supported. I told them it doesn't matter just use JAVA, but they insist. (kind of like the old MACRO v COMMAND level debate for the old time CICS Techs) Any takers? Thanks Glen Larson Zurich North America *** PLEASE NOTE *** This E-Mail/telefax message and any documents accompanying this transmission may contain privileged and/or confidential information and is intended solely for the addressee(s) named above. If you are not the intended addressee/recipient, you are hereby notified that any use of, disclosure, copying, distribution, or reliance on the contents of this E-Mail/telefax information is strictly prohibited and may result in legal action against you. Please reply to the sender advising of the error in transmission and immediately delete/destroy the message and any accompanying documents. Thank you. 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 Starup problem
With MQ security on Win32, it seems there are always 3 places to manage this, and I'd appreciate anyone jumping in and explaining the subtle differences - I tend to check all: Using"setmqaut" from the command line The "obvious" user/group/domain security objects you allude to below Using dcomcnfg.exe - which seems like an alternate to Control Panel > Services The last one tends to fix everything for me. ___ Steve Sacho CSSD - Enterprise Architecture Tel: 805-577-3983 Internal: 92-598-3983 "Supraba Shekharan" <[EMAIL PROTECTED]> Sent by: "MQSeries List" <[EMAIL PROTECTED]> 08/20/2002 04:37 AM Please respond to "MQSeries List" To: [EMAIL PROTECTED] cc: Subject: MQ Starup problem Hi All, I am facing a problem in starting MQSeries and MQSI. We had installed MQSeries and MQSI on our NT machine using an id (local to the machine) with administrator rights. Now this local id is disabled and we need to login thru the network domain. This id doesnt have any administrator rights. But i've included it in the MQM group. But still i able not able to open the MQ Explorer and the or Start the services. What would be the problem? I believe to open the MQexplorer and start services its enough if the login id is a member of MQM group. But still it doesnt work. Am i mising out something? Please help. Thanks, Regards, Supraba. ***The information contained in this message is legally privileged and confidential information intended only for the use of the addressed individual or entity indicated in this message (or responsible for delivery of the message to such person). It must not be read, copied, disclosed, distributed or used by any person other than the addressee. Unauthorised use, disclosure or copying is strictly prohibited and may be unlawful. Opinions, conclusions and other information on this message that do not relate to the official business of any of the constituent companies of the TATA CONSULTANCY SERVICES shall be understood as neither given nor endorsed by the Group. If you have received this message in error, you should destroy this message and kindly notify the sender by e-mail. Thank you.*** 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: MQSeries Client Security - SSL
"The part that seems to be missing with regard to MQSeries SSL support (other than on MVS) is the ability to associate a certificate with a userid." If this is true (and I haven't explored the new SSL features in depth), then I would propose using a workflow layer that DOES do the user-cert association. There are many workflow products that do this natively (e.g. Lotus Notes), or you could use an LDAP directory that stores SSL certs per user. So yes, we're talking another application layer here to fill the gap, but then you're likely to have the architectural need for it anyway independently of the security issues with MQ, right? _______ Steve Sacho CSSD - Enterprise Architecture Tel: 805-577-3983 Internal: 92-598-3983 "Malamud, Mikhail" <[EMAIL PROTECTED]> Sent by: "MQSeries List" <[EMAIL PROTECTED]> 07/15/2002 01:04 PM Please respond to "MQSeries List" To: [EMAIL PROTECTED] cc: Subject: Re: MQSeries Client Security - SSL Bruce - Depending what your business goals are, you could choose either one. SSL solution might prove a lot more scalable in terms of managing security issues and creating trust relationships. For example, if your clients represent outside business partners, they are a lot more likely to adopt a feature of the product rather than third party exit. There are many other reasons why I belive SSL is a good solution. I am not sure what your architecture is but perhaps instead of using a channel exit to associate a client connection with the user id. You could could goup your clients into profiles and then have separate channels that have MCAUSER ID already put in to be accessed by those groups of clients. Further, you could make sure that you clients are not using the access points - channel that they are not supposed to access using DN matching or by having certain keys in your key repository. If you use channel exits that associate user id with each client connection, you will implement something that is called Identity based access control. The solution I described resembles role based acess (RBAC). Here are some guidelines to help you decide which one to go with simply from the security perspective disregarding exits and certificates. Identity Based Access Control Pro's Fine grained configs Better Accountability Perhaps a regulation compliance Auditing Con's Administration overhead, each user needs to be handled separately. Not very scalable. Role Based AC. Pro's Easier Administration. You pretty much have preset profiles and their permissions. Scalable up to a certina point. Easier to import/export/maintain restrictions in the other envrionments. Fits businee model better. Con's are IB bases pro's. If you can deal without the fact that each client session has to be associated with the user id, I would still refrain from using a channel exit. Mikhail. Mikhail, I understand and agree with most of what you're saying. Where I disagree is your statement that all you can do from a security exit is say whether the connection will take place or not. The other thing you can do in the security exit is specify the userid that will be used by the OAM for access control once the connection does take place. The part that seems to be missing with regard to MQSeries SSL support (other than on MVS) is the ability to associate a certificate with a userid. It sounds like you may be able to make this association thru a security exit However, if this were available as part of the base product, we could do away with the security exit entirely. - Bruce Giordano 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: QMGR names when using MQSI
While I appreciate the need to have QM naming convention reflect the underlying platform, I think it makes more sense to keep QM names the same for dev test and prod environments. This is for 2 basic reasons: 1] Many MQ admins rely on script generators such as SupportPac MS03 to save/clone an MQ config for promotion to production, and if the QM names are different, it means editing the files and whatever objects were dependent on the QM name. 2] Some MQ apps do NOT want to use the local default QM for connection, or require a specific destination QM in the MQOPEN for reasons such as "forced" loadbalancing, hence different QM names between environments means changes to code. Although 2] could (and should) be helped by externalizing all QM names/vars in property/profile files, it's a lot easier when you don't have the worry of making QM name changes when promoting to production. OTOH, if your environment is clustered, this makes having different QM names much less of an issue. I've found it boils down to who dominates in your organization: The hardware/infrastructure, or the architect/design/development teams. _______ Steve Sacho CSSD - Enterprise Architecture Tel: 805-577-3983 Internal: 92-598-3983 "Boger, Dan" <[EMAIL PROTECTED]> Sent by: "MQSeries List" <[EMAIL PROTECTED]> 06/24/2002 08:26 AM Please respond to "MQSeries List" To: [EMAIL PROTECTED] cc: Subject: Re: QMGR names when using MQSI > I'm having a disagreement with a colleague on QMGR names when using MQSI on > WIN/NT machines and I'm looking for some confirmation or explanation. My > colleague contends that IBM has a requirement/restriction for all the QMGRs > supporting MQSI on his Development, Test and Production to have the same > name in order for him to move his code between these MQSI machines. I'm not > an MQSI person, but to me, this doesn't make any sense. I'm on the OS/390 > side of the house and I'm saying that QMGR names should all have unique > names within the environment. Can anyone help? For what it's worth, I agree with you. We keep all the QMGRs name unique within our environment. However, that doesn't mean you have to edit your flows when you move from one to the other. You can leave the QMGR name blank in the output node of an MQSI flow, which will resolve as the local QMGR. This means you can have remote queue definitions on the dev broker, pointing to dev servers, which have the same queue name pointing to test servers on a test broker. Hope that helps! Dan 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: Lotus Notes
Francois, be careful choosing the MQLSX - check the archives for the thread I started a few months ago "Lotus Notes trigger monitor, MQLSX support GONE!!!" - kind of self-explanatory! _______ Steve Sacho CSSD - Systems Development Enterprise Architecture Tel: 805-577-3983 Internal: 92-598-3983 "Alan Stewart" <[EMAIL PROTECTED]> Sent by: "MQSeries List" <[EMAIL PROTECTED]> 06/21/2002 03:21 AM Please respond to "MQSeries List" To: [EMAIL PROTECTED] cc: Subject: Re: Lotus Notes Francois askd if there was a reliable way of connecting Notes to MQSeries. I can think of three ways (my experience in the last 3 years): 1) Use the MQ Lotus Script classes (mqlsx) in Notes agents. 2) Use the IBM supplied Java classes (the latest MA88 package for MQ 5.2.1, for example) and write Java agents 3) As for 2 (but external to Notes, eg a Java app/servlet/ejb etc), and connect via the IIOP protocol and create/modify/delete Notes documents. If you want specifics, I'm happy to help. Regards Alan (See attached file: Disclaimer.txt) This email is intended for the named recipient only. The information contained in this message may be confidential, or commercially sensitive. If you are not the intended recipient you must not reproduce or distribute any part of the email, disclose its contents to any other party, or take any action in reliance on it. If you have received this email in error, please contact the sender immediately. Please delete this message from your computer.
Re: MQ vs Connect Direct
I'm aware of the unfortunate misconception of MQ as a glorified and costly FTP, but this is precisely the area in which it's being challenged - Connect Direct is seen as a viable alternative when it's just a file transfer role that's being considered. My question was then as a head-to-head file transfer solution, what's the knock-out punch for MQ vs. CD, if any? [EMAIL PROTECTED] Sent by: "MQSeries List" <[EMAIL PROTECTED]> 06/20/2002 10:15 AM Please respond to "MQSeries List" To: [EMAIL PROTECTED] cc: Subject: Re: MQ vs Connect Direct Connect Direct is a file transfer system... Why do you want to compare them ? CD uses TCP/IP, or SNA (LU6 or LU0) Its very fast using LU0. Steve_Sacho@COUN To: [EMAIL PROTECTED] TRYWIDE.COM cc: Sent by: Subject: MQ vs Connect Direct MQSERIES@akh-wie n.ac.at 06/20/2002 12:07 PM Please respond to MQSERIES Anyone have a brief comparison of MQSeries vs. Connect Direct (from Sterling)? Thanks, Steve Anyone have a brief comparison of MQSeries vs. Connect Direct (from Sterling)? Thanks, Steve This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase & Co., its subsidiaries and affiliates. 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
MQ vs Connect Direct
Anyone have a brief comparison of MQSeries vs. Connect Direct (from Sterling)? Thanks, Steve
Windows Terminal Server
It's been discussed by this group, so I thought you'd be interested in a snippet from a reply I received from IBM, to a Q I asked regarding the whole Windows Terminal Server - MQ conflict issue: "The Windows 2000 Terminal Server environment introduces the idea of name spaces for kernel objects within the operating system. The local and global processes reside within one namespace, and clients and client initiated processes reside in others. Each client, when connected, is allocated a namespace of its own, and the default behaviour for newly created processes is to create them in this client namespace. Processes created in a client s namespace are not immediately accessible by other clients, and therefore the client s namespace can be considered protected and separate, as if the client is running on a separate machine altogether from other clients. Client processes can see the global namespace. . The implication of this to IBM MQSeries is that the core processes such as the queue manager itself, should be launched in the global namespace, and not under individual client namespaces. If the queue manager is started by a client therefore, it will not be available to other clients, or applications local to the server itself. One of the reasons for adhering to this model is to protect against processes being created in temporary namespaces, which are only available for the duration of the client connection. (ie. A client could log into the system then start a queue manager; if the server had access to that queue manager, they could start using it, but then, the client disconnects, and all processes in that namespace are terminated - including the queue manager that may be in use). . In practice, queue managers should be started either by the Windows NT IBM MQSeries Service, by the MMC MQSeries Services snapin, or by a user logged into the server machine locally. The MQSeries Services snap-in works in this scenario because the actual start command is executed under the MUSR_MQADMIN user account, which is running in a local namespace on the server itself. . There has been some discussion that MTS will be supported in MQSeries 5.3, but as of yet I don't have any confirmation. Please be on the look out for product release info that should be coming soon.
Re: MQLSX
Any LotusScript code using MQLSX will surely be "supported" i.e. it won't suddenly break when newer versions of MQ come out - at worst you may have to keep your own copy of the mqlsx.dll. But the larger issue of concern for Lotus developers is IBM's not-so-subtle shift away from LotusScript as the language of choice in Notes, and the MQLSX is a clear casualty. Of course Java is just as good if not better, and if you're still adamant on Basic, just use the VB MQI (COM or ActiveX) API which you can include in LotusScript code, as pointed out by Gary below. Personally, I think it's a good excuse to move to Java with all it's architecture benefits. Another issue to look out for implicit in IBM's Lotus strategy, is the Notes Trigger Monitor SupportPac, and the accompanying "Lotus Notes Agent" process definition that currently is a built in type with MQ 5.x. You may want to take this into account too when architecting new Notes/MQ systems! Bottom line: I would recommend using MA88 for coding Domino agents, and scheduling them every few minutes rather than having them triggered by MQ. Steve "Gary Chesser" <[EMAIL PROTECTED]> Sent by: "MQSeries List" <[EMAIL PROTECTED]> 05/10/2002 07:45 AM Please respond to "MQSeries List" To: [EMAIL PROTECTED] cc: Subject: Re: MQLSX I have attached this thread below for reference. IMHO , I would use the following logic. What is you Production Platform ? If the answer is something other than windows use the MQLSX or MA88 ( Java Bindings). If you want something that is better for High volume use MA88 even though Notes has it's own thread model this works unless you are not comformtable with java in Notes. Then go back to MQLSX knowing that someday this will change someday. If you are only comfortable with LotusScript use the MQLSX. If the answer is Windows use the MQLSX or the VB Bindings or Active X Automation Classes object. There are many options but the right answer depends on the application design , environment and skillset or the resources. When in doubt model it out. Hope this helps, Gary > If you check, the MQLSX dll is distributed with the NT MQ 5.2 client. > The controversy is that IBM has withdrawn the support pak, but since it is > distributed with the client, what does that mean for 5.3? When will > support end? > > I began a thread on this a few months ago. Check the archives for "RE: > Lotus Notes trigger monitor, MQLSX support GONE!!!", and contact me for > any further details if you want. The short answer is IBM has withdrawn > support for it, and recommends using SupportPac MA88 as an alternative... > Years back I went on MQSeries training and remember being told something > about MQLSX. > > Does it still exist and where can I find some documentation? 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: MQLSX
Hi Emile, I began a thread on this a few months ago. Check the archives for "RE: Lotus Notes trigger monitor, MQLSX support GONE!!!", and contact me for any further details if you want. The short answer is IBM has withdrawn support for it, and recommends using SupportPac MA88 as an alternative... - Steve "Emile Kearns" <[EMAIL PROTECTED]> Sent by: "MQSeries List" <[EMAIL PROTECTED]> 05/09/2002 02:50 AM Please respond to "MQSeries List" To: [EMAIL PROTECTED] cc: Subject: MQLSX Hi All, Years back I went on MQSeries training and remember being told something about MQLSX. Does it still exist and where can I find some documentation?
