that's perfect
Dave Adam
Supervalu Home Office
Project Specialist
(952) 828-4736
[EMAIL PROTECTED]
A lone amateur built the Ark.
A large group of professionals built the Titanic
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Roger Lacroix <[EMAIL PROTECTED]>
01/29/2004 04:29 PM
|
To: MQSeries List <[EMAIL PROTECTED]> cc: [EMAIL PROTECTED] Subject: Re: T-Rex distributed systems |
Hi,
Basically, you want to determine what LPAR (I think in terms of MVS!!!) the
code is running on?
Wow, I had to really scratch my head on this one - its been awhile. :)
It took me a while to find my dinosaur suit; it was hiding in the back of the
closet. A little tight, but it still fits. (I'm not sure if I should be happy
or sad!!!)
Warning: For non-mainframe people you can delete this message right now!!
(Quick, look away because here comes some assembler code!!!)
Here's how I would do it in assembler:
* - - - - - - - - - - - - - - - - - - - - - - - -
* Get then set system id
* - - - - - - - - - - - - - - - - - - - - - - - -
USING PSA,0
L R4,FLCCVT R4 -> CVT
USING CVT,R4 .
L R4,CVTSMCA R4 -> SMCA
USING SMCABASE,R4 .
MVC SYSID,SMCASID get system id
DROP R4
*
*
SYSID DS CL4
For those modern mainframe people (if you can call us that!!!) who do C on the
mainframe, here is a C code snippet:
First the defines:
/*-----------------------------------------------------------*
* Pointer to the MVS PSA control block *
*-----------------------------------------------------------*/
#define PSA_PTR ( 0 )
/*-----------------------------------------------------------*
* Pointer to the MVS CVT control block *
*-----------------------------------------------------------*/
#define CVT_PTR ( * (void * *) ( (char *) PSA_PTR + 16) )
/*-----------------------------------------------------------*
* Pointer to the MVS SMCA control block *
*-----------------------------------------------------------*/
#define SMCA_PTR ( * (char * *) ( (char *) CVT_PTR + 196) )
/*-----------------------------------------------------------*
* Pointer to the SMF System Id *
*-----------------------------------------------------------*/
#define SMF_SYSID_PTR ( (char *) SMCA_PTR + 16 )
/******************************************************/
/* Now copy it from the control block to our variable */
/******************************************************/
memcpy( SysId, SMF_SYSID_PTR, 4);
Well, i hope that helped.
Regards,
Roger Lacroix
Capitalware Inc.
http://www.capitalware.biz
Quoting Dave Adam <[EMAIL PROTECTED]>:
> I must not be explaining this right
>
> our production QMGR's are on another pair of ZOS images and are called
> P001 and P002
>
> our test machine has 2 cloned QMGR's that replicate production on a
> different pair of ZOS images D001 and D002
>
> our development brainstorming test QMGR's are on the same pair of test
> machine QMGR's and they are called M001 and M002
>
> SYSPlex Distributor will put the iteration on one of the pairs (M001 or
> M002)
>
> the program has to determine on which ZOS image it is running to do the
> MQCONN
>
> Dave Adam
> Supervalu Home Office
> Project Specialist
> (952) 828-4736
> [EMAIL PROTECTED]
>
> A lone amateur built the Ark.
> A large group of professionals built the Titanic
> ------------------------------------------------------------------------------
--------------------------------------------------------------------------------
------------
>
>
>
>
>
> Rick Tsujimoto <[EMAIL PROTECTED]>
> Sent by: MQSeries List <[EMAIL PROTECTED]>
> 01/29/2004 02:15 PM
> Please respond to MQSeries List
>
>
> To: [EMAIL PROTECTED]
> cc:
> Subject: Re: T-Rex distributed systems
>
>
> Dave,
>
> Two things:
> 1. The apps should probably be getting 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 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
>
> 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
>
>
>