Re: QMAN replication
We are looking at Lakeview's MIMIX product which has MQ support for Mirroring MQ environments across hardware . This is for the iSeries platform. Joan Hughes Brown Shoe / Famous Footwear Tom Schneider [EMAIL PROTECTED]To: [EMAIL PROTECTED] OM cc: Sent by: MQSeriesSubject: Re: QMAN replication List [EMAIL PROTECTED] n.AC.AT 08/26/2003 03:30 PM Please respond to MQSeries List Hi Kris, No, sorry, other than shared queues I don't know of a way to do this. Regards, Tom == Tom Schneider / IBM Global Services (513) 274-4034 [EMAIL PROTECTED] == Sigmon, Kristin [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 08/26/2003 02:33 PM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject:Re: QMAN replication Tom, Is there a way to do this without using shared queues? My company does not have DB2 that is required for shared queues. Thanks, Kris -Original Message- From: Tom Schneider [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 26, 2003 1:26 PM To: [EMAIL PROTECTED] Subject: Re: QMAN replication Hi Enrico, You don't mention the platform, but shared queues on z/OS are pretty much what you are describing. Regards, Tom == Tom Schneider / IBM Global Services (513) 274-4034 [EMAIL PROTECTED] == Enrico Strydom [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 08/26/2003 03:28 AM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject:QMAN replication Hi all, Does MQSeries (or utility software) have the capability to replicate/mirror? a queue manager ? By this I mean the following: 1) Have a queue manager A running on machine a 2) Have queue manager B running on machine b (or maybe A on b ??) 3) any change to queue manager A (ie. a message arrives on a queue, or a message gets taken off a queue etc.) also happens on qmgr B Regards Enrico * [This message and its contents have been scanned for viruses] * 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: WMQ Microsoft Terminal Services...
Title: WMQ & Microsoft Terminal Services... You need to be with MQ V5.2 CSD03 for WTS to be officially supported by IBM. Hope this helps. -Original Message-From: Antony Boggis [mailto:[EMAIL PROTECTED]Sent: Wednesday, 27 August 2003 2:31 AMTo: [EMAIL PROTECTED]Subject: WMQ Microsoft Terminal Services... Can anyone tell me what the minimum requirement is for running WMQ and using MS Terminal Services to admin the box remotely? I have WMQ 5.2 CSD06 (and will be upgrading to WMQ 5.3 CSD04 hopefully soon) running on Windows 2000 Server, Service Pack 4 (AFAIK). I know that there are/were issues with Terminal Services and WMQ 5.2 prior to CSD06 does CSD06 fix most of the issues? TIA, Antony Boggis.
Re: QMAN replication
Hi Enrico, We had the same requirement (as well as a DR solution) ages ago and elected to go with EMC SRDF hardware mirroring as anything else was just too complex and the solution catered for our requirement. I'm sure you would have considered this option as well. Hope this helps. Margherita... -Original Message- From: Tom Schneider [mailto:[EMAIL PROTECTED] Sent: Wednesday, 27 August 2003 4:26 AM To: [EMAIL PROTECTED] Subject: Re: QMAN replication Hi Enrico, You don't mention the platform, but shared queues on z/OS are pretty much what you are describing. Regards, Tom == Tom Schneider / IBM Global Services (513) 274-4034 [EMAIL PROTECTED] == Enrico Strydom [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 08/26/2003 03:28 AM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject:QMAN replication Hi all, Does MQSeries (or utility software) have the capability to replicate/mirror? a queue manager ? By this I mean the following: 1) Have a queue manager A running on machine a 2) Have queue manager B running on machine b (or maybe A on b ??) 3) any change to queue manager A (ie. a message arrives on a queue, or a message gets taken off a queue etc.) also happens on qmgr B Regards Enrico 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: WMQI v2.1 - XML Schemas
Yes, but use CSD 3 , or better 4, as there were a few APARs that when in that fixed problems I had. You can issue the command: mqsiimpxmlschema -f config file, where the config file contains the schema name etc. An example is: # # Parameters file for MQSI V2.1 XML Schema importer # # Name of the message set to import the message into # MessageSet=msTestSchema # # Name of the MRM database to import into # MRM_DB=MQSIMRDB XMLTabName=XML RootElement=SunriseXML # # MRM Database User id - can be overridden on the command line # DB_User=db2admin # # MRM Database Password - can be overridden on the command line # DB_PW=db2admin Verbose=Y Trace=Y ShowSchema=Y # # Name of the top level element in the MRM message # # [FILELIST] # # Name of the XML Schema file # SunriseXML.xsd You don't have to create a message set, as the command will create one if it doesn't exist. Regards Alan Christopher Fryett [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 27/08/2003 04:37 AM Please respond to MQSeries List [EMAIL PROTECTED] To [EMAIL PROTECTED] cc Subject WMQI v2.1 - XML Schemas Hello Folks, Is there support for XML Schemas in WMQI v2.1 and if so do you know which PDF it may be in? Thank you, Chris 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 email is intended for the named recipient only. The informationcontained in this message may be confidential, or commerciallysensitive. If you are not the intended recipient you must not reproduceor distribute any part of the email, disclose its contents to any otherparty, or take any action in reliance on it. If you have received thisemail in error, please contact the sender immediately. Please deletethis message from your computer.
CA Monitoring Agents for MQ
Title: CA Monitoring Agents for MQ We are looking at the possibility of replacing our current MQ monitoring solution with Unicenter Management for MQSeries (on Windows 2000) and SysView E WebSphere MQ Option (on z/OS) feeding into a Unicenter console. The reasoning behind this move is to consolidate much of our enterprise monitoring into Unicenter. Before I get too far down this road, I'm looking for some feedback from folks who have some practical experience with these CA products. Were they easy to install and configure? Were you able to set up all of the alerting that you expected to? Did you encounter any serious roadblocks? Are the agents stable? Anything along this line I welcome any and all comments. If you would prefer to share you comments off list, that is fine as well. Steve Gies Safeco Insurance IT Specialist - WebSphere MQ
Re: Reginaldo S Rosa?? Anyone know this Guy - more info
the following is from Symantec. since we are using e-mail, I wanted to save time and cycles by putting in the message rather than the URL. please forgive me. go to www.symantec.com for more... - EARmerc - P.S I am posting this because someone on the CICS list just reported receiving the virus. It's apparently still active. - © 1995-2003 Symantec Corporation. All rights reserved. Legal Notices Privacy Policy [EMAIL PROTECTED] Discovered on: August 18, 2003 Last Updated on: August 23, 2003 04:12:41 AM Due to the number of submissions received from customers, Symantec Security Response has upgraded this threat to a Category 4 from a Category 3 threat as of August 21, 2003. [EMAIL PROTECTED] is a mass-mailing, network-aware worm that sends itself to all the email addresses it finds in the files that have the following extensions: .dbx .eml .hlp .htm .html .mht .wab .txt The worm uses its own SMTP engine to propagate and attempts to create a copy of itself on accessible network shares, but fails due to bugs in the code. Email routine details The email message has the following characteristics: From: Spoofed address (which means that the sender in the From field is most likely not the real sender). The worm may also use the address [EMAIL PROTECTED] as the sender. NOTES: The spoofed addresses and the Send To addresses are both taken from the files found on the computer. Also, the worm may use the settings of the infected computer's settings to check for an SMTP server to contact. The choice of the internet.com domain appears to be arbitrary and does not have any connection to the actual domain or its parent company. Subject: Re: Details Re: Approved Re: Re: My details Re: Thank you! Re: That movie Re: Wicked screensaver Re: Your application Thank you! Your details Body: See the attached file for details Please see the attached file for details. Attachment: your_document.pif document_all.pif thank_you.pif your_details.pif details.pif document_9446.pif application.pif wicked_scr.scr movie0045.pif NOTES: The worm de-activates on September 10, 2003. The last day on which the worm will spread is September 9, 2003. The aforementioned deactivation date applies only to the mass-mailing, network propagation, and email address collection routines. This means that a [EMAIL PROTECTED] infected computer will still attempt to download updates from the respective list of master servers during the associated trigger period, even after the infection de-activation date. Previous variants of Sobig exhibited similar behavior. Outbound udp traffic was observed on August 22nd coming from systems infected with both Sobig.E and Sobig.F. However the target IP addresses were either nor responding/taken offline or contained not executable content i.e. a link to a adult site. [EMAIL PROTECTED] uses a technique known as email spoofing, by which the worm randomly selects an address it finds on an infected computer. For more information on email spoofing, see the Technical Details section below. Symantec Security Response has developed a removal tool to clean the infections of [EMAIL PROTECTED] Also Known As: Sobig.F [F-Secure], W32/[EMAIL PROTECTED] [McAfee], WORM SOBIG.F [Trend], W32/Sobig-F [Sophos], Win32.Sobig.F [CA], I-Worm.Sobig.f [KAV] Type: Worm Infection Length: about 72,000 bytes Systems Affected: Windows 2000, Windows 95, Windows 98, Windows Me, Windows NT, Windows XP Systems Not Affected: Linux, Macintosh, OS/2, UNIX, Windows 3.x Virus Definitions (Intelligent Updater) * August 19, 2003 Virus Definitions (LiveUpdate?) ** August 19, 2003 * Intelligent Updater definitions are released daily, but require manual download and installation. Click here to download manually. ** LiveUpdate virus definitions are usually released every Wednesday. Click here for instructions on using LiveUpdate. Wild: Number of infections: More than 1000 Number of sites: More than 10 Geographical distribution: High Threat containment: Easy Removal: Moderate Threat Metrics Wild: High Damage: Medium Distribution: High Damage Payload: Large scale e-mailing: Sends email to addresses collected from files with the following extensions: .wab, .dbx, .htm, .html, .eml, .txt. Releases confidential info: May steal system information, including passwords. Distribution Subject of email: Varies Name of attachment: Varies with .pif or .scr file extension Size of attachment: About 72,000 bytes Ports: UDP 123, 995, 996, 997, 998, 999, 8998 When [EMAIL PROTECTED] is executed, it performs the following actions: Copies itself as %Windir%\winppr32.exe. NOTE: %Windir% is a variable. The worm locates the Windows installation folder (by default, this is C:\Windows or C:\Winnt) and copies itself to that location. Creates the file, %Windir%\winstt32.dat. Adds the value: TrayX=%Windir%\winppr32.exe /sinc to the registry key:
SOC 7 error while displaying S99 Fields in COBOL (WMQI 2.1)
Hi , I have the following COBOL copy book imported into WMQI(2.1 WinNT) 06 TESTVARIABLES. 07 TESTINPUT. 08 INTEGERNOSIGN PIC 99. 08 INTEGERSIGNED PIC S99. 08 DECIMALNOSIGN PIC 99V99. 08 DECIMALSIGNED PIC S99V99. 08 COMP3NOSIGN PIC 99V99 COMP-3. 08 COMP3SIGNED PIC S99V99 COMP-3. I assign the following values to them in a compute node SET "OutputRoot"."MRM"."INTEGERNOSIGN" = 12; SET "OutputRoot"."MRM"."INTEGERSIGNED" = -12; SET "OutputRoot"."MRM"."DECIMALNOSIGN" = 1234; SET "OutputRoot"."MRM"."DECIMALSIGNED" = -1234; SET "OutputRoot"."MRM"."COMP3NOSIGN" = 5678; SET "OutputRoot"."MRM"."COMP3SIGNED" = -678; Now when a COBOL program on mainframe reads this message and moves into the same copybook and displays the fields ,I get an SOC 7 error for the S99 field.WHat could be the problem. Pls respond. THanks in ADvance Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month!
Re: SOC 7 error while displaying S99 Fields in COBOL (WMQI 2.1)
What does the MQ message look like? Can you post a hex dump of the record??? bb PS Keep the layout in the REPLY From: Juni Per [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: SOC 7 error while displaying S99 Fields in COBOL (WMQI 2.1) Date: Tue, 26 Aug 2003 21:58:29 -0700 Hi , I have the following COBOL copy book imported into WMQI(2.1 WinNT) 06 TESTVARIABLES. 07 TESTINPUT. 08 INTEGERNOSIGN PIC 99. 08 INTEGERSIGNED PIC S99. 08 DECIMALNOSIGN PIC 99V99. 08 DECIMALSIGNED PIC S99V99. 08 COMP3NOSIGN PIC 99V99 COMP-3. 08 COMP3SIGNED PIC S99V99 COMP-3. I assign the following values to them in a compute node SET OutputRoot.MRM.INTEGERNOSIGN = 12; SET OutputRoot.MRM.INTEGERSIGNED = -12; SET OutputRoot.MRM.DECIMALNOSIGN = 1234; SET OutputRoot.MRM.DECIMALSIGNED = -1234; SET OutputRoot.MRM.COMP3NOSIGN = 5678; SET OutputRoot.MRM.COMP3SIGNED = -678; Now when a COBOL program on mainframe reads this message and moves into the same copybook and displays the fields , I get an SOC 7 error for the S99 field.WHat could be the problem. Pls respond. THanks in ADvance - Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! _ Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige using MSN Messenger http://entertainment.msn.com/imastar 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
Geoff Hopkin/Switzerland/IBM is out of the office.
I will be out of the office starting August 12, 2003 and will not return until August 28, 2003. I am out of the office on vacation until 28th August I will respond to your message when I return. 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: SOC 7 error while displaying S99 Fields in COBOL (WMQI 2.1)
Someone correct me if I am wrong It has been in the back of my mind that the S9 and COMP-3 fields have to be changed ,before they are MQPUTed, to flat PIC 9 s without the assumed sign and COMP-3, and that the assumed sign to be coded as a one byte separate filed -- for conversion purposes. No? Ruzi --- Juni Per [EMAIL PROTECTED] wrote: Hi , I have the following COBOL copy book imported into WMQI(2.1 WinNT) 06 TESTVARIABLES. 07 TESTINPUT. 08 INTEGERNOSIGN PIC 99. 08 INTEGERSIGNED PIC S99. 08 DECIMALNOSIGN PIC 99V99. 08 DECIMALSIGNED PIC S99V99. 08 COMP3NOSIGN PIC 99V99 COMP-3. 08 COMP3SIGNED PIC S99V99 COMP-3. I assign the following values to them in a compute node SET OutputRoot.MRM.INTEGERNOSIGN = 12; SET OutputRoot.MRM.INTEGERSIGNED = -12; SET OutputRoot.MRM.DECIMALNOSIGN = 1234; SET OutputRoot.MRM.DECIMALSIGNED = -1234; SET OutputRoot.MRM.COMP3NOSIGN = 5678; SET OutputRoot.MRM.COMP3SIGNED = -678; Now when a COBOL program on mainframe reads this message and moves into the same copybook and displays the fields , I get an SOC 7 error for the S99 field.WHat could be the problem. Pls respond. THanks in ADvance - Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: SOC 7 error while displaying S99 Fields in COBOL (WMQI 2.1)
The s99 field implies that the data in the sending field is a valid numeric field with the last byte containing a valid numeric sign. If my assembler isn't t rusty. What happens behind the the curtain is that the compiler generates instructions to convert the Zone Decimal field to pack (which doesn't do a validate) and does a ZAP instruction which takes the field down the hardware path where the numeric portion get interrogated. That is where, I believe, the S0C7 is generated. SO.the sending fiels must be a combination of the following F0-F9, C0-C9, D0-D9 there is another range but I don't havv a green card available. I will take a further step in saying, and now I am streaching my brain, that the conversion from display format to the packed format to verify the numeric portion DOES NOT care what is in the hig order signifigant sign portion of the display characters. It just moves the digit portion. (eg SDSDSD) until it gets to the last byte where it retrieves it's sign from. So all the signs can be whatever except the last one which must be a C or D or F and the digits portion in ALL the Zone Decimal must be 0-9. DID I PASS THE TECH INTERVIEW?? (tee hee hee) bobbee From: Ruzi R [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: SOC 7 error while displaying S99 Fields in COBOL (WMQI 2.1) Date: Wed, 27 Aug 2003 08:50:26 -0700 Someone correct me if I am wrong It has been in the back of my mind that the S9 and COMP-3 fields have to be changed ,before they are MQPUTed, to flat PIC 9 s without the assumed sign and COMP-3, and that the assumed sign to be coded as a one byte separate filed -- for conversion purposes. No? Ruzi --- Juni Per [EMAIL PROTECTED] wrote: Hi , I have the following COBOL copy book imported into WMQI(2.1 WinNT) 06 TESTVARIABLES. 07 TESTINPUT. 08 INTEGERNOSIGN PIC 99. 08 INTEGERSIGNED PIC S99. 08 DECIMALNOSIGN PIC 99V99. 08 DECIMALSIGNED PIC S99V99. 08 COMP3NOSIGN PIC 99V99 COMP-3. 08 COMP3SIGNED PIC S99V99 COMP-3. I assign the following values to them in a compute node SET OutputRoot.MRM.INTEGERNOSIGN = 12; SET OutputRoot.MRM.INTEGERSIGNED = -12; SET OutputRoot.MRM.DECIMALNOSIGN = 1234; SET OutputRoot.MRM.DECIMALSIGNED = -1234; SET OutputRoot.MRM.COMP3NOSIGN = 5678; SET OutputRoot.MRM.COMP3SIGNED = -678; Now when a COBOL program on mainframe reads this message and moves into the same copybook and displays the fields , I get an SOC 7 error for the S99 field.WHat could be the problem. Pls respond. THanks in ADvance - Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive _ Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige using MSN Messenger http://entertainment.msn.com/imastar 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: SOC 7 error while displaying S99 Fields in COBOL (WMQI 2.1)
Bobbee, You passed the interview, but are you certified? Regards, John Dawson -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 27, 2003 11:21 AM To: [EMAIL PROTECTED] Subject:Re: SOC 7 error while displaying S99 Fields in COBOL (WMQI 2.1) The s99 field implies that the data in the sending field is a valid numeric field with the last byte containing a valid numeric sign. If my assembler isn't t rusty. What happens behind the the curtain is that the compiler generates instructions to convert the Zone Decimal field to pack (which doesn't do a validate) and does a ZAP instruction which takes the field down the hardware path where the numeric portion get interrogated. That is where, I believe, the S0C7 is generated. SO.the sending fiels must be a combination of the following F0-F9, C0-C9, D0-D9 there is another range but I don't havv a green card available. I will take a further step in saying, and now I am streaching my brain, that the conversion from display format to the packed format to verify the numeric portion DOES NOT care what is in the hig order signifigant sign portion of the display characters. It just moves the digit portion. (eg SDSDSD) until it gets to the last byte where it retrieves it's sign from. So all the signs can be whatever except the last one which must be a C or D or F and the digits portion in ALL the Zone Decimal must be 0-9. DID I PASS THE TECH INTERVIEW?? (tee hee hee) bobbee From: Ruzi R [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: SOC 7 error while displaying S99 Fields in COBOL (WMQI 2.1) Date: Wed, 27 Aug 2003 08:50:26 -0700 Someone correct me if I am wrong It has been in the back of my mind that the S9 and COMP-3 fields have to be changed ,before they are MQPUTed, to flat PIC 9 s without the assumed sign and COMP-3, and that the assumed sign to be coded as a one byte separate filed -- for conversion purposes. No? Ruzi --- Juni Per [EMAIL PROTECTED] wrote: Hi , I have the following COBOL copy book imported into WMQI(2.1 WinNT) 06 TESTVARIABLES. 07 TESTINPUT. 08 INTEGERNOSIGN PIC 99. 08 INTEGERSIGNED PIC S99. 08 DECIMALNOSIGN PIC 99V99. 08 DECIMALSIGNED PIC S99V99. 08 COMP3NOSIGN PIC 99V99 COMP-3. 08 COMP3SIGNED PIC S99V99 COMP-3. I assign the following values to them in a compute node SET OutputRoot.MRM.INTEGERNOSIGN = 12; SET OutputRoot.MRM.INTEGERSIGNED = -12; SET OutputRoot.MRM.DECIMALNOSIGN = 1234; SET OutputRoot.MRM.DECIMALSIGNED = -1234; SET OutputRoot.MRM.COMP3NOSIGN = 5678; SET OutputRoot.MRM.COMP3SIGNED = -678; Now when a COBOL program on mainframe reads this message and moves into the same copybook and displays the fields , I get an SOC 7 error for the S99 field.WHat could be the problem. Pls respond. THanks in ADvance - Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive _ Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige using MSN Messenger http://entertainment.msn.com/imastar 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: SOC 7 error while displaying S99 Fields in COBOL (WMQI 2.1)
That's correct. Signed decimal and packed fields do not survive data conversion. The best practice is that a message should be all binary and not converted or all character if it needs to be converted. Bottom line--all fields in the message should be defined in display formats (PIC X or PIC 9...). -Original Message- From: Ruzi R [SMTP:[EMAIL PROTECTED] Sent: Wednesday, August 27, 2003 8:50 AM To: [EMAIL PROTECTED] Subject: Re: SOC 7 error while displaying S99 Fields in COBOL (WMQI 2.1) Someone correct me if I am wrong It has been in the back of my mind that the S9 and COMP-3 fields have to be changed ,before they are MQPUTed, to flat PIC 9 s without the assumed sign and COMP-3, and that the assumed sign to be coded as a one byte separate filed -- for conversion purposes. No? Ruzi --- Juni Per [EMAIL PROTECTED] wrote: Hi , I have the following COBOL copy book imported into WMQI(2.1 WinNT) 06 TESTVARIABLES. 07 TESTINPUT. 08 INTEGERNOSIGN PIC 99. 08 INTEGERSIGNED PIC S99. 08 DECIMALNOSIGN PIC 99V99. 08 DECIMALSIGNED PIC S99V99. 08 COMP3NOSIGN PIC 99V99 COMP-3. 08 COMP3SIGNED PIC S99V99 COMP-3. I assign the following values to them in a compute node SET OutputRoot.MRM.INTEGERNOSIGN = 12; SET OutputRoot.MRM.INTEGERSIGNED = -12; SET OutputRoot.MRM.DECIMALNOSIGN = 1234; SET OutputRoot.MRM.DECIMALSIGNED = -1234; SET OutputRoot.MRM.COMP3NOSIGN = 5678; SET OutputRoot.MRM.COMP3SIGNED = -678; Now when a COBOL program on mainframe reads this message and moves into the same copybook and displays the fields , I get an SOC 7 error for the S99 field.WHat could be the problem. Pls respond. THanks in ADvance - Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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
JBOSS and WMQ
Anybody out there using JBOSS and WMQ? 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: WMQ Microsoft Terminal Services...
I have MQ V5.2.1 with CSD6 and when I use WTS, I still can't see any MQ objects. Crupi, Margherita To: [EMAIL PROTECTED] [EMAIL PROTECTED] cc: Subject: Re: WMQ Microsoft Terminal Services... Sent by: MQSeries List [EMAIL PROTECTED] en.AC.AT 08/26/2003 06:12 PM Please respond to MQSeries List You need to be with MQ V5.2 CSD03 for WTS to be officially supported by IBM. Hope this helps. -Original Message- From: Antony Boggis [mailto:[EMAIL PROTECTED] Sent: Wednesday, 27 August 2003 2:31 AM To: [EMAIL PROTECTED] Subject: WMQ Microsoft Terminal Services... Can anyone tell me what the minimum requirement is for running WMQ and using MS Terminal Services to admin the box remotely? I have WMQ 5.2 CSD06 (and will be upgrading to WMQ 5.3 CSD04 hopefully soon) running on Windows 2000 Server, Service Pack 4 (AFAIK). I know that there are/were issues with Terminal Services and WMQ 5.2 prior to CSD06 does CSD06 fix most of the issues? TIA, Antony Boggis. '²ÚîrÇè®f§j§*.®f¢)à+-²æìr¸©¶*'j·©®âuçbØ^.+-±êïé©T±êìèy«VÛiÿü0Â[(~×( +ÛiÿûæjHpéÚq«1®'¬j·!÷
Re: MA12 Batch triggering
Peter -
Process name and content
EMAIL.SMTP.MSGS
USED TO PROCESS MAINFRAME EMAI
TO USERS IN
MVS
//*S010EXE EXEC PGM=MQMAIL
//EMAIL DD SYSOUT=(Q,SMTP)
//SYSOUT DD SYSOUT=*
//UTLITYF DD DUMMY
-Original Message-
From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2003 2:45 PM
To: [EMAIL PROTECTED]
Subject: MA12 Batch triggering
The trigger monitor is up and running. I can send the shutdown message to it
via CKTIEND and it shuts down as expected. So I start it back up and try to
drop a message into the triggered queue. The triggered queue name is
MQT1.LOCAL.QUEUE and the process definition is named MQT1.LOCAL.QUEUE as
well.
The problem is, the JCL it produces upon recieving a trigger message fails.
I suspect because my process definition is incorrect?
The JCL I would like to kick off is in @TSMT00.MQ.CNTL(MQEX702B). Here are
the first few lines of it:
01,//MQEX702B PROC
02,//**
03,//** THIS JCL WILL EXECUTE RN0722PC, WHICH CALLS RN0702PP, THE MQ *
04,//** WRAPPER FOR BATCH PROCESSING. *
05,//** IT ASSUMES THAT THE MA12 SUPPORT PAC WILL BE TRIGGERING IT*
06,//** THAT IS WHY THERE IS NO JOBCARD AT THE TOP. MA12 MAKES THE CARD
07,//**
08,//RN072201 EXEC PGM=DFSRRC00,REGION=9000K,
09,// PARM=(DLI,DSNMTV01,RF0001P1)
10,//STEPLIB DD DSN=SYS1.SCSQANLE,DISP=SHR
Here is the process def. (I have tried about 800 different variations, this
is the latest):
DEF PROCESS(MQT1.LOCAL.QUEUE)
APPLICID('//BTACLIB JCLLIB [EMAIL PROTECTED]')
USERDATA('//S1 EXEC PROC=MQEX702B)
APPLTYPE('z/OS')
Here is the output of the job as it fails bb interpretor:
//J7900027 JOB J7211ZZRJB12345678,'P PPOTKAY X77906', *
// MSGLEVEL=1,MSGCLASS=H,[EMAIL PROTECTED]
//*MAIN CLASS=DB2A
//*MAIN SYSTEM=ST1
//*
//* JOB SUBMITTED BY CKTIBAT.
//* PROCESS: MQT1.LOCAL.QUEUE
//* TRIGGERING Q: MQT1.LOCAL.QUEUE
//BTACLIB JCLLIB [EMAIL PROTECTED]
//S1 EXEC PROC=MQEX702B
/*EOF
1 //J7900027 JOB J7211ZZRJB12345678,'P PPOTKAY X77906',
// MSGLEVEL=1,MSGCLASS=H,[EMAIL PROTECTED]
//*MAIN CLASS=DB2A
//*MAIN SYSTEM=ST1
//*
//* JOB SUBMITTED BY CKTIBAT.
//* PROCESS: MQT1.LOCAL.QUEUE
//* TRIGGERING Q: MQT1.LOCAL.QUEUE
2 //BTACLIB JCLLIB [EMAIL PROTECTED]
3 //S1 EXEC PROC=MQEX702B
IEFC025I INSTALLATION MODIFIED JCL - // JOBCARD
ERROR-5 **
and the error messages
STMT NO. MESSAGE
3 IEFC042I JOB CANCELLED BY INSTALLATION EXIT - IEFUJV
3 IEFC029I EXIT ERROR: IEFUJV ATTEMPTED TO INSERT JCL COMMENTS -
STATEM
3 IEFC607I JOB HAS NO STEPS
Peter Potkay
MQSeries Specialist
The Hartford Financial Services
[EMAIL PROTECTED]
x77906
IBM MQSeries Certified
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If
you are not the intended recipient, please notify the sender
immediately by return email and delete this communication and destroy all copies.
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
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: MA12 Batch triggering
No, I never had it working. I mean, I had the job itself working A-OK when I
submitted SUB from inside the member. But someone told me I could not just
submit a JCL member like this from a process definition. I had to change it
to a proc, which are the changes I made below and the reason I posted the
first few lines of the member MQEX702B. I think I made the correct changed
to it to make it a proc (removed the job card, added PROC to the first line
and added PEND to the end)
Actually I wish I was able to make this work by simply be able to do
something like TSO SUB @TSMT00.MQ.CNTL(MQEX702B) in the proccess definition,
but I guess this is not possible. (This is assuming MQEX702B was back in its
original state when it could be run standalaone by just submitting the
member.)
-Original Message-
From: Bullock, Rebecca (CSC) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2003 3:22 PM
To: [EMAIL PROTECTED]
Subject: Re: MA12 Batch triggering
Peter, I don't use MA12 and we're not a JES3 shop, but was it working before
you shut it down? Could it be that a different userid is now associated with
it, and that userid is causing it to fail in the SMF exit? I'd talk to the
SMF exit person and see what would trigger a failure and take it from there.
-- Rebecca
-Original Message-
From: Hill, Dave [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2003 3:07 PM
To: [EMAIL PROTECTED]
Subject: Re: MA12 Batch triggering
Peter -
Process name and content
EMAIL.SMTP.MSGS
USED TO PROCESS MAINFRAME EMAI
TO USERS IN
MVS
//*S010EXE EXEC PGM=MQMAIL
//EMAIL DD SYSOUT=(Q,SMTP)
//SYSOUT DD SYSOUT=*
//UTLITYF DD DUMMY
-Original Message-
From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2003 2:45 PM
To: [EMAIL PROTECTED]
Subject: MA12 Batch triggering
The trigger monitor is up and running. I can send the shutdown message to it
via CKTIEND and it shuts down as expected. So I start it back up and try to
drop a message into the triggered queue. The triggered queue name is
MQT1.LOCAL.QUEUE and the process definition is named MQT1.LOCAL.QUEUE as
well.
The problem is, the JCL it produces upon recieving a trigger message fails.
I suspect because my process definition is incorrect?
The JCL I would like to kick off is in @TSMT00.MQ.CNTL(MQEX702B). Here are
the first few lines of it:
01,//MQEX702B PROC
02,//**
03,//** THIS JCL WILL EXECUTE RN0722PC, WHICH CALLS RN0702PP, THE MQ *
04,//** WRAPPER FOR BATCH PROCESSING. *
05,//** IT ASSUMES THAT THE MA12 SUPPORT PAC WILL BE TRIGGERING IT*
06,//** THAT IS WHY THERE IS NO JOBCARD AT THE TOP. MA12 MAKES THE CARD
07,//**
08,//RN072201 EXEC PGM=DFSRRC00,REGION=9000K,
09,// PARM=(DLI,DSNMTV01,RF0001P1)
10,//STEPLIB DD DSN=SYS1.SCSQANLE,DISP=SHR
Here is the process def. (I have tried about 800 different variations, this
is the latest):
DEF PROCESS(MQT1.LOCAL.QUEUE)
APPLICID('//BTACLIB JCLLIB [EMAIL PROTECTED]')
USERDATA('//S1 EXEC PROC=MQEX702B)
APPLTYPE('z/OS')
Here is the output of the job as it fails bb interpretor:
//J7900027 JOB J7211ZZRJB12345678,'P PPOTKAY X77906', *
// MSGLEVEL=1,MSGCLASS=H,[EMAIL PROTECTED]
//*MAIN CLASS=DB2A
//*MAIN SYSTEM=ST1
//*
//* JOB SUBMITTED BY CKTIBAT.
//* PROCESS: MQT1.LOCAL.QUEUE
//* TRIGGERING Q: MQT1.LOCAL.QUEUE
//BTACLIB JCLLIB [EMAIL PROTECTED]
//S1 EXEC PROC=MQEX702B
/*EOF
1 //J7900027 JOB J7211ZZRJB12345678,'P PPOTKAY X77906',
// MSGLEVEL=1,MSGCLASS=H,[EMAIL PROTECTED]
//*MAIN CLASS=DB2A
//*MAIN SYSTEM=ST1
//*
//* JOB SUBMITTED BY CKTIBAT.
//* PROCESS: MQT1.LOCAL.QUEUE
//* TRIGGERING Q: MQT1.LOCAL.QUEUE
2 //BTACLIB JCLLIB [EMAIL PROTECTED]
3 //S1 EXEC PROC=MQEX702B
IEFC025I INSTALLATION MODIFIED JCL - // JOBCARD
ERROR-5 **
and the error messages
STMT NO. MESSAGE
3 IEFC042I JOB CANCELLED BY INSTALLATION EXIT - IEFUJV
3 IEFC029I EXIT ERROR: IEFUJV ATTEMPTED TO INSERT JCL COMMENTS -
STATEM
3 IEFC607I JOB HAS NO STEPS
Peter Potkay
MQSeries Specialist
The Hartford Financial Services
[EMAIL PROTECTED]
x77906
IBM MQSeries Certified
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If
you are not the intended recipient, please notify the sender
immediately by return email and delete this communication and destroy all
copies.
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Re: MA12 Batch triggering
As you may already know, you don''t have to use MA12
for batch triggering. Instead, you can get CICS to
trigger the JCL. I think the latter is just easier set
up.
Just a thought
Ruzi
--- Bullock, Rebecca (CSC) [EMAIL PROTECTED] wrote:
Peter, I don't use MA12 and we're not a JES3 shop,
but was it working before
you shut it down? Could it be that a different
userid is now associated with
it, and that userid is causing it to fail in the SMF
exit? I'd talk to the
SMF exit person and see what would trigger a failure
and take it from there.
-- Rebecca
-Original Message-
From: Hill, Dave [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2003 3:07 PM
To: [EMAIL PROTECTED]
Subject: Re: MA12 Batch triggering
Peter -
Process name and content
EMAIL.SMTP.MSGS
USED TO PROCESS MAINFRAME EMAI
TO USERS IN
MVS
//*S010EXE EXEC PGM=MQMAIL
//EMAIL DD SYSOUT=(Q,SMTP)
//SYSOUT DD SYSOUT=*
//UTLITYF DD DUMMY
-Original Message-
From: Potkay, Peter M (PLC, IT)
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2003 2:45 PM
To: [EMAIL PROTECTED]
Subject: MA12 Batch triggering
The trigger monitor is up and running. I can send
the shutdown message to it
via CKTIEND and it shuts down as expected. So I
start it back up and try to
drop a message into the triggered queue. The
triggered queue name is
MQT1.LOCAL.QUEUE and the process definition is named
MQT1.LOCAL.QUEUE as
well.
The problem is, the JCL it produces upon recieving a
trigger message fails.
I suspect because my process definition is
incorrect?
The JCL I would like to kick off is in
@TSMT00.MQ.CNTL(MQEX702B). Here are
the first few lines of it:
01,//MQEX702B PROC
02,//**
03,//** THIS JCL WILL EXECUTE RN0722PC, WHICH
CALLS RN0702PP, THE MQ *
04,//** WRAPPER FOR BATCH PROCESSING.
*
05,//** IT ASSUMES THAT THE MA12 SUPPORT PAC
WILL BE TRIGGERING IT*
06,//** THAT IS WHY THERE IS NO JOBCARD AT THE
TOP. MA12 MAKES THE CARD
07,//**
08,//RN072201 EXEC PGM=DFSRRC00,REGION=9000K,
09,// PARM=(DLI,DSNMTV01,RF0001P1)
10,//STEPLIB DD DSN=SYS1.SCSQANLE,DISP=SHR
Here is the process def. (I have tried about 800
different variations, this
is the latest):
DEF PROCESS(MQT1.LOCAL.QUEUE)
APPLICID('//BTACLIB JCLLIB
[EMAIL PROTECTED]')
USERDATA('//S1 EXEC PROC=MQEX702B)
APPLTYPE('z/OS')
Here is the output of the job as it fails bb
interpretor:
//J7900027 JOB J7211ZZRJB12345678,'P PPOTKAY
X77906', *
// MSGLEVEL=1,MSGCLASS=H,[EMAIL PROTECTED]
//*MAIN CLASS=DB2A
//*MAIN SYSTEM=ST1
//*
//* JOB SUBMITTED BY CKTIBAT.
//* PROCESS: MQT1.LOCAL.QUEUE
//* TRIGGERING Q: MQT1.LOCAL.QUEUE
//BTACLIB JCLLIB [EMAIL PROTECTED]
//S1 EXEC PROC=MQEX702B
/*EOF
1 //J7900027 JOB J7211ZZRJB12345678,'P
PPOTKAY X77906',
// MSGLEVEL=1,MSGCLASS=H,[EMAIL PROTECTED]
//*MAIN CLASS=DB2A
//*MAIN SYSTEM=ST1
//*
//* JOB SUBMITTED BY CKTIBAT.
//* PROCESS: MQT1.LOCAL.QUEUE
//* TRIGGERING Q: MQT1.LOCAL.QUEUE
2 //BTACLIB JCLLIB [EMAIL PROTECTED]
3 //S1 EXEC PROC=MQEX702B
IEFC025I INSTALLATION MODIFIED JCL -
// JOBCARD
ERROR-5 **
and the error messages
STMT NO. MESSAGE
3 IEFC042I JOB CANCELLED BY INSTALLATION EXIT
- IEFUJV
3 IEFC029I EXIT ERROR: IEFUJV ATTEMPTED TO
INSERT JCL COMMENTS -
STATEM
3 IEFC607I JOB HAS NO STEPS
Peter Potkay
MQSeries Specialist
The Hartford Financial Services
[EMAIL PROTECTED]
x77906
IBM MQSeries Certified
This communication, including attachments, is for
the exclusive use of
addressee and may contain proprietary, confidential
or privileged
information. If you are not the intended recipient,
any use, copying,
disclosure, dissemination or distribution is
strictly prohibited. If
you are not the intended recipient, please notify
the sender
immediately by return email and delete this
communication and destroy all
copies.
Instructions for managing your mailing list
subscription are provided in
the Listserv General Users Guide available at
http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
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,
Re: MA12 Batch triggering
Hi,
Over the years, I have written a couple of trigger monitors to submit JCL (with
a JOB card) rather than a PROC.
It is really straight forward. You can make a simple one or a more robust
trigger monitor. The simple one would have the PDS(member) in the USERDATA
field. For the complex one, you would just specify the member and then the
program would search a list of PDS(s) for the member.
Either way, the program will read the member then submit it to the INTRDR
(Internal Reader).
I wish I could post the code but I can't (it's not mine).
later
Roger...
Quoting Potkay, Peter M (PLC, IT) [EMAIL PROTECTED]:
No, I never had it working. I mean, I had the job itself working A-OK when I
submitted SUB from inside the member. But someone told me I could not just
submit a JCL member like this from a process definition. I had to change it
to a proc, which are the changes I made below and the reason I posted the
first few lines of the member MQEX702B. I think I made the correct changed
to it to make it a proc (removed the job card, added PROC to the first line
and added PEND to the end)
Actually I wish I was able to make this work by simply be able to do
something like TSO SUB @TSMT00.MQ.CNTL(MQEX702B) in the proccess definition,
but I guess this is not possible. (This is assuming MQEX702B was back in its
original state when it could be run standalaone by just submitting the
member.)
-Original Message-
From: Bullock, Rebecca (CSC) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2003 3:22 PM
To: [EMAIL PROTECTED]
Subject: Re: MA12 Batch triggering
Peter, I don't use MA12 and we're not a JES3 shop, but was it working before
you shut it down? Could it be that a different userid is now associated with
it, and that userid is causing it to fail in the SMF exit? I'd talk to the
SMF exit person and see what would trigger a failure and take it from there.
-- Rebecca
-Original Message-
From: Hill, Dave [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2003 3:07 PM
To: [EMAIL PROTECTED]
Subject: Re: MA12 Batch triggering
Peter -
Process name and content
EMAIL.SMTP.MSGS
USED TO PROCESS MAINFRAME EMAI
TO USERS IN
MVS
//*S010EXE EXEC PGM=MQMAIL
//EMAIL DD SYSOUT=(Q,SMTP)
//SYSOUT DD SYSOUT=*
//UTLITYF DD DUMMY
-Original Message-
From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2003 2:45 PM
To: [EMAIL PROTECTED]
Subject: MA12 Batch triggering
The trigger monitor is up and running. I can send the shutdown message to it
via CKTIEND and it shuts down as expected. So I start it back up and try to
drop a message into the triggered queue. The triggered queue name is
MQT1.LOCAL.QUEUE and the process definition is named MQT1.LOCAL.QUEUE as
well.
The problem is, the JCL it produces upon recieving a trigger message fails.
I suspect because my process definition is incorrect?
The JCL I would like to kick off is in @TSMT00.MQ.CNTL(MQEX702B). Here are
the first few lines of it:
01,//MQEX702B PROC
02,//**
03,//** THIS JCL WILL EXECUTE RN0722PC, WHICH CALLS RN0702PP, THE MQ *
04,//** WRAPPER FOR BATCH PROCESSING. *
05,//** IT ASSUMES THAT THE MA12 SUPPORT PAC WILL BE TRIGGERING IT*
06,//** THAT IS WHY THERE IS NO JOBCARD AT THE TOP. MA12 MAKES THE CARD
07,//**
08,//RN072201 EXEC PGM=DFSRRC00,REGION=9000K,
09,// PARM=(DLI,DSNMTV01,RF0001P1)
10,//STEPLIB DD DSN=SYS1.SCSQANLE,DISP=SHR
Here is the process def. (I have tried about 800 different variations, this
is the latest):
DEF PROCESS(MQT1.LOCAL.QUEUE)
APPLICID('//BTACLIB JCLLIB [EMAIL PROTECTED]')
USERDATA('//S1 EXEC PROC=MQEX702B)
APPLTYPE('z/OS')
Here is the output of the job as it fails bb interpretor:
//J7900027 JOB J7211ZZRJB12345678,'P PPOTKAY X77906', *
// MSGLEVEL=1,MSGCLASS=H,[EMAIL PROTECTED]
//*MAIN CLASS=DB2A
//*MAIN SYSTEM=ST1
//*
//* JOB SUBMITTED BY CKTIBAT.
//* PROCESS: MQT1.LOCAL.QUEUE
//* TRIGGERING Q: MQT1.LOCAL.QUEUE
//BTACLIB JCLLIB [EMAIL PROTECTED]
//S1 EXEC PROC=MQEX702B
/*EOF
1 //J7900027 JOB J7211ZZRJB12345678,'P PPOTKAY X77906',
// MSGLEVEL=1,MSGCLASS=H,[EMAIL PROTECTED]
//*MAIN CLASS=DB2A
//*MAIN SYSTEM=ST1
//*
//* JOB SUBMITTED BY CKTIBAT.
//* PROCESS: MQT1.LOCAL.QUEUE
//* TRIGGERING Q: MQT1.LOCAL.QUEUE
2 //BTACLIB JCLLIB [EMAIL PROTECTED]
3 //S1 EXEC PROC=MQEX702B
IEFC025I INSTALLATION MODIFIED JCL - // JOBCARD
ERROR-5 **
and the error messages
STMT NO. MESSAGE
3 IEFC042I JOB CANCELLED BY INSTALLATION EXIT - IEFUJV
3 IEFC029I EXIT ERROR: IEFUJV ATTEMPTED TO INSERT JCL COMMENTS -
STATEM
Re: MA12 Batch triggering
I believe there was a member of the NJ MQ User's Group who had written a TSO
method described below. I went to the site but did not see it.
On www.google.com a search brought up a TSO method (looks like PL1) on topic
at the following site:
http://www.mainframeweek.com/code/showcode.php/0014/mw14mq1.txt
-Original Message-
From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2003 3:33 PM
To: [EMAIL PROTECTED]
Subject: Re: MA12 Batch triggering
No, I never had it working. I mean, I had the job itself working A-OK when I
submitted SUB from inside the member. But someone told me I could not just
submit a JCL member like this from a process definition. I had to change it
to a proc, which are the changes I made below and the reason I posted the
first few lines of the member MQEX702B. I think I made the correct changed
to it to make it a proc (removed the job card, added PROC to the first line
and added PEND to the end)
Actually I wish I was able to make this work by simply be able to do
something like TSO SUB @TSMT00.MQ.CNTL(MQEX702B) in the proccess definition,
but I guess this is not possible. (This is assuming MQEX702B was back in its
original state when it could be run standalaone by just submitting the
member.)
-Original Message-
From: Bullock, Rebecca (CSC) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2003 3:22 PM
To: [EMAIL PROTECTED]
Subject: Re: MA12 Batch triggering
Peter, I don't use MA12 and we're not a JES3 shop, but was it working before
you shut it down? Could it be that a different userid is now associated with
it, and that userid is causing it to fail in the SMF exit? I'd talk to the
SMF exit person and see what would trigger a failure and take it from there.
-- Rebecca
-Original Message-
From: Hill, Dave [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2003 3:07 PM
To: [EMAIL PROTECTED]
Subject: Re: MA12 Batch triggering
Peter -
Process name and content
EMAIL.SMTP.MSGS
USED TO PROCESS MAINFRAME EMAI
TO USERS IN
MVS
//*S010EXE EXEC PGM=MQMAIL
//EMAIL DD SYSOUT=(Q,SMTP)
//SYSOUT DD SYSOUT=*
//UTLITYF DD DUMMY
-Original Message-
From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2003 2:45 PM
To: [EMAIL PROTECTED]
Subject: MA12 Batch triggering
The trigger monitor is up and running. I can send the shutdown message to it
via CKTIEND and it shuts down as expected. So I start it back up and try to
drop a message into the triggered queue. The triggered queue name is
MQT1.LOCAL.QUEUE and the process definition is named MQT1.LOCAL.QUEUE as
well.
The problem is, the JCL it produces upon recieving a trigger message fails.
I suspect because my process definition is incorrect?
The JCL I would like to kick off is in @TSMT00.MQ.CNTL(MQEX702B). Here are
the first few lines of it:
01,//MQEX702B PROC
02,//**
03,//** THIS JCL WILL EXECUTE RN0722PC, WHICH CALLS RN0702PP, THE MQ *
04,//** WRAPPER FOR BATCH PROCESSING. *
05,//** IT ASSUMES THAT THE MA12 SUPPORT PAC WILL BE TRIGGERING IT*
06,//** THAT IS WHY THERE IS NO JOBCARD AT THE TOP. MA12 MAKES THE CARD
07,//**
08,//RN072201 EXEC PGM=DFSRRC00,REGION=9000K,
09,// PARM=(DLI,DSNMTV01,RF0001P1)
10,//STEPLIB DD DSN=SYS1.SCSQANLE,DISP=SHR
Here is the process def. (I have tried about 800 different variations, this
is the latest):
DEF PROCESS(MQT1.LOCAL.QUEUE)
APPLICID('//BTACLIB JCLLIB [EMAIL PROTECTED]')
USERDATA('//S1 EXEC PROC=MQEX702B)
APPLTYPE('z/OS')
Here is the output of the job as it fails bb interpretor:
//J7900027 JOB J7211ZZRJB12345678,'P PPOTKAY X77906', *
// MSGLEVEL=1,MSGCLASS=H,[EMAIL PROTECTED]
//*MAIN CLASS=DB2A
//*MAIN SYSTEM=ST1
//*
//* JOB SUBMITTED BY CKTIBAT.
//* PROCESS: MQT1.LOCAL.QUEUE
//* TRIGGERING Q: MQT1.LOCAL.QUEUE
//BTACLIB JCLLIB [EMAIL PROTECTED]
//S1 EXEC PROC=MQEX702B
/*EOF
1 //J7900027 JOB J7211ZZRJB12345678,'P PPOTKAY X77906',
// MSGLEVEL=1,MSGCLASS=H,[EMAIL PROTECTED]
//*MAIN CLASS=DB2A
//*MAIN SYSTEM=ST1
//*
//* JOB SUBMITTED BY CKTIBAT.
//* PROCESS: MQT1.LOCAL.QUEUE
//* TRIGGERING Q: MQT1.LOCAL.QUEUE
2 //BTACLIB JCLLIB [EMAIL PROTECTED]
3 //S1 EXEC PROC=MQEX702B
IEFC025I INSTALLATION MODIFIED JCL - // JOBCARD
ERROR-5 **
and the error messages
STMT NO. MESSAGE
3 IEFC042I JOB CANCELLED BY INSTALLATION EXIT - IEFUJV
3 IEFC029I EXIT ERROR: IEFUJV ATTEMPTED TO INSERT JCL COMMENTS -
STATEM
3 IEFC607I JOB HAS NO STEPS
Peter Potkay
MQSeries Specialist
The Hartford Financial Services
[EMAIL PROTECTED]
x77906
IBM MQSeries Certified
This communication, including attachments, is for the exclusive use of
Re: MA12 Batch triggering
I would love to do the simple one Rog.
If I put @TSMT00.MQ.CNTL(MQEX702V) in USERDATA, but what would I put in
APPLCID?
This assume MQEX702V can be submitted stand alone.
-Original Message-
From: Roger Lacroix [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2003 4:11 PM
To: [EMAIL PROTECTED]
Subject: Re: MA12 Batch triggering
Hi,
Over the years, I have written a couple of trigger monitors to submit JCL
(with
a JOB card) rather than a PROC.
It is really straight forward. You can make a simple one or a more robust
trigger monitor. The simple one would have the PDS(member) in the USERDATA
field. For the complex one, you would just specify the member and then the
program would search a list of PDS(s) for the member.
Either way, the program will read the member then submit it to the INTRDR
(Internal Reader).
I wish I could post the code but I can't (it's not mine).
later
Roger...
Quoting Potkay, Peter M (PLC, IT) [EMAIL PROTECTED]:
No, I never had it working. I mean, I had the job itself working A-OK when
I
submitted SUB from inside the member. But someone told me I could not just
submit a JCL member like this from a process definition. I had to change
it
to a proc, which are the changes I made below and the reason I posted the
first few lines of the member MQEX702B. I think I made the correct changed
to it to make it a proc (removed the job card, added PROC to the first
line
and added PEND to the end)
Actually I wish I was able to make this work by simply be able to do
something like TSO SUB @TSMT00.MQ.CNTL(MQEX702B) in the proccess
definition,
but I guess this is not possible. (This is assuming MQEX702B was back in
its
original state when it could be run standalaone by just submitting the
member.)
-Original Message-
From: Bullock, Rebecca (CSC) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2003 3:22 PM
To: [EMAIL PROTECTED]
Subject: Re: MA12 Batch triggering
Peter, I don't use MA12 and we're not a JES3 shop, but was it working
before
you shut it down? Could it be that a different userid is now associated
with
it, and that userid is causing it to fail in the SMF exit? I'd talk to the
SMF exit person and see what would trigger a failure and take it from
there.
-- Rebecca
-Original Message-
From: Hill, Dave [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2003 3:07 PM
To: [EMAIL PROTECTED]
Subject: Re: MA12 Batch triggering
Peter -
Process name and content
EMAIL.SMTP.MSGS
USED TO PROCESS MAINFRAME EMAI
TO USERS IN
MVS
//*S010EXE EXEC PGM=MQMAIL
//EMAIL DD SYSOUT=(Q,SMTP)
//SYSOUT DD SYSOUT=*
//UTLITYF DD DUMMY
-Original Message-
From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2003 2:45 PM
To: [EMAIL PROTECTED]
Subject: MA12 Batch triggering
The trigger monitor is up and running. I can send the shutdown message to
it
via CKTIEND and it shuts down as expected. So I start it back up and try
to
drop a message into the triggered queue. The triggered queue name is
MQT1.LOCAL.QUEUE and the process definition is named MQT1.LOCAL.QUEUE as
well.
The problem is, the JCL it produces upon recieving a trigger message
fails.
I suspect because my process definition is incorrect?
The JCL I would like to kick off is in @TSMT00.MQ.CNTL(MQEX702B). Here are
the first few lines of it:
01,//MQEX702B PROC
02,//**
03,//** THIS JCL WILL EXECUTE RN0722PC, WHICH CALLS RN0702PP, THE MQ
*
04,//** WRAPPER FOR BATCH PROCESSING.
*
05,//** IT ASSUMES THAT THE MA12 SUPPORT PAC WILL BE TRIGGERING IT
*
06,//** THAT IS WHY THERE IS NO JOBCARD AT THE TOP. MA12 MAKES THE
CARD
07,//**
08,//RN072201 EXEC PGM=DFSRRC00,REGION=9000K,
09,// PARM=(DLI,DSNMTV01,RF0001P1)
10,//STEPLIB DD DSN=SYS1.SCSQANLE,DISP=SHR
Here is the process def. (I have tried about 800 different variations,
this
is the latest):
DEF PROCESS(MQT1.LOCAL.QUEUE)
APPLICID('//BTACLIB JCLLIB [EMAIL PROTECTED]')
USERDATA('//S1 EXEC PROC=MQEX702B)
APPLTYPE('z/OS')
Here is the output of the job as it fails bb interpretor:
//J7900027 JOB J7211ZZRJB12345678,'P PPOTKAY X77906', *
// MSGLEVEL=1,MSGCLASS=H,[EMAIL PROTECTED]
//*MAIN CLASS=DB2A
//*MAIN SYSTEM=ST1
//*
//* JOB SUBMITTED BY CKTIBAT.
//* PROCESS: MQT1.LOCAL.QUEUE
//* TRIGGERING Q: MQT1.LOCAL.QUEUE
//BTACLIB JCLLIB [EMAIL PROTECTED]
//S1 EXEC PROC=MQEX702B
/*EOF
1 //J7900027 JOB J7211ZZRJB12345678,'P PPOTKAY X77906',
// MSGLEVEL=1,MSGCLASS=H,[EMAIL PROTECTED]
//*MAIN CLASS=DB2A
//*MAIN SYSTEM=ST1
//*
//* JOB SUBMITTED BY CKTIBAT.
//* PROCESS: MQT1.LOCAL.QUEUE
//* TRIGGERING Q: MQT1.LOCAL.QUEUE
2 //BTACLIB JCLLIB [EMAIL PROTECTED]
Re: SOC 7 error while displaying S99 Fields in COBOL (WMQI 2.1)
The INTEGERSIGNED field (if memory serves me correctly) is treated as a Zoned Decimal field. In other words, the low order byte will have the high order 4 bits set to C for positive and D for negative numbers (system preferred signs). I can't remember if it accepts A and F for positive and B for negative as well. Packed decimal arithmetic will accept any of the A through F bit configurations in the sign position. It sounds like what is getting passed across and converted in the sign position on the host side is resulting in a bit configuration of 0 through 9 accounting for the data exception (S0C7). Cheers... Jim Nuckolls Juni Per wrote: Hi , I have the following COBOL copy book imported into WMQI(2.1 WinNT) 06 TESTVARIABLES. 07 TESTINPUT. 08 INTEGERNOSIGN PIC 99. 08 INTEGERSIGNED PIC S99. 08 DECIMALNOSIGN PIC 99V99. 08 DECIMALSIGNED PIC S99V99. 08 COMP3NOSIGN PIC 99V99 COMP-3. 08 COMP3SIGNED PIC S99V99 COMP-3. I assign the following values to them in a compute node SET OutputRoot.MRM.INTEGERNOSIGN = 12; SET OutputRoot.MRM.INTEGERSIGNED = -12; SET OutputRoot.MRM.DECIMALNOSIGN = 1234; SET OutputRoot.MRM.DECIMALSIGNED = -1234; SET OutputRoot.MRM.COMP3NOSIGN = 5678; SET OutputRoot.MRM.COMP3SIGNED = -678; Now when a COBOL program on mainframe reads this message and moves into the same copybook and displays the fields , I get an SOC 7 error for the S99 field.WHat could be the problem. Pls respond. THanks in ADvance Do you Yahoo!? SBC Yahoo! DSL http://pa.yahoo.com/*http://rd.yahoo.com/evt=1207/*http://promo.yahoo.com/sbc/ - Now only $29.95 per month! Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: MA12 Batch triggering
Humm,
I think you misunderstood me. I meant that you stop using MA12 and write your
own trigger monitor program (C or PLI or COBOL). Your new trigger monitor
program would use the APPLCID and/or USERDATA as they wish.
But most companies don't want to have a custom written trigger monitor. Plus
you would need a compiler / linker on the mainframe.
If you want help writing the code, let me know.
later
Roger...
Quoting Potkay, Peter M (PLC, IT) [EMAIL PROTECTED]:
I would love to do the simple one Rog.
If I put @TSMT00.MQ.CNTL(MQEX702V) in USERDATA, but what would I put in
APPLCID?
This assume MQEX702V can be submitted stand alone.
-Original Message-
From: Roger Lacroix [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2003 4:11 PM
To: [EMAIL PROTECTED]
Subject: Re: MA12 Batch triggering
Hi,
Over the years, I have written a couple of trigger monitors to submit JCL
(with
a JOB card) rather than a PROC.
It is really straight forward. You can make a simple one or a more robust
trigger monitor. The simple one would have the PDS(member) in the USERDATA
field. For the complex one, you would just specify the member and then the
program would search a list of PDS(s) for the member.
Either way, the program will read the member then submit it to the INTRDR
(Internal Reader).
I wish I could post the code but I can't (it's not mine).
later
Roger...
Quoting Potkay, Peter M (PLC, IT) [EMAIL PROTECTED]:
No, I never had it working. I mean, I had the job itself working A-OK when
I
submitted SUB from inside the member. But someone told me I could not just
submit a JCL member like this from a process definition. I had to change
it
to a proc, which are the changes I made below and the reason I posted the
first few lines of the member MQEX702B. I think I made the correct changed
to it to make it a proc (removed the job card, added PROC to the first
line
and added PEND to the end)
Actually I wish I was able to make this work by simply be able to do
something like TSO SUB @TSMT00.MQ.CNTL(MQEX702B) in the proccess
definition,
but I guess this is not possible. (This is assuming MQEX702B was back in
its
original state when it could be run standalaone by just submitting the
member.)
-Original Message-
From: Bullock, Rebecca (CSC) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2003 3:22 PM
To: [EMAIL PROTECTED]
Subject: Re: MA12 Batch triggering
Peter, I don't use MA12 and we're not a JES3 shop, but was it working
before
you shut it down? Could it be that a different userid is now associated
with
it, and that userid is causing it to fail in the SMF exit? I'd talk to the
SMF exit person and see what would trigger a failure and take it from
there.
-- Rebecca
-Original Message-
From: Hill, Dave [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2003 3:07 PM
To: [EMAIL PROTECTED]
Subject: Re: MA12 Batch triggering
Peter -
Process name and content
EMAIL.SMTP.MSGS
USED TO PROCESS MAINFRAME EMAI
TO USERS IN
MVS
//*S010EXE EXEC PGM=MQMAIL
//EMAIL DD SYSOUT=(Q,SMTP)
//SYSOUT DD SYSOUT=*
//UTLITYF DD DUMMY
-Original Message-
From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2003 2:45 PM
To: [EMAIL PROTECTED]
Subject: MA12 Batch triggering
The trigger monitor is up and running. I can send the shutdown message to
it
via CKTIEND and it shuts down as expected. So I start it back up and try
to
drop a message into the triggered queue. The triggered queue name is
MQT1.LOCAL.QUEUE and the process definition is named MQT1.LOCAL.QUEUE as
well.
The problem is, the JCL it produces upon recieving a trigger message
fails.
I suspect because my process definition is incorrect?
The JCL I would like to kick off is in @TSMT00.MQ.CNTL(MQEX702B). Here are
the first few lines of it:
01,//MQEX702B PROC
02,//**
03,//** THIS JCL WILL EXECUTE RN0722PC, WHICH CALLS RN0702PP, THE MQ
*
04,//** WRAPPER FOR BATCH PROCESSING.
*
05,//** IT ASSUMES THAT THE MA12 SUPPORT PAC WILL BE TRIGGERING IT
*
06,//** THAT IS WHY THERE IS NO JOBCARD AT THE TOP. MA12 MAKES THE
CARD
07,//**
08,//RN072201 EXEC PGM=DFSRRC00,REGION=9000K,
09,// PARM=(DLI,DSNMTV01,RF0001P1)
10,//STEPLIB DD DSN=SYS1.SCSQANLE,DISP=SHR
Here is the process def. (I have tried about 800 different variations,
this
is the latest):
DEF PROCESS(MQT1.LOCAL.QUEUE)
APPLICID('//BTACLIB JCLLIB [EMAIL PROTECTED]')
USERDATA('//S1 EXEC PROC=MQEX702B)
APPLTYPE('z/OS')
Here is the output of the job as it fails bb interpretor:
//J7900027 JOB J7211ZZRJB12345678,'P PPOTKAY X77906', *
//
Re: MA12 Batch triggering
Thanks Roger, Im gonna give this another shot tomorrow. I am probably missing somethin really small and insignificant. What I was able to get done now is that I have a member that works fine when I manually sub it. I cut and paste its JobCard out and stuck it into MA12's JobCard parameter. MA12 now builds the dynamic JCL by putting the header at the start of this new JCL. All I gotta figure out know is how to get 1 or 2 lines of JCL code that will call out to another set of JCL and then put that info into the MQ process definition. Its not even an MQ issue at this point. I would have the same problem whether I use MA12 or write my own trigger monitor. The crux of the problem is how do I properly call JCL member B from (dynamically-built-by-MA12) JCL member A? I gotta go bug the mainframe gurus here tomorrow. (Our mainframe MQ expert is on vaca this week, so I inherited this task). They'll probably add a period or a / to my JCL and it will work all of a sudden (that always seems to be the nature of the JCL errors anyway - its the stupidest thing that is missing.) That reminds me, go to mp3.com and do a search on The System Administrator Song. Funny. -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 27, 2003 4:55 PM To: [EMAIL PROTECTED] Subject: Re: MA12 Batch triggering Humm, I think you misunderstood me. I meant that you stop using MA12 and write your own trigger monitor program (C or PLI or COBOL). Your new trigger monitor program would use the APPLCID and/or USERDATA as they wish. But most companies don't want to have a custom written trigger monitor. Plus you would need a compiler / linker on the mainframe. If you want help writing the code, let me know. later Roger... Quoting Potkay, Peter M (PLC, IT) [EMAIL PROTECTED]: I would love to do the simple one Rog. If I put @TSMT00.MQ.CNTL(MQEX702V) in USERDATA, but what would I put in APPLCID? This assume MQEX702V can be submitted stand alone. -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 27, 2003 4:11 PM To: [EMAIL PROTECTED] Subject: Re: MA12 Batch triggering Hi, Over the years, I have written a couple of trigger monitors to submit JCL (with a JOB card) rather than a PROC. It is really straight forward. You can make a simple one or a more robust trigger monitor. The simple one would have the PDS(member) in the USERDATA field. For the complex one, you would just specify the member and then the program would search a list of PDS(s) for the member. Either way, the program will read the member then submit it to the INTRDR (Internal Reader). I wish I could post the code but I can't (it's not mine). later Roger... Quoting Potkay, Peter M (PLC, IT) [EMAIL PROTECTED]: No, I never had it working. I mean, I had the job itself working A-OK when I submitted SUB from inside the member. But someone told me I could not just submit a JCL member like this from a process definition. I had to change it to a proc, which are the changes I made below and the reason I posted the first few lines of the member MQEX702B. I think I made the correct changed to it to make it a proc (removed the job card, added PROC to the first line and added PEND to the end) Actually I wish I was able to make this work by simply be able to do something like TSO SUB @TSMT00.MQ.CNTL(MQEX702B) in the proccess definition, but I guess this is not possible. (This is assuming MQEX702B was back in its original state when it could be run standalaone by just submitting the member.) -Original Message- From: Bullock, Rebecca (CSC) [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 27, 2003 3:22 PM To: [EMAIL PROTECTED] Subject: Re: MA12 Batch triggering Peter, I don't use MA12 and we're not a JES3 shop, but was it working before you shut it down? Could it be that a different userid is now associated with it, and that userid is causing it to fail in the SMF exit? I'd talk to the SMF exit person and see what would trigger a failure and take it from there. -- Rebecca -Original Message- From: Hill, Dave [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 27, 2003 3:07 PM To: [EMAIL PROTECTED] Subject: Re: MA12 Batch triggering Peter - Process name and content EMAIL.SMTP.MSGS USED TO PROCESS MAINFRAME EMAI TO USERS IN MVS //*S010EXE EXEC PGM=MQMAIL //EMAIL DD SYSOUT=(Q,SMTP) //SYSOUT DD SYSOUT=* //UTLITYF DD DUMMY -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 27, 2003 2:45 PM To: [EMAIL PROTECTED] Subject: MA12 Batch triggering The trigger monitor is up and running. I can send the shutdown message to it via CKTIEND and it shuts down as expected. So I start it back up and try to drop a message into the triggered queue. The triggered queue name is
Re: MA12 Batch triggering
(See attached file: temp.txt)
Are you sure your setup is correct. Here is how we do it. Also you
mentioned a PEND at the end of the PROC are you sure you need this since
the proc is cataloged not instream.Please note the space between '//
and exec' we do not user the userdata field at all
TEST process definition
DEFINE PROCESS('PR.H_HAL_010_BILL_OF_LADING.000') +
DESCR('Process for batch job TH1MPU09') +
APPLTYPE(MVS) +
APPLICID('// EXEC TH1MPU09') REPLACE
We do the following in our test environment.
TEST Proc
//TH1MPU09 PROC
//*
//STEP010 EXEC PGM=IEBGENER
//SYSINDD DUMMY
//SYSOUT DD SYSOUT=X
//SYSUT1 DD DSN=TP.HAL.NEW.MINIJCL(TH1MPU09),DISP=SHR
//SYSUT2 DD SYSOUT=(A,INTRDR)
//SYSPRINT DD SYSOUT=X
//
In production we execute a proc which adds a production job to our
production schedule for immediate release.
PRODUCTION
DEFINE PROCESS('PR.H_HAL_010_BILL_OF_LADING.000') +
DESCR('Process for batch job H1MPU09P') +
APPLTYPE(MVS) +
APPLICID('// EXEC CU01AA,MEM=H1MPU09P') REPLACE
here is the PRODUCTION proc CU01AA
//CU01AA PROC MEM=
//* LAST UPDATED BY
//
//* ZEKESET STEP TO COMMUNICATE COMMAND REQUEST TO SCHEDULER - ZEKE *
//
//CU01AA10 EXEC PGM=ZEKESET
//SYSOUT DD SYSOUT=M,DEST=CENTRAL
//SYSUDUMP DD SYSOUT=X,FCB=F800,DEST=CENTRAL
//SYSABEND DD SYSOUT=X,FCB=F800,DEST=CENTRAL
//SYSPRINT DD SYSOUT=M,FCB=F800,DEST=CENTRAL
//SYSIN DD DSN=HP.DPC.A2414(MEM),DISP=SHR
//*** END OF PROC
Roger Lacroix
[EMAIL PROTECTED]To: [EMAIL PROTECTED]
ALWARE.BIZ cc:
Sent by: MQSeries Subject: Re: MA12 Batch triggering
List
[EMAIL PROTECTED]
C.AT
08/27/2003 01:10 PM
Please respond to
MQSeries List
Hi,
Over the years, I have written a couple of trigger monitors to submit JCL
(with
a JOB card) rather than a PROC.
It is really straight forward. You can make a simple one or a more robust
trigger monitor. The simple one would have the PDS(member) in the USERDATA
field. For the complex one, you would just specify the member and then the
program would search a list of PDS(s) for the member.
Either way, the program will read the member then submit it to the INTRDR
(Internal Reader).
I wish I could post the code but I can't (it's not mine).
later
Roger...
Quoting Potkay, Peter M (PLC, IT) [EMAIL PROTECTED]:
No, I never had it working. I mean, I had the job itself working A-OK
when I
submitted SUB from inside the member. But someone told me I could not
just
submit a JCL member like this from a process definition. I had to change
it
to a proc, which are the changes I made below and the reason I posted the
first few lines of the member MQEX702B. I think I made the correct
changed
to it to make it a proc (removed the job card, added PROC to the first
line
and added PEND to the end)
Actually I wish I was able to make this work by simply be able to do
something like TSO SUB @TSMT00.MQ.CNTL(MQEX702B) in the proccess
definition,
but I guess this is not possible. (This is assuming MQEX702B was back in
its
original state when it could be run standalaone by just submitting the
member.)
-Original Message-
From: Bullock, Rebecca (CSC) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2003 3:22 PM
To: [EMAIL PROTECTED]
Subject: Re: MA12 Batch triggering
Peter, I don't use MA12 and we're not a JES3 shop, but was it working
before
you shut it down? Could it be that a different userid is now associated
with
it, and that userid is causing it to fail in the SMF exit? I'd talk to
the
SMF exit person and see what would trigger a failure and take it from
there.
-- Rebecca
-Original Message-
From: Hill, Dave [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2003 3:07 PM
To: [EMAIL PROTECTED]
Subject: Re: MA12 Batch triggering
Peter -
Process name and content
EMAIL.SMTP.MSGS
USED TO PROCESS MAINFRAME EMAI
TO USERS IN
MVS
//*S010EXE EXEC PGM=MQMAIL
//EMAIL DD SYSOUT=(Q,SMTP)
//SYSOUT DD SYSOUT=*
//UTLITYF DD DUMMY
-Original Message-
From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2003 2:45 PM
To: [EMAIL PROTECTED]
Subject: MA12 Batch triggering
The trigger monitor is up and running. I can send the shutdown message to
it
via CKTIEND and it shuts down as expected. So I start it back up and try
to
drop a message into the triggered queue. The triggered queue name is
MQT1.LOCAL.QUEUE and the process definition is named MQT1.LOCAL.QUEUE as
well.
The problem is, the JCL it produces upon recieving a trigger message
BIP0014 WMQI v2.1
Does anybody know how to resolve a BIP0014E errror. I am trying to remove a message from my message set and I keep get this error. So, now I can not delete my message set because it claims that the specific message is checked out. Any insight is greatly appreciated. Thank you. Arg! 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
