Re: triggering TWS job
Title: triggering TWS job Hi Prince, By TWS, you mean Maestro, right? If so, yes, we do that on unix and windows. Let me know if this is the right info, and I'll tell you how we do it. Bridgette -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Jose, PrinceSent: Friday, January 30, 2004 2:49 PMTo: [EMAIL PROTECTED]Subject: triggering TWS job Hello! Does anybody have experience in triggering a program scheduled in TWS from MQSeries? TWS is Tivoli Workload Scheduler for distributed platform. Thanks, Prince
Re: Fish outa water
Jerry, There are several JMS providers in addition to WMQ but none, that I know of anyway, that will pull WMQ messages out of the mainframe. Now, the manager in question may be referring to the ability of WMQ JMS to run over a client connection to connect to the mainframe. This would in fact be free for the Solaris machine but I'm not sure if the Mainframe client connect feature is a licensed component. Someone else on the list is sure to answer that one. In any case, migration to a client when you've already invested in the MQ Server is questionable. The client introduces a few new issues you will need to deal with. First of all, you will be using a synchronous connection to talk with an agent at the QMgr which then talks to MQ. If the connection breaks in between issuance of an API call (GET, PUT, COMMIT, etc.) you have no way of knowing whether the call was successful or not. To deal with this, your application needs to have some way of recovering state after a broken connection. The other issue is security. A server-to-server channel will never do anything other than deliver messages. A client-to-server channel has the ability to alter WMQ objects and, in its default configuration, send PCF messages to the MQ command server. To secure the channel, you will need to use SSL or a channel exit and set the MCAUSER at the mainframe side. It seems like this is a lot of effort to go through in order to save a few thousand dollars on an application that, based on your email, isn't broken. -- T.Rob -Original Message- From: Cergol, Jerry [mailto:[EMAIL PROTECTED] Sent: Friday, January 30, 2004 3:19 PM To: [EMAIL PROTECTED] Subject: Fish outa water I've been running WMQ for z/OS 5.3 on my IBM Mainframe and sending relatively medium-size and moderately frequent persistent messages outbound to a Sun Solaris running WMQ 5.3. The Sun Solaris manager wants to jetison WMQ altogether because it is expensive relative to its utilization. He mentioned a publish/subscribe type architecture what would use Java Messaging Services on the Sun/Solaris to pull data over from z/OS WMQ. I've been implementing and maintaining WMQ on both the mainframe and the Sun but, being strictly limited to dealing with IBM z/OS components, I have no clue as to where to start to get a handle on the requirements for a JMS-WMQ design. Can anyone point me at a manual or reference as a starting point? Thanks in advance. Jerry Cergol Cleveland Clinic Foundation IBM Mainframe System Support -- Confidentiality Note: This message is intended for use only by the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. 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: Fish outa water
Jerry, The following link will take you to where you can download the PDF manual for "WebSphere MQ Using Java". Within this manual you will find the JMS API described. http://www.elink.ibmlink.ibm.com/public/applications/publications/cgibin/pbi.cgi?CTY=US&FNC=SRX&PBL=SC34606602# Cergol, Jerry wrote: I've been running WMQ for z/OS 5.3 on my IBM Mainframe and sending relatively medium-size and moderately frequent persistent messages outbound to a Sun Solaris running WMQ 5.3. The Sun Solaris manager wants to jetison WMQ altogether because it is expensive relative to its utilization. He mentioned a publish/subscribe type architecture what would use Java Messaging Services on the Sun/Solaris to pull data over from z/OS WMQ. I've been implementing and maintaining WMQ on both the mainframe and the Sun but, being strictly limited to dealing with IBM z/OS components, I have no clue as to where to start to get a handle on the requirements for a JMS-WMQ design. Can anyone point me at a manual or reference as a starting point? Thanks in advance. Jerry Cergol Cleveland Clinic Foundation IBM Mainframe System Support -- Confidentiality Note: This message is intended for use only by the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. 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 -- Regards, Thomas DunlapChief Technology Officer[EMAIL PROTECTED] Themis, Inc.http://www.themisinc.com1 (800) 756-3000 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: triggering TWS job
Title: RE: triggering TWS job Our environment is slightly different. The scheduling info is stored in AIX. And the jobs are scheduled via GUI job scheduling console . We have a similar process in place for mainframe. MQ on mainframe triggering batch jobs scheduled in CA7. Currently, I am looking for MQ on AIX triggering a java program which is in TWS. I am not sure how to start the TWS from an external script. -Original Message- From: Jim Ford [mailto:[EMAIL PROTECTED]] Sent: Friday, January 30, 2004 2:58 PM To: [EMAIL PROTECTED] Subject: Re: triggering TWS job No, but I'm trying to figure it out myself. We're running in 'end-to-end' mode, which I guess means that the scheduling info is stored on the mainframe, and I need to use mainframe techniques to get the jobstream scheduled. Is that your environment, too? "Jose, Prince" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Sent by: MQSeries cc: List Subject: triggering TWS job <[EMAIL PROTECTED] n.ac.at> 01/30/2004 01:49 PM Please respond to MQSeries List Hello! Does anybody have experience in triggering a program scheduled in TWS from MQSeries? TWS is Tivoli Workload Scheduler for distributed platform. Thanks, Prince 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
Fish outa water
I've been running WMQ for z/OS 5.3 on my IBM Mainframe and sending relatively medium-size and moderately frequent persistent messages outbound to a Sun Solaris running WMQ 5.3. The Sun Solaris manager wants to jetison WMQ altogether because it is expensive relative to its utilization. He mentioned a publish/subscribe type architecture what would use Java Messaging Services on the Sun/Solaris to pull data over from z/OS WMQ. I've been implementing and maintaining WMQ on both the mainframe and the Sun but, being strictly limited to dealing with IBM z/OS components, I have no clue as to where to start to get a handle on the requirements for a JMS-WMQ design. Can anyone point me at a manual or reference as a starting point? Thanks in advance. Jerry Cergol Cleveland Clinic Foundation IBM Mainframe System Support -- Confidentiality Note: This message is intended for use only by the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. 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: triggering TWS job
No, but I'm trying to figure it out myself. We're running in 'end-to-end' mode, which I guess means that the scheduling info is stored on the mainframe, and I need to use mainframe techniques to get the jobstream scheduled. Is that your environment, too? "Jose, Prince" <[EMAIL PROTECTED]>To: [EMAIL PROTECTED] Sent by: MQSeriescc: List Subject: triggering TWS job <[EMAIL PROTECTED] n.ac.at> 01/30/2004 01:49 PM Please respond to MQSeries List Hello! Does anybody have experience in triggering a program scheduled in TWS from MQSeries? TWS is Tivoli Workload Scheduler for distributed platform. Thanks, Prince 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
triggering TWS job
Title: triggering TWS job Hello! Does anybody have experience in triggering a program scheduled in TWS from MQSeries? TWS is Tivoli Workload Scheduler for distributed platform. Thanks, Prince
Re: How do I see/list current users of a MQ manager
I'm pretty sure that MQ_TERM_EXIT WILL NOT be called if the process is killed -9 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: AMQ6150 MQSeries semaphore is busy
Title: RE: AMQ6150 MQSeries semaphore is busy
If it is when starting up mq, we run the following script on Solaris with "mqm" as the parameter. This can run only when all queue managers are down. The situation happens sometimes when MQ abends.
Regs,
Jeroen
- - - BEGIN OF SCRIPT - - -
if [[ $# -ne 1 ]]
then
print "$0: Removes all semaphores and shared memory for a user"
print "$0: Usage"
print "$0 username"
exit 1
fi
TheUser=$1
# 1) List All IPC Resource
# 2) Select only resource type, resource id, owner
# 3) Select only for one user
# 4) Produce ipcrm command
# 5) Execute commands
ipcs -a | \
awk '{print $1" " $2" "$5}' | \
egrep $TheUser | \
awk '{print "ipcrm -"$1 $2";"}' | \
while read line
do
$line
done
exit 0
- - - END OF SCRIPT - - -
-Original Message-
From: Karthikeyan, T. (Karthikeyan) [mailto:[EMAIL PROTECTED]]
Sent: Friday 16 January 2004 10:10
To: [EMAIL PROTECTED]
Subject: AMQ6150 MQSeries semaphore is busy
Hi all,
On HP-UX MQ 5.2,
I'm getting the following error. Please explain this error message and give
the solution.
AMQ6150: MQSeries semaphore is busy.
EXPLANATION: MQSeries was unable to acquire a semaphore within the normal
timeout period of 0 minutes.
ACTION: MQSeries will continue to wait for access. If the situation does not
resolve itself and you suspect that your system is locked then investigate
the process which owns the semaphore. The PID of this process will be
documented in the accompanying FFST.
thanks
karthik
**
PLEASE NOTE: The above email address has recently changed from a previous naming standard -- if this does not match your records, please update them to use this new name in future email addressed to this individual.
This message and any attachments are intended for the
individual or entity named above. If you are not the intended
recipient, please do not forward, copy, print, use or disclose this
communication to others; also please notify the sender by
replying to this message, and then delete it from your system.
The Timken Company
**
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
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.
Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-
Re: How do I see/list current users of a MQ manager
Hello T.Rob, The pleasure is mine -- that was because of your e-mail I actually started looking at API exits in the books. I have never used them myself but the problem of MQ connection monitoring seems to become of a practical interest for us here as well, so I am trying to figure out how I would go about it. The IBM documentation is one of their strongest points; still, for my particular question I am not sure if it answers it. Namely, would MQ_TERM_EXIT be called if an application is, for example, killed -9 while it owns the connection handle? My main platforms of interest for this is Solaris (8+) and Wintel and, potentially, AIX. I guess MQ tracing could do the thing, at least in theory, but this would amost surely have an unacceptable impact on the system not to mention its having a highly platform-specific controls and output so I am leaving it for a really last resort. Thanks, Pavel "Wyatt, T. Rob" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] MERICA.COM> cc: Sent by: MQSeries Subject: Re: How do I see/list current users of a MQ manager List <[EMAIL PROTECTED] C.AT> 01/30/2004 08:56 AM Please respond to MQSeries List Pavel, I always felt that WMQ terminology is one of those things that steepens the learning curve. We have clients in the context of client-server and clients in the context of client vs. bindings; we have clusters that are not what most people think of as clusters; etc., etc. So based on your comment I had to go look up API Exits. (By the way, thanks IBM - that Bibliography and Glossary book is great!) Turns out you are right. It's not even 9am here and I've already learned something new and useful today. Thank you! Here's what the book said: API exit A user-written program that monitors or modifies the function of an MQI call. For each MQI call issued by an application, the API exit is invoked before the queue manager starts to process the call and again after the queue manager has completed processing the call. The API exit can inspect and modify any of the parameters on the MQI call. The API exit is not supported on WebSphere MQ for z/OS. API-crossing exit A user written program that is similar in concept to an API exit. It is supported only by WebSphere MQ for z/OS and for CICS applications only. -- T.Rob -Original Message- From: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Sent: Thursday, January 29, 2004 6:04 PM To: [EMAIL PROTECTED] Subject: Re: How do I see/list current users of a MQ manager Wow again! Using an API exit is another nice idea (I think the "crossing" term is only used for z/OS, but I am not sure..). Like registering MQ_TERM_EXIT and MQ_CONNX_EXIT and dumping all the results into some queue (where else? :-)) available for curious managers? Seems to be the only way and thank you for pointing it out. But would MQ_TERM_EXIT track the abnormal process terminations? Anyone has any idea (except for "go and try:-)")? Thank you in advance, Pavel 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: Need a utility to move messages from one queue to another.
Title: RE: Need a utility to move messages from one queue to another. Just make the source queue an alias queue that points to the destination queue and let MQ do the work! :-) -Original Message- From: Larry Hendersen [mailto:[EMAIL PROTECTED]] Sent: Thursday 15 January 2004 16:57 To: [EMAIL PROTECTED] Subject: Need a utility to move messages from one queue to another. I would like to move all messages from one queue to another. Is there a support pack that will do that? UNIX or Windows would be fine, or if the source is available any platform? I want the utility to not exit, but rather keep running and wait for more messages. _ Let the new MSN Premium Internet Software make the most of your high-speed experience. http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1 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 - ATTENTION: The information in this electronic mail message is private and confidential, and only intended for the addressee. Should you receive this message by mistake, you are hereby notified that any disclosure, reproduction, distribution or use of this message is strictly prohibited. Please inform the sender by reply transmission and delete the message without copying or opening it. Messages and attachments are scanned for all viruses known. If this message contains password-protected attachments, the files have NOT been scanned for viruses by the ING mail domain. Always scan attachments before opening them. -
Re: T-Rex distributed systems
I am a FORTRAN person myself so thanks to Curt here is the PL/I code Hi Dave, I am writing directly to you since I sometimes have difficulty posting to the list. The following PL/I code will return the System ID to the calling application. If you have a PL/I compiler available, then just compile and use it as is. If no PL/I compiler is available, it at least shows you the control block navigation. Most of our code base is PL/I but perhaps writing this in assembly language would make for a more generic multiple-use component. Regards, Curt MQSYSID: PROCEDURE(SYSID) OPTIONS(REENTRANT) REORDER; DECLARE SYSID CHAR(08); DECLARE ADDR BUILTIN; DECLARE GROUND_ZERO FIXED BIN(31) STATIC INIT(0); DECLARE ADDR_0 POINTER BASED( ADDR(GROUND_ZERO) ); DECLARE 1 PSA BASED(ADDR_0), 2 FILLER CHAR(16), 2 CVT_PTR POINTER; DECLARE 1 CVT BASED(CVT_PTR), 2 FILLER CHAR(340), 2 SYS_ID CHAR(08); SYSID = CVT.SYS_ID; EOM: END MQSYSID; Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] A lone amateur built the Ark. A large group of professionals built the Titanic --
Re: T-Rex distributed systems
since the list has afforded me so many ways to approach the same results (especially getting to clusters through QSG's) I thought I would give the programmers the COBOL equivalent * 01 ZOS-CVT-P USAGE IS POINTER. 01 ZOS-CVT-P-N REDEFINES ZOS-CVT-P PIC S9(9) COMP. 01 ZOS-SYS-P USAGE IS POINTER. 01 ZOS-SYS-P-N REDEFINES ZOS-SYS-P PIC S9(9) COMP. * * - * LINKAGE SECTION. * - * 01 ZOS-CVT USAGE IS POINTER. 01 ZOS-CVT-N REDEFINES ZOS-CVT PIC S9(9) COMP. 01 ZOS-SYSNAME. 05 ZOS-SYS PIC X. 05 FILLER PIC XX. 05 ZOS-SYS-N PIC X. 05 FILLER PIC X(4). * * * * MOVE 16 TO ZOS-CVT-P-N. SET ADDRESS OF ZOS-CVT TO ZOS-CVT-P. COMPUTE ZOS-SYS-P-N = ZOS-CVT-N + 340. SET ADDRESS OF ZOS-SYSNAME TO ZOS-SYS-P. DISPLAY 'SYSNAME IS ' ZOS-SYSNAME. MOVE ZOS-SYS-N TO WPRM-QMGR-4. DISPLAY 'QMGR IS ' WPRM-QMGR. * Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] A lone amateur built the Ark. A large group of professionals built the Titanic -- Roger Lacroix <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 01/29/2004 04:29 PM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: T-Rex distributed systems Hi, Basically, you want to determine what LPAR (I think in terms of MVS!!!) the code is running on? Wow, I had to really scratch my head on this one - its been awhile. :) It took me a while to find my dinosaur suit; it was hiding in the back of the closet. A little tight, but it still fits. (I'm not sure if I should be happy or sad!!!) Warning: For non-mainframe people you can delete this message right now!! (Quick, look away because here comes some assembler code!!!) Here's how I would do it in assembler: * - - - - - - - - - - - - - - - - - - - - - - - - * Get then set system id * - - - - - - - - - - - - - - - - - - - - - - - - USING PSA,0 L R4,FLCCVT R4 -> CVT USING CVT,R4 . L R4,CVTSMCA R4 -> SMCA USING SMCABASE,R4 . MVC SYSID,SMCASID get system id DROP R4 * * SYSID DS CL4 For those modern mainframe people (if you can call us that!!!) who do C on the mainframe, here is a C code snippet: First the defines: /*---* * Pointer to the MVS PSA control block * *---*/ #define PSA_PTR ( 0 ) /*---* * Pointer to the MVS CVT control block * *---*/ #define CVT_PTR ( * (void * *) ( (char *) PSA_PTR + 16) ) /*---* * Pointer to the MVS SMCA control block * *---*/ #define SMCA_PTR ( * (char * *) ( (char *) CVT_PTR + 196) ) /*---* * Pointer to the SMF System Id * *---*/ #define SMF_SYSID_PTR ( (char *) SMCA_PTR + 16 ) /**/ /* Now copy it from the control block to our variable */ /**/ memcpy( SysId, SMF_SYSID_PTR, 4); Well, i hope that helped. Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting Dave Adam <[EMAIL PROTECTED]>: > I must not be explaining this right > > our production QMGR's are on another pair of ZOS images and are called > P001 and P002 > > our tes
Re: How do I see/list current users of a MQ manager
Pavel, I always felt that WMQ terminology is one of those things that steepens the learning curve. We have clients in the context of client-server and clients in the context of client vs. bindings; we have clusters that are not what most people think of as clusters; etc., etc. So based on your comment I had to go look up API Exits. (By the way, thanks IBM - that Bibliography and Glossary book is great!) Turns out you are right. It's not even 9am here and I've already learned something new and useful today. Thank you! Here's what the book said: API exit A user-written program that monitors or modifies the function of an MQI call. For each MQI call issued by an application, the API exit is invoked before the queue manager starts to process the call and again after the queue manager has completed processing the call. The API exit can inspect and modify any of the parameters on the MQI call. The API exit is not supported on WebSphere MQ for z/OS. API-crossing exit A user written program that is similar in concept to an API exit. It is supported only by WebSphere MQ for z/OS and for CICS applications only. -- T.Rob -Original Message- From: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Sent: Thursday, January 29, 2004 6:04 PM To: [EMAIL PROTECTED] Subject: Re: How do I see/list current users of a MQ manager Wow again! Using an API exit is another nice idea (I think the "crossing" term is only used for z/OS, but I am not sure..). Like registering MQ_TERM_EXIT and MQ_CONNX_EXIT and dumping all the results into some queue (where else? :-)) available for curious managers? Seems to be the only way and thank you for pointing it out. But would MQ_TERM_EXIT track the abnormal process terminations? Anyone has any idea (except for "go and try:-)")? Thank you in advance, Pavel 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: T-Rex distributed systems
just keeps getting better we are in the process of implementing QSG's all our QMGR's will be associated with a shared queue in some fashion we should be able to test our cluster theory after that all we have to do is re-think our QSG names to align the sub-system QMGR's so we get to the right one thanks for the heads up Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] A lone amateur built the Ark. A large group of professionals built the Titanic -- "Lovett, Alan J" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 01/30/2004 03:19 AM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: T-Rex distributed systems Hi Dave, If your queue managers are defined in queue sharing groups, your MQCONN can be to the group name (e.g. M000). It doesn't matter if your application doesn't use any shared queues. Connecting to the group automatically connects you to the local queue manager. Jobs can thus run on any member of the sysplex. However, if you aren't into QSG's, other solutions are likely to be easier. Regards, Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Adiraju, Rao Sent: 29 January 2004 21:41 To: [EMAIL PROTECTED] Subject: Re: T-Rex distributed systems Luckily on z/OS only batch jobs/applications need to establish the connections to the Queue Managers (in CICS it's done at the CICS region level) and hence the need to know the QMGR name. This as suggested earlier, can be driven by a Dataset / Loadmodule or DB2 table. The sites that I have worked in the past are either put their QMGR names in a DB2 table (DB2 subsystem switching is done at the JCL level anyway) or put in a QSAM file and every MQ program is supposed to read a file using a standard DD name that provides the QMGR name. When the code gets migrated through SCLM phases, it used to pick up the appropriate subsystem or QSAM qualifiers for the environment. Regarding security, it was controlled by RACF / ACF2. Because most of the sites I have worked, batch user-ids in production are different from other environments including stress testing. Rao Adiraju WebSphere MQ Specialist The National Bank of NZ Ltd. Tel: +64-4-494 4299 Fax: +64-4-802 8509 Mbl: +64-211-216-116 From: Dave Adam [mailto:[EMAIL PROTECTED] Sent: 30 January 2004 10:05 AM To: [EMAIL PROTECTED] Subject: Re: T-Rex distributed systems I must not be explaining this right our production QMGR's are on another pair of ZOS images and are called P001 and P002 our test machine has 2 cloned QMGR's that replicate production on a different pair of ZOS images D001 and D002 our development brainstorming test QMGR's are on the same pair of test machine QMGR's and they are called M001 and M002 SYSPlex Distributor will put the iteration on one of the pairs (M001 or M002) the program has to determine on which ZOS image it is running to do the MQCONN Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] A lone amateur built the Ark. A large group of professionals built the Titanic -- Rick Tsujimoto <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 01/29/2004 02:15 PM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: T-Rex distributed systems Dave, Two things: 1. The apps should probably be getting the queue manager name form some external source, e.g. file, table, etc. 2. Test apps that attempt to connect to prod queue managers should probably be stopped by your security system, e.g. RACF, ACF2, ... Dave Adam <[EMAIL PROTECTED] To: [EMAIL PROTECTED] ERVALU.COM> cc: Sent by: Subject: Re: T-Rex distributed systems MQSeries List <[EMAIL PROTECTED] en.AC.AT> 01/29/2004 02:51 PM Please respond to MQSeries List the issue is with the playground M00n QMGR's if they fail to identify the M, then they will be in the clones of production Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] A lone amateur built the Ark. A large group of professionals built the Titanic
Sender active but receiver inactive
Hi, I had a problem with a channelpair: A sender channel was always in status active, but his receiver channel was inactive since 2 days. The messages in the transmission queue where not transportet. To solve this was not the problem; just stop and start of the sender channel and it was running fine again. But i need to know how this happend! Unfortunately, all the logs on the sender side where already deleted and I cannot reproduce this error. So I have no clue what happend there. On the receiverside, the channel had endet with AMQ 9213 - tcp/ip error: "Timeout". - Does anybody know how how this different channelstatus can appear? - Why the sender channel did not react when there was no more connection to the receiver? - Is there a way to reproduce this problem? I am using AIX 5.x and MQ 5.3. on both sides. In both qm.ini files are those lines: CHANNELS: ADOPTNEWMCA = ALL FASTPATH ADOPTNEWMCATIMEOUT = 60 ADOPTNEWMCACHECK = ALL TCP: KeepAlive = Yes Roland ___ Disclaimer: Diese Mitteilung ist nur fuer die Empfaengerin / den Empfaenger bestimmt. Fuer den Fall, dass sie von nichtberechtigten Personen empfangen wird, bitten wir diese hoeflich, die Mitteilung an die ZKB zurueckzusenden und anschliessend die Mitteilung mit allen Anhaengen sowie allfaellige Kopien zu vernichten bzw. zu loeschen. Der Gebrauch der Information ist verboten. This message is intended only for the named recipient and may contain confidential or privileged information. If you have received it in error, please advise the sender by return e-mail and delete this message and any attachments. Any unauthorised use or dissemination of this information is strictly prohibited. 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: T-Rex distributed systems
that's perfect Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] A lone amateur built the Ark. A large group of professionals built the Titanic -- Roger Lacroix <[EMAIL PROTECTED]> 01/29/2004 04:29 PM To: MQSeries List <[EMAIL PROTECTED]> cc: [EMAIL PROTECTED] Subject: Re: T-Rex distributed systems Hi, Basically, you want to determine what LPAR (I think in terms of MVS!!!) the code is running on? Wow, I had to really scratch my head on this one - its been awhile. :) It took me a while to find my dinosaur suit; it was hiding in the back of the closet. A little tight, but it still fits. (I'm not sure if I should be happy or sad!!!) Warning: For non-mainframe people you can delete this message right now!! (Quick, look away because here comes some assembler code!!!) Here's how I would do it in assembler: * - - - - - - - - - - - - - - - - - - - - - - - - * Get then set system id * - - - - - - - - - - - - - - - - - - - - - - - - USING PSA,0 L R4,FLCCVT R4 -> CVT USING CVT,R4 . L R4,CVTSMCA R4 -> SMCA USING SMCABASE,R4 . MVC SYSID,SMCASID get system id DROP R4 * * SYSID DS CL4 For those modern mainframe people (if you can call us that!!!) who do C on the mainframe, here is a C code snippet: First the defines: /*---* * Pointer to the MVS PSA control block * *---*/ #define PSA_PTR ( 0 ) /*---* * Pointer to the MVS CVT control block * *---*/ #define CVT_PTR ( * (void * *) ( (char *) PSA_PTR + 16) ) /*---* * Pointer to the MVS SMCA control block * *---*/ #define SMCA_PTR ( * (char * *) ( (char *) CVT_PTR + 196) ) /*---* * Pointer to the SMF System Id * *---*/ #define SMF_SYSID_PTR ( (char *) SMCA_PTR + 16 ) /**/ /* Now copy it from the control block to our variable */ /**/ memcpy( SysId, SMF_SYSID_PTR, 4); Well, i hope that helped. Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting Dave Adam <[EMAIL PROTECTED]>: > I must not be explaining this right > > our production QMGR's are on another pair of ZOS images and are called > P001 and P002 > > our test machine has 2 cloned QMGR's that replicate production on a > different pair of ZOS images D001 and D002 > > our development brainstorming test QMGR's are on the same pair of test > machine QMGR's and they are called M001 and M002 > > SYSPlex Distributor will put the iteration on one of the pairs (M001 or > M002) > > the program has to determine on which ZOS image it is running to do the > MQCONN > > Dave Adam > Supervalu Home Office > Project Specialist > (952) 828-4736 > [EMAIL PROTECTED] > > A lone amateur built the Ark. > A large group of professionals built the Titanic > -- > > > > > > Rick Tsujimoto <[EMAIL PROTECTED]> > Sent by: MQSeries List <[EMAIL PROTECTED]> > 01/29/2004 02:15 PM > Please respond to MQSeries List > > > To: [EMAIL PROTECTED] > cc: > Subject: Re: T-Rex distributed systems > > > Dave, > > Two things: > 1. The apps should probably be getting
AW: SSL certificate administration with gsk6cmd - 7th January fix
Hi all, after installing the interim fix it is working again. But now the key files are named like this: key..crl key..kdb key..rdb key..sth Did anynoe make the same experience? Regards Christian -Ursprüngliche Nachricht- Von: Gurney, Matthew [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 29. Januar 2004 10:23 An: [EMAIL PROTECTED] Betreff: Re: SSL certificate administration with gsk6cmd - 7th January fix The 7th January problem where 5.3 CDS5, ships with Signer certificates that expired on 7th January this year. This means that when you try to create the key store, and by default it attempts to load the default CA certificates (verisign etc), it notices they have expired and doesn't allow you to create a new key store. The fix is to download WebSphere MQ v5.3 interim fixes (includes Interim Fix for HIPER APAR IY43610). Which contains a new version of GSK 6.0.5.39, which contains certificates that are not expired. I don't know, but I think if you had 5.3 CSD5, and had created your key store prior to 7th January, it would probably work fine, except if you were actually using the default CA signer certificate that has expired - I don't know which one it is. I am not sure about the other platforms, I had this experience with Solaris. Matt. -Original Message- From: David C. Partridge [mailto:[EMAIL PROTECTED] Sent: 28 January 2004 16:32 To: [EMAIL PROTECTED] Subject: Re: SSL certificate administration with gsk6cmd - 7th January fix What 7th January problem - do tell all! 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 == This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. == 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: T-Rex distributed systems
Hi Dave, If your queue managers are defined in queue sharing groups, your MQCONN can be to the group name (e.g. M000). It doesn't matter if your application doesn't use any shared queues. Connecting to the group automatically connects you to the local queue manager. Jobs can thus run on any member of the sysplex. However, if you aren't into QSG's, other solutions are likely to be easier. Regards, Alan -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Adiraju, RaoSent: 29 January 2004 21:41To: [EMAIL PROTECTED]Subject: Re: T-Rex distributed systems Luckily on z/OS only batch jobs/applications need to establish the connections to the Queue Managers (in CICS it's done at the CICS region level) and hence the need to know the QMGR name. This as suggested earlier, can be driven by a Dataset / Loadmodule or DB2 table. The sites that I have worked in the past are either put their QMGR names in a DB2 table (DB2 subsystem switching is done at the JCL level anyway) or put in a QSAM file and every MQ program is supposed to read a file using a standard DD name that provides the QMGR name. When the code gets migrated through SCLM phases, it used to pick up the appropriate subsystem or QSAM qualifiers for the environment. Regarding security, it was controlled by RACF / ACF2. Because most of the sites I have worked, batch user-ids in production are different from other environments including stress testing. Rao Adiraju WebSphere MQ Specialist The National Bank of NZ Ltd. Tel: +64-4-494 4299 Fax: +64-4-802 8509 Mbl: +64-211-216-116 From: Dave Adam [mailto:[EMAIL PROTECTED] Sent: 30 January 2004 10:05 AMTo: [EMAIL PROTECTED]Subject: Re: T-Rex distributed systems I must not be explaining this right our production QMGR's are on another pair of ZOS images and are called P001 and P002 our test machine has 2 cloned QMGR's that replicate production on a different pair of ZOS images D001 and D002 our development brainstorming test QMGR's are on the same pair of test machine QMGR's and they are called M001 and M002 SYSPlex Distributor will put the iteration on one of the pairs (M001 or M002) the program has to determine on which ZOS image it is running to do the MQCONNDave AdamSupervalu Home OfficeProject Specialist(952) 828-4736[EMAIL PROTECTED]A lone amateur built the Ark. A large group of professionals built the Titanic-- Rick Tsujimoto <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 01/29/2004 02:15 PM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: T-Rex distributed systemsDave,Two things:1. The apps should probably be getting the queue manager name form someexternal source, e.g. file, table, etc.2. Test apps that attempt to connect to prod queue managers should probablybe stopped by your security system, e.g. RACF, ACF2, ... Dave Adam <[EMAIL PROTECTED] To: [EMAIL PROTECTED] ERVALU.COM> cc: Sent by: Subject: Re: T-Rex distributed systems MQSeries List <[EMAIL PROTECTED] en.AC.AT> 01/29/2004 02:51 PM Please respond to MQSeries Listthe issue is with the playground M00n QMGR'sif they fail to identify the M, then they will be in the clones ofproductionDave AdamSupervalu Home OfficeProject Specialist(952) 828-4736[EMAIL PROTECTED]A lone amateur built the Ark.A large group of professionals built the Titanic-- Rick Tsujimoto <[EMAIL PROTECTED]> To: Sent by: MQSeries List [EMAIL PROTECTED] <[EMAIL PROTECTED]> cc: Subject: Re: T-Rex distributed systems 01/29/2004 01:30 PM Please respond to MQSeries ListIf you simply want to connect to the default QMGR on each LPAR, you couldgenrate the load module that defines the default queue manager and add thatlibrary to the application's STEPLIB. Dave Adam <[EMAIL PROTECTED] To:[EMAIL PROTECTED] ERVALU.COM> cc:
Re: Cluster Getting and Putting!
Unless you are willing to pay a great performance price you could build it yourself... the Queue Sharing Groups / Queues on z/OS are not only stored in the CF, but also DB2 is used... So on Unix either using Oracle or DB2 you can map your queues to database tables and then they are available from anywhere... you could still have the occasional stranded message (i.e. queue manager goes down, before the database picked it up), but in theory it can be done... Keep dreaming Hubert! Without dreamers the world would be a different place today!!! :-) Michael -Oorspronkelijk bericht- Van: MQSeries List [mailto:[EMAIL PROTECTED] Lovett, Alan J Verzonden: vrijdag 30 januari 2004 10:01 Aan: [EMAIL PROTECTED] Onderwerp: Re: Cluster Getting and Putting! Dream on Herbert, but avoid dreaming about locks, and guaranteed _once_ only delivery! Regards, Alan Alan Lovett [mailto: [EMAIL PROTECTED] * +44 (01253) 6 88311 Mob.* +44 (07768) 210500 Fax * +44 (01253) 6 88156 E* [EMAIL PROTECTED] -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Kleinmanns, Hubert Sent: 29 January 2004 08:01 To: [EMAIL PROTECTED] Subject: AW: Cluster Getting and Putting! Hi Alan, I agree, it is just an idea, how shared queues may eventually be realized in the far future on a system other than S/390. I know, that nothing similar to a coupling facility exists at the moment for AIX or other Unix boxes. Concurrent cluster means only, that disks may be shared between to or more boxes and are accessible at the same time (using raw devices, not file systems I think). Using such disk space instead of shared memory (shared between several servers) would be not very fast, but maybe it could work (let me have a dream ;-) ). To my mind, the main advantage of clustering is the simplifying of MQ administration. That means, you need not to define remote queues or every channel connection manually - clustering takes over these actions. Load balancing and fail-over are more or less "side-effects", but not to compare with workload management on mainframes and fail-over mechanisms like SYSPLEX or HACMP. But the tracing of message flow becomes not easier at all by using MQ clustering. Regards Hubert -Ursprungliche Nachricht- Von: Lovett, Alan J [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 28. Januar 2004 14:20 An: [EMAIL PROTECTED] Betreff: Re: Cluster Getting and Putting! Hi, Neither am I, but s/390 queue sharing relies on its coupling facility (a mix of shared memory, custom hardware and layers of fancy software) to host the queues and manage the locks. As far as I am aware, HACMP 'only' shares disk arrays and network connections. Don't expect queue sharing on AIX without some mechanism for shared memory. In the future, anything might happen, but queue sharing on non-s390 platforms is _very_ unlikely in the forseeable future (IMHO). Regards, Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Kleinmanns, Hubert Sent: 28 January 2004 10:48 To: [EMAIL PROTECTED] Subject: AW: Cluster Getting and Putting! Hi Sid, I am not an IBMer, but what you mean is what I know as shared queues. They are available since MQ 5.2 - unfortunately only on mainframes. You need something like memory or disks, shared to several systems. Maybe concurrent cluster on HACMP could be a solution (sometime in the future)? Regards Hubert -Ursprungliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 28. Januar 2004 07:13 An: [EMAIL PROTECTED] Betreff: Cluster Getting and Putting! Howdy All, This question is really only directed to members of the list who are with IBM. If putting to a cluster is global and gets are local, is it likely to change in the future so that gets are global if only one instance of a cluster queue exists in the cluster? Sid 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 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
Re: A WMQ Security question
Title: A WMQ Security question You can use a security exit (possibly a product) to verify the credentials of the client, and based on those to set MCAUSER dynamically for the channel instance. Dave -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Adiraju, RaoSent: 29 January 2004 23:42To: [EMAIL PROTECTED]Subject: A WMQ Security question We have a Weblogic server which talks to WMQ Manager through Server connections. And also according WMQ V5.3 documentation, PUTAUT(CTX) isn't allowed for SVRCONN channels. How do I enforce the user level security then. Any ideas - Interested to know what other Weblgoic / MQ sites are doing on this regard. Even though it is only INTRANET, considering the utmost securities we preach in banking sector, we want to absolutely make sure that, only authorised user-account(s) is putting the messages on the queue. Thanks Rao Adiraju WebSphere MQ Specialist The National Bank of NZ Ltd. Tel: +64-4-494 4299 Fax: +64-4-802 8509 Mbl: +64-211-216-116 This communication is confidential and may contain privileged material. If you are not the intended recipient you must not use, disclose, copy or retain it. If you have received it in error please immediately notify me by return email and delete the emails.Thank you.
Re: Cluster Getting and Putting!
Dream on Herbert, but avoid dreaming about locks, and guaranteed _once_ only delivery! Regards, Alan Alan Lovett [mailto: [EMAIL PROTECTED] * +44 (01253) 6 88311 Mob.* +44 (07768) 210500 Fax * +44 (01253) 6 88156 E* [EMAIL PROTECTED] -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Kleinmanns, Hubert Sent: 29 January 2004 08:01 To: [EMAIL PROTECTED] Subject: AW: Cluster Getting and Putting! Hi Alan, I agree, it is just an idea, how shared queues may eventually be realized in the far future on a system other than S/390. I know, that nothing similar to a coupling facility exists at the moment for AIX or other Unix boxes. Concurrent cluster means only, that disks may be shared between to or more boxes and are accessible at the same time (using raw devices, not file systems I think). Using such disk space instead of shared memory (shared between several servers) would be not very fast, but maybe it could work (let me have a dream ;-) ). To my mind, the main advantage of clustering is the simplifying of MQ administration. That means, you need not to define remote queues or every channel connection manually - clustering takes over these actions. Load balancing and fail-over are more or less "side-effects", but not to compare with workload management on mainframes and fail-over mechanisms like SYSPLEX or HACMP. But the tracing of message flow becomes not easier at all by using MQ clustering. Regards Hubert -Ursprungliche Nachricht- Von: Lovett, Alan J [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 28. Januar 2004 14:20 An: [EMAIL PROTECTED] Betreff: Re: Cluster Getting and Putting! Hi, Neither am I, but s/390 queue sharing relies on its coupling facility (a mix of shared memory, custom hardware and layers of fancy software) to host the queues and manage the locks. As far as I am aware, HACMP 'only' shares disk arrays and network connections. Don't expect queue sharing on AIX without some mechanism for shared memory. In the future, anything might happen, but queue sharing on non-s390 platforms is _very_ unlikely in the forseeable future (IMHO). Regards, Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Kleinmanns, Hubert Sent: 28 January 2004 10:48 To: [EMAIL PROTECTED] Subject: AW: Cluster Getting and Putting! Hi Sid, I am not an IBMer, but what you mean is what I know as shared queues. They are available since MQ 5.2 - unfortunately only on mainframes. You need something like memory or disks, shared to several systems. Maybe concurrent cluster on HACMP could be a solution (sometime in the future)? Regards Hubert -Ursprungliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 28. Januar 2004 07:13 An: [EMAIL PROTECTED] Betreff: Cluster Getting and Putting! Howdy All, This question is really only directed to members of the list who are with IBM. If putting to a cluster is global and gets are local, is it likely to change in the future so that gets are global if only one instance of a cluster queue exists in the cluster? Sid 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 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
