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
>
>
>



Reply via email to