Re: T-Rex distributed systems
Yes, shame on me -- I was too eager to show the shortest "Hello, World". I have not
been doing any REXX for about 13 years. At least this one
say Hello World
is probably the shortest one for the users who don't care much about missing commas
:-). I just wanted to capitalize on this nice manner of REXX to default the variables
to the strings equal to their names. Such a nice idea for any interpreter but AFAIK
only REXX got it! And the word 'say' seems to be the shortest reasonable verb for
writing to stdout. I have been using it as a function name all the time while coding
in other languagues since the old days.
Sorry for the off-topic.
Pavel
Russell Finn
<[EMAIL PROTECTED]To: [EMAIL PROTECTED]
IBM.COM> cc:
Sent by: MQSeriesSubject: Re: T-Rex distributed systems
List
<[EMAIL PROTECTED]
n.AC.AT>
02/04/2004 09:17
AM
Please respond to
MQSeries List
Almost ,but not quite that simple:
say hello,world
Oooops ! ... try again. Unexpected ",", ")", or "]"
You could have had:
say hello world
say 'hello, world'
Russell
Russell Finn
MQSeries System Test
[EMAIL PROTECTED]
Pavel Tolkachev <[EMAIL PROTECTED]>
Sent by: MQSeries List <[EMAIL PROTECTED]>
To:[EMAIL PROTECTED]
cc:
Subject:Re: T-Rex distributed systems
03/02/2004 13:22
Please respond to MQSeries List
And the shortest in the world "Hello, world" program. Just
say Hello, world
:-) Pavel
peter d
<[EMAIL PROTECTED]To: [EMAIL PROTECTED]
NE.NET> cc:
Sent by: MQSeriesSubject: Re: T-Rex distributed systems
List
<[EMAIL PROTECTED]
n.AC.AT>
02/02/2004 10:29
PM
Please respond to
MQSeries List
Rexx with PIPES ... was SO powerful !
We wrote connectors from Shadow Web, Enterprise Web, and Domino Go to
CICS/IMS/VSAM/DB2/etc with Rexx ... much faster than CGI, much more secure too.
/peter d.
-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of David C. Partridge
Sent: Monday, February 02, 2004 10:40 AM
To: [EMAIL PROTECTED]
Subject: Re: T-Rex distributed systems
Ah - fond memories. Whenever I'm faced with Unix shell scripts, DOS bat files,
or even (though to a much lesser degree) Perl scripts, I pine for Rexx - such power,
ease of use and flexibility.
Dave
--
This e-mail may contain confidential and/or privileged information. If you are not the
intended recipient (or have received this e-mail in error) please notify the sender
immediately and destroy this e-mail. Any unauthorized copying, disclosure or
distribution of the material in this e-mail is strictly forbidden.
In
Re: T-Rex distributed systems
Almost ,but not quite that simple: say hello,world Oooops ! ... try again. Unexpected ",", ")", or "]" You could have had: say hello world say 'hello, world' Russell Russell Finn MQSeries System Test [EMAIL PROTECTED] Pavel Tolkachev <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 03/02/2004 13:22 Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: T-Rex distributed systems And the shortest in the world "Hello, world" program. Just say Hello, world :-) Pavel peter d <[EMAIL PROTECTED] To: [EMAIL PROTECTED] NE.NET> cc: Sent by: MQSeries Subject: Re: T-Rex distributed systems List <[EMAIL PROTECTED] n.AC.AT> 02/02/2004 10:29 PM Please respond to MQSeries List Rexx with PIPES ... was SO powerful ! We wrote connectors from Shadow Web, Enterprise Web, and Domino Go to CICS/IMS/VSAM/DB2/etc with Rexx ... much faster than CGI, much more secure too. /peter d. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of David C. Partridge Sent: Monday, February 02, 2004 10:40 AM To: [EMAIL PROTECTED] Subject: Re: T-Rex distributed systems Ah - fond memories. Whenever I'm faced with Unix shell scripts, DOS bat files, or even (though to a much lesser degree) Perl scripts, I pine for Rexx - such power, ease of use and flexibility. Dave -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: T-Rex distributed systems
David, the fun of using rexx2nrx in combination with Netrexx, let's you code in classic rexx and then generate java code(.class files) from it... during generation you can keep the .java sources, for when you 'leave'... :--))) Michael - Oorspronkelijk bericht - Van: "David C. Partridge" <[EMAIL PROTECTED]> Datum: dinsdag 3 februari 2004 om 10:08 uur Onderwerp: Re: T-Rex distributed systems > Thanks for that pointer - trouble is of course when you're on a > customersite ... > > Dave > > -Original Message- > From: MQSeries List [EMAIL PROTECTED] Behalf Of Roger > Lacroix > Sent: 02 February 2004 19:42 > To: [EMAIL PROTECTED] > Subject: Re: T-Rex distributed systems > > > Hi, > > I've got 2 words for you: Regina Rexx. > > Regina Rexx is Mark Hessling's FREE Rexx interpreter for a variety of > platforms. > > Regina Rexx is currently supported on: most Unix platforms (Linux, > FreeBSD,Solaris, AIX, HP-UX), OS/2, eCS, DOS, Win9x/Me/NT/2k/XP, > Amiga, AROS, QNX, > BeOS, MacOS X, EPOC32, AtheOS, OpenVMS and OpenEdition. > > Regina Rexx's home page is at: > http://regina-rexx.sourceforge.net/index.html > > Regards, > Roger Lacroix > 416-566-7307 > Capitalware Inc. > http://www.capitalware.biz > > > Quoting "David C. Partridge" <[EMAIL PROTECTED]>: > > > Ah - fond memories. Whenever I'm faced with Unix shell > scripts, DOS bat > > files, or even (though to a much lesser degree) Perl scripts, I > pine for > > Rexx - such power, ease of use and flexibility. > > > > Dave > > > > Instructions for managing your mailing list subscription are > provided in > the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > Instructions for managing your mailing list subscription are > provided in > the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: T-Rex distributed systems
And the shortest in the world "Hello, world" program. Just
say Hello, world
:-) Pavel
peter d
<[EMAIL PROTECTED]To: [EMAIL PROTECTED]
NE.NET> cc:
Sent by: MQSeries Subject: Re: T-Rex distributed systems
List
<[EMAIL PROTECTED]
n.AC.AT>
02/02/2004 10:29
PM
Please respond to
MQSeries List
Rexx with PIPES ... was SO powerful !
We wrote connectors from Shadow Web, Enterprise Web, and Domino Go to
CICS/IMS/VSAM/DB2/etc with Rexx ... much faster than CGI, much more secure too.
/peter d.
-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of David C. Partridge
Sent: Monday, February 02, 2004 10:40 AM
To: [EMAIL PROTECTED]
Subject: Re: T-Rex distributed systems
Ah - fond memories. Whenever I'm faced with Unix shell scripts, DOS bat files,
or even (though to a much lesser degree) Perl scripts, I pine for Rexx - such power,
ease of use and flexibility.
Dave
--
This e-mail may contain confidential and/or privileged information. If you are not the
intended recipient (or have received this e-mail in error) please notify the sender
immediately and destroy this e-mail. Any unauthorized copying, disclosure or
distribution of the material in this e-mail is strictly forbidden.
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: T-Rex distributed systems
Thanks for that pointer - trouble is of course when you're on a customer site ... Dave -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Roger Lacroix Sent: 02 February 2004 19:42 To: [EMAIL PROTECTED] Subject: Re: T-Rex distributed systems Hi, I've got 2 words for you: Regina Rexx. Regina Rexx is Mark Hessling's FREE Rexx interpreter for a variety of platforms. Regina Rexx is currently supported on: most Unix platforms (Linux, FreeBSD, Solaris, AIX, HP-UX), OS/2, eCS, DOS, Win9x/Me/NT/2k/XP, Amiga, AROS, QNX, BeOS, MacOS X, EPOC32, AtheOS, OpenVMS and OpenEdition. Regina Rexx's home page is at: http://regina-rexx.sourceforge.net/index.html Regards, Roger Lacroix 416-566-7307 Capitalware Inc. http://www.capitalware.biz Quoting "David C. Partridge" <[EMAIL PROTECTED]>: > Ah - fond memories. Whenever I'm faced with Unix shell scripts, DOS bat > files, or even (though to a much lesser degree) Perl scripts, I pine for > Rexx - such power, ease of use and flexibility. > > Dave > Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: T-Rex distributed systems
Rexx with PIPES ... was SO powerful ! We wrote connectors from Shadow Web, Enterprise Web, and Domino Go to CICS/IMS/VSAM/DB2/etc with Rexx ... much faster than CGI, much more secure too. /peter d. -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of David C. PartridgeSent: Monday, February 02, 2004 10:40 AMTo: [EMAIL PROTECTED]Subject: Re: T-Rex distributed systems Ah - fond memories. Whenever I'm faced with Unix shell scripts, DOS bat files, or even (though to a much lesser degree) Perl scripts, I pine for Rexx - such power, ease of use and flexibility. Dave
Re: T-Rex distributed systems
Hi, I've got 2 words for you: Regina Rexx. Regina Rexx is Mark Hessling's FREE Rexx interpreter for a variety of platforms. Regina Rexx is currently supported on: most Unix platforms (Linux, FreeBSD, Solaris, AIX, HP-UX), OS/2, eCS, DOS, Win9x/Me/NT/2k/XP, Amiga, AROS, QNX, BeOS, MacOS X, EPOC32, AtheOS, OpenVMS and OpenEdition. Regina Rexx's home page is at: http://regina-rexx.sourceforge.net/index.html Regards, Roger Lacroix 416-566-7307 Capitalware Inc. http://www.capitalware.biz Quoting "David C. Partridge" <[EMAIL PROTECTED]>: > Ah - fond memories. Whenever I'm faced with Unix shell scripts, DOS bat > files, or even (though to a much lesser degree) Perl scripts, I pine for > Rexx - such power, ease of use and flexibility. > > Dave > Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: T-Rex distributed systems
Ah - fond memories. Whenever I'm faced with Unix shell scripts, DOS bat files, or even (though to a much lesser degree) Perl scripts, I pine for Rexx - such power, ease of use and flexibility. Dave
Re: T-Rex distributed systems
In case anyone cares about REXX, here's some code that I put together years agoand it still works !!!
/* REXX */
/* SYSNAME - GET MVS SYSTEM NAME. IF CALLED AS COMMAND, DISPLAY SYSTEM NAME
IF CALLED AS A FUNC OR SUB, RETURN NAME */
/* ADDRS ARE BIG DECIMAL NUMBERS */
NUMERIC DIGITS 20
/* CVT ADDRESS */
LOC = STORAGE("10",4)
/* ADDR SYS NAME */
LOC = D2X( C2D(LOC) + X2D("154") )
/* GET 4 CHARACTER SYSTEM ID */
SYSID = STORAGE(LOC,4)
PARSE SOURCE . HOWCALLED .
IF HOWCALLED = "COMMAND" THEN
SAY "SYSTEM ID:" SYSID
ELSE RETURN SYSID
Enjoy!
Cheers,
Art
Arthur C. Schanz
Operating Systems Programmer I. - Specialist
Federal Reserve Information Technology
Distributed Systems Engineering
[EMAIL PROTECTED]
Roger Lacroix <[EMAIL PROTECTED]>
Sent by: MQSeries List <[EMAIL PROTECTED]>
01/29/2004 05:29 PM
Please respond to MQSeries List
To: [EMAIL PROTECTED]
cc:
Subject: Re: T-Rex distributed systems
Hi,
Basically, you want to determine what LPAR (I think in terms of MVS!!!) the
code is running on?
Wow, I had to really scratch my head on this one - its been awhile. :)
It took me a while to find my dinosaur suit; it was hiding in the back of the
closet. A little tight, but it still fits. (I'm not sure if I should be happy
or sad!!!)
Warning: For non-mainframe people you can delete this message right now!!
(Quick, look away because here comes some assembler code!!!)
Here's how I would do it in assembler:
* - - - - - - - - - - - - - - - - - - - - - - - -
* Get then set system id
* - - - - - - - - - - - - - - - - - - - - - - - -
USING PSA,0
L R4,FLCCVT R4 -> CVT
USING CVT,R4 .
L R4,CVTSMCA R4 -> SMCA
USING SMCABASE,R4 .
MVC SYSID,SMCASID get system id
DROP R4
*
*
SYSID DS CL4
For those modern mainframe people (if you can call us that!!!) who do C on the
mainframe, here is a C code snippet:
First the defines:
/*---*
* Pointer to the MVS PSA control block *
*---*/
#define PSA_PTR ( 0 )
/*---*
* Pointer to the MVS CVT control block *
*---*/
#define CVT_PTR ( * (void * *) ( (char *) PSA_PTR + 16) )
/*---*
* Pointer to the MVS SMCA control block *
*---*/
#define SMCA_PTR ( * (char * *) ( (char *) CVT_PTR + 196) )
/*---*
* Pointer to the SMF System Id *
*---*/
#define SMF_SYSID_PTR ( (char *) SMCA_PTR + 16 )
/**/
/* Now copy it from the control block to our variable */
/**/
memcpy( SysId, SMF_SYSID_PTR, 4);
Well, i hope that helped.
Regards,
Roger Lacroix
Capitalware Inc.
http://www.capitalware.biz
Quoting Dave Adam <[EMAIL PROTECTED]>:
> I must not be explaining this right
>
> our production QMGR's are on another pair of ZOS images and are called
> P001 and P002
>
> our test machine has 2 cloned QMGR's that replicate production on a
> different pair of ZOS images D001 and D002
>
> our development brainstorming test QMGR's are on the same pair of test
> machine QMGR's and they are called M001 and M002
>
> SYSPlex Distributor will put
Re: T-Rex distributed systems
I am a FORTRAN person myself so thanks to Curt here is the PL/I code Hi Dave, I am writing directly to you since I sometimes have difficulty posting to the list. The following PL/I code will return the System ID to the calling application. If you have a PL/I compiler available, then just compile and use it as is. If no PL/I compiler is available, it at least shows you the control block navigation. Most of our code base is PL/I but perhaps writing this in assembly language would make for a more generic multiple-use component. Regards, Curt MQSYSID: PROCEDURE(SYSID) OPTIONS(REENTRANT) REORDER; DECLARE SYSID CHAR(08); DECLARE ADDR BUILTIN; DECLARE GROUND_ZERO FIXED BIN(31) STATIC INIT(0); DECLARE ADDR_0 POINTER BASED( ADDR(GROUND_ZERO) ); DECLARE 1 PSA BASED(ADDR_0), 2 FILLER CHAR(16), 2 CVT_PTR POINTER; DECLARE 1 CVT BASED(CVT_PTR), 2 FILLER CHAR(340), 2 SYS_ID CHAR(08); SYSID = CVT.SYS_ID; EOM: END MQSYSID; Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] A lone amateur built the Ark. A large group of professionals built the Titanic --
Re: T-Rex distributed systems
since the list has afforded me so many ways to approach the same results (especially getting to clusters through QSG's) I thought I would give the programmers the COBOL equivalent * 01 ZOS-CVT-P USAGE IS POINTER. 01 ZOS-CVT-P-N REDEFINES ZOS-CVT-P PIC S9(9) COMP. 01 ZOS-SYS-P USAGE IS POINTER. 01 ZOS-SYS-P-N REDEFINES ZOS-SYS-P PIC S9(9) COMP. * * - * LINKAGE SECTION. * - * 01 ZOS-CVT USAGE IS POINTER. 01 ZOS-CVT-N REDEFINES ZOS-CVT PIC S9(9) COMP. 01 ZOS-SYSNAME. 05 ZOS-SYS PIC X. 05 FILLER PIC XX. 05 ZOS-SYS-N PIC X. 05 FILLER PIC X(4). * * * * MOVE 16 TO ZOS-CVT-P-N. SET ADDRESS OF ZOS-CVT TO ZOS-CVT-P. COMPUTE ZOS-SYS-P-N = ZOS-CVT-N + 340. SET ADDRESS OF ZOS-SYSNAME TO ZOS-SYS-P. DISPLAY 'SYSNAME IS ' ZOS-SYSNAME. MOVE ZOS-SYS-N TO WPRM-QMGR-4. DISPLAY 'QMGR IS ' WPRM-QMGR. * Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] A lone amateur built the Ark. A large group of professionals built the Titanic -- Roger Lacroix <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 01/29/2004 04:29 PM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: T-Rex distributed systems Hi, Basically, you want to determine what LPAR (I think in terms of MVS!!!) the code is running on? Wow, I had to really scratch my head on this one - its been awhile. :) It took me a while to find my dinosaur suit; it was hiding in the back of the closet. A little tight, but it still fits. (I'm not sure if I should be happy or sad!!!) Warning: For non-mainframe people you can delete this message right now!! (Quick, look away because here comes some assembler code!!!) Here's how I would do it in assembler: * - - - - - - - - - - - - - - - - - - - - - - - - * Get then set system id * - - - - - - - - - - - - - - - - - - - - - - - - USING PSA,0 L R4,FLCCVT R4 -> CVT USING CVT,R4 . L R4,CVTSMCA R4 -> SMCA USING SMCABASE,R4 . MVC SYSID,SMCASID get system id DROP R4 * * SYSID DS CL4 For those modern mainframe people (if you can call us that!!!) who do C on the mainframe, here is a C code snippet: First the defines: /*---* * Pointer to the MVS PSA control block * *---*/ #define PSA_PTR ( 0 ) /*---* * Pointer to the MVS CVT control block * *---*/ #define CVT_PTR ( * (void * *) ( (char *) PSA_PTR + 16) ) /*---* * Pointer to the MVS SMCA control block * *---*/ #define SMCA_PTR ( * (char * *) ( (char *) CVT_PTR + 196) ) /*---* * Pointer to the SMF System Id * *---*/ #define SMF_SYSID_PTR ( (char *) SMCA_PTR + 16 ) /**/ /* Now copy it from the control block to our variable */ /**/ memcpy( SysId, SMF_SYSID_PTR, 4); Well, i hope that helped. Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting Dave Adam <[EMAIL PROTECTED]>: > I must not be explaining this right > > our production QMGR's
Re: T-Rex distributed systems
just keeps getting better we are in the process of implementing QSG's all our QMGR's will be associated with a shared queue in some fashion we should be able to test our cluster theory after that all we have to do is re-think our QSG names to align the sub-system QMGR's so we get to the right one thanks for the heads up Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] A lone amateur built the Ark. A large group of professionals built the Titanic -- "Lovett, Alan J" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 01/30/2004 03:19 AM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: T-Rex distributed systems Hi Dave, If your queue managers are defined in queue sharing groups, your MQCONN can be to the group name (e.g. M000). It doesn't matter if your application doesn't use any shared queues. Connecting to the group automatically connects you to the local queue manager. Jobs can thus run on any member of the sysplex. However, if you aren't into QSG's, other solutions are likely to be easier. Regards, Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Adiraju, Rao Sent: 29 January 2004 21:41 To: [EMAIL PROTECTED] Subject: Re: T-Rex distributed systems Luckily on z/OS only batch jobs/applications need to establish the connections to the Queue Managers (in CICS it's done at the CICS region level) and hence the need to know the QMGR name. This as suggested earlier, can be driven by a Dataset / Loadmodule or DB2 table. The sites that I have worked in the past are either put their QMGR names in a DB2 table (DB2 subsystem switching is done at the JCL level anyway) or put in a QSAM file and every MQ program is supposed to read a file using a standard DD name that provides the QMGR name. When the code gets migrated through SCLM phases, it used to pick up the appropriate subsystem or QSAM qualifiers for the environment. Regarding security, it was controlled by RACF / ACF2. Because most of the sites I have worked, batch user-ids in production are different from other environments including stress testing. Rao Adiraju WebSphere MQ Specialist The National Bank of NZ Ltd. Tel: +64-4-494 4299 Fax: +64-4-802 8509 Mbl: +64-211-216-116 From: Dave Adam [mailto:[EMAIL PROTECTED] Sent: 30 January 2004 10:05 AM To: [EMAIL PROTECTED] Subject: Re: T-Rex distributed systems I must not be explaining this right our production QMGR's are on another pair of ZOS images and are called P001 and P002 our test machine has 2 cloned QMGR's that replicate production on a different pair of ZOS images D001 and D002 our development brainstorming test QMGR's are on the same pair of test machine QMGR's and they are called M001 and M002 SYSPlex Distributor will put the iteration on one of the pairs (M001 or M002) the program has to determine on which ZOS image it is running to do the MQCONN Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] A lone amateur built the Ark. A large group of professionals built the Titanic -- Rick Tsujimoto <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 01/29/2004 02:15 PM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: T-Rex distributed systems Dave, Two things: 1. The apps should probably be getting the queue manager name form some external source, e.g. file, table, etc. 2. Test apps that attempt to connect to prod queue managers should probably be stopped by your security system, e.g. RACF, ACF2, ... Dave Adam <[EMAIL PROTECTED] To: [EMAIL PROTECTED] ERVALU.COM> cc: Sent by: Subject: Re: T-Rex distributed systems MQSeries List <[EMAIL PROTECTED] en.AC.AT> 01/29/2004 02:51 PM Please respond to MQSeries List the issue is with the playground M00n QMGR's if they fail to identify the M, then they will be in the clones of production Dave Adam Supervalu Home Office Project Specialist (
Re: T-Rex distributed systems
that's perfect Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] A lone amateur built the Ark. A large group of professionals built the Titanic -- Roger Lacroix <[EMAIL PROTECTED]> 01/29/2004 04:29 PM To: MQSeries List <[EMAIL PROTECTED]> cc: [EMAIL PROTECTED] Subject: Re: T-Rex distributed systems Hi, Basically, you want to determine what LPAR (I think in terms of MVS!!!) the code is running on? Wow, I had to really scratch my head on this one - its been awhile. :) It took me a while to find my dinosaur suit; it was hiding in the back of the closet. A little tight, but it still fits. (I'm not sure if I should be happy or sad!!!) Warning: For non-mainframe people you can delete this message right now!! (Quick, look away because here comes some assembler code!!!) Here's how I would do it in assembler: * - - - - - - - - - - - - - - - - - - - - - - - - * Get then set system id * - - - - - - - - - - - - - - - - - - - - - - - - USING PSA,0 L R4,FLCCVT R4 -> CVT USING CVT,R4 . L R4,CVTSMCA R4 -> SMCA USING SMCABASE,R4 . MVC SYSID,SMCASID get system id DROP R4 * * SYSID DS CL4 For those modern mainframe people (if you can call us that!!!) who do C on the mainframe, here is a C code snippet: First the defines: /*---* * Pointer to the MVS PSA control block * *---*/ #define PSA_PTR ( 0 ) /*---* * Pointer to the MVS CVT control block * *---*/ #define CVT_PTR ( * (void * *) ( (char *) PSA_PTR + 16) ) /*---* * Pointer to the MVS SMCA control block * *---*/ #define SMCA_PTR ( * (char * *) ( (char *) CVT_PTR + 196) ) /*---* * Pointer to the SMF System Id * *---*/ #define SMF_SYSID_PTR ( (char *) SMCA_PTR + 16 ) /**/ /* Now copy it from the control block to our variable */ /**/ memcpy( SysId, SMF_SYSID_PTR, 4); Well, i hope that helped. Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting Dave Adam <[EMAIL PROTECTED]>: > I must not be explaining this right > > our production QMGR's are on another pair of ZOS images and are called > P001 and P002 > > our test machine has 2 cloned QMGR's that replicate production on a > different pair of ZOS images D001 and D002 > > our development brainstorming test QMGR's are on the same pair of test > machine QMGR's and they are called M001 and M002 > > SYSPlex Distributor will put the iteration on one of the pairs (M001 or > M002) > > the program has to determine on which ZOS image it is running to do the > MQCONN > > Dave Adam > Supervalu Home Office > Project Specialist > (952) 828-4736 > [EMAIL PROTECTED] > > A lone amateur built the Ark. > A large group of professionals built the Titanic > -- > > > > > > Rick Tsujimoto <[EMAIL PROTECTED]> > Sent by: MQSeries List <[EMAIL PROTECTED]> > 01/29/2004 02:15 PM > Please respond to MQSeries List > &
Re: T-Rex distributed systems
Hi Dave, If your queue managers are defined in queue sharing groups, your MQCONN can be to the group name (e.g. M000). It doesn't matter if your application doesn't use any shared queues. Connecting to the group automatically connects you to the local queue manager. Jobs can thus run on any member of the sysplex. However, if you aren't into QSG's, other solutions are likely to be easier. Regards, Alan -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Adiraju, RaoSent: 29 January 2004 21:41To: [EMAIL PROTECTED]Subject: Re: T-Rex distributed systems Luckily on z/OS only batch jobs/applications need to establish the connections to the Queue Managers (in CICS it's done at the CICS region level) and hence the need to know the QMGR name. This as suggested earlier, can be driven by a Dataset / Loadmodule or DB2 table. The sites that I have worked in the past are either put their QMGR names in a DB2 table (DB2 subsystem switching is done at the JCL level anyway) or put in a QSAM file and every MQ program is supposed to read a file using a standard DD name that provides the QMGR name. When the code gets migrated through SCLM phases, it used to pick up the appropriate subsystem or QSAM qualifiers for the environment. Regarding security, it was controlled by RACF / ACF2. Because most of the sites I have worked, batch user-ids in production are different from other environments including stress testing. Rao Adiraju WebSphere MQ Specialist The National Bank of NZ Ltd. Tel: +64-4-494 4299 Fax: +64-4-802 8509 Mbl: +64-211-216-116 From: Dave Adam [mailto:[EMAIL PROTECTED] Sent: 30 January 2004 10:05 AMTo: [EMAIL PROTECTED]Subject: Re: T-Rex distributed systems I must not be explaining this right our production QMGR's are on another pair of ZOS images and are called P001 and P002 our test machine has 2 cloned QMGR's that replicate production on a different pair of ZOS images D001 and D002 our development brainstorming test QMGR's are on the same pair of test machine QMGR's and they are called M001 and M002 SYSPlex Distributor will put the iteration on one of the pairs (M001 or M002) the program has to determine on which ZOS image it is running to do the MQCONNDave AdamSupervalu Home OfficeProject Specialist(952) 828-4736[EMAIL PROTECTED]A lone amateur built the Ark. A large group of professionals built the Titanic-- Rick Tsujimoto <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 01/29/2004 02:15 PM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: T-Rex distributed systemsDave,Two things:1. The apps should probably be getting the queue manager name form someexternal source, e.g. file, table, etc.2. Test apps that attempt to connect to prod queue managers should probablybe stopped by your security system, e.g. RACF, ACF2, ... Dave Adam <[EMAIL PROTECTED] To: [EMAIL PROTECTED] ERVALU.COM> cc: Sent by: Subject: Re: T-Rex distributed systems MQSeries List <[EMAIL PROTECTED] en.AC.AT> 01/29/2004 02:51 PM Please respond to MQSeries Listthe issue is with the playground M00n QMGR'sif they fail to identify the M, then they will be in the clones ofproductionDave AdamSupervalu Home OfficeProject Specialist(952) 828-4736[EMAIL PROTECTED]A lone amateur built the Ark.A large group of professionals built the Titanic-- Rick Tsujimoto <[EMAIL PROTECTED]> To: Sent by: MQSeries List [EMAIL PROTECTED] <[EMAIL PROTECTED]> cc: Subject: Re: T-Rex distributed systems 01/29/2004 01:30 PM Please respond to MQSeries ListIf you simply want to connect to the default QMGR on each LPAR, you couldgenrate the load module that defines the default queue manager and add thatlibrary to the application's STEPLIB. Dave Adam <[EMAI
Re: T-Rex distributed systems
Hi, Basically, you want to determine what LPAR (I think in terms of MVS!!!) the code is running on? Wow, I had to really scratch my head on this one - its been awhile. :) It took me a while to find my dinosaur suit; it was hiding in the back of the closet. A little tight, but it still fits. (I'm not sure if I should be happy or sad!!!) Warning: For non-mainframe people you can delete this message right now!! (Quick, look away because here comes some assembler code!!!) Here's how I would do it in assembler: * - - - - - - - - - - - - - - - - - - - - - - - - *Get then set system id * - - - - - - - - - - - - - - - - - - - - - - - - USING PSA,0 L R4,FLCCVT R4 -> CVT USING CVT,R4 . L R4,CVTSMCA R4 -> SMCA USING SMCABASE,R4. MVC SYSID,SMCASID get system id DROP R4 * * SYSIDDSCL4 For those modern mainframe people (if you can call us that!!!) who do C on the mainframe, here is a C code snippet: First the defines: /*---* * Pointer to the MVS PSA control block * *---*/ #define PSA_PTR ( 0 ) /*---* * Pointer to the MVS CVT control block * *---*/ #define CVT_PTR ( * (void * *) ( (char *) PSA_PTR + 16) ) /*---* * Pointer to the MVS SMCA control block * *---*/ #define SMCA_PTR ( * (char * *) ( (char *) CVT_PTR + 196) ) /*---* * Pointer to the SMF System Id * *---*/ #define SMF_SYSID_PTR ( (char *) SMCA_PTR + 16 ) /**/ /* Now copy it from the control block to our variable */ /**/ memcpy( SysId, SMF_SYSID_PTR, 4); Well, i hope that helped. Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting Dave Adam <[EMAIL PROTECTED]>: > I must not be explaining this right > > our production QMGR's are on another pair of ZOS images and are called > P001 and P002 > > our test machine has 2 cloned QMGR's that replicate production on a > different pair of ZOS images D001 and D002 > > our development brainstorming test QMGR's are on the same pair of test > machine QMGR's and they are called M001 and M002 > > SYSPlex Distributor will put the iteration on one of the pairs (M001 or > M002) > > the program has to determine on which ZOS image it is running to do the > MQCONN > > Dave Adam > Supervalu Home Office > Project Specialist > (952) 828-4736 > [EMAIL PROTECTED] > > A lone amateur built the Ark. > A large group of professionals built the Titanic > -- > > > > > > Rick Tsujimoto <[EMAIL PROTECTED]> > Sent by: MQSeries List <[EMAIL PROTECTED]> > 01/29/2004 02:15 PM > Please respond to MQSeries List > > > To: [EMAIL PROTECTED] > cc: > Subject:Re: T-Rex distributed systems > > > Dave, > > Two things: > 1. The apps should probably be getting the queue manager name form some > external source, e.g. file, table, etc. > 2. Test apps that attempt to connect to prod queue managers should > probably > be stopped by your security system, e.g. RACF, ACF2, ... > > > > > Dave Adam > <[EMAIL PROTECTED] To: [EMAIL PROTECTED] > ERVALU.COM> cc: > Sent by: Subject: Re: T-Rex > distributed systems > MQSeries List > <[EMAIL PROTECTED] > en.AC.AT> > > > 01/29/2004 02:51 > PM > Please respond > to MQSeries List > > > > > > > the issue is with the playground M00n QMGR's > > if they fail to identify the M, then they will be in the clones of > production > > Dave Adam > Supervalu Home Office > Project Specialist > (952) 828-4736 > [EMAIL PROTECTED] > > A lone amateur built the Ark. > A large group of professionals built the Titanic
Re: T-Rex distributed systems
Luckily on z/OS only batch jobs/applications need to establish the connections to the Queue Managers (in CICS it's done at the CICS region level) and hence the need to know the QMGR name. This as suggested earlier, can be driven by a Dataset / Loadmodule or DB2 table. The sites that I have worked in the past are either put their QMGR names in a DB2 table (DB2 subsystem switching is done at the JCL level anyway) or put in a QSAM file and every MQ program is supposed to read a file using a standard DD name that provides the QMGR name. When the code gets migrated through SCLM phases, it used to pick up the appropriate subsystem or QSAM qualifiers for the environment. Regarding security, it was controlled by RACF / ACF2. Because most of the sites I have worked, batch user-ids in production are different from other environments including stress testing. Rao Adiraju WebSphere MQ Specialist The National Bank of NZ Ltd. Tel: +64-4-494 4299 Fax: +64-4-802 8509 Mbl: +64-211-216-116 From: Dave Adam [mailto:[EMAIL PROTECTED] Sent: 30 January 2004 10:05 AMTo: [EMAIL PROTECTED]Subject: Re: T-Rex distributed systems I must not be explaining this right our production QMGR's are on another pair of ZOS images and are called P001 and P002 our test machine has 2 cloned QMGR's that replicate production on a different pair of ZOS images D001 and D002 our development brainstorming test QMGR's are on the same pair of test machine QMGR's and they are called M001 and M002 SYSPlex Distributor will put the iteration on one of the pairs (M001 or M002) the program has to determine on which ZOS image it is running to do the MQCONNDave AdamSupervalu Home OfficeProject Specialist(952) 828-4736[EMAIL PROTECTED]A lone amateur built the Ark. A large group of professionals built the Titanic-- Rick Tsujimoto <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 01/29/2004 02:15 PM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: T-Rex distributed systemsDave,Two things:1. The apps should probably be getting the queue manager name form someexternal source, e.g. file, table, etc.2. Test apps that attempt to connect to prod queue managers should probablybe stopped by your security system, e.g. RACF, ACF2, ... Dave Adam <[EMAIL PROTECTED] To: [EMAIL PROTECTED] ERVALU.COM> cc: Sent by: Subject: Re: T-Rex distributed systems MQSeries List <[EMAIL PROTECTED] en.AC.AT> 01/29/2004 02:51 PM Please respond to MQSeries Listthe issue is with the playground M00n QMGR'sif they fail to identify the M, then they will be in the clones ofproductionDave AdamSupervalu Home OfficeProject Specialist(952) 828-4736[EMAIL PROTECTED]A lone amateur built the Ark.A large group of professionals built the Titanic-- Rick Tsujimoto <[EMAIL PROTECTED]> To: Sent by: MQSeries List [EMAIL PROTECTED] <[EMAIL PROTECTED]> cc: Subject: Re: T-Rex distributed systems 01/29/2004 01:30 PM Please respond to MQSeries ListIf you simply want to connect to the default QMGR on each LPAR, you couldgenrate the load module that defines the default queue manager and add thatlibrary to the application's STEPLIB. Dave Adam <[EMAIL PROTECTED] To:[EMAIL PROTECTED] ERVALU.COM> cc: Sent by: Subject: Re: T-Rexdistributed systems MQSeries List <[EMAIL PROTECTED] en.AC.AT> 01/29/2004 02:19 PM Please respond to MQSeries Listhere would be a simplistic view of the 2 LPAR'sLPAR D001 D002QMGR's (1) D001 D002 (bothfull repositories for cluster TST1 )QMGR's(2) M001 M002 (bothfull repositories for cluster TST2 )the default QMGR is D00n on each ZOS imagethe low level qualifier is the "n" numericby
Re: T-Rex distributed systems
Dave,
A quick-and-dirty solution would be create a subprogram that the
application calls, which returns the LPAR name, or concocted QMGR name.
The subprogram could simply extract the SYSID from the OS control blocks.
If you want the code, let me know and I'll email it to you.
Dave Adam
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
ERVALU.COM> cc:
Sent by: Subject: Re: T-Rex distributed systems
MQSeries List
<[EMAIL PROTECTED]
en.AC.AT>
01/29/2004 04:04
PM
Please respond
to MQSeries List
I must not be explaining this right
our production QMGR's are on another pair of ZOS images and are called P001
and P002
our test machine has 2 cloned QMGR's that replicate production on a
different pair of ZOS images D001 and D002
our development brainstorming test QMGR's are on the same pair of test
machine QMGR's and they are called M001 and M002
SYSPlex Distributor will put the iteration on one of the pairs (M001 or
M002)
the program has to determine on which ZOS image it is running to do the
MQCONN
Dave Adam
Supervalu Home Office
Project Specialist
(952) 828-4736
[EMAIL PROTECTED]
A lone amateur built the Ark.
A large group of professionals built the Titanic
--
Rick Tsujimoto
<[EMAIL PROTECTED]> To:
Sent by: MQSeries List [EMAIL PROTECTED]
<[EMAIL PROTECTED]> cc:
Subject:Re:
T-Rex distributed systems
01/29/2004 02:15 PM
Please respond to MQSeries List
Dave,
Two things:
1. The apps should probably be getting the queue manager name form some
external source, e.g. file, table, etc.
2. Test apps that attempt to connect to prod queue managers should probably
be stopped by your security system, e.g. RACF, ACF2, ...
Dave Adam
<[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
ERVALU.COM> cc:
Sent by: Subject: Re: T-Rex
distributed systems
MQSeries List
<[EMAIL PROTECTED]
en.AC.AT>
01/29/2004 02:51
PM
Please respond
to MQSeries List
the issue is with the playground M00n QMGR's
if they fail to identify the M, then they will be in the clones of
production
Dave Adam
Supervalu Home Office
Project Specialist
(952) 828-4736
[EMAIL PROTECTED]
A lone amateur built the Ark.
A large group of professionals built the Titanic
--
Rick Tsujimoto
<[EMAIL PROTECTED]> To:
Sent by: MQSeries List [EMAIL PROTECTED]
<[EMAIL PROTECTED]> cc:
Subject:Re:
T-Rex distributed systems
01/29/2004 01:30 PM
Please respond to MQSeries List
If you simply want to connect to the default QMGR on each LPAR, you could
genrate the load module that defines the default queue manager and add that
library to the application's STEPLIB.
Dave Adam
<[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
ERVALU.COM> cc:
Sent by: Subject: Re: T-Rex
distributed systems
MQSeries List
<[EMAIL PROTECTED]
en.AC.AT>
01/29/2004 02:19
PM
Please respond
to MQSeries List
here would be a simplistic view of the 2 LPAR's
LPAR D001 D002
QMGR's (1) D001 D002(both
full repositories for cluster TST1 )
QMGR's(2) M001 M002 (both
full repositories for cluster TST2 )
the default QMGR is D00n on each ZOS image
the low level qualifier is the "n" numeric
by getting the sysname symbolic, all we have to do is overlay the 4th
character to get the MQCONN name
there are partial repositories under the full repositor
Re: T-Rex distributed systems
I must not be explaining this right our production QMGR's are on another pair of ZOS images and are called P001 and P002 our test machine has 2 cloned QMGR's that replicate production on a different pair of ZOS images D001 and D002 our development brainstorming test QMGR's are on the same pair of test machine QMGR's and they are called M001 and M002 SYSPlex Distributor will put the iteration on one of the pairs (M001 or M002) the program has to determine on which ZOS image it is running to do the MQCONN Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] A lone amateur built the Ark. A large group of professionals built the Titanic -- Rick Tsujimoto <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 01/29/2004 02:15 PM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: T-Rex distributed systems Dave, Two things: 1. The apps should probably be getting the queue manager name form some external source, e.g. file, table, etc. 2. Test apps that attempt to connect to prod queue managers should probably be stopped by your security system, e.g. RACF, ACF2, ... Dave Adam <[EMAIL PROTECTED] To: [EMAIL PROTECTED] ERVALU.COM> cc: Sent by: Subject: Re: T-Rex distributed systems MQSeries List <[EMAIL PROTECTED] en.AC.AT> 01/29/2004 02:51 PM Please respond to MQSeries List the issue is with the playground M00n QMGR's if they fail to identify the M, then they will be in the clones of production Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] A lone amateur built the Ark. A large group of professionals built the Titanic -- Rick Tsujimoto <[EMAIL PROTECTED]> To: Sent by: MQSeries List [EMAIL PROTECTED] <[EMAIL PROTECTED]> cc: Subject: Re: T-Rex distributed systems 01/29/2004 01:30 PM Please respond to MQSeries List If you simply want to connect to the default QMGR on each LPAR, you could genrate the load module that defines the default queue manager and add that library to the application's STEPLIB. Dave Adam <[EMAIL PROTECTED] To: [EMAIL PROTECTED] ERVALU.COM> cc: Sent by: Subject: Re: T-Rex distributed systems MQSeries List <[EMAIL PROTECTED] en.AC.AT> 01/29/2004 02:19 PM Please respond to MQSeries List here would be a simplistic view of the 2 LPAR's LPAR D001 D002 QMGR's (1) D001 D002 (both full repositories for cluster TST1 ) QMGR's(2) M001 M002 (both full repositories for cluster TST2 ) the default QMGR is D00n on each ZOS image the low level qualifier is the "n" numeric by getting the sysname symbolic, all we have to do is overlay the 4th character to get the MQCONN name there are partial repositories under the full repositories (that are not cloned) and they float between LPAR's this requires additional logic to resolve not sure if there is an easier way to attack this D00n QMGR's are clones of production M00n QMGR's are a playground for programmers Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] A lone amateur built the Ark. A large group of professionals built the Titanic -- Rick Tsujimoto <[EMAIL PROTECTED]> To: Sent by: MQSeries List [EMAIL PROTECTED] <[EMAIL PROTECTED]> cc: Subject: Re:
Re: T-Rex distributed systems
Dave,
Two things:
1. The apps should probably be getting the queue manager name form some
external source, e.g. file, table, etc.
2. Test apps that attempt to connect to prod queue managers should probably
be stopped by your security system, e.g. RACF, ACF2, ...
Dave Adam
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
ERVALU.COM> cc:
Sent by: Subject: Re: T-Rex distributed systems
MQSeries List
<[EMAIL PROTECTED]
en.AC.AT>
01/29/2004 02:51
PM
Please respond
to MQSeries List
the issue is with the playground M00n QMGR's
if they fail to identify the M, then they will be in the clones of
production
Dave Adam
Supervalu Home Office
Project Specialist
(952) 828-4736
[EMAIL PROTECTED]
A lone amateur built the Ark.
A large group of professionals built the Titanic
--
Rick Tsujimoto
<[EMAIL PROTECTED]> To:
Sent by: MQSeries List [EMAIL PROTECTED]
<[EMAIL PROTECTED]> cc:
Subject:Re:
T-Rex distributed systems
01/29/2004 01:30 PM
Please respond to MQSeries List
If you simply want to connect to the default QMGR on each LPAR, you could
genrate the load module that defines the default queue manager and add that
library to the application's STEPLIB.
Dave Adam
<[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
ERVALU.COM> cc:
Sent by: Subject: Re: T-Rex
distributed systems
MQSeries List
<[EMAIL PROTECTED]
en.AC.AT>
01/29/2004 02:19
PM
Please respond
to MQSeries List
here would be a simplistic view of the 2 LPAR's
LPAR D001 D002
QMGR's (1) D001 D002(both
full repositories for cluster TST1 )
QMGR's(2) M001 M002 (both
full repositories for cluster TST2 )
the default QMGR is D00n on each ZOS image
the low level qualifier is the "n" numeric
by getting the sysname symbolic, all we have to do is overlay the 4th
character to get the MQCONN name
there are partial repositories under the full repositories (that are not
cloned) and they float between LPAR's
this requires additional logic to resolve
not sure if there is an easier way to attack this
D00n QMGR's are clones of production
M00n QMGR's are a playground for programmers
Dave Adam
Supervalu Home Office
Project Specialist
(952) 828-4736
[EMAIL PROTECTED]
A lone amateur built the Ark.
A large group of professionals built the Titanic
--
Rick Tsujimoto
<[EMAIL PROTECTED]> To:
Sent by: MQSeries List [EMAIL PROTECTED]
<[EMAIL PROTECTED]> cc:
Subject:Re:
T-Rex distributed systems
01/29/2004 10:18 AM
Please respond to MQSeries List
Dave,
What exactly are you referring to when you mention "low level qualifier"?
Is (QMGR name) it the low level qualifier of a data set name? Could you
give an example of the naming convention you're using?
Dave Adam
<[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
ERVALU.COM> cc:
Sent by: Subject: T-Rex distributed
systems
MQSeries List
<[EMAIL PROTECTED]
en.AC.AT>
01/29/2004 09:46
AM
Please respond
to MQSeries List
I think the majority of the list'rs are not ZOS based but I have a simple
question about our big PC
when you have multiple cluster environments across multiple LPAR's and the
QMGR's are split up by naming conventions
is a simple check on the low level qualifier the easiest way to
programmatically do MQCONN's
especially wh
Re: T-Rex distributed systems
the issue is with the playground M00n QMGR's if they fail to identify the M, then they will be in the clones of production Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] A lone amateur built the Ark. A large group of professionals built the Titanic -- Rick Tsujimoto <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 01/29/2004 01:30 PM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: T-Rex distributed systems If you simply want to connect to the default QMGR on each LPAR, you could genrate the load module that defines the default queue manager and add that library to the application's STEPLIB. Dave Adam <[EMAIL PROTECTED] To: [EMAIL PROTECTED] ERVALU.COM> cc: Sent by: Subject: Re: T-Rex distributed systems MQSeries List <[EMAIL PROTECTED] en.AC.AT> 01/29/2004 02:19 PM Please respond to MQSeries List here would be a simplistic view of the 2 LPAR's LPAR D001 D002 QMGR's (1) D001 D002 (both full repositories for cluster TST1 ) QMGR's(2) M001 M002 (both full repositories for cluster TST2 ) the default QMGR is D00n on each ZOS image the low level qualifier is the "n" numeric by getting the sysname symbolic, all we have to do is overlay the 4th character to get the MQCONN name there are partial repositories under the full repositories (that are not cloned) and they float between LPAR's this requires additional logic to resolve not sure if there is an easier way to attack this D00n QMGR's are clones of production M00n QMGR's are a playground for programmers Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] A lone amateur built the Ark. A large group of professionals built the Titanic -- Rick Tsujimoto <[EMAIL PROTECTED]> To: Sent by: MQSeries List [EMAIL PROTECTED] <[EMAIL PROTECTED]> cc: Subject: Re: T-Rex distributed systems 01/29/2004 10:18 AM Please respond to MQSeries List Dave, What exactly are you referring to when you mention "low level qualifier"? Is (QMGR name) it the low level qualifier of a data set name? Could you give an example of the naming convention you're using? Dave Adam <[EMAIL PROTECTED] To: [EMAIL PROTECTED] ERVALU.COM> cc: Sent by: Subject: T-Rex distributed systems MQSeries List <[EMAIL PROTECTED] en.AC.AT> 01/29/2004 09:46 AM Please respond to MQSeries List I think the majority of the list'rs are not ZOS based but I have a simple question about our big PC when you have multiple cluster environments across multiple LPAR's and the QMGR's are split up by naming conventions is a simple check on the low level qualifier the easiest way to programmatically do MQCONN's especially when the default QMGR's cannot be resolved in system symbolics (this does work for the highest level QMGR) Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] A lone amateur built the Ark. A large group of professionals built the Titanic -- Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: T-Rex distributed systems
If you simply want to connect to the default QMGR on each LPAR, you could
genrate the load module that defines the default queue manager and add that
library to the application's STEPLIB.
Dave Adam
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
ERVALU.COM> cc:
Sent by: Subject: Re: T-Rex distributed systems
MQSeries List
<[EMAIL PROTECTED]
en.AC.AT>
01/29/2004 02:19
PM
Please respond
to MQSeries List
here would be a simplistic view of the 2 LPAR's
LPAR D001 D002
QMGR's (1) D001 D002(both
full repositories for cluster TST1 )
QMGR's(2) M001 M002 (both
full repositories for cluster TST2 )
the default QMGR is D00n on each ZOS image
the low level qualifier is the "n" numeric
by getting the sysname symbolic, all we have to do is overlay the 4th
character to get the MQCONN name
there are partial repositories under the full repositories (that are not
cloned) and they float between LPAR's
this requires additional logic to resolve
not sure if there is an easier way to attack this
D00n QMGR's are clones of production
M00n QMGR's are a playground for programmers
Dave Adam
Supervalu Home Office
Project Specialist
(952) 828-4736
[EMAIL PROTECTED]
A lone amateur built the Ark.
A large group of professionals built the Titanic
--
Rick Tsujimoto
<[EMAIL PROTECTED]> To:
Sent by: MQSeries List [EMAIL PROTECTED]
<[EMAIL PROTECTED]> cc:
Subject: Re:
T-Rex distributed systems
01/29/2004 10:18 AM
Please respond to MQSeries List
Dave,
What exactly are you referring to when you mention "low level qualifier"?
Is (QMGR name) it the low level qualifier of a data set name? Could you
give an example of the naming convention you're using?
Dave Adam
<[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
ERVALU.COM> cc:
Sent by: Subject: T-Rex distributed
systems
MQSeries List
<[EMAIL PROTECTED]
en.AC.AT>
01/29/2004 09:46
AM
Please respond
to MQSeries List
I think the majority of the list'rs are not ZOS based but I have a simple
question about our big PC
when you have multiple cluster environments across multiple LPAR's and the
QMGR's are split up by naming conventions
is a simple check on the low level qualifier the easiest way to
programmatically do MQCONN's
especially when the default QMGR's cannot be resolved in system symbolics
(this does work for the highest level QMGR)
Dave Adam
Supervalu Home Office
Project Specialist
(952) 828-4736
[EMAIL PROTECTED]
A lone amateur built the Ark.
A large group of professionals built the Titanic
--
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: T-Rex distributed systems
here would be a simplistic view of the 2 LPAR's LPAR D001 D002 QMGR's (1) D001 D002 (both full repositories for cluster TST1 ) QMGR's(2) M001 M002 (both full repositories for cluster TST2 ) the default QMGR is D00n on each ZOS image the low level qualifier is the "n" numeric by getting the sysname symbolic, all we have to do is overlay the 4th character to get the MQCONN name there are partial repositories under the full repositories (that are not cloned) and they float between LPAR's this requires additional logic to resolve not sure if there is an easier way to attack this D00n QMGR's are clones of production M00n QMGR's are a playground for programmers Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] A lone amateur built the Ark. A large group of professionals built the Titanic -- Rick Tsujimoto <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 01/29/2004 10:18 AM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: T-Rex distributed systems Dave, What exactly are you referring to when you mention "low level qualifier"? Is (QMGR name) it the low level qualifier of a data set name? Could you give an example of the naming convention you're using? Dave Adam <[EMAIL PROTECTED] To: [EMAIL PROTECTED] ERVALU.COM> cc: Sent by: Subject: T-Rex distributed systems MQSeries List <[EMAIL PROTECTED] en.AC.AT> 01/29/2004 09:46 AM Please respond to MQSeries List I think the majority of the list'rs are not ZOS based but I have a simple question about our big PC when you have multiple cluster environments across multiple LPAR's and the QMGR's are split up by naming conventions is a simple check on the low level qualifier the easiest way to programmatically do MQCONN's especially when the default QMGR's cannot be resolved in system symbolics (this does work for the highest level QMGR) Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] A lone amateur built the Ark. A large group of professionals built the Titanic -- Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: T-Rex distributed systems
Dave, What exactly are you referring to when you mention "low level qualifier"? Is (QMGR name) it the low level qualifier of a data set name? Could you give an example of the naming convention you're using? Dave Adam <[EMAIL PROTECTED] To: [EMAIL PROTECTED] ERVALU.COM> cc: Sent by: Subject: T-Rex distributed systems MQSeries List <[EMAIL PROTECTED] en.AC.AT> 01/29/2004 09:46 AM Please respond to MQSeries List I think the majority of the list'rs are not ZOS based but I have a simple question about our big PC when you have multiple cluster environments across multiple LPAR's and the QMGR's are split up by naming conventions is a simple check on the low level qualifier the easiest way to programmatically do MQCONN's especially when the default QMGR's cannot be resolved in system symbolics (this does work for the highest level QMGR) Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] A lone amateur built the Ark. A large group of professionals built the Titanic -- 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
