Re: How can we replace "scmmqm" in IBM MQ Series 5.2.1....
Hi Gaurav,
I would recommend to get a copy of the srvany.exe
command/tool from the Windows NT Resource Kit. I
believe that it is freely available from the microsoft
website.
This program allows you to create your own services
and srvany will execute your script/application until
completion (ie. your script/application "exits" or
will loop depending on your requirements). When
installing srvany, there may be some minor registry
changes to point srvany to your script/application
name and any parameters that it might require.
The other method (even though not recommended by IBM,
reading the documentation) is to attempt to create an
MQ "Custom MQ Service" but I havent personally tried
that one.
Regards,
John
--- Gaurav Bhushan <[EMAIL PROTECTED]>
wrote:
> Hi All,
>
> We are upgrading IBM MQ Series 5.0 to IBM MQ Series
> 5.2.1 on Windows NT. We
> have to install IBM MQ Series 5.2.1 with
> "upgradation" as well as with
> "complete" option, depending on the setup.
>
> We apply a startup.cmd script using "scmmqm" command
> to start QM etc., at the
> time of IBM MQ Series Service startup.
>
> Since "scmmqm" has NOT been supported in IBM MQ
> Series 5.2.1, we found an
> alternate way to directly use a Windows registry key
> called "AutoStart" under
>
"HKEY_LOCAL_MQCHINE/Software/IBM/MQSeries/CurrentVersion/AutoStart".
> This works
> fine with "upgradation" option, but when we install
> IBM MQ Series 5.2.1 from
> scratch ("Complete"), above mentioned windows
> registry key does not exist.
>
> Kindly advice us as to how can we apply startup.cmd
> script without using
> "scmmqm"?
>
> Thanks in advance.
>
> Regards,
> Gaurav
>
> ==
> Gaurav Bhushan Gothi
> OrbiTech Solutions Limited.
> * 91-22-8290019 ext 1317
> ==
>
> 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
__
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.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
How can we replace "scmmqm" in IBM MQ Series 5.2.1....
Hi All,
We are upgrading IBM MQ Series 5.0 to IBM MQ Series 5.2.1 on Windows NT. We
have to install IBM MQ Series 5.2.1 with "upgradation" as well as with
"complete" option, depending on the setup.
We apply a startup.cmd script using "scmmqm" command to start QM etc., at the
time of IBM MQ Series Service startup.
Since "scmmqm" has NOT been supported in IBM MQ Series 5.2.1, we found an
alternate way to directly use a Windows registry key called "AutoStart" under
"HKEY_LOCAL_MQCHINE/Software/IBM/MQSeries/CurrentVersion/AutoStart". This works
fine with "upgradation" option, but when we install IBM MQ Series 5.2.1 from
scratch ("Complete"), above mentioned windows registry key does not exist.
Kindly advice us as to how can we apply startup.cmd script without using
"scmmqm"?
Thanks in advance.
Regards,
Gaurav
==
Gaurav Bhushan Gothi
OrbiTech Solutions Limited.
* 91-22-8290019 ext 1317
==
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: MQWorkflow: how to add user to run-time ?
Paul, Just reset the password in the build time and export it into FDL file, Then import into runtime. Check the cause of warning messages if any. Rgds, Palavesam.S --- Paul Celari <[EMAIL PROTECTED]> wrote: Hi all, I installed workflow run-time, admin-utils, and client to a server. Run fmcibie to import from an fdl file exported from build-time system in a development environment. To my understanding, build-time system's everything get into run-time database when it's imported into run-time. There is not need to install build-time unless development is needed on a system. I have user1, user2, etc defined in the fdl file, and the import log also says the profiles were created successfully. But from workflow client, I can only login as ADMIN. When I try to login as user1, user2 etc, I only get "password not found" response. What am I missing here? I could neither find a place in the admin utility to add user. Can anyone give me some hint where to look for the problem? appreciate your help. Paul C.Chat with friends online, try MSN Messenger: Click Here 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 __ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.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
Re: Question about deleting Perm. Dynamic queues
Ok, here's a different perspective on the overall question of reply to queues in a request/reply scenario. Assign each user a permanent dynamic reply queue that is used by all apps, each app retrieving its messages by message and correlation id's, this nicely handles the following issues, security of visibility to confidential information, containing the impact of a rogue app that reads messages it shouldn't and simplifies the admin tasks related to handling dynamic queues. An apps code works along these lines MQOPEN REPLY.myuser.QUEUE and if this fails it then does an MQOPEN on the Model queue specifying the name REPLY.myuser.QUEUE in the dynamic queue name field. Or for the purposes of access control the generation of the permanent dynamic queue and its access could be done when a new user is created, and deleted when the user is removed from the system. This sounded a bit wierd the first time I heard it but the more I think about it the more I like it. Regards Tim A "Miller, Dennis" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] OM> cc: Sent by: MQSeriesSubject: Re: Question about deleting Perm. Dynamic queues List 27/08/2002 03:22 AM Please respond to MQSeries List But Steve, the main advantage of persistent messages is to survive a qmgr restart. You go to great lengths for persistent replies, then undermine it by purging the reply queues?? Also, persistence is not a typical requirement for request/reply application, so I have to question whether you really need it. Generally, dynamically creating/deleting permanent queues introduces more headaches than relief. The effort backfires because keeping all involved parties in-sync on an ongoing basis gets too messy. With good naming standards, 200 equivalent reply queues should not overwhelm the administrators. On the other hand, if you really want to simplify admin, sharing a reply queue among 200 clients is quite feasible--especially for request/reply apps where the queue depth is customarily shallow. > -Original Message- > From: Steve Muller [SMTP:[EMAIL PROTECTED]] > Sent: Monday, August 26, 2002 6:27 AM > To: [EMAIL PROTECTED] > Subject: Re: Question about deleting Perm. Dynamic queues > > Dennis: > > Thanks for your reponse. Below, I will explain why > and how I decided to use PD (Perm. Dyn.) queues --I > WOULD LIKE ALL THESE pd QUEUES GONE BEFORE MQ > SHOT-DOWN-- in order not to cause any headache to the > MQ Admin guys. Here is the requirement and the design > to acheive this: > > Requirement: > - > We'll have about 200 clients (Win2K MQ 5.2) that will > send mostly persistent requests to the server (we > don't know the platform yet) and receive their > persistent replies in their perspective reply queues. > > Some of these clients will run almost non stop (for > days if not weeks or months... due to business > req's)and some may stop at the end of the day. > > Design: > --- > > I don't want to create 200 regular local queues for > admin purposes. I also don't want to create say 20 > local queues each of which to be shared by 10 clients > due to competition for getting replies (based on a > correlid) and the fact that failure of one client can > impact the others in the group. I thought, with > separate PD queues I can store both persistent and > non-persistant messages. These queues will also be > used for sub/pub purposes (Smalltalk sub/pub, not MQ). > Both the client and the server app will be written in > Smalltalk. > > Here is the order or operations: > > 1. Client app starts and connects to the MQ server > 2. Client app subscribes to publications/topics >(specifying the PDReplyQ as the reply-to-q) > 3. Client sends a request (w/ PDReplyQ as the > repl-to-q) > 4. Client gets the reply/publication from the PDReplyQ > 5. Step 3 and 4 are repeated all day long (maybe once > every 5-10). The rest of the time it will stay idle > 6. During the idle time the client will do an MQGET on > the PDReplyQ (say every 2 min) to detect qmgr > quiescing > 7. Client, just before it stops, closes its queues and > deletes its PDReplyQ (with purge option on the > CLOSE). > > ===Important: As part of the shut-down process > (shutting down the server app or the qmgr): Admin will > send a message to the server app with MQFB_QUIT; and > in turn, the server app, before it terminates, will > send a message to its clients with MQFB_QUIT, to stop > processing=== > > HOW TO HANDLE ORPHANED PD QUEUES: > - > Because of the step 7, there won't be any PDReplyQ > queues left behind. However, if the client app stopped > abnormally it will leave its PDReplyQ "undeleted". In > order to take care of this situation h
MQWorkflow: how to add user to run-time ?
Hi all, I installed workflow run-time, admin-utils, and client to a server. Run fmcibie to import from an fdl file exported from build-time system in a development environment. To my understanding, build-time system's everything get into run-time database when it's imported into run-time. There is not need to install build-time unless development is needed on a system. I have user1, user2, etc defined in the fdl file, and the import log also says the profiles were created successfully. But from workflow client, I can only login as ADMIN. When I try to login as user1, user2 etc, I only get "password not found" response. What am I missing here? I could neither find a place in the admin utility to add user. Can anyone give me some hint where to look for the problem? appreciate your help. Paul C.Chat with friends online, try MSN Messenger: Click Here 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 Urgent Help in MQExplorer
** Note: This e-mail is subject to the disclaimer contained at the bottom of this message. ** : I had the same problem with a queue manager in an NT cluster.ended up having to recreate queue manager, When you run 'runmqsc' against the qm are you able to issue command 'dis chl (*)' and 'dis q (*)' and get complete lsiting of objects. Also are you able to successfully run 'saveqmgr' against the qm. When I had the problem these activities failed because there appeared to be a corrupt object. : The information transmitted in this message and attachments (if any) is intended only for the person or entity to which it is addressed. The message may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited. If you have received this in error, please contact the sender and delete this e-mail and associated material from any computer. The intended recipient of this e-mail may only use, reproduce, disclose or distribute the information contained in this e-mail and any attached files, with the permission of CGU Insurance. This message has been scanned for viruses and cleared by MailMarshal. : 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: Expiration time problem.
Don't quote me on this, but I thought 5.3 was going to remedy that. You may need to open the queue for a browse (or a get) in order to "really" clear these messages. What you see may also be affecting your logs (ie. they may be filling up). -Original Message- From: Pablo Javier Carreras [mailto:[EMAIL PROTECTED]] Sent: Monday, August 26, 2002 4:36 PM To: [EMAIL PROTECTED] Subject: Expiration time problem. Hi all, An on-line application puts messages on a queue with the expiration time option. And after this time is over, although there are no messages on the queue, I can still see (by executing a DIS QUEUE command) that the curdepth of the queue is 1983 and not 0. Is this a normal behaviour when expiration time is used? Can anybody tell me when this depth value is goning to be refreshed? Thanks in advance. Pablo. -- Pablo Javier Carreras Gerencia de Infraestructura Tecnológica - Area Mainframe Banco RIO de la Plata S.A. - Grupo SCH Bartolomé Mitre 480 - 2do. piso Buenos Aires - Argentina Tel. (54)11-4341-1000 Int. 3596 Fax. (54)11-4341-1620 Visite http://www.bancorio.com.ar y tenga el Banco al alcance de su mano. NOTA DE CONFIDENCIALIDAD / CONFIDENTIALITY NOTE Este mensaje (y sus anexos) es confidencial y puede contener informacion (i) de propiedad exclusiva de Banco Rio de la Plata S.A. sus afiliadas o subsidiarias; o (ii) amparada por el secreto profesional. Si usted ha recibido este fax o e-mail por error, por favor comuniquelo inmediatamente via fax o e-mail y tenga la amabilidad de destruirlo; no debera copiar el mensaje ni divulgar su contenido a ninguna persona. Muchas gracias. This message (including attachments) is confidential. It may also contain information that (i) is exclusively property of Banco Rio de la Plata S.A. or its affiliates or subsidiaries; or (ii) is privileged or otherwise legally exempt from disclosure. If you have received it by mistake please let us know by fax or e-mail immediately and destroy or delete it from your files or system; you should also not copy the message nor disclose its contents to anyone. 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
Windows MSI install - handling 'Performance Monitor Running' question
Ok that was a test.. The question is - using the Microsoft Software Installer, silent install, how do I handle the prompt that appears (if I had run in the setup manually in a GUI) when there is a Performance Monitor running that has a lock on needed files? I think this performance monitor is some other software installed by the server staff. Peter/Syracuse 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: Expiration time problem.
The messages will be removed when the first non-broese MQGET is performed that would have normally returned the message that is expired if it had not expired. This is 5.2 and down. In 5.3 there will be a background process that does normal cleanup as we thought MQ should do without the mumbo jumbo of non-browse MQGET yadda yadda yadda.. bobbee >From: Pablo Javier Carreras <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Expiration time problem. >Date: Mon, 26 Aug 2002 17:36:14 -0300 > >Hi all, >An on-line application puts messages on a queue with the expiration time >option. And after this time is over, although there are no messages on >the queue, I can still see (by executing a DIS QUEUE command) that the >curdepth of the queue is 1983 and not 0. Is this a normal behaviour when >expiration time is used? Can anybody tell me when this depth value is >goning to be refreshed? >Thanks in advance. >Pablo. > >-- >Pablo Javier Carreras >Gerencia de Infraestructura Tecnolsgica - Area Mainframe > >Banco RIO de la Plata S.A. - Grupo SCH >Bartolomi Mitre 480 - 2do. piso >Buenos Aires - Argentina >Tel. (54)11-4341-1000 Int. 3596 >Fax. (54)11-4341-1620 > > > > >Visite http://www.bancorio.com.ar y tenga el Banco al alcance de su mano. > > >NOTA DE CONFIDENCIALIDAD / CONFIDENTIALITY NOTE >Este mensaje (y sus anexos) es confidencial y puede contener informacion >(i) de propiedad exclusiva de Banco Rio de la Plata S.A. sus afiliadas o >subsidiarias; o (ii) amparada por el secreto profesional. Si usted ha >recibido este fax o e-mail por error, por favor comuniquelo >inmediatamente via fax o e-mail y tenga la amabilidad de destruirlo; no >debera copiar el mensaje ni divulgar su contenido a ninguna persona. >Muchas gracias. > >This message (including attachments) is confidential. It may also >contain information that (i) is exclusively property of Banco Rio de la >Plata S.A. or its affiliates or subsidiaries; or (ii) is privileged or >otherwise legally exempt from disclosure. If you have received it by >mistake please let us know by fax or e-mail immediately and destroy or >delete it from your files or system; you should also not copy the >message nor disclose its contents to anyone. 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 _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx 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: Expiration time problem.
Yes, that is normal IF no destructive get has been issued against the queue. Even though they are expired, the message still exists until a get is done to cause cleanup. Glen Shubert Pablo Javier Carreras <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 08/26/2002 05:06 PM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Expiration time problem. Hi all, An on-line application puts messages on a queue with the expiration time option. And after this time is over, although there are no messages on the queue, I can still see (by executing a DIS QUEUE command) that the curdepth of the queue is 1983 and not 0. Is this a normal behaviour when expiration time is used? Can anybody tell me when this depth value is goning to be refreshed? Thanks in advance. Pablo. -- Pablo Javier Carreras Gerencia de Infraestructura Tecnológica - Area Mainframe Banco RIO de la Plata S.A. - Grupo SCH Bartolomé Mitre 480 - 2do. piso Buenos Aires - Argentina Tel. (54)11-4341-1000 Int. 3596 Fax. (54)11-4341-1620 Visite http://www.bancorio.com.ar y tenga el Banco al alcance de su mano. NOTA DE CONFIDENCIALIDAD / CONFIDENTIALITY NOTE Este mensaje (y sus anexos) es confidencial y puede contener informacion (i) de propiedad exclusiva de Banco Rio de la Plata S.A. sus afiliadas o subsidiarias; o (ii) amparada por el secreto profesional. Si usted ha recibido este fax o e-mail por error, por favor comuniquelo inmediatamente via fax o e-mail y tenga la amabilidad de destruirlo; no debera copiar el mensaje ni divulgar su contenido a ninguna persona. Muchas gracias. This message (including attachments) is confidential. It may also contain information that (i) is exclusively property of Banco Rio de la Plata S.A. or its affiliates or subsidiaries; or (ii) is privileged or otherwise legally exempt from disclosure. If you have received it by mistake please let us know by fax or e-mail immediately and destroy or delete it from your files or system; you should also not copy the message nor disclose its contents to anyone. 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: Expiration time problem.
Pablo, Yes, this is normal behaviour. The manual (can't remember which one at the moment) says that expired messages count towards the queue depth, even though you can't read them any more. Queue depth will go to 0 then the messages are deleted from the queue - this happens when the first non-browse GET scans the queue looking for mesages to get. Richard. Pablo Javier Carreras <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 26/08/2002 17:36:14 Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Expiration time problem. Hi all, An on-line application puts messages on a queue with the expiration time option. And after this time is over, although there are no messages on the queue, I can still see (by executing a DIS QUEUE command) that the curdepth of the queue is 1983 and not 0. Is this a normal behaviour when expiration time is used? Can anybody tell me when this depth value is goning to be refreshed? Thanks in advance. Pablo. -- Pablo Javier Carreras Gerencia de Infraestructura Tecnológica - Area Mainframe Banco RIO de la Plata S.A. - Grupo SCH Bartolomé Mitre 480 - 2do. piso Buenos Aires - Argentina Tel. (54)11-4341-1000 Int. 3596 Fax. (54)11-4341-1620 - 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. The views expressed in this e-mail are not necessarily the views of Westpac Banking Corporation. Westpac Banking Corporation is incorporated in New South Wales, 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
Re: Expiration time problem.
Pablo, this is normal. Expired messages will stay on the queue until they are read (or until you try to read them). 1) For nonOS/390, a browse will do it. Just browse all the messages in the queue. 2) For OS/390, the read must be a destructive one. This raises the interesting question of how you get rid of expired messages but leave nonexpired ones alone if your applications don't just read everything on the queue (if, for example, you get by msgid or correlid). I don't have an answer to that. Does anyone out there? Best regards, Rebecca Rebecca Bullock Computer Sciences Corporation Educational Testing Service Account Princeton, NJ 08541 e-mail: [EMAIL PROTECTED][EMAIL PROTECTED] -Original Message- From: Pablo Javier Carreras [mailto:[EMAIL PROTECTED]] Sent: Monday, August 26, 2002 4:36 PM To: [EMAIL PROTECTED] Subject: Expiration time problem. Hi all, An on-line application puts messages on a queue with the expiration time option. And after this time is over, although there are no messages on the queue, I can still see (by executing a DIS QUEUE command) that the curdepth of the queue is 1983 and not 0. Is this a normal behaviour when expiration time is used? Can anybody tell me when this depth value is goning to be refreshed? Thanks in advance. Pablo. -- Pablo Javier Carreras Gerencia de Infraestructura Tecnológica - Area Mainframe Banco RIO de la Plata S.A. - Grupo SCH Bartolomé Mitre 480 - 2do. piso Buenos Aires - Argentina Tel. (54)11-4341-1000 Int. 3596 Fax. (54)11-4341-1620 Visite http://www.bancorio.com.ar y tenga el Banco al alcance de su mano. NOTA DE CONFIDENCIALIDAD / CONFIDENTIALITY NOTE Este mensaje (y sus anexos) es confidencial y puede contener informacion (i) de propiedad exclusiva de Banco Rio de la Plata S.A. sus afiliadas o subsidiarias; o (ii) amparada por el secreto profesional. Si usted ha recibido este fax o e-mail por error, por favor comuniquelo inmediatamente via fax o e-mail y tenga la amabilidad de destruirlo; no debera copiar el mensaje ni divulgar su contenido a ninguna persona. Muchas gracias. This message (including attachments) is confidential. It may also contain information that (i) is exclusively property of Banco Rio de la Plata S.A. or its affiliates or subsidiaries; or (ii) is privileged or otherwise legally exempt from disclosure. If you have received it by mistake please let us know by fax or e-mail immediately and destroy or delete it from your files or system; you should also not copy the message nor disclose its contents to anyone. 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 ** 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
Expiration time problem.
Hi all, An on-line application puts messages on a queue with the expiration time option. And after this time is over, although there are no messages on the queue, I can still see (by executing a DIS QUEUE command) that the curdepth of the queue is 1983 and not 0. Is this a normal behaviour when expiration time is used? Can anybody tell me when this depth value is goning to be refreshed? Thanks in advance. Pablo. -- Pablo Javier Carreras Gerencia de Infraestructura Tecnológica - Area Mainframe Banco RIO de la Plata S.A. - Grupo SCH Bartolomé Mitre 480 - 2do. piso Buenos Aires - Argentina Tel. (54)11-4341-1000 Int. 3596 Fax. (54)11-4341-1620 Visite http://www.bancorio.com.ar y tenga el Banco al alcance de su mano. NOTA DE CONFIDENCIALIDAD / CONFIDENTIALITY NOTE Este mensaje (y sus anexos) es confidencial y puede contener informacion (i) de propiedad exclusiva de Banco Rio de la Plata S.A. sus afiliadas o subsidiarias; o (ii) amparada por el secreto profesional. Si usted ha recibido este fax o e-mail por error, por favor comuniquelo inmediatamente via fax o e-mail y tenga la amabilidad de destruirlo; no debera copiar el mensaje ni divulgar su contenido a ninguna persona. Muchas gracias. This message (including attachments) is confidential. It may also contain information that (i) is exclusively property of Banco Rio de la Plata S.A. or its affiliates or subsidiaries; or (ii) is privileged or otherwise legally exempt from disclosure. If you have received it by mistake please let us know by fax or e-mail immediately and destroy or delete it from your files or system; you should also not copy the message nor disclose its contents to anyone. 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: MQSI CSDs
Robert, A faster and "browser-free" site: ftp://ftp.software.ibm.com/software/mqseries/fixes/wmqiv21/ Tibor >>-Original Message- >>From: Robert Broderick [mailto:[EMAIL PROTECTED]] >>Sent: Sunday, August 25, 2002 6:48 PM >>To: [EMAIL PROTECTED] >>Subject: MQSI CSDs >> >> >>Anybody got the URL for the Integrator Csd downoad page?? >> >> bb >> >> >> >>_ >>MSN Photos is the easiest way to share and print your photos: >>http://photos.msn.com/support/worldwide.aspx >> >>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 > _ > Send and receive Hotmail on your mobile device: http://mobile.msn.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: Question about deleting Perm. Dynamic queues
Good Points... Thanks Dennis... Steve --- "Miller, Dennis" <[EMAIL PROTECTED]> wrote: > But Steve, the main advantage of persistent > messages is to survive a > qmgr restart. You go to great lengths for persistent > replies, then undermine > it by purging the reply queues?? Also, > persistence is not a typical > requirement for request/reply application, so I have > to question whether you > really need it. > > Generally, dynamically creating/deleting > permanent queues introduces > more headaches than relief. The effort backfires > because keeping all > involved parties in-sync on an ongoing basis gets > too messy. With good > naming standards, 200 equivalent reply queues should > not overwhelm the > administrators. On the other hand, if you really > want to simplify admin, > sharing a reply queue among 200 clients is quite > feasible--especially for > request/reply apps where the queue depth is > customarily shallow. > > > > -Original Message- > > From: Steve Muller [SMTP:[EMAIL PROTECTED]] > > Sent: Monday, August 26, 2002 6:27 AM > > To: [EMAIL PROTECTED] > > Subject: Re: Question about deleting Perm. > Dynamic queues > > > > Dennis: > > > > Thanks for your reponse. Below, I will explain > why > > and how I decided to use PD (Perm. Dyn.) queues > --I > > WOULD LIKE ALL THESE pd QUEUES GONE BEFORE MQ > > SHOT-DOWN-- in order not to cause any headache to > the > > MQ Admin guys. Here is the requirement and the > design > > to acheive this: > > > > Requirement: > > - > > We'll have about 200 clients (Win2K MQ 5.2) that > will > > send mostly persistent requests to the server (we > > don't know the platform yet) and receive their > > persistent replies in their perspective reply > queues. > > > > Some of these clients will run almost non stop > (for > > days if not weeks or months... due to business > > req's)and some may stop at the end of the day. > > > > Design: > > --- > > > > I don't want to create 200 regular local queues > for > > admin purposes. I also don't want to create say 20 > > local queues each of which to be shared by 10 > clients > > due to competition for getting replies (based on a > > correlid) and the fact that failure of one client > can > > impact the others in the group. I thought, with > > separate PD queues I can store both persistent and > > non-persistant messages. These queues will also be > > used for sub/pub purposes (Smalltalk sub/pub, not > MQ). > > Both the client and the server app will be written > in > > Smalltalk. > > > > Here is the order or operations: > > > > 1. Client app starts and connects to the MQ server > > 2. Client app subscribes to publications/topics > >(specifying the PDReplyQ as the reply-to-q) > > 3. Client sends a request (w/ PDReplyQ as the > > repl-to-q) > > 4. Client gets the reply/publication from the > PDReplyQ > > 5. Step 3 and 4 are repeated all day long (maybe > once > > every 5-10). The rest of the time it will stay > idle > > 6. During the idle time the client will do an > MQGET on > > the PDReplyQ (say every 2 min) to detect qmgr > > quiescing > > 7. Client, just before it stops, closes its queues > and > > deletes its PDReplyQ (with purge option on the > > CLOSE). > > > > ===Important: As part of the shut-down process > > (shutting down the server app or the qmgr): Admin > will > > send a message to the server app with MQFB_QUIT; > and > > in turn, the server app, before it terminates, > will > > send a message to its clients with MQFB_QUIT, to > stop > > processing=== > > > > HOW TO HANDLE ORPHANED PD QUEUES: > > - > > Because of the step 7, there won't be any PDReplyQ > > queues left behind. However, if the client app > stopped > > abnormally it will leave its PDReplyQ "undeleted". > In > > order to take care of this situation here are Some > of > > the options I have in mind: > > > > Option A: > > 1. Clinet will create its own PDReplyQ and let the > > server app know about it (in MD) during > Request/reply > > or pub/sub situation > > 2. Server app will ping the client app on a > regular > > basis (say every 2 min which is same as the > > time-interval used during idle time by the > client). > > The message will have no app data (maybe it will > have > > only a user-defined feedback code... I haven't > given > > this much thought yet). I know it will increase > the > > traffic over the channel but it it can be > tolerated). > > > > 3. If the server app does not get a response after > say > > 5 attempts it will assume that the client is gone > and > > it will delete the client's 'subscriptions and > > PDReplyQ" (by sending a PCF message to the command > > server). > > > > > > Option B: > > > > 1- PDReplyQs are all created (with the predefined > full > > names) by the server app when it first starts up. > > 2- Client app OPENs (like a local queue) and uses > its > > PDReplyQ as usual > > 3- Before sever app stops, it sends a terminate > > me
problem with building purify version of mq program
Hi All, I am having difficulty doing a purify build of a mq program. I am on a sun solaris platform. Here is what I get when I try a purify build: purify CC +w -g -mt -xildoff -features=no%conststrings -features=no%altspell -features=no%anachronisms -mt -DRELEASE="red10" -DSEQUENCE=0 -I/usr/openwin/include -I/opt/bea/wle/rtk/include -I. -I/mbs/prg/red10/inc -I/mbs/prg/purple9/inc -I/mbs/prg/blue9/inc -I/mbs/prg/green9/inc -I/mbs/prg/yellow9/inc -I/mbs/prg/orange9/inc -I/mbs/prg/beta/inc -I/mbs/prg/base/inc -I/mbs/prg/local/inc -o CLS-B330 cls-b330.o -lorc -lsbgdt -lsbctn -lsbsql -lsbsbx -lsbcbt -lsbacm -lsbfin -lsbsec -lsbpfm -lsbxdt -lsbcit -lsbagm -lsbrft -lsbatm -lsbamf -limqb23as -limqs23as -lmqm -lmqmcs -lmqmzse -lsocket -lnsl -ldl -lrt Purify 2002a.06.00 Solaris 2 (32-bit) Copyright (C) 1992-2002 Rational Software Corp. All rights reserved. Instrumenting: Linking ld: warning: file /opt/rational/releases/purify.sol.2002a.06.00/cache/usr/lib/libimqb23as.so_pure_p3_c0_105022037_58_32_4047592S: attempted multiple inclusion of file ld: warning: file /opt/rational/releases/purify.sol.2002a.06.00/cache/usr/lib/libimqs23as.so_pure_p3_c0_105022037_58_32_5068868S: attempted multiple inclusion of file ld: warning: file /opt/rational/releases/purify.sol.2002a.06.00/cache/usr/lib/libmqmcs.so_pure_p3_c0_105022037_58_32_3779600S: attempted multiple inclusion of file ld: warning: file /opt/rational/releases/purify.sol.2002a.06.00/cache/usr/lib/libmqm.so_pure_p3_c0_105022037_58_32_4657012S: attempted multiple inclusion of file ld: warning: file /opt/rational/releases/purify.sol.2002a.06.00/cache/usr/lib/libmqmzse.so_pure_p3_c0_105022037_58_32_6580S: attempted multiple inclusion of file ld: warning: file libposix4.so.1_pure_p3_c0_105022037_58_32_1257056S: required by /opt/rational/releases/purify.sol.2002a.06.00/cache/usr/lib/libmqm.so_pure_p3_c0_105022037_58_32_4657012S, not found Does anyone know how to rectify this? Prits 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: Question about deleting Perm. Dynamic queues
But Steve, the main advantage of persistent messages is to survive a qmgr restart. You go to great lengths for persistent replies, then undermine it by purging the reply queues?? Also, persistence is not a typical requirement for request/reply application, so I have to question whether you really need it. Generally, dynamically creating/deleting permanent queues introduces more headaches than relief. The effort backfires because keeping all involved parties in-sync on an ongoing basis gets too messy. With good naming standards, 200 equivalent reply queues should not overwhelm the administrators. On the other hand, if you really want to simplify admin, sharing a reply queue among 200 clients is quite feasible--especially for request/reply apps where the queue depth is customarily shallow. > -Original Message- > From: Steve Muller [SMTP:[EMAIL PROTECTED]] > Sent: Monday, August 26, 2002 6:27 AM > To: [EMAIL PROTECTED] > Subject: Re: Question about deleting Perm. Dynamic queues > > Dennis: > > Thanks for your reponse. Below, I will explain why > and how I decided to use PD (Perm. Dyn.) queues --I > WOULD LIKE ALL THESE pd QUEUES GONE BEFORE MQ > SHOT-DOWN-- in order not to cause any headache to the > MQ Admin guys. Here is the requirement and the design > to acheive this: > > Requirement: > - > We'll have about 200 clients (Win2K MQ 5.2) that will > send mostly persistent requests to the server (we > don't know the platform yet) and receive their > persistent replies in their perspective reply queues. > > Some of these clients will run almost non stop (for > days if not weeks or months... due to business > req's)and some may stop at the end of the day. > > Design: > --- > > I don't want to create 200 regular local queues for > admin purposes. I also don't want to create say 20 > local queues each of which to be shared by 10 clients > due to competition for getting replies (based on a > correlid) and the fact that failure of one client can > impact the others in the group. I thought, with > separate PD queues I can store both persistent and > non-persistant messages. These queues will also be > used for sub/pub purposes (Smalltalk sub/pub, not MQ). > Both the client and the server app will be written in > Smalltalk. > > Here is the order or operations: > > 1. Client app starts and connects to the MQ server > 2. Client app subscribes to publications/topics >(specifying the PDReplyQ as the reply-to-q) > 3. Client sends a request (w/ PDReplyQ as the > repl-to-q) > 4. Client gets the reply/publication from the PDReplyQ > 5. Step 3 and 4 are repeated all day long (maybe once > every 5-10). The rest of the time it will stay idle > 6. During the idle time the client will do an MQGET on > the PDReplyQ (say every 2 min) to detect qmgr > quiescing > 7. Client, just before it stops, closes its queues and > deletes its PDReplyQ (with purge option on the > CLOSE). > > ===Important: As part of the shut-down process > (shutting down the server app or the qmgr): Admin will > send a message to the server app with MQFB_QUIT; and > in turn, the server app, before it terminates, will > send a message to its clients with MQFB_QUIT, to stop > processing=== > > HOW TO HANDLE ORPHANED PD QUEUES: > - > Because of the step 7, there won't be any PDReplyQ > queues left behind. However, if the client app stopped > abnormally it will leave its PDReplyQ "undeleted". In > order to take care of this situation here are Some of > the options I have in mind: > > Option A: > 1. Clinet will create its own PDReplyQ and let the > server app know about it (in MD) during Request/reply > or pub/sub situation > 2. Server app will ping the client app on a regular > basis (say every 2 min which is same as the > time-interval used during idle time by the client). > The message will have no app data (maybe it will have > only a user-defined feedback code... I haven't given > this much thought yet). I know it will increase the > traffic over the channel but it it can be tolerated). > > 3. If the server app does not get a response after say > 5 attempts it will assume that the client is gone and > it will delete the client's 'subscriptions and > PDReplyQ" (by sending a PCF message to the command > server). > > > Option B: > > 1- PDReplyQs are all created (with the predefined full > names) by the server app when it first starts up. > 2- Client app OPENs (like a local queue) and uses its > PDReplyQ as usual > 3- Before sever app stops, it sends a terminate > message (with MQFB_QUIT) to all of the clients > 4- CLients terminate > 5- Server app deletes these PD queues (with CLOSE... > if not successful, with PCF to the command server). > > Option C: > > 1- When client starts, it will create its PDReplyQ; if > it already exists it will open it as a regular local > queue (without mentioning the model queue name) > 2- When qmgr is coming down, the admin will send t
Time and MQSeries
We are on MQSeries V2.1. Does anyone have any experience/knowledge with MQS going 'backward' when daylight savings/standard time is involved? Thank you. Carol Criscione ITSS, CICS/MQSeries Technical Services Computer Services Division Department of Information Services State of Washington (360) 902-3051 [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
Creating a compound element in MQSI 2.1 using ESQL
Hi everyone, I have a requirement where i would like to create a compound element using ESQL. I can create and attach simple elements using the 'create' command in ESQL. Does anyone know how to do this? e.g. if I say 'create OutputRoot.MQRFH2' then an MQRFH2 element is created. (it becomes like the folder element in the tree). When I create the compound element it need not have all the elements in it, just need the starting point from where i can create all the elements in it. If the elements of the compound type are there with some default values that would be great. Thanks very much. Kind Regards Aby 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 Urgent Help in MQExplorer
Title: RE: Need Urgent Help in MQExplorer go to MQ services, set them to automatic start, then reboot the machine. the GUI sometimes cheat you. cheers, -Original Message- From: Yeh, Jeff [mailto:[EMAIL PROTECTED]] Sent: Monday, August 26, 2002 10:51 AM To: [EMAIL PROTECTED] Subject: Need Urgent Help in MQExplorer I just encountered a strange situation during my MQ Clustering test. I have MQ v5.2.1 in my standalone machine, W2K advance server. There are four queue managers on it. Only one queue manager is not able to be connected to MQExplorer. All three of them are fine. All four queue managers are fine in MQ Services MMC. First I stopped all Qmgrs from MQ Services MMC. Then Start MQExplorer, it displayed all four qmgr stopped. That's perfect. Clicked that specific qmgr to start it, it displayed a yellow warning icon. I checked all services in MQServices MMC, everything is running. I went to comman prompt, I was able to use RUNMQSC for this qmgr. I came back to MQExplorer, right click qmgr and select to connect, it shows Unknown Object Name, amq4049. I hid this qmgr and tried to show it again. First the qmgr turned green then turn yellow and display an error message - An error occurred connecting to thje queue manager (amq4027). All other three qmgrs are fine. Thanks. Jeff Yeh EPS - Transaction and Messaging Technical Services Phone: 216-257-7342 Pager: 800-632-9182 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
Need Urgent Help in MQExplorer
I just encountered a strange situation during my MQ Clustering test. I have MQ v5.2.1 in my standalone machine, W2K advance server. There are four queue managers on it. Only one queue manager is not able to be connected to MQExplorer. All three of them are fine. All four queue managers are fine in MQ Services MMC. First I stopped all Qmgrs from MQ Services MMC. Then Start MQExplorer, it displayed all four qmgr stopped. That's perfect. Clicked that specific qmgr to start it, it displayed a yellow warning icon. I checked all services in MQServices MMC, everything is running. I went to comman prompt, I was able to use RUNMQSC for this qmgr. I came back to MQExplorer, right click qmgr and select to connect, it shows Unknown Object Name, amq4049. I hid this qmgr and tried to show it again. First the qmgr turned green then turn yellow and display an error message - An error occurred connecting to thje queue manager (amq4027). All other three qmgrs are fine. Thanks. Jeff Yeh EPS - Transaction and Messaging Technical Services Phone: 216-257-7342 Pager: 800-632-9182 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: SAP IDocs size limitation with MQ
Hi, Here is an extract from our R3Link Documentation which might be helpful: " Restrictions The amount of R/3 IDoc data that can be sent in a single message is limited by the maximum MQSeries message size. With MQSeries Version 5 the maximum message size is 100 MB and with earlier versions of MQSeries the maximum size of MQSeries messages is 4MB. Because the MQSeries link for R/3 header fields are part of the space that is assigned to MQSeries messages, the actual space available for R/3 | transaction data is less than the full 100MB (or 4MB). R/3 transaction data can consist | of one IDoc or batched IDocs. SAP AG recommends a maximum of 2MB for each IDoc." Hope this answers your question. Regards Andre -Original Message-From: Naveen Kumar [mailto:[EMAIL PROTECTED]]Sent: 26 August 2002 03:32To: [EMAIL PROTECTED]Subject: SAP IDocs size limitation with MQ Hi, I would like to know if there are any limitations on the size of the SAP IDocs that can be used with MQSeries Link for R/3 or MQSI or any of the adapters for SAP that MQ or MQSI supports. Thanks in Advance Do You Yahoo!?Yahoo! Finance - Get real-time stock quotes = Disclaimer = "This message may contain information which is private, privileged or confidential and is intended solely for the use of the individual or entity named in the message. If you are not the intended recipient of this message, please notify the sender thereof and destroy / delete the message. Neither the sender nor Sappi Limited (including its subsidiaries and associated companies) shall incur any liability resulting directly or indirectly from accessing any of the attached files which may contain a virus or the like."
SAP IDocs size limitation with MQ
Hi, I would like to know if there are any limitations on the size of the SAP IDocs that can be used with MQSeries Link for R/3 or MQSI or any of the adapters for SAP that MQ or MQSI supports. Thanks in AdvanceDo You Yahoo!? Yahoo! Finance - Get real-time stock quotes
Re: Question about deleting Perm. Dynamic queues
Dennis: Thanks for your reponse. Below, I will explain why and how I decided to use PD (Perm. Dyn.) queues --I WOULD LIKE ALL THESE pd QUEUES GONE BEFORE MQ SHOT-DOWN-- in order not to cause any headache to the MQ Admin guys. Here is the requirement and the design to acheive this: Requirement: - We'll have about 200 clients (Win2K MQ 5.2) that will send mostly persistent requests to the server (we don't know the platform yet) and receive their persistent replies in their perspective reply queues. Some of these clients will run almost non stop (for days if not weeks or months... due to business req's)and some may stop at the end of the day. Design: --- I don't want to create 200 regular local queues for admin purposes. I also don't want to create say 20 local queues each of which to be shared by 10 clients due to competition for getting replies (based on a correlid) and the fact that failure of one client can impact the others in the group. I thought, with separate PD queues I can store both persistent and non-persistant messages. These queues will also be used for sub/pub purposes (Smalltalk sub/pub, not MQ). Both the client and the server app will be written in Smalltalk. Here is the order or operations: 1. Client app starts and connects to the MQ server 2. Client app subscribes to publications/topics (specifying the PDReplyQ as the reply-to-q) 3. Client sends a request (w/ PDReplyQ as the repl-to-q) 4. Client gets the reply/publication from the PDReplyQ 5. Step 3 and 4 are repeated all day long (maybe once every 5-10). The rest of the time it will stay idle 6. During the idle time the client will do an MQGET on the PDReplyQ (say every 2 min) to detect qmgr quiescing 7. Client, just before it stops, closes its queues and deletes its PDReplyQ (with purge option on the CLOSE). ===Important: As part of the shut-down process (shutting down the server app or the qmgr): Admin will send a message to the server app with MQFB_QUIT; and in turn, the server app, before it terminates, will send a message to its clients with MQFB_QUIT, to stop processing=== HOW TO HANDLE ORPHANED PD QUEUES: - Because of the step 7, there won't be any PDReplyQ queues left behind. However, if the client app stopped abnormally it will leave its PDReplyQ "undeleted". In order to take care of this situation here are Some of the options I have in mind: Option A: 1. Clinet will create its own PDReplyQ and let the server app know about it (in MD) during Request/reply or pub/sub situation 2. Server app will ping the client app on a regular basis (say every 2 min which is same as the time-interval used during idle time by the client). The message will have no app data (maybe it will have only a user-defined feedback code... I haven't given this much thought yet). I know it will increase the traffic over the channel but it it can be tolerated). 3. If the server app does not get a response after say 5 attempts it will assume that the client is gone and it will delete the client's 'subscriptions and PDReplyQ" (by sending a PCF message to the command server). Option B: 1- PDReplyQs are all created (with the predefined full names) by the server app when it first starts up. 2- Client app OPENs (like a local queue) and uses its PDReplyQ as usual 3- Before sever app stops, it sends a terminate message (with MQFB_QUIT) to all of the clients 4- CLients terminate 5- Server app deletes these PD queues (with CLOSE... if not successful, with PCF to the command server). Option C: 1- When client starts, it will create its PDReplyQ; if it already exists it will open it as a regular local queue (without mentioning the model queue name) 2- When qmgr is coming down, the admin will send the above mentioned a "terminate message" (MQFB_QUIT) to the app server and app server will do the same with its clients (to stop processing) 3- CLient will "try to" delete (in the CLOSE call) its PDREPlyQ 4- Admin then will run a PCF script to delete all the dynamic queues. Most of the PD queues will have been already deleted by the clients by now; as a result the Admin will get "queue does not exist" RC, which will be just ignored. So, the script will take care of only the orphaned PD queues if any. In option B, both the client and server app will have to know the names of all the PD queues. As all of the PD queues will be created when the server app starts, some of these queues just may not be used for a while as their respective clients are not up yet; but this is OK. However, the server app may leave behind orphaned queues if it terminates abnormally. Whic is also true for Option A. That's why I am leaning more towards option C which will take care of them (orphaned PD queues) via the PCF script. I would very much appreciate everyone's comments regrading the above and alternative design approaches. Thank you very much, Steve --- "Miller, Dennis" <[EMAIL PROTECTED]> wrote: > Yes, you can de
